¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: Command to set maximum fundamental SI5351 frequency implemented

 

@Larry
Can you try the edy555 0.2.3 release and see if that also locks up on capture?


Re: Are there any firmware releases supporting calibration kits?

 

Can someone specify how these should be added to the calibration correction calculation?

This is the current code where "measured" is the raw data that gets corrected

void apply_error_term_at(int i)
{
// S11m' = S11m - Ed
// S11a = S11m' / (Er + Es S11m')
float s11mr = measured[0][i][0] - cal_data[ETERM_ED][i][0];
float s11mi = measured[0][i][1] - cal_data[ETERM_ED][i][1];
float err = cal_data[ETERM_ER][i][0] + s11mr * cal_data[ETERM_ES][i][0] - s11mi * cal_data[ETERM_ES][i][1];
float eri = cal_data[ETERM_ER][i][1] + s11mr * cal_data[ETERM_ES][i][1] + s11mi * cal_data[ETERM_ES][i][0];
float sq = err*err + eri*eri;
float s11ar = (s11mr * err + s11mi * eri) / sq;
float s11ai = (s11mi * err - s11mr * eri) / sq;
measured[0][i][0] = s11ar;
measured[0][i][1] = s11ai;

// CAUTION: Et is inverted for efficiency
// S21m' = S21m - Ex
// S21a = S21m' (1-EsS11a)Et
float s21mr = measured[1][i][0] - cal_data[ETERM_EX][i][0];
float s21mi = measured[1][i][1] - cal_data[ETERM_EX][i][1];
float esr = 1 - (cal_data[ETERM_ES][i][0] * s11ar - cal_data[ETERM_ES][i][1] * s11ai);
float esi = - (cal_data[ETERM_ES][i][1] * s11ar + cal_data[ETERM_ES][i][0] * s11ai);
float etr = esr * cal_data[ETERM_ET][i][0] - esi * cal_data[ETERM_ET][i][1];
float eti = esr * cal_data[ETERM_ET][i][1] + esi * cal_data[ETERM_ET][i][0];
float s21ar = s21mr * etr - s21mi * eti;
float s21ai = s21mi * etr + s21mr * eti;
measured[1][i][0] = s21ar;
measured[1][i][1] = s21ai;
}

Adding setting the three parameters
* offset delay of the open
* offset delay of the short.
* C0 of the open
and saving them as part of a config or calibration dataset I know how to do


Re: Latest edy555 firmware release with dfu file

 

Seems to work well.

One small request - Could the velocity factor that has been used please be added to the TDR marker text, or displayed in some other way, so that it's more obvious if you have used the wrong value for the type of cable being measured.

Regards,

Martin - G8JNJ


Latest edy555 firmware release with dfu file

 

Hot off the presses, folks:

Version 0.2.3

edy555 released this 1 hour ago

-change toggle behavior of trace menu and marker menu
-add transform command to change mode of TDR
- add threadshold command
-remove cal glitch between different harmonic modes
-NanoVNA-saver in multisegment mode shall work well

** Needs touch calibration and save it after flashing firmware.



Regards,
Larry


File updated in [email protected]

[email protected] Notification
 

Hello,

This email message is a notification to let you know that the following files have been updated in the Files area of the [email protected] group.

Uploaded By: Larry Rothman <nlroth@...>

Description:
This is the latest update of the Console Commands for the NanoVNA as of Oct 7th. It replaces the previous version (Oct-4-19). Please let me know of any errors or omissions.

Cheers,
The Groups.io Team


Are there any firmware releases supporting calibration kits?

Dr. David Kirkby from Kirkby Microwave Ltd
 

Are there any *firmware* releases that have support for *proper*
calibration kits? By that I minimum of

* offset delay of the open
* offset delay of the short.
* C0 of the open

More parameters would be useful, especially of lower quality kits, but the
above would be a start

Dave
--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom


Re: Annotated nanoVNA menu diagram

 

Hi W5DXP (and others) -

Help for use of FORMAT options is wanted.
I know a little about LOGMAG, PHASE, SMITH, but:
* when to use others?
* what other settings interact?


Re: Inductor S21 measurement using nanoVNA

 

On Mon, Oct 7, 2019 at 04:03 AM, Kurt Poulsen wrote:
Kurt,

Thanks for your more detailed explanation. I think I understand the "trick" you are suggesting more thoroughly. It certainly makes a difference if you want to more precisely characterize the 13 micro-Henry inductor at higher frequencies like 30 MHz to 100 MHz.

--
Bryan, WA5VAH

Hi Bryan
Thank you for your comment. I see you have not fully under my trick, so I will
take some small steps to explain what is going on.
Consider we have calibrated at the female SMA calibration plane at the end of
the female female adaptor which we do using the supplied male calibration kit
and we then add a male to female adaptor and we place a component e.g. a coil
on the far end of this added adaptor, one way or the other. The added male to
female adaptor constitutes a shunt capacitor to the coil by the delay in ps in
this adaptor multiplied by 20fF as 1ps=20fF. For such an adaptor the delay is
about 50ps so we have 100fF or 1 pF shunted to the coil and that gives a
resonance frequency of 150MHz, if the coil has no self capacitance, which Is
has. Bottom line, this 1pF changes the self resonance downwards in frequency.
The way the inductance changes you need to do some calculation, but at least
you know that the effective inductance will change and drop when we approach
towards resonance as the capacitance "steals" some inductance.
In the real life we would like to use a female SMA bulkhead/PCB edge adaptor,
for soldering the coil (in this example) to the far end, so we need after the
calibration to remove the female female adaptor, which has a delay of 82ps,
so now our calibration plane is sitting somewhere out in the blue air. It is
actually 17mm from the male calibration plane, to which we fit the
bulkhead/pcb edge adaptor, because the velocity in the female female adaptor
is 1 mm per 4.83ps and 82/4.83 is giving 17mm without decimal. So what to do
??
That is exactly what the display/scale/Electrical Delay can fix, as it simply
pulls the calibration plane backwards and 100ps is just a nice number which
pull the calibration plane 18ps into the test cable allowing to add up to
100ps again. As when we then add the bulkhead/PCB edge adaptor we the must
move the calibration plane forward again to the rearside of the added adaptor,
and a phase trace it the tool to use, as when it show 0 degree out
measurement plane is equal to the shifted calibration plane. Thus there is
nothing shunting the test object e.g. your coil. There is only a very minor
snag as such, because if you used a bulkhead/pcb edge adaptor shorted with a
cupper disk, then the delay shall be adjusted by a few ps (now with 180 degree
as reference and a hopeless case for th NanoVNA as wobbling up and down
between + and - 180 degree )because we have actually removed the fringe C from
the center pin being maybe 100fF, but a benefit as we the cane measure
capacitances down to a fraction of a pF. Measuring Q requires that if we use a
shorted bulkhead/pcb edge adaptor to check the resistance is 0 ohm or few
mohm, and that can be this moving backward/forward does not fully satisfy this
requirement, as the electrical delay take for granted the impedance of the
adaptor/test cable is pure 50 ohm.
I hope this get you on level with this trick
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af bryburns
via Groups.Io
Sendt: 7. oktober 2019 03:49
Til: [email protected]
Emne: Re: [nanovna-users] Inductor S21 measurement using nanoVNA

Kurt,

Good points for more precise calibration. It would certainly be more precise
than my suggestion. I certainly agree with you that it is a good idea to
calibrate as close to the measurement plane as possible.

My basic question is fairly simple. How much change will your approach make
to the measurement of a 13 micro-Henry inductor? At 1 MHz a 13 uH inductor
has a reactance of 2*pi*13 ohms which is about 82 ohms. At 10 MHz the
reactance is about 820 ohms. As an example, how much impact does 100
pico-seconds have at 1 MHz or even 10 MHz. It seems a 100-pico-second delay
error would be a pretty small phase change at 1 MHz or even 10 MHz. Perhaps
I don't understand your procedure completely.

--
Bryan, WA5VAH




Re: Command to set maximum fundamental SI5351 frequency implemented

 

Erik,
Your release 0.2.2_1 may have a bug with the 'capture' console command - device locks-up when I try to use capture.
Regards,
Larry

On Saturday, October 5, 2019, 4:01:44 p.m. GMT-4, <erik@...> wrote:

Edy555 has implemented in his GitHub nanoVNA repository a command to set the threshold for switching to harmonics mode
Command
threshold {Frequency in Hz}
The default is 300MHz.
After changing you can use the save configuration command to permanently store the new value
This greatly simplifies testing if your SI5351 has difficult reaching 300MHz and if so, provides a easy workaround
I can not test now. Maybe tomorrow


Re: errors of "error" models

 

Good afternoon nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi;

As I stated in an earlier post, our communications get somewhat contaminated in translation. Please understand that you have my unreserved agreement on your definition. My use of quotation marks encompassing any... i.e. ¡°any¡± VNA was intended to communicate that I am not all knowing with respect to the architectural differences employed by various equipment manufacturers. In the context of our discussions, I also believe that the hardware choice is not relevant, and that it is your desire to focus on the software independent of the hardware choice in the evaluation of the derived measurement uncertainties. My overtly verbose description was an attempt to separate the hardware from the software, to ensure my understanding of the point that the hardware employed for the measurements is irrelevant.

I have not yet read your response in its entirety. I sensed a priority to put your mind at ease, and respond immediately in that regard. I will comment on anything I feel unclear about your response after giving it my undivided attention.

73

Gary, N3GO






agreement

--
73

Gary, N3GO


Re: Upgrade Firmware

 

I have been unable to upgrade the firmware on my NanoVNA on Windows. Every approach I try ends up with the DFU tool claiming that the file I'm trying to program is the wrong format. I pointed to several different .dfu files, and also tried to use the DFU file manager to read the file, with the same error. I got the same issue on two different Windows laptops, both running Windows 10. Maybe there is a driver step I'm overlooking, or that is assumed in the instructions?

However, I was able to program my NanoVNA on the first try on my Mac, using the same .dfu files.

Ralph


Re: Annotated nanoVNA menu diagram

 

Hi W5DXP:

How about this?
I notice that your PNG lacks recent TRANSFORM update.

Tricky CSS in
automagically draws menu tree leaves, branches and twigs
by redefining relatively simple HTML (<dl><dt><dt>, <ul><li>, <p> <tt>)
that reflects menu structure and which markup is relatively easy
to revise and supplement with tool tips and links.

I lack wit or ambition to invent CSS that dynamically optimizes path generation.
I reject JavaScript, based on traumatic stress as Unix system administrator
when enterprise IT released pathological proxy.pac.

I lost sleep last night, pondering Stan's suggestion for CSS changes
which may result in overall cleaner (if not smaller) diagrams.

I still think it better to first complete
adding more help links and tool tips for recent firmware extensions.


Re: Upgrade Firmware

 

Thanks, just need to find the DFU programming software now.


Re: Annotated nanoVNA menu diagram

W5DXP
 

Oristo wrote: I could move that block closer to the left edge, though.
How about this?


Re: Upgrade Firmware

 

Please remember that with rapid S/W development, there will always be some kind of niggling issues somewhere in the code.
To be safe, you can stick with releases from either edy555 or hugen.
Erik also has some cutting edge releases that are based on the 2 sources above.
Check out the firmware folder in FILES. edy555 is at 0.2.2 and erik has just released 0.2.2_1The last Oct 2 release from hugen had some issues.
Read the Oct 2 userguide for flashing instructions - EVERYTHING you need is in the WIKI or FILES sections.
Now play!

On Monday, October 7, 2019, 8:49:27 a.m. GMT-4, Leith Cullen <leithacullen@...> wrote:

When I heard there was the ability to extent the range to 2.5 GHz, I got over exited.? Because I'm not forking out $800 bucks for a Analyzer.? So which build do you recommend?


Re: Upgrade Firmware

 

When I heard there was the ability to extent the range to 2.5 GHz, I got over exited. Because I'm not forking out $800 bucks for a Analyzer. So which build do you recommend?


Re: Upgrade Firmware

 

How would I go about upgrading the firmware safely?
IMO, most danger comes from potential static discharge
when jumpering DFU contacts.
Firmware bugs may leave nanoVNA in hung state at power on,
so forcing hardware DFU is an ongoing requirement.
I and others added a switch, e.g.

There are several DFU articles linked in Wiki and Files, e.g.


Re: Upgrade Firmware

 

Please DO NOT use that firmware - it was purely experimental and was indicated as such when Erik talked about it.There will be no support if you have any issues.
However, it you DO want to play with it,?/g/nanovna-users/files/Firmware/NanoVNA%20firmware%20build%20by%20Erik

On Monday, October 7, 2019, 7:48:20 a.m. GMT-4, Leith Cullen <leithacullen@...> wrote:

Sorry for the stupid question.? But a recently saw a firmware update with
the ability to go up to 2.5GHz freq.? But I can't seem to find a solid wait
to upgrade on windows.

How would I go about upgrading the firmware safely?

73


Re: Annotated nanoVNA menu diagram

 

help is updated for new firmware functions
TRANSFORM submenu


Re: errors of "error" models

 

37 : The [LeastVNA]

@Gary O'Neil - 6 October 2019 : /g/nanovna-users/message/4194

35 : Straight In The Heart of The Matter - 6 October 2019
/g/nanovna-users/message/4184

-

Dear Gary,

Swell !

We already wrote a detailed draft, as a reply to your
interesting message above, of equal if not more length than that
and we will send it sometime later.

However, we have to interpreter your lengthy message as a kind
of manifestation of hesitation by you - not at all an
unjustifiable one ! - to accept our [AnyVNA] description, that
is of what you already called it "any" VNA, which signifies a
lack of consensus from your side to accept unreservedly that:

"Primarily, [AnyVNA] measures ( Amplitude Ratio , Phase
Difference ) couples in terms of Frequency"

because, according to you:

"More precisely, any VNA measures amplitude vs. frequency, and
either measures or computes phase in accordance with the
architecture of its design"

in which you drop the [Ratio] and [Difference] terms and
exclusively or-ed the measurement with computation, that is
- in our humble opinion - you reduce the Vector Network Analyzer
to a Scalar one, and most importantly, you cancel your attempt
to separate "hw" from "sw" and/or "fw".

After that, because our point of view stays constantly as a
facupov one, that is : From A common User's Point Of View, and
because we trust you, we accept your reservations regarding the
phase in the different ways of "any VNA" realization, and while
we are waiting your full explanations on why your modifications
increase the precision of your "any VNA" description, we
decrease right now our expectations from [AnyVNA] to [LeastVNA],
but we greatly increase its description by giving even more
details as follows - always facupov:

The [LeastVNA] :

(a) has at least one port realized by an external connector
with two sides : an internal and an external ones,

(b) uses an either internal or external device plus internal
circuitry in order to separate two cosinusoidal waves of the
same frequency coexisting at least into its port and beyond
that internally : an Input to- and Output from- the port,
caused by one-or-two coexisting signals at the external side
of its connector,

(c) measures in a range of frequencies "whatever needed" to
form a couple of two dimensionless quantities :

( Amplitude Ratio , Phase Difference )

between two cosinusoidal signals of the same frequency
resulting from- and analogous to- these two Input and Output
waves, respectively, as the first and second operands in these
formed division and subtraction operations,

(d) indicates these two quantities to its user,

(f) provides the user with a conceptual "error" model, that
is with a set of a rather small number of rather simple
algebraic equations, connecting the measurement of any load
with unknown or "known" nominal value Gamma with its indicated
value gamma,

using intermediately three 3 parameters "S", obviously
determinable by measuring three 3 "standard" loads of "known"
nominal value, with obviously the same indications in this
range of frequencies, independently of any other load of
unknown nominal value,

that is, after 4 = 3 + 1 measurements in total,

BUT :

(g) does not provide its user with the means to complete his
measurements because it ignores the uncertainty of these
three 3 "standards" and the inaccuracy of these 8 = 4 x 2
indications.

And we are basing our today description on that 51 years
old simplification - perhaps in the first ever publicly known
related paper - that is:

"is simply a microwave frequency vector ratio voltmeter",

given by Richard H. Hackborn at 'An Automatic Network
Analyzer System', Microwave Journal, May 1968, p.46.

However, yes, indeed. Our research has to do with an investigation
of the possibility of founding a seeing facupov of [AnyVNA] through
[LeastVNA] from now on, or equivalently, after your apt comments,
to see it conceptually. Therefore, we think that we have your
unreserved consensus to this sharable point and thus we put this
Very Cause into our small objective world, that is into our "sow"
from now on.

Please, stay tuned !

Kind regards,

73

nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi

37