NanoVNA Custom Software

[Pinörkel]

I have stumbled over a possible easy to fix bug in the Solver64 step and impulse response graph display. Apparently, when saving curves via the store button, the saved impulse curves, as opposed to the live sweep impulse curve, are not displayed in the right hand side impulse coordinate system, but in the left hand side step response coordinate system. This can be seen when displaying the live and one saved impulse response and then showing and hiding one step response, while Y auto-scaling is on.

[joeqsmith]

I have stumbled over a possible easy to fix bug in the Solver64 step and impulse response graph display. Apparently, when saving curves via the store button, the saved impulse curves, as opposed to the live sweep impulse curve, are not displayed in the right hand side impulse coordinate system, but in the left hand side step response coordinate system. This can be seen when displaying the live and one saved impulse response and then showing and hiding one step response, while Y auto-scaling is on.

Good catch.  The TDR/TDT memory was an after thought and because I seldom use the impulse, I missed setting the graphs to their proper scales.  This is simple to correct, and is already implemented. 

I doubt I will release 5.10 until after I run that T-Check experiment as I am expecting to run into other changes I want to make.   As it stands 5.10 has the following changes:

Update readouts when loading S2P files
Combine stability trigger to other cursor handler, all cursors now track
Change 2-Port  Adv. Plots to SI units
Change TDR/TDT impulse curves to use the amplitude scale
Swap TDR/TDT samples/seconds graph selection

***
When I looked at the scales, I had not noticed that the samples and seconds were swapped. 

[Pinörkel]

I may have another simple one: Due to a hint in my other thread, I experimented with the port extension setting. If I just load an SnP file in Solver64, this setting is not applied (e.g. to the step and impulse response graph) to the loaded data, though it could be useful if it was. It is useful that it is not applied to saved TDR traces, so on can compare the effects of different port extension settings. However, since SnP files are loaded as if they were obtained by a live sweep, I would intuitively expect that port extension setting also could be changed on them live or at least be applied on loading.

And maybe a complicated one: In my other thread here I noticed that the TDR graphs in Solver64 jump up and down significantly when switching window functions as if the whole curve is scaled vertically with the Y axis zero value as the scaling center. This does not happen when processing the same data in the VNA Tools. There, only the high frequency components of the TDR signal change in intensity but there is not any global Y scaling happening. Is there a possibility that, maybe in connection with some data point interpolation, the zero point in the complex space is not computed consistently when using different window functions, resulting in a global offset for all frequency components, which then scales the values in real space?

[joeqsmith]

You're opening a can of worms...   
https://www.merriam-webster.com/dictionary/open%20a%20can%20of%20worms

I may have another simple one: Due to a hint in my other thread, I experimented with the port extension setting. If I just load an SnP file in Solver64, this setting is not applied (e.g. to the step and impulse response graph) to the loaded data, though it could be useful if it was. It is useful that it is not applied to saved TDR traces, so on can compare the effects of different port extension settings. However, since SnP files are loaded as if they were obtained by a live sweep, I would intuitively expect that port extension setting also could be changed on them live or at least be applied on loading.

That is correct.  You can change the extension when collecting data but not when post processing.  This is also true for calibration standard coefficients, error terms,  smoothing, averages, isolation, maybe others.   

Import was added for debugging my software.  I was using AppCAD (old HP software) to view Touchstone files.  It was a bit too restrictive and someone here pointed out METAS.  I have used it ever since as my main post processor.   It too has some limitations I don't like, for example, the lack of a Smith chart.   There are also various simulation tools as well that can be used to post process your data.  You may want to have a look at what it out there.  These tools would allow you to do much more than just trim the port extensions. 

And maybe a complicated one: In my other thread here I noticed that the TDR graphs in Solver64 jump up and down significantly when switching window functions as if the whole curve is scaled vertically with the Y axis zero value as the scaling center. This does not happen when processing the same data in the VNA Tools. There, only the high frequency components of the TDR signal change in intensity but there is not any global Y scaling happening. Is there a possibility that, maybe in connection with some data point interpolation, the zero point in the complex space is not computed consistently when using different window functions, resulting in a global offset for all frequency components, which then scales the values in real space?

As I have stated and demonstrated, the LiteVNA really doesn't have the frequency range to provide you with enough resolution to look at connectors.   There is no getting around that.  There is more to the filter than just the window type.   There is also the number of taps, cut off frequency.....  These other settings are hidden from the user.    Sadly, I don't have any standards.  What I did was fabricate a homemade 70mm airline Beatty standard.  I then set the window to rectangle and set the filter up to get me as sharp of an edge as possible without it ringing.  The software then can measure the FWHH of that mismatch with a reasonable accuracy.  I would have no way of knowing how much error is my standard, setup, software.....    It seems to always read high by a millimeter but is is very possible that the standard is off by that much.       

I could expose all of these filter settings and allow you to save them into the defaults file.  You could then play with them to your hearts content. 

[joeqsmith]

Getting back to the T-Check experiment,  shown are my two connector savers and standards that I plan to use.   The connector savers are like I previously mentioned, and SMA M/F attached to a 3.5mm M/F.   These adapters are sacrificial.  Note they are marked 1&2 for their port designation.

I had mentioned I had attempted to make a T-Check on FR4, then using a modified coaxial adapter.  These did not work very well.  The plan this time is to use standard components to make the T-Check.  The part on the left is a very low cost Chinese made  T.  I think these were four for $20 or something like that.   Attached is the load that was supplied with my V2Plus4 VNA. 

The second T-Check on the right is using a MA-COM T and my third worse, Mini-Circuits ANNE terminator. 

The next step is to measure both T-Checks with my Agilent VNA which will be calibrated using the ECals that were setup using a known set of standards I had borrowed.  Again, the end goal is to see if I can improve on the T-Check measurement using the LiteVNA64.  The R&S paper provided limits: 

Any deviation from 100% indicates inaccuracies of the network analyzer. Deviations of up to ±10% are considered as minor (green range). Deviations between 10% and 15% are still acceptable (yellow range) and those more than 15% should not occur in a good vector network analyzer after careful system error calibration (red alert).

https://www.rohde-schwarz.com/ca/applications/t-check-accuracy-test-for-vector-network-analyzers-utilizing-a-tee-junction-application-note_56280-15519.html

Up till now, any test I have attempted with the low cost VNAs has been limited to I think 500MHz using that 15% rule.   
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg5656063/#msg5656063

If these T-Checks perform well with a good VNA that has been calibrated properly, the next step will be to try an characterize the SOLT standards provided with the V2Plus or LiteVNA using the Agilent, then see if we can use these coefficients with my software to improve the calibration. 

[joeqsmith]

I damaged another one of the supplied cables.   The one with the yellow tape came with the V2Plus4 and was damaged when a setup I was working on slid off the desk pulling the VNA down with it.  The other cable met a similar fate.  It doesn't take much to damage these where they are no longer stable.  I bought some 50cm RG402 cables off Amazon for $11 a set.  These are longer and stiffer than the stock cables. They only rate these for 3GHz but I have tested them with the LiteVNA at 6GHz. 

The T-Check test requires a full 2-port measurement.  I plan to use the same cables and transfer relay as before as I do not believe this is the main source of my errors.   

[joeqsmith]

With low confidence, I ran the M/A-COM + ANNE T-Check up to 2.5GHz.  I was very surprised to see this stayed within +/-3%.  That's the best results I have ever achieved.   It tells us that the the PNA (which I repaired/aligned) and E-Cals which I had created user transfers for, and my cables.... all work decent, at least up to this low frequency.   

I should point out that the software is showing that the PNA has not been calibrated.   This is due to my not yet adding support for the E-Cal.  The PNA is calibrated manually.  It then sends up calibrated data.   The software is just displaying/processing that calibrated data. 

***
Measuring the second T-Check with the low cost T and included V2Plus4 load,  I measured 100 +0/-6%.  Still very usable.   

[Pinörkel]

You're opening a can of worms...   
https://www.merriam-webster.com/dictionary/open%20a%20can%20of%20worms

OK sorry, point taken. Then I will keep the worm cans closed. No further bug hunting.

As I have stated and demonstrated, the LiteVNA really doesn't have the frequency range to provide you with enough resolution to look at connectors.   There is no getting around that.

Yes, due to your good explanations, I already have come to terms with this. However, the effect I tried to describe does not seem to be resolution related.

There is more to the filter than just the window type.   There is also the number of taps, cut off frequency.....  These other settings are hidden from the user.

Ah, I thought those were the ones already available in the "Filters" tab.

Sadly, I don't have any standards.  What I did was fabricate a homemade 70mm airline Beatty standard.  I then set the window to rectangle and set the filter up to get me as sharp of an edge as possible without it ringing.  The software then can measure the FWHH of that mismatch with a reasonable accuracy.  I would have no way of knowing how much error is my standard, setup, software.....    It seems to always read high by a millimeter but is is very possible that the standard is off by that much.       

I could expose all of these filter settings and allow you to save them into the defaults file.  You could then play with them to your hearts content.

So, you basically made a manual impulse response optimization, like when calibrating an oscilloscope, which sounds totally fine to me. I may be wrong there, but I do not think the observed behavior is related to some kind of real world calibration but of mathematical nature. I had a second thought on my first theory of something with the DC zero value being wrong, but I do no longer think that this is the case. This would have Y-offset the whole curve and not just caused a scaling effect. I will have to think about this further to understand it. Thank you for your explanations. Just to visualize the effect better, I have created some screenshots of the behavior that occurs when just switching filter functions in Solver64 and VNA Tools on the same data.

[joeqsmith]

OK sorry, point taken. Then I will keep the worm cans closed. No further bug hunting.

Bug hunting is fine and appreciated.  The two items you mention are by design.  To change how the software works would require changing the architecture.   Not trivial but could certainly be done.   If I had a use for it, or it was some sort of commercial money maker,  I would certainly consider it.   

As it stands today,  the future for Solver64 is bleak.  With a perpetual license for Labview now costing more than $15,000 USD,  it isn't something I would consider for home use.  Eventually I will loose access to the PC I am using for the builds.  Once that happens, the software is at the end of life.  I doubt Solver is popular enough that the user base could support it, but I think I would run a pole to see if there was enough interest to donate towards the purchase of a license.   

The reason I do not ask for donations today or accept any other income is to prevent any bias in my reviews, or what I work on.  It's a hobby for the fun of it, not a business.

Ah, I thought those were the ones already available in the "Filters" tab.

Notice how these are titled "Smooth".   These settings setup the smoothing filter selected in the main page.  They have nothing to do with any of the time domain measurements.   

I would need to make something like this for the time domain, which today the software does not have.

[gf]

Notice how these are titled "Smooth".   These settings setup the smoothing filter selected in the main page.  They have nothing to do with any of the time domain measurements.   

I would need to make something like this for the time domain, which today the software does not have.

Basically, a non-rectangular window function already does smooth the time domain trace as it acts as lowpass filter. Multiplication with a window function in the frequency domain is equivalent to a convolution with the FIR filter kernel ifft(window_function) in the time domain.

[joeqsmith]

Notice how these are titled "Smooth".   These settings setup the smoothing filter selected in the main page.  They have nothing to do with any of the time domain measurements.   

I would need to make something like this for the time domain, which today the software does not have.

Basically, a non-rectangular window function already does smooth the time domain trace as it acts as lowpass filter. Multiplication with a window function in the frequency domain is equivalent to a convolution with the FIR filter kernel ifft(window_function) in the time domain.

Obviously. 

[joeqsmith]

I may be wrong there, but I do not think the observed behavior is related to some kind of real world calibration but of mathematical nature. I had a second thought on my first theory of something with the DC zero value being wrong, but I do no longer think that this is the case.  ....  Just to visualize the effect better, I have created some screenshots of the behavior that occurs when just switching filter functions in Solver64 and VNA Tools on the same data.

Increasing the lower cutoff frequency would allow Solver to behave more like METAS where changing the window type would have less of an effect.  Currently I really step on it.  It could all be exposed and you could tune it to your liking.  Of course, there is always other more feature rich viewers available.

Today, this filter only effects the displayed time domain data and has no effect on exported Touchstone files.   Smooth, average, IFBW all effect the data collection. 

[joeqsmith]

Looking at the low cost T check from 300k to 9G.  Over the 6.3G range of the LiteVNA64, it stays within +1/-6%.  Well within the +/-10% margin.   

   

[joeqsmith]

Next, using the same expendable adapters with the PNA, I measured the two sets of standards supplied with the LiteVNA64 and the V2Plus4.   Shown is the normalized data comparing the two sets of shorts and opens.   The difference is minimal and I suspect they were supplied by the same manufacture.   

I plan to continue this little experiment using the modified standards supplied with the V2Plus4 along with my sorted load as these are what I have used for all of my previous tests. 

[joeqsmith]

After measuring all four standards I let METAS perform the fit.   This data was then fed back into Agilent's CalKitEditor to create a new file for the PNA.   The data was also entered into Solver. 

Next step, use this new calibration file and standards to calibrate the PNA and remeasure the T-Check.   I also dug out the Transco transfer relay.   

[joeqsmith]

I had forgotten that the newer calibration editor will cause an out of memory error when trying to import the file it created into my PNA.   The older editor on the left will also produce the same error when trying to import the files.

After creating a valid file, running back through the calibration using the V2Plus4 standards, then measuring the T-Check, it does stay within +15/-7% but that's a long way off from our +7/-6% we initially measured with the E-Cal.   I suspect something went wrong with the process.   

I think my initial T-Check tests were at 50MHz, then 500MHz.   Running the T-Check with the LiteVNA + Transfer relay is really bad compared with the PNA.  Maybe it could be used to 3GHz on a stretch.  Still, it's an improvement.

[joeqsmith]

I repeated all of my measurements and recalculated the coefficients with METAS.  As before, poor performance.

It took some effort to get standards that were good enough to be characterized using Mario's Matlab script.  It would not converge.   I suspect with these low cost standards being so non-linear, we just can't get a good fit.   Couple that with the Lite's lower performance above 3GHz, I think we are just asking too much from such a low cost device.   Still, even feeding the METAS results back into the PNA, then calibrating with the low cost standards,  results are poor.  I think the writing is on the wall, we need better standards.

What I could do is maybe run smaller slices.  Characterize the standards over a much smaller frequency range where they would have a flatter response.   

If you have attempted to characterize these low cost standards over the entire working range of the Lite, and had good results,  I would like to hear from you.   

[joeqsmith]

Looking the the Open standard supplied with the V2Plus4, measured with the calibrated Agilent.   

Left, showing the METAS VNA tools fitter.   The coefficients it selects were entered into Solver, then the polynomial was plotted along with the original data.   Basically, closing the loop on Solver's math. 

I think the only way to use the low cost standards and improve the T-Check is to ditch the polynomial fit.  This means adding support to Solver to directly support the measured data of each standard.   

[joeqsmith]

I added support to my software that allows the use of the measured data from the Agilent for the standards rather than the polynomial.  Results with the T-Check are still poor when measured with the LiteVNA.   

[joeqsmith]

I repeated all of my measurements and recalculated the coefficients with METAS.  As before, poor performance.
....

Still, even feeding the METAS results back into the PNA, then calibrating with the low cost standards,  results are poor.  I think the writing is on the wall, we need better standards.

I had gone back over all of my work a second time and noticed when I had used the calibration editor to create the file for the Agilent. I had transposed the 2nd and 3rd coefficients for both the short and open.      

After correcting the file, I calibrated the system again using the V2Plus4 standards with sorted load.  This time when I measured the T-Check, it was well within +/-10%.   

Also shown comparing the S-parameters of the T-Check when measured with the E-Cal and with the METAS fitted model. 

It certainly suggests even these low cost standards are not my limitation with the LiteVNA.  Yes, I rechecked to make sure I hadn't transposed the data in Solver... 

***
Note, the error can be seen in the previous post.   The older CalEditor uses the same arrangement.   I think being so used to reading left to right, top down, I could look right at the problem and not see it.   Too funny.   

So far, this was all done using Agilent's firmware/software to avoid adding more complications by introducing my software into the mix.    Next step, update my software for the Agilent and see if I can get the T-Check to perform well.   

[joeqsmith]

Basically the Solver software, both T-Checks and METAS coefficients have all been verified with the Agilent.  When using Solver to error correct the Agilent, the T-Check provides results well below +/-10% over the full 9GHz range when using the METAS fitter, or the measured S-parameters from the Agilent.

I updated the LiteVNA version of Solver and repeated the tests.   While I am using different cables, adapters and adding the transfer relay,  these parts are all decent quality.   The big difference is we now have a $120 VNA.   

Shown using the MA/COM T + Mini-Circuits ANNE for the T-Check.   Solver is using the METAS fit data and sweeping from 300k to 6.3GHz.  Once again, using the +/-10% margin, about 3GHz is the limit.  Using the +/-15%, maybe 3.5GHz.   Using the S-parameters measured with the Agilent rather than METAS fit data, there is little improvement.  I also wasted some time added a 6dB attenuator to the LiteVNA's Port2 to try and improve the port match.   

***
When using the Agilent to prove out my software, I found two math errors.  Since getting the Agilent, I started using its built-in calibration routines so I never saw the problem with my software.   While I do still use these error corrections with the low cost VNAs, their poor performance masked the problems.  These corrections are what caused the difference from the previous test with the T-Check and LiteVNA.     

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

[joeqsmith]

Friend Flipper sent over the latest LiteVNA 64.  Shown comparing the three revisions I have.  Looks like they have continued to improve it over the entire operating range. 

Price has gone up about $40 USD but I would say it's still well worth the price.   

[joeqsmith]

Comparing the second unit that belongs to Flipper with mine.  This data was taken using their cables and cal standards, so there are differences in the setup.  Still, very similar results and shows that the performance improvement isn't unique to a single unit. 

[joeqsmith]

With the lower noise, I wanted to see what improvement we would get with the  T-Check.  Shown with the same vertical scale and same M/A-COM T-Check.   I did not take the time to torque anything including the cables but this is a noticeable improvement in the mid range.   I'll repeat this test later using the full 9.3GHz range with everything torqued properly. 

***
Repeating the calibration, torquing the connections and allowing the VNA a half hour to warm up made little difference.  The 3.2 hardware is measurably improved over the previous revisions, but it's not good enough to pass the T-Check anywhere near the 6.3GHz upper end.   Still, using the +/-10% criteria, it's trivial to verify the calibration to 3GHz.  For something that fits in your shirt pocket and is very reasonably priced, impressive.

I've also attached the data that was provided for the LibreVNA compared with the latest 3.2 revision. 

[joeqsmith]

Comparing the latest LiteVNA 3.2 with data that was provided for the Siglent SVA1032.