开云体育

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."

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."

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

Larry,

I'm all for contributing changes back to the community. I'm a maintainer
of multiple open-source SW projects, too.

However, the feedback I got to my first email when I courteously wanted to
discuss possible changes was only negative:
- The NanoVNA is an inexpensive device, so I should not expect it to
implement the time domain like a R&S/Keysight VNA would do.
- It's not of interest to many users.
- It should not be done in firmware for code size reasons.

Maybe I'm misreading the emails but to me that's not the warmest of
welcomes to someone new to the forum, either. This leads me to the question
whether contributing my changes (via pull request) would only result in
similar negativity/disinterest. So, why should I try it, then?

Larry,

I'm all for contributing changes back to the community. I'm a maintainer of multiple open-source SW projects, too.

However, the feedback I got to my first email when I courteously wanted to discuss possible changes was only negative:
- The NanoVNA is an inexpensive device, so I should not expect it to implement the time domain like a R&S/Keysight VNA would do.
- It's not of interest to many users.
- It should not be done in firmware for code size reasons.

Maybe I'm misreading the emails but to me that's not the warmest of welcomes to someone new to the forum, either. This leads me to the question whether contributing my changes (via pull request) would only result in similar negativity/disinterest. So, why should I try it, then?

Perhaps as a postscript an explanation why this is not merely an "academic"
exercise but it has a practical application - at least to me. This is also how
I found the discrepancy in the first place.

I have some devices that are basically lines with tunable delay and
attenuation. I like to use time-domain transmission (i.e., S21 transformed)
measurements in band-pass impulse mode, because these allow me to see both the
delay and the average attenuation (over the frequency range chosen in the VNA)
at one glance. See the screenshot for an example. This is especially important
when tuning the lines because in that way I get an immediate feedback
regarding the parameters I'm changing. But, of course, this then requires the
magnitude of the impulse response to be free of systematic errors that merely
occur due to the IFFT and related signal processing.

I hope this explains why I wanted to fix this in the firmware.