VNA for cable characterization

[tggzzz]

My ignorance is unlimited!  So you use the common for a decimal and a period for a separator.  Crazy stuff.   I think this is a few minute change.  Let me test it first and I'll upload it for you to try.

That's why I18N libraries are used. (I18N is internationalisation).

Wait until you see how numbers are written in the world's most populous country: search for "crore" and "lakh", and see how 3*10⁶ is expressed.

[tggzzz]

... to use English UI language, are set to use German date and number formatting and of course metric units. ...

The nice thing about date (and times) is that there are so many standard forms to choose from. See ISO8601

[Pinörkel]

I've made the changes and tested both the export and import on both the 32 & 64-bit systems using both decimal formats.  It does what I expect but that by no means suggests it solves your problem. Try it and let me know.

I just tested export and import and if there is anything different than in the previous version, I am not able to spot it. Exported files, as one would expect, still contain the decimal format set in my system settings and imported files have to be in that format to be read properly. I also tested swapping my systems decimal format and the input/output in Solver64 changed as expected. As a result, all "," in the Touchstone files still have to be replaced with "." after export, so other programs like METAS VNA Data Explorer would read the files, which always expect the English number format.

Apart from that I noticed that the time domain x-autoscaling is on by default again, which is nice. Thanks for that.

[joeqsmith]

I've made the changes and tested both the export and import on both the 32 & 64-bit systems using both decimal formats.  It does what I expect but that by no means suggests it solves your problem. Try it and let me know.

I just tested export and import and if there is anything different than in the previous version, I am not able to spot it. Exported files, as one would expect, still contain the decimal format set in my system settings and imported files have to be in that format to be read properly. I also tested swapping my systems decimal format and the input/output in Solver64 changed as expected. As a result, all "," in the Touchstone files still have to be replaced with "." after export, so other programs like METAS VNA Data Explorer would read the files, which always expect the English number format.

Apart from that I noticed that the time domain x-autoscaling is on by default again, which is nice. Thanks for that.

I already regret my last improvement suggestion, since it lead to the time domain graph defaulting the X-autoscaling to being off, resulting in several extra clicks, every time I use it.

Odd, as that change was made on the 9/2/24 in version 5.07. 
https://www.eevblog.com/forum/rf-microwave/vna-for-cable-characterization/msg5627253/#msg5627253

Interesting is I downloaded the latest version and tried it with German settings and it does not work.   Odd as the version number is correct.   Let me have a look.

[joeqsmith]

Something went wrong when I copied the files to the second PC.  You were running the same version.   I  went through the rebuild again and uploaded.  I just tried to download the new files back to the other PC and it seems to work.   Should display 5.09.   

[Pinörkel]

Something went wrong when I copied the files to the second PC.  You were running the same version.   I  went through the rebuild again and uploaded.  I just tried to download the new files back to the other PC and it seems to work.   Should display 5.09.

Now, it is working. So much easier to get files into METAs. Thank you very much.

[joeqsmith]

Something went wrong when I copied the files to the second PC.  You were running the same version.   I  went through the rebuild again and uploaded.  I just tried to download the new files back to the other PC and it seems to work.   Should display 5.09.

Now, it is working. So much easier to get files into METAs. Thank you very much.

Most of the feedback I receive is from people who struggle with the basics.  It's rare to discuss problems like this that actually could be addressed.  So thank you for bringing it to my attention, and taking the time to test it.   

Does working suggest you have tested both the export as well as the import and it now works as you expect?   Both import and export of S1P and S2P should now work the same.

[mawyatt]

In practice, we "Zoom in" on time-domain ranges using the Inverse Chirp Z transform. Zero padding is feasible but increases computation time. See my write-up at https://coppermountaintech.com/inverse-chirp-z-transform-for-vna-time-domain-processing/ for more information.

Very powerful algorithm that few folks know about, good to see the CZT and ICZT hasn't been totally forgotten and displaced by the FFT!! Back in 1980 we developed a handheld special real time SA (3~4watts) based upon the CZT, utilized custom very long CCD devices as the Complex Convolvers. This was developed for finding and "Zooming In" on certain signals of interest.

Going the conventional DSP and FFT route would have taken the equivalent of 1/3 of a Cray One Computational Power at the time, which wasn't going to yield a handheld!!

Nice article

Best,

[Pinörkel]

Does working suggest you have tested both the export as well as the import and it now works as you expect?   Both import and export of S1P and S2P should now work the same.

By working I mean that exporting s1p and s2p files now produces files that can be read by third party software out of the box and imported in Solver64 again. I also tested this by disabling sweeping and manually clearing all graphs in between. Loading s2p files jumps me to the 2-port-plot display, but that has never displayed any data for me (maybe because the liteVNA is not a 2-port-VNA?).

By the way, I have a related question regarding the "Export Data to Clipboard" function in the graphs. Is there any special reason (besides it being the display format of the graphs) that you chose to export numbers in the compact number format rather than the scientific number format?

[joeqsmith]

Does working suggest you have tested both the export as well as the import and it now works as you expect?   Both import and export of S1P and S2P should now work the same.

By working I mean that exporting s1p and s2p files now produces files that can be read by third party software out of the box and imported in Solver64 again. I also tested this by disabling sweeping and manually clearing all graphs in between. Loading s2p files jumps me to the 2-port-plot display, but that has never displayed any data for me (maybe because the liteVNA is not a 2-port-VNA?).

If you load the FHX13X_FHX14X.s2p that is located in the touchstone directory I would expect you to see the attached image.  If not, something is wrong.

While the LiveVNA64 and V2Plus4 are both 2-port, 1-path devices, my software supports use of a transfer relay with these along with a 12-term error model.  This is how that T-Check you mentioned is measured. 

If you tell the software to create a 2-port file but you are not using a transfer relay, I think I save S11 to S22 and S21 to S12.   

By the way, I have a related question regarding the "Export Data to Clipboard" function in the graphs. Is there any special reason (besides it being the display format of the graphs) that you chose to export numbers in the compact number format rather than the scientific number format?

Exporting data like you mention is built into LabView.  See the following article:

https://www.ni.com/docs/en-US/bundle/labview/page/exporting-data-and-images.html

[Pinörkel]

If you load the FHX13X_FHX14X.s2p that is located in the touchstone directory I would expect you to see the attached image.  If not, something is wrong.

Ah, yes that works. This file is quite interesting, since it is also the only file METAS can display a TDR graph for. It does not do that for any s1p or s2p file I produced with Solver64. I tried to figure out the reason for the s2p files, but both files have nine columns and a correctly specified option line:

Code: [Select]

# Hz S DB R 50 (Solver64)

Code: [Select]

# GHZ S MA R 50 (FHX13X_FHX14X.s2p)

Nothing I tried, like modifying the option line, swapping the line endings, removing the S12 and S22 columns or defining additional SNP file parameters is able to make the Solver64 file work in Time Domain Mode in METAS and nothing is able to break the FHX13X_FHX14X.s2p file so it no longer works. Since METAS can display all S parameter data in a Solver64 exported file it should be no read error. Also, it does not seem like METAS can not display time domain information for files with DB format. If I define the option line in FHX13X_FHX14X.s2p to be DB, METAS can still display time domain graphs. Very confusing.

If you tell the software to create a 2-port file but you are not using a transfer relay, I think I save S11 to S22 and S21 to S12.   

Yes, that is how my saved files look like.

Exporting data like you mention is built into LabView.  See the following article:

https://www.ni.com/docs/en-US/bundle/labview/page/exporting-data-and-images.html

Ah, that explains it, thank you. The thing with this format is, although it is nice to read for a human, almost no other software supports it. Especially no Excel clone. I fiddled together some formula to convert it, but that involves creating an extra column for each data series and applying the formula, before the values can be processed further.

[joeqsmith]

If you load the FHX13X_FHX14X.s2p that is located in the touchstone directory I would expect you to see the attached image.  If not, something is wrong.

Ah, yes that works. This file is quite interesting, since it is also the only file METAS can display a TDR graph for. It does not do that for any s1p or s2p file I produced with Solver64. I tried to figure out the reason ...

Also, it does not seem like METAS can not display time domain information for files with DB format....

See attached file for waveguide filter using dB format created with my software with LiteVNA and home made X-band extender. 

Exporting data like you mention is built into LabView.  See the following article:
https://www.ni.com/docs/en-US/bundle/labview/page/exporting-data-and-images.html

Ah, that explains it, thank you. The thing with this format is, although it is nice to read for a human, almost no other software supports it. Especially no Excel clone. I fiddled together some formula to convert it, but that involves creating an extra column for each data series and applying the formula, before the values can be processed further.

I would just post process the Touchstone files.   

[joeqsmith]

S1P files, Open and Short

***
Load METASE and select a file like 70mmBettyAireline.s1p in the Touchstone directory.   Select TDR.  You should see the blank screen.  Now select Control F11.   You should see the errors why this particular file can not be processed.

[Pinörkel]

S1P files, Open and Short

***
Load METASE and select a file like 70mmBettyAireline.s1p in the Touchstone directory.   Select TDR.  You should see the blank screen.  Now select Control F11.   You should see the errors why this particular file can not be processed.

Here, all your files open and display TDR graphs for "Band Pass Impulse" mode, but not for the "Low Pass Step" and "Low Pass Impulse" modes. Ctrl+F11 does nothing for me. However, your command line screenshot was very enlightening. To me it seems like METAS at some point divides the maximum frequency by the number of sampling intervals in the and cannot process further if that does not match the actual largest sampling interval size in the file.

If I change the start frequency to 0Hz before exporting in Solver64, METAS can display all time domain graphs in any mode. The scale on the X and Y axis does not match what I see in Solver64 (even when I leave the velocity factor at 1). Impedance values and lengths are off. Since the length on the X axis in Solver64 matches with the length of my cables when the velocity factor is set right, I would trust Solver64 more at this point.

If I change the maximum frequency in my files by subtracting the start frequency from the last points frequency, METAS can display all time domain graphs in any mode. However in this case, the "Impulse" modes get an additional bump at the beginning and the "Step" mode a frequency dependent drift.

Looks like METAS might have some bugs, but at least the vnatools group does not seem to be very responsive to error reports. Interesting is, however, that it displays stuff before the zero point in TDR mode.

[joeqsmith]

Ctrl+F11 does nothing for me.

Select the Options pulldown and select Console (same as ctrl F11). 

I am currently running 2.8.8875.19141.  Maybe your German settings cause it problems.  You could ask them, or just try using the USA settings and see it it behaves correctly.

[Pinörkel]

Select the Options pulldown and select Console (same as ctrl F11). 

I am currently running 2.8.8875.19141.  Maybe your German settings cause it problems.  You could ask them, or just try using the USA settings and see it it behaves correctly.

Seems like the reduced version called "VNA Data Explorer" that I am using does not have that. I will try to get the full version.
Also, I have added my three experimental Touchstone files to my last post for comparison.

[gf]

Interesting is, however, that it displays stuff before the zero point in TDR mode.

1) Note that the non-ideal, non-zero impulse width (and possibly Gibbs artifacts) introduced due to the VNA's upper frequency limit and windowing in the frequency domain extends from the center of the impulse to both sides. If the impulse is centered at or near t=0, then the impulse shape also extend to negative time.

2) Keep in mind that IFFT is circular, therefore the time axis wraps around, too. Anything you see at negative time could also be wrapped positive time.

EDIT: Also think about the implications when you try to integrate the impulse response on the (circular) time axis in order to get the corresponding step response. The starting point of the integral on the time axis definitively makes a difference.

[joeqsmith]

Seems like the reduced version called "VNA Data Explorer" that I am using does not have that.

Correct.  This is supported with the VNA Tools.   This version of their tools offers some other features as well that may be of interest.  Eventually, I plan to use it to attempt to characterize the included standards for that T-Check experiment.   

The do support a polar plot but sadly, no Smith chart.  The one thing I really dislike is the inability to change the trace colors.  Yellow on white, really difficult to see. 

[Pinörkel]

I slowly get the impression that, even if I had a highly precise characterized calibration set, it would be quite difficult to get precise impedance values from a measurement, as long as the data is not recorded and evaluated by an expensive professional VNA. Every time a transformation to time domain is performed, there are apparently possible differences in the calculation, regarding the data interpolation, integration, different window functions, which all lead to differences of multiple ohms, as can be seen in the differences between Solver64 and the METAS VNA Tools when processing the same data.

Apart from that, I played again with my initial idea of using a BNC calibration set to minimize the number of measured devices around the cable. For this, I modified the Chinese PCB mount connectors, I had bought for playing around. As already mentioned the ring of springy contacts in the male connectors had a too small diameter to make contact with the inner side of the outer contact in the female connectors, which is the reason I had classified the connectors as unusable. Just for verifying if that connection issue was the cause of the bad calibration results, I bent all of the contacts slightly to the outside, so the would be able to make contact. Although the result was the opposite of good mechanical quality (and will still go to the bin), my modified open and short and the good quality BNC terminator from Telegärtner were able to produce a pretty good calibration. It was not even half as susceptible to reconnecting the BNC connectors than I thought.

When comparing my H155 cable using this BNC calibration and another calibration done with the liteVNA SMA set and putting an SMA-M to BNC-F adapter before the cable, I noticed something. Maybe not starting the measurement right at the reference plane of the BNC connector of the cable but at an earlier SMA reference plane is not a bad thing at all. As can be seen in the attached image the green curve taken with the BNC calibration starts right at the top of the peak produced by the BNC connection and then goes down. Since this peak is not symmetrical, there is no way of knowing the correct impedance offset of the values after the peak, especially, since the peak is most likely the place with the highest probability of integration errors. The SMA calibrated white curve includes both sides of the BNC connection and we know from this measurement that the BNC reference place of the BNC connection deviates significantly from 50 Ohms. So in this case the curve is nailed to 50 Ohms at a point where we know for sure it is not 50 Ohms. I also made a copy of the green BNC calibrated curve, changed its color to pink and moved it over the white SMA calibrated curve for better comparison. It seems to match the curve quite closely, except for the peak at the beginning, which is apparently about one Ohm higher. I think, that only one curve can be correct about the height of the peak. But I do not know whether the BNC calibrated curve has a starting artifact or the SMA calibrated one is too flat because e.g. it does not sample the highest position(which the BNC calibrated curve should by design) or there is a sampling/integration error.

[gf]

As I said, it is important where you start to integrate the impulse response in order to get the step response. The integral should include the whole extent of the first impulse. If you have a discotinuity at (near) the calibration plane (t=0), then the first impulse is centered at (near) t=0 and the impulse width extends to negative time. Therefore you should start integrating at a negative point in time in order to include the whole impulse. If the software can only start integrating at t=0, then you can try to shift the first impulse into the positive time region by applying some electrical delay. This works at least with the internal TDR of the NanoVNA firmware. I can't comment how that applies to Joe's Solver as I've never used it.

Furthermore, I'm also not sure if it is a good idea to use a rectangular window function in conjunction with a wideband DUT. The abrupt truncation at the upper frequency limit of the sweep turns an ideal impulse response of the DUT into an impulse with Dirichlet-kernel shape (showing lots of ringing which is not present in reality). So I'd rather use a non-rectangular window function even if it results in a softer (wider) impulse shape (but you'll get less unreal overshoot/ringing in the step response). To show the difference, I've attached the IFFT impulse responses of rectangular (blue), van Hann (brown) and Blackman (yellow) window function. Which one would you consider the best approximation with finite support? Certainly not the blue one. IOW, where would you start to integrate the blue impulse so that the integral includes the whole impulse?

[Pinörkel]

@gf: Thank you for this very useful explanation. So, the filter windows function is basically one of those trade-off choices like it is in computational image processing. Luckily, I bought two SMA port saver in my last adapter purchase, which, as I now realize, can also be used as signal delays. So I made some quick measurements, of my H155 cable with none, one and two port savers inserted between the calibration plane and my SMA to BNC adapter (I will repeat these measurements later with better warmed up equipment). I also did some comparisons between rectangular and Blackman window functions in Solver64 and METAS VNA Tools. The results were quite interesting.

I found that the measurements with one and two port savers in between generally tended to be more alike than the one without additional electrical delays in terms of absolute values for the cable impedance in the non-connectors region of the cable. As I see it, this suggests that working with an additional delay before going to BNC could be favorable in this case. However, this has to be taken with a grain of salt, because I noticed that I am finally in a region where repeatably tightening the SMA connectors properly makes a visible difference (thanks to joeqsmith for hammering that into my brain ). For this, I used my improvised 3D-printed torque wrench and ensured that I used a method, that let me get the same results over and over again, when loosening and re-tigthening the connector. So, I am kind of sure that I am at least sufficiently repeatable there without tightening to a specific calibrated torque value.

The second interesting finding was that using different windows (e.g. Rectangular vs. Blackman) made a large difference in terms of absolute impedance values in Solver64, but nearly no difference in the VNA Tools. In the VNA Tools I only observed less pronounced peaks, kind of like a low pass filter effect. In Solver 64 on the other hand, the mid section of the curve jumps by nearly 1.5 Ohms, which may hint at large integration differences ath the peak caused by the first BNC connection.

Solver64 electrical delay and filter function comparison with three electrical delays (no, one and two port savers inserted behind the calibration plane). The upper three curves are with with Rectangular window function, the lower three ones with Blackman:



The Blackman curves, and this is also true for the Hanning filter, show more pronounced ringing in the step response, which is kind of the opposite of what gf predicted.

One comparison of different filters in VNA Tools. I still have not found an easy way to get time domain loadable s1p files from Solver64 into VNA Tools, so only one curve here. The first image shows Rectangular and the second one Blackman:





Here, the curve with the Rectangular window shows, as predicted by gf, less ringing. Also the low pass components of the curve do not jump up and down, when switching filter windows, like they do in Solver64.

[gf]

no, one and two port savers inserted behind the calibration plane

With "electrical delay" I actually meant a virtual delay, applied mathematically by the VNA software/firmware. I'd be surprised if Solver would not offer "electrical delay" or "port extension" settings, or both. (When using NanoVNA standalone, you can set EDELAY in the GUI.)

I still have not found an easy way to get time domain loadable s1p files from Solver64 into VNA Tools

You mean in conjunction with low pass TDR, or in general? Lowpass mode requires evenly spaced frequency points from 0Hz to f_max. The S₁₁ readings for frequencies below the VNA's lower limit down to DC are usually estimated by extrapolation. Just a guess, but I could imagine that the VNA tools might expect these extrapolated values to be already present in the loaded s1p files if you want to calculate a lowpass TDR?

[Pinörkel]

I just repeated my measurements multiple times and got the same results, except for some really minor deviations.

With "electrical delay" I actually meant a virtual delay, applied mathematically by the VNA software/firmware. I'd be surprised if Solver would not offer "electrical delay" or "port extension" settings, or both. (When using NanoVNA standalone, you can set EDELAY in the GUI.)

Ah ok, my bad. Solver64 indeed has a port extension parameter. If I set it to e.g. -10000 ps, I can actually see the same curve parts as in VNA Tools. If I choose the delay large enough that the curve starts in that flat region at the left, then the resulting curves are very close in amplitude to each other. If I hit that bathtub at the beginning or the subsequent peak, the rest of the curve shifts vertically, which might be an integration issue. That aside, switching filter window functions still causes the curve to hop around in Solver64, while I cannot observer this in VNA Tools.

You mean in conjunction with low pass TDR, or in general? Lowpass mode requires evenly spaced frequency points from 0Hz to f_max. The S₁₁ readings for frequencies below the VNA's lower limit down to DC are usually estimated by extrapolation. Just a guess, but I could imagine that the VNA tools might expect these extrapolated values to be already present in the loaded s1p files if you want to calculate a lowpass TDR?

Yes, the issue VNA Tools has with the Solver64 touchstone files is, that the maximum frequency is not a multiple of the largest frequency step. Lets say I measured from 100 kHz to 6.3 GHz with 801 points. Then I have to manually edit the frequency of the last point to 6.2999 GHz, to enable VNA Tools to compute the time domain graphs. I am pretty sure that this messes something up, and produces bad measurement values, but I have not found a better workaround yet.

[gf]

Yes, the issue VNA Tools has with the Solver64 touchstone files is, that the maximum frequency is not a multiple of the largest frequency step. Lets say I measured from 100 kHz to 6.3 GHz with 801 points. Then I have to manually edit the frequency of the last point to 6.2999 GHz, to enable VNA Tools to compute the time domain graphs. I am pretty sure that this messes something up, and produces bad measurement values, but I have not found a better workaround yet.

What if you choose a start and stop frequency which are both an integer multiple of the step size, for example 6300 points from 1MHz to 6300MHz?

[Pinörkel]

What if you choose a start and stop frequency which are both an integer multiple of the step size, for example 6300 points from 1MHz to 6300MHz?

That would of course work, but leaves me with no resolution for looking at short cables or discards a lot of the lower bandwidth. The liteVNA only supports about 1024 sampling points. So, I could maybe go with 6.3M to 6.3G and 1000 points (or 9M to 9G and 1000 points for trying to squeeze more resolution out of the liteVNA) to get loadable files that contain the required harmonic grid. I am still not sure what I am loosing by not being able to utilize the frequencies below 6.3M. Maybe, it is best to use multiple calibration ranges here: One for TDR that satisfies harmonic constraints and another one for return loss measurements that includes lower frequencies.