I'm trying to set a measurement/calibration plane out at the end of two 15m (50 foot) test cables.  While a normal nanovnasaver measurement with calibration at the SMAs is OK,  a calibration made with the SW out at the ends of these cables is not.  I think there is insufficient dwell time after frequency point  has changed to allow a stable reading in this high group delay environment.    Measurement BW seems to be down at 1 kHz so perhaps this is influencing the required settling time.

On the VNA itself Bandwidth is indicated as 6.2 kHz 400 P/s with not adjustment possible.   In the SW there seems to be no adjustment for this calibration situation which seems not to be appropriate.

I can make a good calibration if I do not use nanovnasaver but only the on-board VNA calibration tool.  vnasaver seems to not provide enough dwell to allow a new measurement condition to stabilize on these longer cables.

What is the correct way to slow each frequency point measurement setting, prior to the calibration measurement, in order to achieve good calibration with vnasaver?

Glenn n6gn

[apologies if this is doubly posted, I haven't visited the group for a long time and seem to be using it wrong.]

I'm trying to use nanoVNA V2 Plus4 v20250121 to make a calibrated 2-port measurement at the end of two long, 15m/50'  50 ohm test cables using nanoVNAsaver 0.6.2.    While this measurement works fine using the on-board calibration tools of the VNA, it does not work properly when I try to calibrate from NanoVNA-saver SW.    I believe the problem is that -saver does not dwell sufficiently long after a frequency change to allow for the group delay of the extra cable length.   The resulting calibration is garbage while the same calibration done from the VNA is fine. Accordingly the resulting measurement from vnasaver is useless.

I see the on-board IF is set to 6.2 kHz 400 P/s and cannot be changed.    NanoVNA-saver:Manage indicates a Bandwidth of 1 kHz also with no way to alter it.  I see no way to slow the measurement down to allow for it to stabilize during a calibration.

Even when I save the desired calibration in Save0 from the VNA, when I then start NanoVNA-saver, it does not use that calibration but instead reverts to a cal:reset state.

Is there no way that I can make a calibrated measurements at a 'distant' measurement/calibration plane using NanoVNA-saver?

Glenn n6gn

Glen
I'm not in the workshop so can't check but I'm sure I've been able to
use an instrument calibration within NanoVNASaver, in the past. ie:
displayed results have been congruent on both the instrument and the
PC.
Perhaps there is a checkbox or other setting in the PC software that
controls the behavior?

Dave, G1OGY



Dave, G1OGY


On Thu, 28 Aug 2025 at 08:41, Glenn n6gn via groups.io
<n6gn=sonic.net@groups.io> wrote:

>
> [apologies if this is doubly posted, I haven't visited the group for a long time and seem to be using it wrong.]
>
> I'm trying to use nanoVNA V2 Plus4 v20250121 to make a calibrated 2-port measurement at the end of two long, 15m/50' 50 ohm test cables using nanoVNAsaver 0.6.2. While this measurement works fine using the on-board calibration tools of the VNA, it does not work properly when I try to calibrate from NanoVNA-saver SW. I believe the problem is that -saver does not dwell sufficiently long after a frequency change to allow for the group delay of the extra cable length. The resulting calibration is garbage while the same calibration done from the VNA is fine. Accordingly the resulting measurement from vnasaver is useless.
>
> I see the on-board IF is set to 6.2 kHz 400 P/s and cannot be changed. NanoVNA-saver:Manage indicates a Bandwidth of 1 kHz also with no way to alter it. I see no way to slow the measurement down to allow for it to stabilize during a calibration.
>
> Even when I save the desired calibration in Save0 from the VNA, when I then start NanoVNA-saver, it does not use that calibration but instead reverts to a cal:reset state.
>
> Is there no way that I can make a calibrated measurements at a 'distant' measurement/calibration plane using NanoVNA-saver?
>
> Glenn n6gn
>

I’m using NanoVNA-Saver and original NanoVNAs, and I have no problem
calibrating at the end of a 30m/100ft transmission line, either with the
NanoVNA by itself, or doing it inside NanoVNA.

I’ve not looked at the code inside the NanoVNA to see how long it allows after
setting the synthesizers to a new frequency, before capturing the next epoch
of samples to measure the values. It’s not “speedy”. I would expect the
synthesizer to settle quite quickly - you’d have to look at the schematic and
code to see what the loop filter time constant is (the loop filter is
programmable, and it depends, also, on the reference frequency/step size of
the PLL)



As I recall, it collects a millisecond worth of samples (maybe faster on the
VNA2), which sets the basic 1 kHz measurement bandwidth.

The delay through a 30m transmission line, one way, is on the order of 150 ns
one way.

So the two way delay is 300 ns. Let’s assume that the audio ADC starts
sampling instantly after the frequency change is done - at 96 ksps, that’s
about 10 microseconds. So out of the hundred samples taken to form the I/Q
value, you might have just the first one corrupted, maybe.



I don’t think that’s your problem.





> On Aug 28, 2025, at 00:40, Glenn n6gn via groups.io
<n6gn=sonic.net@groups.io> wrote:
>
>

> 

>

> I'm trying to set a measurement/calibration plane out at the end of two 15m
(50 foot) test cables. While a normal nanovnasaver measurement with
calibration at the SMAs is OK, a calibration made with the SW out at the ends
of these cables is not. I think there is insufficient dwell time after
frequency point has changed to allow a stable reading in this high group
delay environment. Measurement BW seems to be down at 1 kHz so perhaps this
is influencing the required settling time.

>

>
>

> On the VNA itself Bandwidth is indicated as 6.2 kHz 400 P/s with not
adjustment possible. In the SW there seems to be no adjustment for this
calibration situation which seems not to be appropriate.

>

>
>

> I can make a good calibration if I do not use nanovnasaver but only the on-
board VNA calibration tool. vnasaver seems to not provide enough dwell to
allow a new measurement condition to stabilize on these longer cables.

>

>
>

> What is the correct way to slow each frequency point measurement setting,
prior to the calibration measurement, in order to achieve good calibration
with vnasaver?
>

>
>

> Glenn n6gn

_._,_._,_

* * *

The way I have been taught to do this, is calibrate at the VNA, then use port extensions to “move” the cap point to the end of the cable. After calibrating, add the cable (open ended is OK), then adjust the poet extensions for the “best” ball at the right most (open) point on the smith chart.

This now should let you add an antenna, and see the effect of the antenna, not the cable “system”.



Frank

KLA2FWC

Port extensions only deal with time (usually) not loss, unless you can put in a complete S21 description of the cable/port extension.
That's pretty easy in scikit-rf because it does nice chained network processing.

Yes, this is the problem with using port extensions, they only use a model of the intervening test cable based on,  at best, attenuation and delay and not on the actual structure that has had its error contributions included by a full calibration.   Incidentally, even a 1-path 2-port calibration such as we are restricted to in the nanoVNA series of HW doesn't provide everything necessary for completely  accurate calibration_plane=measurement_plane calibration. For that a full 2-port test set that turns everything around such that stimulus can emanate from  port 2 (of S21) instead of only port 1 is required. This is done in high end VNAs but not as often in simpler ones due to the significant increase in HW cost.  Even high end VNAs only handle transmission lines assuming a TEM model.  At very high impedance the TM component becomes significant and the entire VNA  model breaks down because there can no longer be a simple calibration/measurement plane when longitudinal component of the e-fields becomes significant.  See Introduction to the Propagating Wave on a SIngle Conductor ( https://www.researchgate.net/publication/334746131_Introduction_to_the_Propagating_Wave_on_a_Single_Conductor ).

I did find that an earlier nanoVNA,   a little one with a ~900 MHz  upper limit, did provide a calibration which did not show the problems of the nanoVNA V2 Plus4.  No doubt its different source  HW and control SW within it made the difference.  But since both  new and old nanoVNAs can measure properly, once calibrated,  but only the newer V2 version can't perform a proper calibration, I'm left to suspect that there is something that needs to be done to handle the large group delay case during calibration in order to make it work.   As I mentioned, this problem is not unique to tinyVNAs. Any VNA must let measurement conditions settle after a  change to allow the port signals to stabilize.  High Q and large group delay devices force this dwell time to be higher than when a broadband calibration very close to the physical VNA is all that is being asked for.

There may be a simple work-around for this problem since the tinyVNA V2 is able to make a measurement in the presence of long delays.  Clearly something in the code is providing the necessary dwell time for a measurement that is not being provided in the calibration mode.   Correction of the problem  probably doesn't require a large change to the code but it is a necessary one.   I was hoping that someone had found a work around that doesn't require that code change.

Meanwhile, I've made the measurements I need to using an older tinyVNA.

Thanks to all who have commented.

Glenn n6gn