开云体育

I saw a post about problems with Saver, and the ini file, so I renamed mine, and ran Saver.

I have a cal that is reliable.
The H4 shows the proper e-delay and phase change for an SMA adapter and for a coax extension.

Saver?
Rats. The e-delay is way off...
Then I looked at it not for its value, but for how it related to the H4.
It is half the H4.
The delay in Saver was 730 ps and when I shutdown Saver, disconnected, and restarted H4, I put 1460 ps in e-delay. That zeroed phase.

This is another example of how the lack of consistency across product lines and the lack of docs causes problems.

I don't understand why some earlier posters in threads related to this didn't comment. Surely mine cannot be the only H4 and Saver combo that works this way. I don't care which method is used, but I should not have to experiment to see what fields mean.

When the author of NanoVNA saver implemented "offset delay" it was discussed in this group. The consensus was that it should be in accordance with the standard definitions used for calibration kit parameters. If a set of commercial loads is supplied they will provide this data. In fact one of the members of this group generated the parameters for the cal loads shipped with the NanoVNA and published them in this group. A screenshot of the calibration entry screen is below.

If you want to add an extension to a calibrated "reference plane" you can do this in NanoVNA Saver by determining the delay in picoseconds through the extension and entering this as a negative number in the Calibration screen. The negative number is by industry convention when a port extension is connected to a reference plane.

An example of this is attaching a 15.5 cm (6 inch) RG-316 cable to a calibrated VNA port. The velocity factor is about 70% so the "electrical length" of the cable is 22.2 cm. The speed of light is about 3.33 ns per meter so the delay is 3.33 * .222 = .74 ns or 740 picoseconds. Entering -740 in NanoVNA Saver gives the result below.

If we do the port extension on a NanoVNA-H4 we need to be aware that the device does not always conform to industry standards. For example the CH0 and CH1 ports should be designated as Port 1 and Port 2 (they are on later generation products). The firmware has had different developers and they chose to use the term "e-delay" or "electrical delay" and used it differently than "offset delay". The correct input for a port extension requires the "round trip" delay to be entered as a positive number . So in this case +1480 picoseconds is required. A screenshot after this entry is attached.

A nice video on this topic was done by W2AEW >>

Summary: NanoVNA Saver uses the conventional term "offset delay" and implements it correctly. Some NanoVNA firmware uses a different variable e-delay and users need to be aware of how to use it correctly.

Roger

On 2022-05-13 18:05:-0700, you wrote:

If you want to add an extension to a calibrated "reference plane" you can do this in NanoVNA Saver by determining the delay in picoseconds through the extension and entering this as a negative number in the Calibration screen. The negative number is by industry convention when a port extension is connected to a reference plane.

Please take all of the following bearing in mind that I am a VNA novice...it is nice to have this perspective on the table. I intend to search the forum for the threads mentioned...

I actually don't know much about the VNA industry, so I am pleased to see this write up. I found it curious to find

"Time The amount of port extension delay in time. Enter a positive value."

and
"Keysight Technologies Specifying Calibration Standards and Kits for Keysight Vector Network Analyzers"
Enter the delay from Table 1: OFFSET DELAY, 0.0108309, ns.

"Agilent_Advanced_VNA_calibration.pdf"
positive delay for port extension

"TTR500-User-Manual-077125400.pdf"
only mentions choosing twixt "Length Delay" and "Time Delay", but no mention of sign.
Enter the delay value as a length of lossless transmission line (m) or a measure of time (seconds).

"R&S� ZNB Vector Network Analyzers User Manual"
3.6.1.1 Definition of Offset Parameters The delay is the propagation time of a wave traveling through the transmission line. The electrical length is equal to the delay times the speed of light in the vacuum and is a measure for the length of the transmission line between the standard and the actual calibration plane....
In the "CHANNEL > OFFSET EMBED > Offset" tab, "Electrical Length, Mechanical Length" or "Delay" are coupled parameters. When one of them is changed, the other two follow.

"user-guide-keysight-agilent-n9923a-fieldfox-rf-vector-network-analyzer-2-mhz-4-ghz-6-ghz.pdf"
Emacs!


Everyone should understand that I take these snippets out of context, because I am not experienced with VNAs. But there is no "requirements spec" or "design spec" which would contain these specifications and their basis, at least in my business.

A nice video on this topic was done by W2AEW >>
It's a well-done vid on port extensions...

these is still the question of whether to enter the round trip delay ... it doesn't matter to the user if the software/firmware processes it as a round trip...
note that the extension produces a ?positive phase shift?, indicating that a negative phase shift might be needed to compensate..but that is not the same as a negative offset delay.
I see in the vid that the length is displayed as roughly twice what I'd consider the length of the extension used.

I usually start my delay estimates at length/(VoP*c). And then I double that for the nVNA.

On Sat, May 14, 2022 at 06:33 AM, Rich NE1EE wrote:

I actually don't know much about the VNA industry, so I am pleased to see this
write up. I found it curious to find

"Time The amount of port extension delay in time. Enter a positive value."

Rich,

From your reference links it looks like the "offset delay" should be entered as a positive number representing the one way delay through the port extension. I have modified my fork of NanoVNA Saver to do this. You can download it from my Box account >>

If you want to see this change in a future "official" version you will have to raise it as an "issue" on the NanoVNA Saver github >> . The developer zarath will decide if it will be implemented.

Roger

On 2022-05-14 11:07:-0700, you wrote:

From your reference links it looks like the "offset delay" should be entered as a positive number representing the one way delay through the port extension. I have modified my fork of NanoVNA Saver to do this. You can download it from my Box account >>

I did download, and will use it on my next tests. Thanks also for the writeup. It is very useful to keep in mind when using Saver. I think that I must
start and connect nVNA to PC
start Saver
immediately config Saver to match nVNA
connect (button) Saver to nVNA...all to avoid Saver from changing my config. I will be testing this specifically, because it is annoying to setup the nVNA, only to find it changed after connecting to Saver.

I did try deleting the ini file, but it did not correct the behaviour I saw.

In addition, I read that Saver stops the nVNA from sweeping. I have seen this, and not been able to restart the sweep without power cycle.

I renamed it to Saver 0.4.1 Roger, to keep it separate from the others.

If you want to see this change in a future "official" version you will have to raise it as an "issue" on the NanoVNA Saver github >> . The developer zarath will decide if it will be implemented.

I will see how to do that.
~R~