开云体育

Sorry I didn't reply again - I was on lunch break and had to go back in to
work (thankfully I can still go to work!)
As John noted, you can set the Velocity Factor: it is at the end of the
transform menu.
Another important note for TDR use, which builds on what John was saying: when
doing very high frequency measurements, there is ambiguity introduced if the
reflection delay is longer than the frequency allows.
So to do TDR on short lengths of cable, with high resolution, use a high stop
frequency.
But to do TDR on long lengths of cable, you need to use a lower stop
frequency.
For TDR, you should always leave the start frequency at 50KHz (the lowest,
which is essentially 0 compared to the stop frequency) - this makes the FFT
math work right. And you should set it to "Low Pass Impulse" for length
measurements, and "Low Pass Step" for reading impedance changes along the
cable (also shows length, but less distinctly).
Tables don't work too well here, but see if this makes sense, all at a
velocity factor of 1.0 (100 on the H4 display):

StopFreq:1500MHz gives tmax=26ns --> maxlen=3.9m or 12.8ft
StopFreq:1000MHz gives tmax=39ns --> maxlen=5.85m or 19ft
StopFreq:500MHz gives tmax=78ns --> maxlen=11.7m or 38.4ft
StopFreq:200MHz gives tmax=195ns --> maxlen=29.2m or 95.8ft
StopFreq:100MHz gives tmax=390ns --> maxlen=58.5m or 192ft

Those figures are a bit misleading, because with a lower velocity factor, the
lengths are shorter by that factor.
So when you want to measure a cable that is ~100ft long, you need to use a
StopFreq of about 100MHz to get a true reading without the ambiguity factors -
otherwise the 'pulse' doesn't have time to make it down the cable and back to
be measured.

This also means that the measurement accuracy is smaller for longer lengths
(since each measurement point is larger in time/length, corresponding to the
frequency bin being smaller). I haven't yet tried to figure out the accuracy
numbers, but I know it is within a millimeter at 1500MHz/26ns, and I suspect
it is only within several inches at 100MHz/390ns. And as for John's idea of
using the Electrical Delay: I don't know what happens if it is set longer than
the max lengths above: it will shift the window, but if used beyond the range
of the 'tmax' value, it still can't do away with the ambiguity that results
from multiple waves reflecting (when set to have a tmax shorter than the cable
length requires).

I hope some of that makes sense; don't know how well I described it.
Stan

Hi Jerry, Velocity Factor is set (in ver 0.5.0) in the transform page
at the bottom

Well thank you all for you replies and observations. Forgive me not mentioning
everyone by name.

Larry I do download stuff where I can check it for malware on pc or to some
extent linux but that is somwhat different to firmware downloads for a device
for which the av software is not native or probably able to check.

I think it was Jerry who said I could vet the source code. well :) that would
entail a deal more familiarity with the language and GitHub environment. I
have programmed and still do but I did assembly language which means C or Java
and the like leave me stone cold. So setting up an environment to recompile
the code or whatever doesn't float my boat.

With what sound like 3 different versions of firmware from the programmers
that seems more confusing as to which to use. I suppose it can be seen as a
plus in that users have choices but as a user that is NOT familiar with core
hardware design and its limitations I won't know if the firmware is trying to
do things it shouldn't. For example Extending frequency range is not just down
to a software setting.

I'll re-look at Smith Chart displays to check again what figures are displayed
but I didn't recall spotting the parameters I was seeking.

Again, I think it was Jerry talking about writing a manual vs viewing
youtubes... I agree, I prefer to be able to read and flip back and forth
through text not listen to what is often a monotone drone that then doesn't
cover what I was hoping for. Writing a manual that covers the basics and terms
used in context to what analyser does and the results it provides is some
task. I wish you well with that as I think there are many radio amateurs that
are just blackbox users that simply don't understand the tech. I include
myself in a number of areas where that would apply .... Smith Charts and VNA
being such an area.

Thanks again.
Phil

Jerry,
I didn't mean to imply that one should not set the velocity factor. I'm
usually content with just the delay, but that is partly because I am usually
looking for things like cable impedance rather than fault location on a
particular type of cable.
--John Gord

Stan,

I was following John Gord's instructions as included in my previous email
This procedure uses the stock transform mode of the nanovna firmware,
it does not rely on any kind of special purpose TDR firmware.
There is no provision for setting a velocity factor.

Jerry, KE7ER



On Wed, Sep 23, 2020 at 02:42 PM, Stan Dye wrote:

Jerry, something is wrong here. The displayed values should show the
one-way delay, and directly read the cable length if you set the velocity
factor via the menu. How did you calibrate for this measurement, and what
frequency start/stop are you using?

I might add that you need to remember, the Nanovna is an inexpensive hobby
device and although it is quite accurate in many ways, it is not a lab grade
device like R&S, Keysight, etc.
There was only so much memory space to work with at the time and the dev that
added the fft routines did a great job.
You may want to contact edy555 or DiSlord via issues in their Nanovna githubs
if you think there is something that needs attention in the firmware.

On Wed, 23 Sep 2020 at 5:46 PM, John Gord via
groups.io<johngord@...> wrote: Christian,
In the firmware (not necessarily the PC software), the "Low Pass Step" mode
appears to give correct step reflection amplitudes when the selected format is
"Real".? I tend to treat the impulse modes as "indication only".
--John Gord

Hello,

please excuse if this has been discussed before ? perhaps I searched the
list archive using the wrong keywords.

Do you think that the time domain mode built into NanoVNA firmware (in my
case: hugen79's version 0.4.5) should correct the displayed amplitude for
losses in the IFFT due to windowing and zero-padding? Other VNAs do so: see
the attached files, where the same DUT ? an open-ended coax cable ? was
measured with a Rohde & Schwarz ZVA and with NanoVNA in time domain mode.

Neglecting the (very small) cable losses, the DUT presents a total reflection
and is shown as such (≈ 0 dB) by the R&S ZVA. In contrast, on the NanoVNA,
the peak depends on the selected mode (bandpass, lowpass impulse or lowpass
step) and on the selected window. This can be explained by looking at the
signal processing performed by the NanoVNA firmware. For example, in bandpass
mode with normal window, it applies a 101 point Kaiser window (shape factor 6)
[1] and zero-pads to do a 256 point IFFT. Therefore, the loss is
20*log10(256/sum(kaiser(101,6))) ≈ 14.2 dB. Actually, the peak in the
NanoVNA result (blue curve) reads as ca. -14.6 dB, which matches very well.

Imho, the firmware should correct these systematic losses that happen purely
by signal processing in order to give a result consistent to expensive VNAs.
(Keysight does the same as R&S here. [2]) But maybe this topic was already
discussed and a there was a good reason _not_ to correct the losses in
NanoVNA?

Regards
Christian

[1]

[2] Keysight's time domain app-note even states "There is also some scaling
and renormalization that takes place to ensure the value of the time domain
transform retains its physical meaning. For example, the frequency response of
the S11 of an ideal open circuit, with no delay, has a value of 1 for all
frequencies; its inverse transform is a delta function. However, when the data
is sampled and windowed, the time domain transform of the response of an open
circuit will be spread by the windowing function and does not return an
impulse of unity height. Therefore, it is necessary to renormalize to ensure
that the time domain response of the open circuit has a value of unity."

Jerry, something is wrong here. The displayed values should show the
one-way delay, and directly read the cable length if you set the velocity
factor via the menu. How did you calibrate for this measurement, and what
frequency start/stop are you using?

Phil,

When you are just starting out things can seem a bit overwhelming at first.
There is no manual shipped with the product so you have to start hunting
around. The Wiki for this group has a lot of useful information. If you want
good starter videos I suggest W2AEW videos on YouTube Start with #312 >>
. Your time will be well
spent watching these.

To get you going try reading some of the info below.

User Guides >> /g/nanovna-users/wiki/12475

Test Board Tutorial >>

As you experiment with the NanoVNA you will see that the menu allows you to
change the number of traces on the display. You can also change what the
traces display like SWR, Return Loss, Resistance, Reactance etc. When you want
to measure an antenna set the frequency range that you are interested in using
the Stimulus menu option and then calibrate and save the calibration in one of
the spare slots (1-4). Then attach your antenna to CH0 and get the results. By
default you will get Return Loss in dB and a Smith Chart. You can change the
yellow trace to SWR if you want. By using the rocker switch you move the
marker along to read out the measurements at different frequencies. The Smith
Chart (green trace) will give you resistance and inductance/capacitance. All
measurements are where you made the calibration.

Roger

Hello,

please excuse if this has been discussed before ? perhaps I searched the
list archive using the wrong keywords.

Do you think that the time domain mode built into NanoVNA firmware (in my
case: hugen79's version 0.4.5) should correct the displayed amplitude for
losses in the IFFT due to windowing and zero-padding? Other VNAs do so: see
the attached files, where the same DUT ? an open-ended coax cable ? was
measured with a Rohde & Schwarz ZVA and with NanoVNA in time domain mode.

Neglecting the (very small) cable losses, the DUT presents a total reflection
and is shown as such (≈ 0 dB) by the R&S ZVA. In contrast, on the NanoVNA,
the peak depends on the selected mode (bandpass, lowpass impulse or lowpass
step) and on the selected window. This can be explained by looking at the
signal processing performed by the NanoVNA firmware. For example, in bandpass
mode with normal window, it applies a 101 point Kaiser window (shape factor 6)
[1] and zero-pads to do a 256 point IFFT. Therefore, the loss is
20*log10(256/sum(kaiser(101,6))) ≈ 14.2 dB. Actually, the peak in the
NanoVNA result (blue curve) reads as ca. -14.6 dB, which matches very well.

Imho, the firmware should correct these systematic losses that happen purely
by signal processing in order to give a result consistent to expensive VNAs.
(Keysight does the same as R&S here. [2]) But maybe this topic was already
discussed and a there was a good reason _not_ to correct the losses in
NanoVNA?

Regards
Christian

[1]

[2] Keysight's time domain app-note even states "There is also some scaling
and renormalization that takes place to ensure the value of the time domain
transform retains its physical meaning. For example, the frequency response of
the S11 of an ideal open circuit, with no delay, has a value of 1 for all
frequencies; its inverse transform is a delta function. However, when the data
is sampled and windowed, the time domain transform of the response of an open
circuit will be spread by the windowing function and does not return an
impulse of unity height. Therefore, it is necessary to renormalize to ensure
that the time domain response of the open circuit has a value of unity."