开云体育

Hello DiSlord,

Should the interpolation not be based on radial interpolation: so average
of modulus and average of angle? All things here are complex numbers, so I
think that we should also do a complex interpolation.
Or do I misunderstand?

All the best,

Victor

Op di 5 okt. 2021 om 19:18 schreef DiSlord <dislordlive@...>:

Better do one calibration or on NanoVNA or on CPU side
Calibration data contain noise, this noise added to calibrated value (increase noise), after send to CPU and use as basic calibration in CPU side, and additional increase noise after.

About interpolation, NanoVNA use linear interpolation, and if phase/amplitude rotate fast between points - can give big error (see image):
Exist 2 points, on linear interpolation used line, so result vector - red point, but correct value - green point. On small phase between 2 points error small, but on big ... can be wrong
Bigger point count - reduce phase/amplitude shift

V2 - have this problem in range < 30MHz, so need calibrated in 2 ranges 1MHz to 140MHz and 40MHz - max (on less 1 MHz better add additional calibration)
H/H4 - not critical calibrate in 1 to 1500MHz range (but also have problems in harmonic change near 300, 900MHz at this point i use extrapolation, this reduce error, but not remove it)

I was referring to interpolation between points. If you calibrate
with 401 points between 1 and 1.5G on the device and then
calibrate with 2000 points on PC, all those in between values
are interpolated.

I always leave the slot 0 uncalibrated, calibrating on the PC is
superior in any case due to higher number of points, calibration
standard parameters, better algorithms
(Enhanced Response Correction for example), etc.

On 10/5/21 8:12 AM, DiSlord wrote:

in my firmware need use:
'scan start stop points mask'

mask - output mask
#define SCAN_MASK_OUT_FREQ (1<<0) // Output freq in Hz
#define SCAN_MASK_OUT_DATA0 (1<<1) // Output complex S11
#define SCAN_MASK_OUT_DATA1 (1<<2) // Output complex S21
#define SCAN_MASK_NO_CALIBRATION (1<<3) // Send no calibrated data

Also in old firmwares you can on/off/reset calibration by command:
Disable calibration
'cal off'
Enable calibration
'cal on'
Reset calibration
'cal reset'

That's useful.

On 10/5/21 8:06 AM, Dragan Milivojevic wrote:

If I understand correctly this will lead to interpolation
by Nano firmware which is not a good idea.

Well, as a substitute for "no calibration" which isn't easy to command, if the wideband cal is stored in #0, it has the advantage of "power cycle and you're in a known state"

I'm not sure what the interpolation algorithm does if it's over, say, 1-100 MHz, and it extrapolates for, say, 500 MHz.? If it just assumes "carry 100 MHz cal all the way to the top" that's probably ok.? If it's "continue last linear segment" then you could wind up with a weird result, if the cal coefficients between 99-100 MHz happened to be changing rapidly.

On Tue, 5 Oct 2021 at 15:32, Jim Lux <jim@...> wrote:

On 10/4/21 6:07 PM, Roger Need via groups.io wrote:

Rune had a good suggestion where you calibrate slot 0 in the NanoVNA for

the maximum frequency range you would ever need and then leave it that way
and use the other slots for other frequency ranges you might want.
That is a good idea.

Challenging but doable, you will have to use "Shunt through" method.
For an easy to understand explanation of the problem:

in my firmware need use:
'scan start stop points mask'

mask - output mask
#define SCAN_MASK_OUT_FREQ (1<<0) // Output freq in Hz
#define SCAN_MASK_OUT_DATA0 (1<<1) // Output complex S11
#define SCAN_MASK_OUT_DATA1 (1<<2) // Output complex S21
#define SCAN_MASK_NO_CALIBRATION (1<<3) // Send no calibrated data

Also in old firmwares you can on/off/reset calibration by command:
Disable calibration
'cal off'
Enable calibration
'cal on'
Reset calibration
'cal reset'

If I understand correctly this will lead to interpolation
by Nano firmware which is not a good idea.

On 10/4/21 8:55 PM, DiSlord wrote:

NanoVNA firmware can send uncalibrated data, then calibration need use in external software
But by default NanoVNA send calibrated data (if calibration apply on NanoVNA) in this case not need made calibration in external software, and if need calibration in external soft better disable/reset calibration on NanoVNA

You can see this in NanoVNA-App, and select mode None/VNA/App

What commands make the NanoVNA send uncalibrated data?? I was casually looking around, and it seemed to me that you can turn off calibration with the menu, but there's no command that you can send over the wire to make that happen.

On 10/4/21 7:14 PM, Walter Miller, AJ6T wrote:

I need to measure a very low impedance device for a non-ham application.....probably less than 1 Ohm.? Is the NanoVNA able to make an accurate measurement on such a load in the 14 MHz range?

73, Walt, AJ6T

It's all about how accurately can you measure the reflection coefficient: Gamma = (Zload-Z0)/(Zload+Z0)

For Z0 = 50, and Zload = 1

gamma = -49/51 = -0.96078

A 10% change in Zload would be

gamma = -49.1/51.1 = -0.96086

Not a huge difference. The NanoVNA calculates gamma by dividing reflected voltage by incident voltage (as measured by the two internal receivers) = gamma = Vr/Vi

In this case, the incident voltage will be pretty much the same (it's the measured source signal)

The reflected voltage is large (which is a good thing, large SNR), so to get 10% accuracy, you're looking at measuring the difference between -0.96078 and -0.96086 -> about 0.00008

To do that that implies the noise is at least 80dB below the signal.? That's probably "ragged edge" of the nanoVNA's capability.

On the other hand to measure the difference between 1 ohm and two ohms is between -0.96078 and -0.93208, a difference of 0.032, a sort of 30dB SNR need, which is more likely.

On 10/4/21 6:07 PM, Roger Need via groups.io wrote:

Rune had a good suggestion where you calibrate slot 0 in the NanoVNA for the maximum frequency range you would ever need and then leave it that way and use the other slots for other frequency ranges you might want.

That is a good idea.

Then you can calibrate for the desired range you want in NanoVNA Saver using the number of segments (more data points) and degree of averaging that you want. Now the two calibrations (hardware and Saver) are independent and the saved calibrations in NanoVNA can be recalled and used as long as the nanoVNA is set to slot 0 (power up default).

I tend to use NanoVNA app by OneOfEleven when I want to use the PC. More features than Saver, easy calibration, more graphs, better scaling (which is easier to use) and up to five traces at a time.

I just started using NanoVNA-saver because it's in Python, and I'm familiar with scikit-rf.

This is a tricky measurement even with a high grade VNA.

A compact article on the topic is at:

Note the erratum in the reply at the bottom of the page.

PeterS G8EZE

Thanks Roger,


Op di 5 okt. 2021 om 03:07 schreef Roger Need via groups.io <sailtamarack=
[email protected]>:

Rune had a good suggestion where you calibrate slot 0 in the NanoVNA for
the maximum frequency range you would ever need and then leave it that way
and use the other slots for other frequency ranges you might want.

That is indeed good advice. This slot 0 will remove the 'large
errors/compensation' of the NanoVNA and hopefully it is also a reproducible
calibration on the NanoVNA (after say a factory reset of the NanoVNA).
A stable calibration of slot 0 of the NanoVNA is essential, as all the
saved calibrations in the NanoVNA Saver will refer to that NanoVNA
calibration.

I will need to redo my NanoVNA Saver calibrations with that in mind.

All the best,

Victor

NanoVNA firmware can send uncalibrated data, then calibration need use in external software
But by default NanoVNA send calibrated data (if calibration apply on NanoVNA) in this case not need made calibration in external software, and if need calibration in external soft better disable/reset calibration on NanoVNA

You can see this in NanoVNA-App, and select mode None/VNA/App

I need to measure a very low impedance device for a non-ham application.....probably less than 1 Ohm.? Is the NanoVNA able to make an accurate measurement on such a load in the 14 MHz range?

73, Walt, AJ6T

Rune had a good suggestion where you calibrate slot 0 in the NanoVNA for the maximum frequency range you would ever need and then leave it that way and use the other slots for other frequency ranges you might want.

Then you can calibrate for the desired range you want in NanoVNA Saver using the number of segments (more data points) and degree of averaging that you want. Now the two calibrations (hardware and Saver) are independent and the saved calibrations in NanoVNA can be recalled and used as long as the nanoVNA is set to slot 0 (power up default).

I tend to use NanoVNA app by OneOfEleven when I want to use the PC. More features than Saver, easy calibration, more graphs, better scaling (which is easier to use) and up to five traces at a time.

Roger

On 10/4/21 9:19 AM, Victor Reijs wrote:

I fully support this view of Chris!

I also thought that the calibration of the NanoVNA Saver was independent of
the NanoVNA. Otherwise 'Save' of calibration in NanoVNA Saver makes no real
sense (as one seems also to know the NanoVNA calibration settings when
saving in NanoVNA Saver)...
Although I had read the remark of Rune. I had hoped otherwise. Stacking
calibration also does not sound very wise (and perhaps reduces accuracy)....

I'm not sure about the accuracy implications - there are some numerical precision effects that would need to be looked at.

So it would be nice if the NanoVNA Saver could get the results from NanoVNA
without any calibration, and of course it would be nice if NanoVNA Saver
could import the device (nanoVNA) calibration.

I believe there is a "scanraw" command in some of the firmware versions that does this (get uncalibrated data) - it's listed in that command list from 2019, but there's a lot of functions that have come and gone since then.

Likewise, some versions of the firmware can return the calibration tables, but I don't know what format they are in, off hand.

Reading the reaction of the people, it looks that such a distinction has
not been considered yet in the software (both NanoVNA and NanoVNA Saver).
Due to this present behavior, it might even be difficult to untangle and
stay backwards compatible...

On 10/4/21 8:23 AM, Chris K2STP wrote:

Interesting discussion…. Me thinks the calibration procedure/protocols/software for BOTH the unit, and software (saver) need to be fixed/made more user friendly. Especially for non-tech users like myself that do not understand much of this stuff and just want basic results after following easy instructions without taking an EE course on it!

Well, saver and the device are two completely separate entities, with some versioning differences to boot (e.g. NanoVNA-Saver works with lots of different devices). But yes, some summarizing and restating would be useful.

I had thought when you did a cal reset in saver, it did a hardware cal reset (as if you did it on the Nanak nagar)? I guess that is not true….

So did I, until I discovered otherwise. I think that's because not all nanovna type devices even allow you to reset the device cal, and there are some potential reasons why you might not want to do that (e.g. arithmetic issues)

A perfect example of why this cal stuff needs cleaned up a bit. Before all you smart guys jump on me for saying this, and state “if you read the documentation….”, I did read all the docs, as well as many of these threads. And, it gets very confusing for novice users like myself, and VERY easy to miss a simple hidden message about resetting the unit first, or doing a larger span cal on it prior to doing the software cal….

If I hit “reset” on something, it’s customary to assume everything is “RESET” and your starting from scratch. Now in this thread I find that is not the case….

The trap is that you're hitting reset on NanoVNA-Saver so that resets NanoVNA-Saver, but not the external device.

A few simple checks in the software could solve many of these calibration issues/questions. For example, if you cal for a span 7.0 to 8.0Mhz, and then try scanning 7.5 to 8.5Mhz, it should NOT let you! You should get a message to the effect “The scan is out of cal. range”!

Actually, though, it will probably work ok in that case - I don't know what algorithm the firmware uses to extrapolate beyond the cal range, but realistically, the calibration parameters don't vary that quickly from a straight line approximation.? If you had calibrated for 7-8 MHz and then wanted to go 0-900 MHz, that's a different story. It's a basic device, so some of the sophistication is not in the software, but in the user <grin>.

If saver then calibrates on top of calibration data already on the unit, it should should check for this and tell you “Unit using calibrated data, are you sure…..?”

I know, your going to say you should check all this yourself…. BUT I should also check if my car has enough oil in it prior to every trip down the road too, but I don’t. And thankfully, since around 1930, there has been a red light on the dash to tell me if the oil is low! NanoVNA firmware and it’s app’s like Saver, should add the “red light” for us!! That is my 6 cents on the subject.

Like all software, I suspect that there is a much longer list of "feature requests" than there is capability to do it. And since nobody is making money from it, the changes tend to be those that the developer is personally interested in.? There's also the issue of "squeezing into the chip" - I don't know how tight a fit the firmware is.

My philosophy is to make the changes in the software running in the PC side (i.e. NanoVNA-Saver).? But even beyond that, you'll find that sometimes, the actual problem is in a library which it uses (I ran across a plotting bug, which turned out to be in the plotting library)

I fully support this view of Chris!

I also thought that the calibration of the NanoVNA Saver was independent of
the NanoVNA. Otherwise 'Save' of calibration in NanoVNA Saver makes no real
sense (as one seems also to know the NanoVNA calibration settings when
saving in NanoVNA Saver)...
Although I had read the remark of Rune. I had hoped otherwise. Stacking
calibration also does not sound very wise (and perhaps reduces accuracy)....

So it would be nice if the NanoVNA Saver could get the results from NanoVNA
without any calibration, and of course it would be nice if NanoVNA Saver
could import the device (nanoVNA) calibration.

Reading the reaction of the people, it looks that such a distinction has
not been considered yet in the software (both NanoVNA and NanoVNA Saver).
Due to this present behavior, it might even be difficult to untangle and
stay backwards compatible...

I hope it can be better streamlined between naonoVNA and NanoVNA Saver
developers (thus easier for novices and less explaining to do in the manual
or by experts). I am willing to think about how to convert this behavior
(and hopefully stay backwards compatible). I am not good in coding in these
github environments...

All the best,

Victor



Op ma 4 okt. 2021 om 17:24 schreef Chris K2STP <ccarrara@...>:

Nanak Nagar = NanoVNA Autocorrect needs fixing also!! ;-)

--
Regards,
Chris K2STP