开云体育

On Sun, Oct 17, 2021 at 02:11 PM, Jim Lux wrote:

Barring pathological cases (you've got things with narrowband phenomena,
inside the calibration plane, like a stub that's a significant fraction
of the wavelength),? I don't think the cal performance is degraded very
much.? The cal parameters don't vary in a radical or fast way, most of
the time, and the calculations are done with sufficient precision, that
the limit on accuracy is something else (SNR of the measurement).? The
interpolation is done in floating point, as are the calibration
calculations.

There are places where I'd watch out - if you cross a harmonic
switchover boundary, there's likely to be a glitch, because gains, etc.
all change, and interpolation might not be valid.

Jim,

I agree with you. Here are some measurements of a 20M dipole. First measurement was made using calibrated range of 1 to 30 MHz. Next was using same calibration but "zooming in" to 13 to 15 MHz. Last was calibrated from 13 to 15 MHz. Interpolation worked very well for this experiment.

Roger

On 10/17/21 1:48 PM, Kenneth Hendrickson via groups.io wrote:

--- On Sunday, October 17, 2021, 09:28:17 AM EDT, Joe WB9SBD <nss@...> wrote:

When you do a calibration open/short/50, Stimulus from 3 to 30 Mhz.
it should then be accurate between 3 and 30 Mhz correct?
OK you calibrated with the 3 to 30 Mhz scan width.
Now if you change the stimulus width to like 14 to 14.5 Mhz and not do a new calibration,
is the calibration still good since this narrower window is still inside the original scan width?

When you choose a set of frequency limits, and a set of frequencies in that span (number of frequency steps), then only and exactly that set of frequencies is calibrated. If you then make a measurement on that range, the perfect calibration is used for each frequency.

If you change the frequency range, or the number of frequency steps, then interpolation must be performed, and the calibration is not as good as it could be.

Barring pathological cases (you've got things with narrowband phenomena, inside the calibration plane, like a stub that's a significant fraction of the wavelength),? I don't think the cal performance is degraded very much.? The cal parameters don't vary in a radical or fast way, most of the time, and the calculations are done with sufficient precision, that the limit on accuracy is something else (SNR of the measurement).? The interpolation is done in floating point, as are the calibration calculations.

There are places where I'd watch out - if you cross a harmonic switchover boundary, there's likely to be a glitch, because gains, etc. all change, and interpolation might not be valid.

If you want the best results, always calibrate every time you change frequency range or the number of frequency steps.

--- On Sunday, October 17, 2021, 09:28:17 AM EDT, Joe WB9SBD <nss@...> wrote:

When you do a calibration open/short/50, Stimulus from 3 to 30 Mhz.
it should then be accurate between 3 and 30 Mhz correct?

OK you calibrated with the 3 to 30 Mhz scan width.
Now if you change the stimulus width to like 14 to 14.5 Mhz and not do a new calibration,
is the calibration still good since this narrower window is still inside the original scan width?

When you choose a set of frequency limits, and a set of frequencies in that span (number of frequency steps), then only and exactly that set of frequencies is calibrated. If you then make a measurement on that range, the perfect calibration is used for each frequency.

If you change the frequency range, or the number of frequency steps, then interpolation must be performed, and the calibration is not as good as it could be.

If you want the best results, always calibrate every time you change frequency range or the number of frequency steps.

73,
Ken N8KH

Roger,
Note that I am only clever enough to post a link to the calculator. The Aussie, Jose Miguel Vaca, VK3CPU is the one who did all the magic so I don't need to use the CF scale on my slip stick.
Jose also has a couple other handy calculators on his website.

Cliff

Cliff,

That is a very impressive calculator!.

A suggestion - You only calculate L with the initial permeability. You already plot X so it would be nice if you could add L to the graph since it varies with frequency as the permeability changes. This would mean the user would not have to manually divide X by 2*pi*freq to get L at a desired frequency.

Second suggestion - Powdered iron cores would be a nice addition.

Bug report - The frequency slider did not work for me on Chrome, Firefox or Edge. The other sliders worked fine

Roger

Please read ANY of the user guides and learn what the letters on the left side of the display mean.



On Sun., 17 Oct. 2021 at 10:18 a.m., Joe WB9SBD<nss@...> wrote: Now when you save a calibration to a memory.

Is that good still after a power down and then fired up again some other
day?

Joe

YES.

Hello Andy,

I just installed the drivers from the ST site on a Win10 computer using the "Absolute Beginner's Guide to NanoVNA" yesterday in hopes of connecting to a NanoVNA-H4. The guide is very helpful but I did run into one issue with installing the the DfuSe_Demo driver.
-- The first driver (Virtual COM Port) installation & validation went fine using the Win8 driver - as suggested by the guide.
-- The second driver (DfuSe_Demo) installation went fine using the Win10 driver. However, when I put the H4 into DFU mode the computer would not recognize it and told me that I had the wrong driver...

Long story short -- I finally decided to try the Win8 driver for DfuSe_Demo and everything worked fine.

The NanoVNA-H4 successfully upgraded to V 1.0.69 and so far works with nanoVNA-saver and nanoVNA-app.

Perhaps this will work on your Win10 machine.

Terry-KD8RGJ

Now when you save a calibration to a memory.

Is that good still after a power down and then fired up again some other day?

Joe

I had wondered about this. I will calibrate over several different ranges
(e.g. 143 to 147 MHz, 431 to 433 MHz, etc.) and save each one. I am
assuming the calibration is saved each time one of the frequency ranges is
saved.

73, Zack W9SZ

Hi Joe,

YES. However if you desire to improve accuracy, then do the calibration again over the smaller freq span.

For your work, you might consider calibration over each of the ham bands and store each cal sweep in each of the 5 memory locations. Probably overkill, but not a big deal.

So consider doing a 5 MHz sweep over each ham band as a start.

On 10/17/21 6:28 AM, Joe WB9SBD wrote:

When you do a calibration

open/short/50,

Stimulus from 3 to 30 Mhz.

it should then be accurate between 3 and 30 Mhz correct?

OK you calibrated with the 3 to 30 Mhz scan width.

Now if you change the stimulus width to like 14 to 14.5 Mhz.
and not do a new calibration,

is the calibration still good since this narrower window is still inside the original scan width/

Joe

Yes, for the most part.? Let's say you have the original NanoVNA which uses 101 points. Your original cal is 101 points over the 27 MHz between 3 and 30, so about 270 kHz/point.? If you "zoom in" to 14 -14.5, the VNA interpolates between the 3 or 4 points covering that range.? Since it's unlikely that the VNA radically varies over that bandwidth, you'll get good measurements.


A notable exception might be if you're calibrating at the end of a longish feedline.? Then, there could be significant variations over a narrower frequency range (for instance, if you happened to be exactly 1/4 or 1/2 wavelength right in the middle of the band).

When you do a calibration

open/short/50,

Stimulus from 3 to 30 Mhz.

it should then be accurate between 3 and 30 Mhz correct?

OK you calibrated with the 3 to 30 Mhz scan width.

Now if you change the stimulus width to like 14 to 14.5 Mhz.
and not do a new calibration,

is the calibration still good since this narrower window is still inside the original scan width/

Joe

Excellent explanation Gregg - thanks!
I also stepped into the same trap

Read Absolute Beginner's Guide to NanoVNA
/g/nanovna-users/files/Absolute%20Beginner%20Guide%20to%20The%20NanoVNA/Absolute_Beginner_Guide_NanoVNA_v1_6.pdf

73
Martin 9A2JK

From Jose Miguel Vaca, VK3CPU. In beta testing.
Designed to help make toroids more accessible to designer/builders. Currently supports designing inductors, but will add support for suppressors soon. Optimised to work on mobiles, but should also work on desktop browsers. (Although layouts need work.) Looking forward to constructive feedback or bug reports. It supports the most common ferrite mixes and uses manufacturers data and equations for calculations.

Hello to the group,

I have tried this before but ran into such a brick wall that I had to walk away from it. That said some time has passed and I am trying this again. I have a semi newer H4 Version 0.5.0 and am having a problem getting windows to recognize the VNA.

With that said, I am ready to give it a try again. Based on my current position, what is the next step when you plug it in and get the message below?

Thanks,

I wouldn't normally design a 100 ohm system using 50 ohm transmission lines and innerconnects and then compound it with stubs but I was going off your original comment of works meaning no loss of performance. But yes, now that we are no longer constrained by that, it opens the doors to pretty much anything.

I don't see any reason why you'd need 100 ohm cables. You'd replace the bridge (CH0) and pad (CH1) components to make it 100 ohms, the short cable to the T would make some difference, but at 900 MHz (top of band for stock NanoVNA) that would be a few cm at most and not a huge impedance transformation. The "mismatch" such as it is would would come out in the calibration.

It kind of depends on "how important is it that the VNA present a 50 ohm impedance to the DUT"

and a tradeoff against performance.
You could use a 3dB broadband splitter (but probably lose bandwidth) instead of a 6 dB resistive divider (or a T and two 50 ohm resistors)

The transfer relay isn't a panacea - 80dB is typical isolation. The HP VNA test sets use a pair of SPDTs and switch only the source, which probably has better isolation.

If you're measuring systems where you need 80 dB SNR, I suspect that *any* scheme is going to need some special care.

Most software implementations expect arguments to trig functions in radians while most calculators expect degrees.? If you use GNU Octave, there are now functions for either.? sin(theta) expects that theta will be expressed in radians.? sind(theta) expects theta in degrees and so on for the other trig functions and inverse trig functions.

Maynard Wright, W6PAP