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.