NanoVNA Custom Software

[gf]

We can't simply measure it as the are doing some switching.  Thinking it may be an artifact from sweeping,  I tried to select the CW mode from their built-in firmware but it has no effect.    I repeated this with the V2Plus4 with the same results.

Attached plots show the effect for both low cost VNAs.  What is interesting is how the LiteVNA changes about an ohm as it chops,  compared with the V2Plus4 at about 2 ohms.

They have only a single receiver/mixer, but they need to measure 3 quantities for each frequency point. So the 3 readings need to be multiplexed. The source currently being measured is connected to the receiver, and the other sources are connected to a terminator. Then the receiver is switched to the next source... OTOH, the original NanaoVNA has 3 receivers/mixers. Maybe it's the better choice for 150MHz anyway?

[joeqsmith]

I mentioned CW not having any effect, but you can also disable the sweeps in the firmware and it will still switch.   

[Fred_B]

Attached plots show the effect for both low cost VNAs.  What is interesting is how the LiteVNA changes about an ohm as it chops,  compared with the V2Plus4 at about 2 ohms.

Something else to be aware of.

You've brought up something there that I am actively wondering about, the switching. I had a look at the schematic for the V2Plus4. Apparently it switches back and forth between measuring S11 and S21 for each frequency point. If I comprehend your post correctly, you're measuring the low cost VNA, with a quality PNA. I fail to make sense of what your are showing, a switching that is apparently every few MHz or so across the frequency sweep, and we fail to see that when self-measuring the port 2 input impedance of the low cost units. That's too slow for the S11/S21 switching. So, what do you think that is?

Just for giggles, could you use the PNA to measure the output impedance of port 1 on the low cost devices?

A couple more notes about the SPICE model. The original calibration cable attached to port 1 has been omitted from the model because for all practical purposes it has been calibrated out of the measurement. Also, the magnitude of signal at port 2 in the model is reported as close to -6 dB, that's because LTSpice normalizes the signal level at the internal input to the voltage source, which in this case has been set to 1V, before the source output impedance is applied to the signal, rather than to the external output of the voltage source after the source impedance has been applied to the signal. That means in VNA terms the signal level at port 2 is -0 dB relative to that level at port 1, which can be checked by looking at the signal level at node P1 in the model. Basically, V(P1) = V(P2) meaning there's zero loss in the "lossless" transmission line model.

[joeqsmith]

Apparently it switches back and forth between measuring S11 and S21 for each frequency point.

Three measurements.  Port1 incident and reflected along with Port2.  I did not try to disable the S21 measurement as I didn't see it in the firmware.   

If I comprehend your post correctly, you're measuring the low cost VNA, with a quality PNA.

Yes

I fail to make sense of what your are showing, a switching that is apparently every few MHz or so across the frequency sweep, and we fail to see that when self-measuring the port 2 input impedance of the low cost units. That's too slow for the S11/S21 switching. So, what do you think that is?

It's the asynchronous switching of the low cost VNAs, which I can't seem to disable from firmware. 

Just for giggles, could you use the PNA to measure the output impedance of port 1 on the low cost devices?

It's a 2-port, 1 path VNA.  Port 2 is an input only.  Port 1 will drive the output.   So no. 

[gf]

Just for giggles, could you use the PNA to measure the output impedance of port 1 on the low cost devices?

It's a 2-port, 1 path VNA.  Port 2 is an input only.  Port 1 will drive the output.   So no.

@Fred, with a (calibrated) full 2-port VNA, the reported S_xy are already compensated for impedance mismatch at ports 1 and 2, so it does not matter whether the ports have exactly 50 Ohm or not. They don't - it is difficult to make them exactly 50 Ohm over a wide frequency range. The calibration and error correction takes care of the deviation.

But with a 2-port, 1-path VNA (aka. T/R VNA), only the source mismatch (at port1) can be compensated by the calibration and error model, but not the load mismatch at port2. For one-port measurements, already the SOL calibration at port1 does this, and for 2-port measurements, "Enhanced Response calibration" takes care of source mismatch (my NanoVNA V2.2 also offers this option).

To mitigate the load mismatch, you can add a (good) attenuator to the end of the port2 cable, and calibrate at the end of the attached attenuator. Then the calibration plane is established at the end of the attenuator, and the cable and attenuator are still calibrated out. Of course you have to renounce some S21 dynamic range when you do that.

There are two special cases where a 12-term error correction is still possible with a 2-port, 1-path VNA:

1) If the DUT is insertable at the two calibration planes in reverse direction (IOW, if both connectors of the 2-port DUT are the same type and sex), you could measure the DUT twice (in forward and reverse direction) and do full 12-term error correction with the combined measurements.

2) If the DUT is known to be reciprocal and symmetric, then a Fake Flip error correction can be done, w/o actually flipping the DUT.

Both are not supported by the firmware, so you could only do it with an external program. [ I think Joe's program also supports (1) with an automated DUT flip via external transfer relay, so that no manual flip is required. But better Joe should comment on that. ]

For more details, see
https://scikit-rf.readthedocs.io/en/latest/examples/metrology/Calibration%20With%20Three%20Receivers.html

Btw, you said that your DUT is a coupler. So it is not a 2-port, but actually an N-port, with N > 2. For full characterization of its NxN S-parameter matrix, you would actually need an N-port VNA. [ It is however possible to calculate the full NxN S-parameter matrix from (full) 2-ports measurements of each port pair. See also https://scikit-rf.readthedocs.io/en/latest/examples/metrology/Measuring%20a%20Mutiport%20Device%20with%20a%202-Port%20Network%20Analyzer.html. ]

[joeqsmith]

Recently I watched Picotech's sales training videos for their VNAs.  One story they told was how a competitor was looking at how good their port matching is.   

Return loss on my old 1970s HP isn't very good: 
https://accusrc.com/uploads/datasheets/6274_8754A.pdf

The old 2000's Agilent is much better:
https://www.testequipmenthq.com/datasheets/Agilent-E8357A-Datasheet.pdf

My software doesn't support using M/F cal standards for the full 2-port calibration.  I've thought about adding it for the Agilent, which of course supports it with their software.   

[Fred_B]

@Fred, with a (calibrated) full 2-port VNA, the reported S_xy are already compensated for impedance mismatch at ports 1 and 2, so it does not matter whether the ports have exactly 50 Ohm or not. They don't - it is difficult to make them exactly 50 Ohm over a wide frequency range. The calibration and error correction takes care of the deviation.

Yeah, I thought of that after I made the post. What ever impedance it is is calibrated out.

To mitigate the load mismatch, you can add a (good) attenuator to the end of the port2 cable, and calibrate at the end of the attached attenuator. Then the calibration plane is established at the end of the attenuator, and the cable and attenuator are still calibrated out. Of course you have to renounce some S21 dynamic range when you do that.

I've discussed this on the nano forum already. Adding an attenuator just sweeps the reflected wave from the mismatch under the carpet so to say. The mismatch and the reflection are still there. The reflection just gets to a greater or lesser extent dissipated in the loss of the attenuator. I would like a better solution, one that preserves dynamic range. Although an attenuator may get me by well enough. We'll see.

Btw, you said that your DUT is a coupler. So it is not a 2-port, but actually an N-port, with N > 2. For full characterization of its NxN S-parameter matrix, you would actually need an N-port VNA. [ It is however possible to calculate the full NxN S-parameter matrix from (full) 2-ports measurements of each port pair. See also https://scikit-rf.readthedocs.io/en/latest/examples/metrology/Measuring%20a%20Mutiport%20Device%20with%20a%202-Port%20Network%20Analyzer.html. ]

Yes, it's a hybrid coupler, so it has 4 ports. And that creates the problem in sight of the hybrid being sensitive to impedances on it's ports. The operating point shifts a couple of MHz when I switch my port 2 VNA cable from port 2 to port 3 to measure the phase and signal balance. Shifting the operating point also shift the signal levels on the ports and so that makes tuning the hybrid more of a problem than it already is.

[joeqsmith]

I am interested in seeing your hybrid's construction and more details about the design and your application for it.   

[Fred_B]

It's a coupled line hybrid made with lumped element components for use in a circular polarized antenna system that's going to be a commercial product, so that's about all I want to say about it specifically. In general though lumped element hybrids are fairly simple networks. Because they operate at RF frequencies, the difficulty in making them work as desired is getting the component values adjusted away from calculated ideal values to deal the the parasitics of the layout. Therein lies the need for precise measurement.

[joeqsmith]

Only reason I asked for more details is if it would be possible to replicate your findings, now that I see my original V2Plus4 behaves similar to yours.  I have zero plans to start selling antennas or any products. 
 
Symmetrical?   Based on your questions, I assume it's for the 2-meter ham band.   

[Fred_B]

It's for low earth orbit amateur radio satellites. VHF one way and UHF the other. Which way is which, uplink or downlink, depends on the satellite.

[KedasProbe]

I'm trying to calibrate with Sover64 (Windows 7 64Bit LiteVNA64 HW64-0 3.1 FW1.3.07, Build Time Sep17 2023)
but the files seems to be wrong the values make no sense.

I also tried the calibration on the device and in the "saver" app and that is working I see a nice -20dB.
So I assume the calibration fails with Solver64 (attached the calibration file, remove .hex)

It does make measurements though like S21 -60dB too low and -150dB when not connected.
obviously it doesn't support such a big dynamic range so somehow the calibration file is wrong.
When I  use the Ref functionality then I can measure the 20dB attenuation that I connect.

A few screenshots attached to see it, I think I narrowed the problem down to the calibration file.
But when you load the calibration file shouldn't the RAW data stay the same before and after, that is not the case in my test....

So anyone any idea what I can try to fix this or maybe have an idea what I am doing wrong or is wrong?

Thanks

[joeqsmith]

I'm trying to calibrate with Sover64 (Windows 7 64Bit LiteVNA64 HW64-0 3.1 FW1.3.07, Build Time Sep17 2023)
but the files seems to be wrong the values make no sense.

I also tried the calibration on the device and in the "saver" app and that is working I see a nice -20dB.
So I assume the calibration fails with Solver64 (attached the calibration file, remove .hex)

It does make measurements though like S21 -60dB too low and -150dB when not connected.
obviously it doesn't support such a big dynamic range so somehow the calibration file is wrong.
When I  use the Ref functionality then I can measure the 20dB attenuation that I connect.

A few screenshots attached to see it, I think I narrowed the problem down to the calibration file.
But when you load the calibration file shouldn't the RAW data stay the same before and after, that is not the case in my test....

So anyone any idea what I can try to fix this or maybe have an idea what I am doing wrong or is wrong?

Thanks

You didn't provide many details and I'm guessing you run through a full SOLT cal, attach a 20dB attenuator from port 1 to port 2 and my software shows -80dB rather than -20.  Suggesting your thru standard was a 60dB attenuator rather than the supplied thru.  I doubt that is what you are doing but I have no idea.    If that's the case, make a video showing every detail of your approach, from power on to making the measurements.   

***
I am using V1.3.12 firmware but I doubt the firmware has anything to do with what you are seeing.

[KedasProbe]

Yes I did a full SOLT calibration (to make the file, as shown in your manual), just like I did on the device itself and also did with the Saver app, they worked correctly so I don't think there is an hardware problem with the SOLT procedure.
The SOLT is done at the end of the 2 included cables with the included S O L (T is done with male/make part 0dB)

I only used an -20dB to verify, the device itself and Saver did confirm that the 20dB is working properly.
(even Solver64 confirmed -20dB, by using your Ref feature, see screenshots)

Maybe you can provide a less than 1GHz calibration file (for LiteVNA), I know I can't use it but it would confirm that it is working in the right range, then it's only making the file that is the cause of the problems. (my cal file is attached)

[joeqsmith]

From what I have seen the LiteVNAs are consistent enough  you should be able to load my cal file and get something meaningful.    You never state what you use for a model.  My software defaults to ideal but I have seen people attempt to use their own models.   Assuming you are using the ideal,  I ran through the same test.   Measuring a 20dB attenuator with 801 points, no calibration.  We get the same results.   I then perform a SOLT using 1001 points and leave the thru standard attached which shows 0dB as expected.  I then remove the thru (port ports are now floating) and measure 80dB as expected.   I then attach a 20dB attenuator and measure 20dB as expected.

I have attached my calibration file. 

***
Loading your cal file, I get the same results you are seeing.  With you having tested with the device stand alone and getting correct results, we can assume the standards are fine.  This suggests there is something wrong with how you are performing the SOLT.  Provide more details about what you are doing and I am sure we could sort it out.

[KedasProbe]

Thanks for the file and the fast response, I tried your file and that is working just fine (with my -20dB)
(and no nothing custom yet)

Tomorrow I will try to make a few more SOLT files again to see if the problem remains maybe I made a mistake, I don't know... I let you know.

[joeqsmith]

Did you use the ideal model or try to changed things?  Post a screen shot of what you are using (Setup/Diagnostics, Calibration Terms).  If you load your calibration file, you will see that the coefficients are all bad.  Even the SOL is not correct.  The software wrote a readable file so it seems that the data was bad after the cal and not a problem when saving the data to the file. 

I've seen people post invalid information on models and others trying to use it to I guess, improve accuracy without understanding what they were doing.  I changed my software to allow these people to enter bad data.   Just be aware of that.   You went through the manual and followed the procedure.  I wouldn't think you would start out by making changes like this before you learned to use the software but you have never provided any details. 

I can tell you that the software is fairly old and is used regularly.  Calibration is common and I have not yet seen a problem with it.  There was a viewer claiming that my calculations when using waveguides was wrong but I think I put that to bed by comparing the results with my old Agilent VNA.   Outside of that and the people using bad models are the only things I can remember coming up. 

[joeqsmith]

So anyone any idea what I can try to fix this or maybe have an idea what I am doing wrong or is wrong?

I had a look at the your calibration file and there are a few things I notice.  First, you had the short installed for every standard rather than the SOLT.  The next thing I notice is the values are not changing. 

Having gone through the manual you know that the software does very little to prevent the user from causing themselves problems.  As I have stated many times, this is because I don't want the software to limit my use of it.  For example, if I tell the software to sweep 20TH with a 300MHz VNA, the software assumes you know what you are doing and is not going to prevent that.  If you tell it to sweep from 140mHz with a span of 20mHz, guess what, that is exactly what it tries to do. 

I can replicate your calibration file easy enough.  I setup the VNA the way you have it, install the short, turn off the sweeping, then run the calibration.  The software does exactly what  you request and runs the cal with the last data recorded, which was the short.  The user could insert all the standards when prompted, but because sweeping was turned off, it gladly saves the last recorded data for each standard.   

Of course, you are able to read the 20dB using the relative measurement, which means that you turned the sweeping back on after running the calibration with the sweeping turned off.

The odd thing for me is why anyone would think that that disabling sweeps while trying to run the VNA is logical.  So, maybe there is some other way to make this happen but I am not seeing it. 

But when you load the calibration file shouldn't the RAW data stay the same before and after, that is not the case in my test....

The raw data you are looking at is after applying the corrections which includes the reference plane compensation and any averaging.     

[joeqsmith]

I remember another user who had a similar problem:

https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4067353/#msg4067353

[KedasProbe]

I remember another user who had a similar problem:

https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4067353/#msg4067353

Yes, that was the problem, Sweep must be turned on before you start the calibration.
It wasn't in the manual (at least not the parts that I read) and it is the opposite of what the Saver app requires, Saver even gives a warning that the Cal cannot start until you disable the continuous sweep.
I think that makes sense since the Cal procedure wants to take control of a few single sweeps, but obviously you can write code however you want, works just fine when you know how to set it up.

You can also just turn it on at the start of the cal and turn it back to the previous state after calibration, but since this isn't a commercial software you probably couldn't care less
Still, it's the availability of your software that made buying the LiteVNA an easier choice for me.

Thanks for the Help problem solved

[joeqsmith]

Yes, that was the problem, Sweep must be turned on before you start the calibration.  It wasn't in the manual (at least not the parts that I read) and it is the opposite of what the Saver app requires, Saver even gives a warning that the Cal cannot start until you disable the continuous sweep.

I can believe there are a lot of what I consider common sense details not included in that document.  Yes, I could add warnings to try and guide users.  But I'm not going waste their time pointing out the obvious.   Of course, I have created several videos demonstrating how to use the software as well.  It's up to users to take advantage of them or not. 

I have never used Saver outside of looking at it for a video I made.  It was very ham'ish which I'm sure the hams appreciate.  My advice is if you like how Saver runs and it does everything you need, just use Saver.  You're wasting your time (and mine) pointing out my software doesn't function like it.   

You can also just turn it on at the start of the cal and turn it back to the previous state after calibration, but since this isn't a commercial software you probably couldn't care less

No doubt, I can control the VNAs within the limitations of the firmware.  I certainly care how my software drives.  Maybe more to your point, I dare say in some cases I even care what others have to say about it enough to make changes. 

12. Getting Started
...
12.5 Displaying Data
The software will default to a center frequency of 10MHz with a 2MHz span and 201 data
points (Frequency spectrum shown in Figure 11). The V2+ was programmed with these
defaults when the connection was made. The V2+ is actually sweeping at this time. Select the
Sweep button and the software will begin collecting data from the V2+.

[joeqsmith]

Looking at my code, it doesn't check to see if you have the VNA linked up before calibration as well.   While it seems obvious that you would need it to be linked to run a cal, I bet for some, that too isn't obvious.  I suggest both states would need to be checked.   

[joeqsmith]

I have added a check for both the link and sweep.  The software will report the errors to the user and will attempt to correct them.  I don't see this being a problem for me as the only time I can think of that I have attempted to run a cal without sweeping was to replicate the problem.   

There are many other settings that also need to be set prior to running the calibration.   The software does have a set of defaults and the user can change and save them but maybe if they have not created a defaults file, we should force that condition as well? 

Keep in mind, I have added color coding to easily detect what mode the VNA is in, auto region detection, allowing the use of 0s in the calibration models, allowing 0's in the Touchstone files to allow importing from that QT software.   Like above, all of these were added to help guide the user so I am asking what else do you feel should be added to prevent the user from making mistakes without limiting the use of the software?   

Any users are free to comment.

[joeqsmith]

Based on the lack of any feedback, I assume there are no other problems, or at least none that users want to discuss.  Based on that,  I have updated the repository to include 4.05


4.05, 12/31/2023
Twice now people have reported problems when calibrating.  In both cases users disabled sweeping, disabling data collection.   The software previously allowed this and used the last data collected.   Apparently based on how some other software works, these users expected this software required them to disable sweeping to calibrate.  This software now warns the user if a link has not been established or sweeping is disabled.  It will then attempt to connect to the VNA and enable sweeps prior to beginning the calibration.   

4.04, 10/14/2023
Move RefPlaneComp from state1 to state0.   Allows function to be used for Touchstone export.

4.03, 09/23/2023
Use calibration standard connector type to determine if we are running a waveguide cal or coaxial rather than the externder.  Allows waveguide calibration without the extender. (Lite supports any harmonics)
Add Window, FilterType, MarkerIndex, Units,  to Plot trigger
Add plot trigger to TDR cursor release.

[joeqsmith]

Prompted by a viewer, finally compared the lastest LiteVNA 64 hardware with the previous version.  Looks like they made a few hardware changes.