VNA for cable characterization

[joeqsmith]

LiteVNA 64 was calibrated using the modified standards from the V2Plus4 (sorted ANNE terminator) from 300k-9GHz, 1kHz IFBW, ideal model.   The two Amphenol BNC SMA adapters (C & D) from:
https://www.eevblog.com/forum/rf-microwave/vna-for-cable-characterization/msg5602515/#msg5602515
were attached.  Note the Port1 cable was locked in the vice during calibration and other measurements.

Next I measured the insertion loss of a few cables.  Their lengths were also noted along with the connector brand (if known).   

***
Link for ProbeMaster cable:
https://probemaster.com/bnc-cables-2/

Also attached photo of the Pasternak RG-400/U.  Datasheet may be found:
https://www.pasternack.com/images/ProductPDF/RG400-U.pdf

At 1GHz its 14.7dB for 100' or 0.91dB for our 74inches.  Which is very close to what we measured with the added loss of our adapters and connectors.   

[Pinörkel]

Next I measured the insertion loss of a few cables.  Their lengths were also noted along with the connector brand (if known).   

At 1GHz its 14.7dB for 100' or 0.91dB for our 74inches.  Which is very close to what we measured with the added loss of our adapters and connectors.

So it seems like the liteVNA can produce some usable quantitative results.

I tried to reproduce your insertion loss measurement with my test setup. The liteVNA was warmed up one hour, and then calibrated with the supplied cables and standards from 100k-6.3G, 1kHz IFBW, ideal model. I did not go all the way up to 9G, because I stumbled upon a strange calibration artifact, which I will try to show later. Then, I connected one of my cheap SMA-M to BNC-F adapters to the double SMA-F adapter at the cable on port 1 and a SMA-F to BNC-F adapter to the cable at port 2. The DUT cables then went in-between the BNC-F adapters.



As cables, I had:
RG58 C/U MIL C17F, 107 cm
Datasheet: 1GHz  51.8 dB Attenuation dB/100m -> for 107 cm : 0.55426 dB

Belden H155, 91.7 cm
Datasheet: 1GHz  29.6 dB Attenuation dB/100m -> for 91.7 cm : 0.271432 dB

This is what I got:



The image shows two measurements for each cable in the 100k to 1G range. One measured with 801 points from 100k to 6.3G and one with 801 points from 100k to 1G. The one with the denser sampling showed a large peak at the beginning going up to about 5.2, a strange small disturbance at 100MHz (which stays there, even when varying the sweep parameters) and some periodic superimposed oscillation. Unfortunately, the measured insertion loss values are not even close to the theoretical values I listed above. Maybe I messed up something with my measurement setup or my SMA to BNC adapters are too bad. At the moment, I do not have sufficient materials to test the insertion loss of only the adapters.


I also got myself some PCB mount BNC-M connectors to experiment with building BNC calibration standards, like described here. It seems those are only available from china manufacturers and no known quality manufacturer makes those. The first try was a complete and perfect failure.  The springy outer conductor of the connectors is too small in diameter by about .3mm and does not make good contact to any mating BNC-F connector. So, the connectors themselves are really bad. Nonetheless, I created an open and short by filing down the center conductor and then soldering a small tinned copper disk for the short, just for the fun of it. The result was smith chart that looks like Indiana Jones whip after calibrating. For open, short and load (even below 1GHz) the smith chart does not even get close to where it is supposed to be and jumps all over the place when just looking at the connector. I really wonder how the guy from the website linked above managed to get anything out of these connectors, but it may also well be my soldering skills.

[joeqsmith]

I'm guessing much of that loss is the adapters and connectors.   I suspect the switch points have changed over time.  Because I don't run the VNA standalone and have no use for any features beyond getting the data into the PC,  its rare I would change the firmware.  Shown with the VNA uncalibrated and a thru attached at 801 and 1601 points.  Note the higher spikes at the start. 

If I increase the number of data points to 2001, calibrate  and measure the thru, it is within 0.04dB.  Now when I insert a 48" section of RG58U and BNC connectors/adapters, my LiteVNA64 does not exhibit the large transients you show. 

You could try taping the cables to the table to prevent them from moving during the calibrations then measurement.  You could also try running the same firmware just to remove that variable.

[joeqsmith]

You do not specifically state that you recal the VNA when you are changing the number of points and frequency range.   

While the software has a limited interpolation if you work inside the frequency range that the VNA was calibrated, changing the number of data points would lead to some pretty strange results.  Shown with the same setup but I have changed the number of data points.  Of course the software would tell you there is an problem (CalRange error is active) but by design, it is not going to prevent you from doing such things.   

[joeqsmith]

Assuming you are calibrating the VNA for each setup, here is the LiteVNA with the two ports open after calibration using 2001 points, ideal model as before but with 100 averages.  Noise floor is about -100dB with mine.   I expect yours would be the same.   

I then attached two Coline 20dB attenuators in series and again averaged 100 times.  Note the min/max is enabled in both plots to show the peaks.   

The spec +/-0.2dB frp, DC to 1GHz with these where I measure about 1dB with the two. Again though, the VNA was calibrated with the SMAs and we have added these adapters which are another error source. 

[Pinörkel]

I'm guessing much of that loss is the adapters and connectors.   I suspect the switch points have changed over time.  Because I don't run the VNA standalone and have no use for any features beyond getting the data into the PC,  its rare I would change the firmware.  Shown with the VNA uncalibrated and a thru attached at 801 and 1601 points.  Note the higher spikes at the start.

If I increase the number of data points to 2001, calibrate  and measure the thru, it is within 0.04dB.  Now when I insert a 48" section of RG58U and BNC connectors/adapters, my LiteVNA64 does not exhibit the large transients you show. 

You could try taping the cables to the table to prevent them from moving during the calibrations then measurement.  You could also try running the same firmware just to remove that variable.

Looks like I get some better connectors then. Unfortunately, I can not really compare the ones from Telegärtner to another renowned brand, because Telegärtner seems to be kind of unknown outside of Germany. However, I have heard people say that their adapters might be similar in quality to same-priced Radiall, H&S and Pasternack devices.

You do not specifically state that you recal the VNA when you are changing the number of points and frequency range.   

While the software has a limited interpolation if you work inside the frequency range that the VNA was calibrated, changing the number of data points would lead to some pretty strange results.  Shown with the same setup but I have changed the number of data points.  Of course the software would tell you there is an problem (CalRange error is active) but by design, it is not going to prevent you from doing such things.   

Regarding the artifacts, I mentioned earlier, I already had a suspicion, that they might be interpolation errors. Though, I thought that I had recalibrated for the 100k to 1G range, I redid the measurement and the large spike at the start, the hiccup at 100M and the oscillations disappeared. The rest of the curve was very close to the two earlier measurements.

Assuming you are calibrating the VNA for each setup, here is the LiteVNA with the two ports open after calibration using 2001 points, ideal model as before but with 100 averages.  Noise floor is about -100dB with mine.   I expect yours would be the same.

This is what I get for the same parameters:



Did you enable averaging before or after calibrating? Since calibrating takes a lot longer with averaging on, it seems to make a difference.

[joeqsmith]

Did you enable averaging before or after calibrating? Since calibrating takes a lot longer with averaging on, it seems to make a difference.

After. 

[joeqsmith]

There are a few things about the LiteVNA you should be aware of that may cause you some problems.   When I showed the uncalibrated through measurement, you could see the switch points.  Normally these wouldn't cause a problem but if you are looking to measure losses in the 20dB or lower, these can be problematic.   The easiest way to see the problem is to cal the VNA for say 50k to 1M with say 800 points, then connect a step attenuator between the two ports.  As you add more loss, you will see a step in the response.  These happen at discrete frequencies.  The steps can be more than 2dB.   As you adjust the attenuator, the steps polarity can change.

It seems member Dislord had explained this in my large thread.  I think they provided the switch points and went into details of what was happening.  I added support to change some of the advanced settings of the LiteVNA to try and mitigate these problems.  There is no fix that I am aware of.  This was long after I had stopped updating the manual so the only place it is documented is in the forums. 

So when you see these spikes and shifts in your data, just be aware that the VNA can also attribute to them.

There are a few things that the original NanoVNA did much better than the LiteVNA and V2Plus.  I was surprised when I first bought the V2Plus4 how poor it was by comparison.  The designer of the V2Plus claimed that the LiteVNA was a ripoff of their design.   It certainly suffers from the same problems.    In some cases, you can work around it by using both the tools.   Of course, you still have that square wave drive.   I think when you get down to that level, it's time to think about getting a used high end system. 

[joeqsmith]

Going back a few years, here you can find the discussion switch points.   
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4136797/#msg4136797

After normalization, attached showing the 400kHz switch point with and without AGC when measuring a 30dB attenuator.

Also shown is how the step can change location depending on attenuation.  The leading glitch at the low frequency starts showing up below 16dB.  You can toggle the attenuator between 16 and 17dB and watch the leading glitch come and go. 

I'm sure most of the people using the LiteVNA are aware of the shortcomings like this but there isn't a good source for all the little traps for people just getting started. 

So if you see something really odd that you can't explain, it may very well be inherent to the VNA. 

[DiSlord]

LiteVNA use 2 generators MS5351 (from min to 100M) and MAX2871 to 6.3 - 6.4GHz (and t ~8G use harmonic mode)
On low frequency range also switch IF
800Hz - 20k use 6k IF
20kHz - 400k use 12k IF
400kHz - 100MHz - use 60k IF and MS5351
> 100MHz use 60k IF and MAX2871

Exist 2 problems:
Different IF on OpAMP give little different gain and phase rotation (compensated on last firmwares but not ideal) also OpAmp gain not ideal linear (calibration allow fix only linear errors)

As result:
- difficult fix problems on switch 20k, 400k and 100MHz (errors small, but exist)

[joeqsmith]

Thanks for chiming in.   While its pretty easy to detect the switch points and I agree that for the most part, they really don't cause a problem.    I have always wondered about what appears to be a change in the switch points based on signal level.   Where the low frequency switch points seem to be very predictable, the 100MHz one appears to move.  Eventually locks in.   See the zoomed in area of the previous data set for a better view. 

You can see I am running very old firmware and maybe some of this has been improved.   That version I am running I think was when you opened up the harmonic mode for me to make it unlimited. 

[virtualparticles]

There are many different ways of measuring the impedance of cable, but if I had to choose a methodology that's a good compromise between accuracy, simplicity, and cost, I would use a VNA and the methodology I describe in this video:

This is how I would do the measurement as well. TDR measurements made with VNAs are helpful, but frankly, no VNA manufacturer provides metrology for this mode. The TDR method involves Time Domain inversion and requires aggregating a thousand or so frequency measurements. Determining uncertainties for this is impossible, as far as I know. VNA TDR has the advantage of making a series of measurements in a narrow bandwidth instead of a single measurement in a GHz or higher bandwidth, resulting in a 1000x better signal-to-noise performance. This virtual TDR will work over hundreds of feet of relatively low-loss cable.

See https://coppermountaintech.com/time-domain-processing/

[joeqsmith]

This is how I would do the measurement as well. TDR measurements made with VNAs are helpful, but frankly, no VNA manufacturer provides metrology for this mode. ...

As I understand it, the OP is not asking about a section of coax.  For their cable, they are considering the entire system.  We know Tektronix had made a custom connector to improve the return loss.   I don't see how you would use the method you linked to evaluate the effects of the connectors, adapters, workmanship...   Using the LiteVNA with TDR is not good enough to see a lot of detail but you can get a relative feel for which combinations are better.   

With that in mind, how would you recommend they measure these effects?

[virtualparticles]

Getting back to your questions,

One thing is the step and impulse diagrams in the time domain. As far as I understand it, those should be convertible into each other by means of integration and differentiation. ...

Beyond not having enough data points, looking at my software I have been using a trapezoidal integral rather than Simpon's which would cause some small errors.  I doubt you would see a difference but I have gone ahead and changed it. 

You can of course zero-pad in the frequency domain (before doing the IFFT) to interpolate in the time domain. With increasing resolution in the time domain, the integration method becomes less and less important.

EDIT: That results not only in a higher resulution in the time domain, but also in a proper sin(x)/x interpolation, while e.g. trapezoidal integration calculates the integral as if there was linear interpolation between the points, and Simpson is not equivalent to sin(x)/x either.

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.

[joeqsmith]

So you are suggesting TDR? 

***
While GF seemed to have missed my comment about zero padding, I have used that method for some time.  This is what the OP is currently using.

[tggzzz]

So you are suggesting TDR?

if you want to see how impedance varies as a function of distance, then TDR would be my first choice.

Examples: "wideband" digital signal integrity on PCBs, connector "suboptimal characteristics", faultfinding in inaccessible locations, e.g. inside aircraft fuselages.

OTOH, if you are interested in "narrowband" frequency domain behaviour, then a VNA would be my first choice.

As is usually the case, "there is more than one way to skin a cat".

[Pinörkel]

I am not sure if i will stumble on effects related to the switching points, but I will try to keep their existence in mind. The Inverse Chirp Z-transformation sounds interesting. I will try to read the paper in the next weeks and see if I can understand it.

In the meantime I invested roughly a liteVNA64 value in better adapters. I am glad I did so, because that lead to a bunch of new insights (part of which had already been predicted by the more experienced members in this thread). Basically, I got several types of SMA to BNC, SMA to SMA and BNC to BNC adapters from Telegärtner, including what looked like a decent quality 50Ω Terminator and some port savers.

As far as I can see, this BNC-M terminator seems to perform even better than the Fairview Microwave ST3B-F I originally had in mind for terminating the cable. The following picture shows an S11 measurement taken with the liteVNA, calibrated with the supplied cal set. The black curve is the S11 of the liteVNA SMA calibration load, the red curve shows my old 50Ω terminator, i had lying around and the other three curves show the new TG terminator for three different connection states (e.g. extra pushing or pulling at the BNC connection before measurement). When comparing with the curves from the respective datasheets it performs better that the ST3B-F and the Mini-Circuits BTRM-50+.



My next (expected) finding was that my no-name SMA to BNC adapters are crap. On my new set of adapters all connections give an incredibly better haptic feedback when establishing an loosening the connections. Everything feels way more precise. Also they perform much better in a direct comparison. For that, I calibrated the liteVNA and then connected my H155 BNC cable via an SMA-M to BNC-F adapter to the liteVNA cable with the SMA through adapter. On the other side of the cable I connected a 50Ω termination and measured the TDR with Solver64. Then I swapped out the adapters and terminations at both sides of the cable between the no-name and Telegärtner ones and attached the liteVNA SMA load, the old 50Ω BNC termination and the new Telegärtner 50Ω BNC termination. The test setup and variations are shown here (the golden SMA adapters are the no-name ones):



One could immediately see that at least the SMA part of all the no-name adapters is unusable and produces a downward spike in the TDR graph that is not there with the quality adapters. The upwards spikes in the graph are caused by the BNC connections. I verified that via another measurement with an  improvised bad quality BNC cal kit which made the curve start at the top of the first spike and go downward from there. As expected there are two spikes at the end, when connecting a BNC terminator via a double BNC-F adapter. My old BNC terminator produced a spike at the end that went up to over 80Ω, and some oscillations. As expected, the cable part measured the same on all measurements, except for temperature drift variations and the offset caused by the SMA to BNC adapter between the cable and the liteVNA through adapter. Regarding the observed offset, my brain is still not sure why the hiccup caused by an adapter should influence the absolute value of the cable measured after the adapter. Is that because of an insufficiently dense sampled input signal resulting in integration errors on the way to calculating the TDR, which then of course sum up over the integration distance?



I hope I will find the time to redo the recent S21 measurements with the new adapters this weekend.

@joeqsmith: While playing with exporting Touchstone s1p and s2p files from Solver64, I noticed that Solver64 respects the locale of the PC it is used on pretty much everywhere in the UI, including said export. However, the Touchstone file format seems to be only defined for using the English decimal separators. Consequently, Solver64 outputs unreadable Touchstone files on all PCs with a locale using other decimal separators. Of course this also affects the SnP load function. Solver64 will not load correct Touchstone files on PCs with other locales. I fixed this by post-processing the files and replacing all commas with a point, so METAS VNA Data Explorer can open them, but maybe there is an easy fix for this in future releases.

[charliedelta]

Anyone tried to use a  VNA to measure longitudinal balance?

I want to build a LISN for CAT5 or CAT6 cable and need to verify the longitudinal balance?

Any ideas welcome?

[joeqsmith]

@joeqsmith: While playing with exporting Touchstone s1p and s2p files from Solver64, I noticed that Solver64 respects the locale of the PC it is used on pretty much everywhere in the UI, including said export. However, the Touchstone file format seems to be only defined for using the English decimal separators. Consequently, Solver64 outputs unreadable Touchstone files on all PCs with a locale using other decimal separators. Of course this also affects the SnP load function. Solver64 will not load correct Touchstone files on PCs with other locales. I fixed this by post-processing the files and replacing all commas with a point, so METAS VNA Data Explorer can open them, but maybe there is an easy fix for this in future releases.

Growing up in the USA, we were taught the metric system at a young age, and were told we would switch soon.  Now that I am reaching the end of my life, I have seen little progress.   I have worked for industries that should have pushed to correct it.  As dumb as switching between imperial and metric is,  I can't imagine having to use commas in some cases and decimal points in others. Growing up with our hybrid "impertric" system,  I am guessing you also just accept the stupidity of it all.     

If you select a country code that uses the comma for a decimal place, my software uses the comma for everything being displayed or exported.  I assume that these countries have tools that support your choice.  It sounds like that may not be the case.   Today, I force the exported Touchstone files to use the comma if this is what you have chosen.   It would actually make the code cleaner to export data using only the decimal.  I had added this after someone had asked about it.

The Touchstone import was something I added for my own debugging.  It only supports files that use a period for the decimal point.     

If I force the Touchstone export to always use a period for a decimal point,  does it cause problems for people in other parts of the world?   

***
If you do decide you want me to change it, let me know what OS you are using, how you have it setup (screen shots).  First step would be to replicate what you are seeing.

[Pinörkel]

Growing up in the USA, we were taught the metric system at a young age, and were told we would switch soon.  Now that I am reaching the end of my life, I have seen little progress.   I have worked for industries that should have pushed to correct it.  As dumb as switching between imperial and metric is,  I can't imagine having to use commas in some cases and decimal points in others. Growing up with our hybrid "impertric" system,  I am guessing you also just accept the stupidity of it all.

Kind of... if I ever think "It cannot get worse", I have a look at this. Soon after, hope and humor are back on track.

If you select a country code that uses the comma for a decimal place, my software uses the comma for everything being displayed or exported.  I assume that these countries have tools that support your choice.  It sounds like that may not be the case.   Today, I force the exported Touchstone files to use the comma if this is what you have chosen.   It would actually make the code cleaner to export data using only the decimal.  I had added this after someone had asked about it.

The Touchstone import was something I added for my own debugging.  It only supports files that use a period for the decimal point.     

If I force the Touchstone export to always use a period for a decimal point,  does it cause problems for people in other parts of the world?

I noticed there was an issue, when METAS VNA Tools and Copper Mountain S2VNA could not load the files, because they are apparently hard-coded to use a period. In S2VNA the UI even becomes non-functional (buttons do not update any more) and after some time it spams the user with hundreds of error dialogs. The thing is that the Touchstone file format specification does not define, but only imply that a period has to be used as a decimal separator. The fault here is that the file format neither defines the separator, nor offers a way to specify it in the file. Thus it becomes a file format that would require to look at the data and make a guess, which is inherently bad. So your choice of handling it is not wrong (in fact, I think, it is a better interpretation of the format specification), but will not work with many programs and devices that use Touchstone files. Since there is no standard compatible way to specify the separator in the Touchstone file, a configurable option in Solver64 for just the Touchstone file decimal separator would be a way to handle the faulty standard. However, most Solver64 users may live in the US and it may very well not be worth the effort. The only drawback of an external correction is, that the compatibility of corrected files is inverted. After correction all progams but Solver64 can read them.


As it is maybe of interest: I had a short look at S2VNA Software to see, if it does anything different when extracting time domain data from an S11 measurement. Apparently ist is very close to what Solver64 does, but I could not find a way to display the Y axis as impedance:

[joeqsmith]

If you do decide you want me to change it, let me know what OS you are using, how you have it setup (screen shots).  First step would be to replicate what you are seeing.

Again, if you want it changed,  I am not asking what my software looks like but what OS you are using and how you have if configured.   I use 10 and noticed all the BS they have added to support these formats that we can't agree on.  MS can't even give you simple area as I assume it is more screwed up than that.   Imagine the time that was wasted coding the OS, testing it.... Just stupid IMO. 

[Pinörkel]

The Touchstone import was something I added for my own debugging.  It only supports files that use a period for the decimal point.     

If I use the import, it only works with files that use the same decimal separators as defined in the current system number format settings, which is what I would expect.

If you do decide you want me to change it, let me know what OS you are using, how you have it setup (screen shots).  First step would be to replicate what you are seeing.

Again, if you want it changed,  I am not asking what my software looks like but what OS you are using and how you have if configured.   I use 10 and noticed all the BS they have added to support these formats that we can't agree on.  MS can't even give you simple area as I assume it is more screwed up than that.   Imagine the time that was wasted coding the OS, testing it.... Just stupid IMO. 

There are even countries that have mixed use of number formats (Map).
I have attached my number format settings for testing. I use English Win10 and German Win7, but the number format settings are the same on both. However, please do not invest time into this if there is a chance that the result is worse. 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.

[joeqsmith]

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.   

[Pinörkel]

So you use the common for a decimal and a period for a separator.  Crazy stuff.

That is exactly what would make it difficult to detect the number formatting. At work, we write all our scientific papers in English, since most literature and papers are in English. Consequently we also use English number formatting. However, many PCs although set to use English UI language, are set to use German date and number formatting and of course metric units.


In the meantime I redid the S21 measurements with my RG58 C/U and H155 cables. The new adapters improve the insertion loss at 1GHz by approximately 0.1 dB per cable. The H155 cable is now missing approximately 0.2 dB to spec and several RG58 C/U cables are missing 0.2 to 0.3. This difference might be from to the two BNC connectors at each cable. If that is so, I wonder why the insertion loss of the RG58 connectors is higher that the one of the H155 connectors.

[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.