¿ªÔÆÌåÓý

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

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


Upgrade Firmware

 

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: info update

 

On Sun, 6 Oct 2019 at 21:30, <in3elx@...> wrote:

Now I am forced to save only 2 memories:
0) 1Mhz-900Mhz; track 1: SWR CH1; track 2: Smith CH1
1) "empty"
2) "empty"
3) "empty"
4) 1Mhz-900Mhz; track 1: LOG CH1; track 2: LOG CH2

Why?
Ciao Roberto,
I wish I had the time to look at the code but my 'real' job keeps me
very busy. :-(

The developer of the firmware you are using might be reading this
group... or might not.
It's good to ask here first, because someone else might have already
seen the bug, or maybe has a way to work around it.

If no one here has any thoughts to share, then the best idea is to
report the bug to the developer on Github.
For edy555, you can go to and
click on the 'Issues' link near the top.

Thanks for helping to make the NanoVNA project better!
73 de Buck, KC2HIZ
--buck


Re: Inductor S21 measurement using nanoVNA

 

Hi aa_talaat,

Your smith plot, using linear sample points, is similar to expected results using a Simsmith model. First straight line caused by very wide sample points.
SimSmith model is shown in:

Second SimSmith model in above link is performed with Log sample points to fill in low frequency range.
Ferrite material loss for this device, represented as parallel resistance, Rp, is 600 to 700 Ohms at high frequencies. Near constant parallel loss results with near constant S21 loss at high frequencies, as shown in your measured S21 trace.

John KN5L


Re: info update

 

On Sun, Oct 6, 2019 at 9:30 PM <in3elx@...> wrote:
I have a problem with all types of firmware (NanoVNA-edy555, NanoVNA-H):
If you execute and save more than two calibrations,
the others ... show always SWR 1:1, even with the SMA connector open (CH0)!

Usually memories (calibrated) that I saved are this:
0) 1Mhz-900Mhz; track 1: SWR CH1; track 2: Smith CH1
1) 1Mhz-30Mhz; track 1: SWR CH1; track 2: Smith CH1
2) 30Mhz-100Mhz; track 1: SWR CH1; track 2: Smith CH1
3) 80Mhz-500Mhz; track 1: SWR CH1; track 2: Smith CH1
4) 1Mhz-900Mhz; track 1: LOG CH1; track 2: LOG CH2

Note: before any upgrade I used the file for cleaning "DMR-CLEAR_MEMORY_DFU.dfu " (131 kB; Sep 30).
FWIW, I don't think DMR-CLEAR_MEMORY_DFU.dfu helps
unless some desired firmware otherwise fails to load.

Now I am forced to save only 2 memories:
0) 1Mhz-900Mhz; track 1: SWR CH1; track 2: Smith CH1
1) "empty"
2) "empty"
3) "empty"
4) 1Mhz-900Mhz; track 1: LOG CH1; track 2: LOG CH2

Why?
My >> guess<< is that
this may be another consequence
from overlap of code and data flash segments.

Developers traditionally like to add new features but dislike testing.
Ideally, code functions and issue resolutions should require
automated unit regression tests, which can be hard for GUI.

I guess this currently happens especially with recent edy555 releases,
which may be more focused on PC software programmer requests:


..than on-device usability.

NanoVNA-H lists fewer issues:


Your issue could be added, if repeatable...

FWIW, I see no issues recalling 4 different calibrations
saved with NanoVNA-H__900_ch_20191003.dfu
from


Re: Inductor S21 measurement using nanoVNA

 

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: Inductor S21 measurement using nanoVNA

 

On Sun, Oct 6, 2019 at 09:03 PM, Kurt Poulsen wrote:

I have a suggestion which work with good precision up to 100Mhz
Link added to /g/nanovna-users/wiki/Application-Notes


Re: Determining SOLT kit errors via basis pursuit

 

If you are modelling the terminal SOLT elements correctly you should have the same number of equations as elements. The correct calibration procedure should therefore be extended to beyond, 12, 16 or even 32 point calibration techniques. The use of linear programming or least squares estimation techniques are for the case of fewer equations than the number of elements. It will introduce errors in an unknown and perhaps uncontrolled manner.


Re: NanoVNA-Saver 0.0.12

 

Hi David,
I will try sending you an experimental version at some point, and if it
works, I could include that code in the future releases. Whether it keeps
working is a different matter altogether.

Rune
================================

Many thanks, Rune.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv


Re: Cal-Kit Standards' Definitions

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Sun, 6 Oct 2019 at 19:26, Oristo <ormpoa@...> wrote:

If the NanoVNA could provide a negative Electrical delay it could be
fixed.

IMHO, we really need a way of *properly* defining a calibration kit in
*firmware*. That means as a minimum a delay, (which can be negative), and
at least fixed capacitance C0 to support *professional* cal kits.

To support poorer kits C0, C1, C2, C3, L0, L1, L2, loss terms and
impedance.

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: NanoVNA-Saver 0.0.12

 

Hi David,
I will try sending you an experimental version at some point, and if it
works, I could include that code in the future releases. Whether it keeps
working is a different matter altogether.

--
Rune

On Mon, 7 Oct 2019 at 08:26, David J Taylor via Groups.Io <gm8arv=
[email protected]> wrote:

The only discrepancy - which is fatal to the software working - that I have
seen thus far, is that the developers have changed the prompt line, which I
use to detect when output from the device has finished. Being able to
detect either prompt might make it work, or there might be other
differences. I don't have a way to test this at this time.

edy555's firmware has recently received a number of updates the use of
which is limited to newer firmwares, but which are pretty much required to
have both fast and stable PC control of the NanoVNA. I'm looking at
implementing support for these in the next version, or the one after, of
NanoVNA-Saver.

I'm all in favour of trying to support the variety of devices and firmwares
that are appearing, but the software is primarily going to be tested
against the hardware I have - a NanoVNA-H running edy555's 0.2.2 firmware
at the moment.

Rune / 5Q5R
======================================

Rune,

I have both the nanoVNA and the nanoVNA-F, and I would be happy to test
any
updates you may bring.

On another PC I do have Python installed (2.7, but could update) so
perhaps
I could help with (some elements of) the source too? I don't know whether
that PC has the right drivers, though.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv





Re: Another modified nanoVNA software

 
Edited

On Mon, Oct 7, 2019 at 04:02 AM, <neb40gsm@...> wrote:


In reference to Alex_M modified version, nanoVNAv1.03TDRb4 doesn't use Python
anymore to measure TDR cable length.
I will be glad to see remark in the about window that TDR code in C# was developed by alex_m :)

You can also add window type selection option. In most case Blackman window provides best result for TDR, but sometimes Rectangle and Triangle window also useful. I didn't added it just because don't have time to work on UI interface.

It's already here, just select window type depends on user selection:

public static complex[] TDR(complex[] vector, WindowType window = WindowType.Blackman)
{
var size = DSP.GetPOT(vector.Length);
size = Math.Max(size, 16384);
vector = vector.ToArray();
if (window != WindowType.Rectangular)
{
DSP.ApplyWindow(vector, window);
}
var ifft = DSP.ZeroPadded(vector, size);
ifft = DSP.IFFT(ifft);
// padding attenuation compensation
DSP.Scale(ifft, (double)size / ((double)vector.Length));
return ifft;
}


Re: NanoVNA-Saver 0.0.12

 

The only discrepancy - which is fatal to the software working - that I have
seen thus far, is that the developers have changed the prompt line, which I
use to detect when output from the device has finished. Being able to
detect either prompt might make it work, or there might be other
differences. I don't have a way to test this at this time.

edy555's firmware has recently received a number of updates the use of
which is limited to newer firmwares, but which are pretty much required to
have both fast and stable PC control of the NanoVNA. I'm looking at
implementing support for these in the next version, or the one after, of
NanoVNA-Saver.

I'm all in favour of trying to support the variety of devices and firmwares
that are appearing, but the software is primarily going to be tested
against the hardware I have - a NanoVNA-H running edy555's 0.2.2 firmware
at the moment.

Rune / 5Q5R
======================================

Rune,

I have both the nanoVNA and the nanoVNA-F, and I would be happy to test any updates you may bring.

On another PC I do have Python installed (2.7, but could update) so perhaps I could help with (some elements of) the source too? I don't know whether that PC has the right drivers, though.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv


Re: 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: Inductor S21 measurement using nanoVNA

 

Hi Bryan
You are forgetting that the female female adaptor has a delay which when removed shift the measurement plane away form the calibration plane.
I have a suggestion which work with good precision up to 100Mhz or even higher pending the expectations and what is mentioned under Note!!.
The proposal is the following:
1. Enable a phase trace with 1degree/division at reference point 5.
2. Enable a Display/Scale/Electrical Delay of 100ps.
3. Set the frequency range of interest e.g. 50KHz to 100MHz
4. Calibrate at the end of the test cable with the male calibration kit fitted to the female female adaptor and do not use the open adaptor from the kit, just leave the female female adaptor unterminated during open calibration. Save calibration to either 1 to 4.
5. Observe after the calibration that the phase trace is slanting slightly downwards with a phase of about 0.15dgree at 100MHz
6. Remove the female female adaptor and observe the phase trace raises upwards quite considerable as we removed the phaseshift for the female female adaptor.
7. mount the bulkhead/pcb edge adaptor to the test cable and now trim the Display/Scale/Electrical delay until the phase trace is horizontal with 0 degree all over the frequency range.
8. Now the measurement plane is to the rear of the bulhead/PCB edge adaptor without any parasitic component and accurate measurements possible.
9. Remember to remove the Display/Scale/electrical delay afterwards
Note !! The condition for getting the phase trace adjusted to 0 degree is the bulkhead/pcb edge adaptor must have a shorter delay than the female female adaptor. If not increase the 100 ps delay.
I recommend to use a better SMA testcable than the one supplied and if you have another Female Female aadaptor use it as the one supplied have excessive loss
Kind regards
Kurt
-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af bryburns via Groups.Io
Sendt: 6. oktober 2019 23:13
Til: [email protected]
Emne: Re: [nanovna-users] Inductor S21 measurement using nanoVNA

Hi, aa_talaat,

Here is a suggestion.

I would recommend that you connect the inductor from the center conductor of port 0 to the ground of port 0 with the shortest possible wires. If you could, I would recommend soldering it across an SMA female connector that directly connects to the location where you did the Open, Short, and Load calibration for S11. In your most recent pictures, with short cables, that would mean you use an SMA femaile connector and solder the part to the back of the SMA connector where you would normally mount it to the circuit board. As long as you connect to the same point as you did the open, short, and load calibration, the measurements should be pretty good. You can then measure the inductor directly by observing the S11 information.

Several of the programs (nanoVNASaver or nanoVNA_mod_v2 for example) will show you the equivalent parallel impedance of the device connected to port 0. What you should see on the Smith chart is a short at very low frequencies, say 50 kHz, (a dot near the left side of the Smith Chart) with an increasing impedance (primarily inductive reactance) of the device you have connected. On the Smith chart the plot should start near the left edge of the horizontal axis and proceed clockwise around the outer circle on the Smith chart as the frequency is increased. Based on what you have said, I wouldn't go much beyond 30-100 MHz as the stop frequency; however, experimenting with the stop frequency would be instructive regarding the device you are measuring. At some frequency, the inductor will appear as a very high impedance (this will be reflected by the plot going to the right side of the chart) because it will have a parallel resonance which is an indication of the amount of capacitance in your coil.

I hope this helps.

--
Bryan, WA5VAH


Re: Another modified nanoVNA software

 

Hi,

In reference to Alex_M modified version, nanoVNAv1.03TDRb4 doesn't use Python anymore to measure TDR cable length.

neb


Re: Quick compare with HP 8753C...

 

On Sun, Oct 6, 2019 at 03:47 PM, <bryburns@...> wrote:


However, I don't think it will not run everything directly.
Should read: "However, I don't think it will run everything directly."

--
Bryan, WA5VAH


Re: Annotated nanoVNA menu diagram

 

Hi Stan -

That would make it just a little bit narrower also.
Sadly, that little horizontal twig just right of "Press control" block
is hard-wired for all vertical branches
and would be pretty hard to remove for only one; I tried...
I may try again, after help is updated for new firmware functions,
but that involves much CSS whittling, not my strong suit.
I could move that block closer to the left edge, though.

I am hoping that iOS 13 (which adds mouse support) will allow
tool tips to appear for mouse hovers. Even without nanoVNA attach support,
being able to better use iProducts for help would be worthwhile..


Re: Annotated nanoVNA menu diagram

 

associated help file content is revised,
but not yet for firmware updates (the next step):