Kirkby calibration kit alternatives?

[hendorog]

Even though skrf does not have TDR/DTF that I know of

It does by the way, here are a couple of examples:

https://scikit-rf.readthedocs.io/en/latest/examples/networktheory/Time%20domain%20reflectometry%2C%20measurement%20vs%20simulation.html
https://scikit-rf.readthedocs.io/en/latest/examples/networktheory/Time%20Domain.html

Something to be aware of when comparing VNA TDR with scikit-rf is that scikit-rf does not use the Chirp-Z algorithm.

Some more info here:
https://github.com/scikit-rf/scikit-rf/issues/1093

[EggertEnjoyer123]

Keep in mind the cheap Chinese loads look like this

[vsilves]

It does by the way, here are a couple of examples:

Sorry, yes, I actually mean to say DTF, not TDR.  I used the extrapolate_to_dc() call as the only way to add points to pre-recorded S11 data which allows to extend the time/space range.  Tried many things that failed before that.

Also used network.plot_s_db_time() very rudimentary to plot amplitude vs time.

skrf is great, specially to ingest .s1p, .s2p, .s3p files robustly.

[vsilves]

Something to be aware of when comparing VNA TDR with scikit-rf is that scikit-rf does not use the Chirp-Z algorithm.

Some more info here:
https://github.com/scikit-rf/scikit-rf/issues/1093

For my DTF script I used np.fft.ifft() for the IFFT transform and scipy.signal.czt for the Chirp-Z. Something wrong in my use of CZT, all the trace is consistently off by one frequency bin from the IFFT, and I cannot figure out how to fix it so far.  Just experimenting to see if results look good.

[vsilves]

It does by the way, here are a couple of examples:

https://scikit-rf.readthedocs.io/en/latest/examples/networktheory/Time%20domain%20reflectometry%2C%20measurement%20vs%20simulation.html
https://scikit-rf.readthedocs.io/en/latest/examples/networktheory/Time%20Domain.html

No matter how many times I read the examples, which I had already seen before this post, I was only registering the plot_s_db() calls and thinking that skrf could only plot values vs time, but not return values over time for custom processing and plotting.  Of course, I was wrong, and totally missed the skrf.network.Network.step_response() calls.  Indeed, I ended up reinventing the wheel instead of relying on existing skrf functionality.  I will investigate and use step_response().

[vsilves]

I wanted a way to tell if a coax was 50Ω or 75Ω from S11 or S22 alone.  Did not find any info on how to do this online.  Decided to measured the cables I had laying around on my Siglent SVA1032X, combine .s1p measurements to a single .s2p file, and study the different reflection coefficients.  Eventually got a rudimentary algorithm that more or less works.  I detail the steps graphically with some examples in the attached PDF. Importantly (for me), the algorithm works without letting the script know what the expected impedance is "a priori."

[hendorog]

Here is a method which at first glance looks like what I have used before for PCB stripline.

It should work with any transmission line like coax.
https://chemandy.com/technical-articles/measuring-track-characteristic-impedance/measuring-track-characteristic-impedance-article1.htm

And a manual calculator for one point:
https://chemandy.com/calculators/characteristic-impedance-measurement-calculator.htm

Could be worth a try to validate your algorithm

Edit: Of course you can use TDR to determine impedance too.
https://scikit-rf.readthedocs.io/en/latest/examples/networktheory/Time%20domain%20reflectometry%2C%20measurement%20vs%20simulation.html

[vsilves]

As a complete RF noob I cannot cease to be amazed at what skrf can do.  Made a short list of things to try related to coax impedance measurements, based on hendorog pointers (thanks again), but got distracted with other measurements.

I think I figured out how to use impulse and step time-domain responses as well as time gating. Got super distracted (obsessed?) with simulated networks.  Pic1 shows a real RG58 coax measurement (.s2p) vs a simulated RG58 coax (using skrf's distributed circuit).  Pic2 shows more charts of real vs sim RG58.  Pic3 shows some time gating on the real RG58 only.  I had no idea you could do all this!

Would be nice if I could simulate a 50Ω load and use that for a simulated calibration (I have no idea this is possible or even makes sense) and measure my assumed good calibration loads.

[vsilves]

Recently got a LibreCal for my SVA1030X and, even though the loads in the LibreCal are nothing remarkable (first picture), the fact they are characterized with .s1p files using "Agilent Technologies,E5071C,MY46524282,B.12.04" up to 8.5GHz and the LibreCal's python script generated Siglent e-cal packet is quite large (I think uses all the .s1p and .s2p files) allows the SVA to see all my mystery loads for what they are (second picture).

In the second picture, ANNE1 is the original ANNE I had (quite good).  ANNE2 is a second ANNE I acquired since, and looks not quite as good but still very decent.  Long1 and 2 are the loads from NanoVNA-F v2 (RIP) and v3 (still strong) that I had been using as my uncharacterized OSL kits (not bad!).  BNCload is a Mini-Circuits load which is not horrible taking into account it is BNC.  L1 represents a set of 3 similar loads that I had thought were better than that (previously). China1 represents a set of 5 similar loads that are as remarkable bad as I had guessed.

This sort of closes the loop on my unknown loads and opens the door (for me) to characterize loads and use them with off-line calibrations and skrf.

[joeqsmith]

Looks like an easy way to calibrate.  Appears seem less.  Are the S-parameters stored on the ecal, or do you need to load them into the VNA manually?   Does the manufacture provide data for each unique serial number?   

I found this video but there are no details.     

[tautech]

Looks like an easy way to calibrate.  Appears seem less.  Are the S-parameters stored on the ecal, or do you need to load them into the VNA manually?   Does the manufacture provide data for each unique serial number?   

The Touchstone files of each Ecal are stored on the device and loaded when an Ecal calibration is performed.
It is very quick and offers the advantage of much less connector wear by only needing 1 connection cycle.

Using the LibreCal is a new hack of SVA/X-R analyzers in order to use a more cost efficient Ecal from other suppliers.
A little more info here:
https://www.eevblog.com/forum/testgear/siglent-sva1015x-1-5ghz-spectrum-vector-network-analyzer-(coming)/msg5976343/#msg5976343

[vsilves]

Does the manufacture provide data for each unique serial number?   

It does. The .s1p and .s2p files are exposed in a read-only volume (that Siglent SVAs do not look for or recognize) but if somehow you lose them, they are available online, based on serial number of device, for download (link in LibreCal GitHub).

Siglent SVAs cannot read the .s1p/.s2p files as presented so a script available in LibreCal GitHub needs to be run.  The script processes all the .s1p/.s2p files and creates a siglent folder in the read-write volume of the LibreCal that Siglent SVAs recognize and load during e-cal.  Other e-cals can be added, for example, after characterizing any connectors or protectors added to the LibreCal SMAf ports.  I think for Siglent SVAs one would need to regenerate the compressed Siglent e-cal packet in the read-write volume of the LibreCal using the new .s1p/.s2p files, instead of the original files for the bare SMAf ports on the LibreVNA.

[joeqsmith]

Thanks.   I wonder why in 2025, why it was limited to 1202 points and even multiple data sets.   Do they have software tools that allow you to re-characterize it?       

[vsilves]

Experienced folks seem to favor as few points as possible (to reduce measurement time and increase stability) so I was glad we did not get 201 points :-).  The 1202 points cover all the way up to 8.5 GHz, so, yes, I would prefer more points to 3.2 GHz (Siglent) or NanoVNA (mine is 6 GHz).  But folks with higher end Siglent SVAs should be happy with coverage.  Works very well, so cannot complain.

Any higher end equipment can be used to re-characterize the standards on each port as they can be manually selected clicking hardware buttons.  Including the Siglent SVA after e-cal.  The new .s1p/.s2p would be the new characterization, which can be saved (for LibreVNA use only) and compiled into a Siglent e-cal packet on the read-write volume.  Just need to follow the structure of the existing files and instructions on GitHub.

GitHub has a LibreCal-GUI app.  I had to use the Windows version on a virtual machine, and realized I did not need it.  Mac version crashes and cannot be digitally signed for some reason.  Did not try Linux version.  App only allows selecting standards manually for each port, and shows a temperature graph to know when device meets limits (this can also be observed on biking LEDs).

Would be neat if the NanoVNA had enough resources for a brave soul to implement e-cal magic!!!  However, I think measuring the LibreVNA standards with NanoVNA and then doing uncalibrated NanoVNA DUT measurements for off-line calibrations will be easy enough (and no need for e-cal).

This goes to show what @hendorog has pointed out several times in these forums.  You only need a proper traceable calibration measurement of your standards for proper calibrated measurements on your VNA (off-line if VNA cannot take .s1p/.s2p files). The standards themselves can be crappy or not, and either way, that will NOT affect the resulting calibration/measurements (within reason).

[tautech]

Experienced folks seem to favor as few points as possible (to reduce measurement time and increase stability) so I was glad we did not get 201 points :-).  The 1202 points cover all the way up to 8.5 GHz, so, yes, I would prefer more points to 3.2 GHz (Siglent) or NanoVNA (mine is 6 GHz).  But folks with higher end Siglent SVAs should be happy with coverage.  Works very well, so cannot complain.

Any higher end equipment can be used to re-characterize the standards on each port as they can be manually selected clicking hardware buttons.  Including the Siglent SVA after e-cal.  The new .s1p/.s2p would be the new characterization, which can be saved (for LibreVNA use only) and compiled into a Siglent e-cal packet on the read-write volume.  Just need to follow the structure of the existing files and instructions on GitHub.

GitHub has a LibreCal-GUI app.  I had to use the Windows version on a virtual machine, and realized I did not need it.  Mac version crashes and cannot be digitally signed for some reason.  Did not try Linux version.  App only allows selecting standards manually for each port, and shows a temperature graph to know when device meets limits (this can also be observed on biking LEDs).

Would be neat if the NanoVNA had enough resources for a brave soul to implement e-cal magic!!!  However, I think measuring the LibreVNA standards with NanoVNA and then doing uncalibrated NanoVNA DUT measurements for off-line calibrations will be easy enough (and no need for e-cal).

This goes to show what @hendorog has pointed out several times in these forums.  You only need a proper traceable calibration measurement of your standards for proper calibrated measurements on your VNA (off-line if VNA cannot take .s1p/.s2p files). The standards themselves can be crappy or not, and either way, that will NOT affect the resulting calibration/measurements (within reason).

FYI my SEM5032A 26 GHz Ecal provides 6114 points.....not specified in the datasheet. 
https://siglentna.com/wp-content/uploads/dlm_uploads/2023/10/SEM5000A_datasheet_DS60050_E_01A.pdf

Sweep in attached screenshot not associated with any Ecal info. 

[joeqsmith]

GitHub has a LibreCal-GUI app.  I had to use the Windows version on a virtual machine, and realized I did not need it.  Mac version crashes and cannot be digitally signed for some reason.  Did not try Linux version.  App only allows selecting standards manually for each port, and shows a temperature graph to know when device meets limits (this can also be observed on biking LEDs).

I thought the support for the LibreCal was added to the Siglent firmware.  Sound like they have a separate application that you run manually to select the standards.  Please clarify.

Would be neat if the NanoVNA had enough resources for a brave soul to implement e-cal magic!!! However, I think measuring the LibreVNA standards with NanoVNA and then doing uncalibrated NanoVNA DUT measurements for off-line calibrations will be easy enough (and no need for e-cal).

Sorry but you completely lost me with that second statement. 

This goes to show what @hendorog has pointed out several times in these forums.  You only need a proper traceable calibration measurement of your standards for proper calibrated measurements on your VNA (off-line if VNA cannot take .s1p/.s2p files). The standards themselves can be crappy or not, and either way, that will NOT affect the resulting calibration/measurements (within reason).

That's correct.  You can read the patents for the HP ecal or other documents on databased standards which basically describes this.  It makes them cheaper to manufacture.  In the case of LiteVNA, the limiting factor wasn't the standards but the VNA's hardware.   As long as they documented the interface, I don't think it would take much to support it. 

***
Of course, if you have a program today that will manually select the standards you may be all set.  At least Solver supports S-parameters as well as the standard HP polynomial fit.

https://coppermountaintech.com/using-a-databased-solt-calibration-kit/
***

[vsilves]

I thought the support for the LibreCal was added to the Siglent firmware.  Sound like they have a separate application that you run manually to select the standards.  Please clarify.

The opposite.  Somebody (guy in the video I think) reverse engineered Siglent e-cal SCPI commands and added that to the LibreCal's firmware.  With the latest LibreCal firmware (and an easy to generate Siglent package in LibreCal storage), plugging the LibreCal into a Siglent SVA works seamlessly with unmodified/original Siglent firmware.

LibreCal has a separate standalone app to control certain aspects of the LibreCal, but it is absolutely not necessary to update its firmware, or operate the LibreCal in any way.  All LibreCal operations can be controlled with the two hardware buttons, and reading the manual to place the LibreCal in various states.  The physical buttons in the LibreCal also allow selecting a port, and then selecting which standard is presented on that port, or none.  LibreCal has 4 ports, each with their own OSLT available.  Once LibreCal is configured with latest firmware and the necessary Siglent folder is created (by you running a python script), it is seamless. Meaning, you just turn LibreCal on, wait until it warms up (LED stops blinking), plug to Siglent USB port (to read e-cal data), connect ports 1 and 2 to Siglent VNA, load e-cal in Siglent VNA, perform S11 calibration on Siglent VNA, perform S21 calibration on Siglent VNA, done in under 10 seconds, as shown in the video. No need to press any buttons on LibreCal.  In the video, a button is held, but that was for older firmware.  New LibreCal firmware detects the Siglent folder and defaults to Siglent mode; you actually have to hold a button to enter LibreVNA mode instead of Siglent mode when this Siglent folder exists.  All explained in its GitHub.

To be clear, there is no support from Siglent or apps from Siglent to select anything. The Siglent VNA will just see and load the LibreCal e-cal (conveniently named Siglent) when a properly configured LibreCal device is plugged to USB and port 1 and 2.

Sorry but you completely lost me with that second statement.

Sorry, this is convoluted, and tedious, if not scripted.  You may find some discussion about this in the forum.  Basically, using the characterization .s1p files in the LibreCal as "ideal OSL."  Then measuring the OSL in the LibreCal with an uncalibrated NanoVNA (or any other VNA) and calling those .s1p files "custom OSL".  Allows, using some scikit-rf python magic to, measure a DUT using an uncalibrated NanoVNA, and then use the ideal OSL, custom OSL, and raw DUT measurements, to output a calibrated and traceable .s1p measurement of the DUT, as if the NanoVNA had been in fact physically calibrated with the e-Cal.  So this is an off-line calibration and you may have done that with other software that I am unfamiliar with.  I only know how to do this with scikit-rf and python.

---

Still playing with a python script I made to generate User Cal-Kit coefficient to see if it works but that is imperfect by design, when compared with using full .s1p files for the OSL standards.  Still, handy if it is close enough, since it works on device (Siglent) vs off-line (scikit-rf).  However, my NanoVAN has no way to enter cal-kit definitions, so using the NanoVNA in raw mode and scripting calibrations offline is very handy.  I simply pull the S11 and S21 traces via USB with python as .s1p or .s2p files, and apply the calibrations to them.

I refuse to use Windows (or repeatedly click UIs like a drunken monkey), so had to re-invent some wheels in MacOS via python, scikit-rf, and numpy.

[joeqsmith]

What you described is how I calibrate the VNA's when using Solver and databased calibration.  Of course it is all done live rather than post processed (off-line as  you seem to describe).

Still playing with a python script I made to generate User Cal-Kit coefficient to see if it works but that is imperfect by design, when compared with using full .s1p files for the OSL standards. 

I had used METAS to create the polynomial coefficients for the cheap standards after measuring them on my old Agilent. In the end, using the S-parameters compared with the Agilent polynomial fit made no significant difference with the LiteVNA.  The real limitation was the LiteVNA's hardware. 

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

Still, handy if it is close enough, since it works on device (Siglent) vs off-line (scikit-rf).  However, my NanoVAN has no way to enter cal-kit definitions, so using the NanoVNA in raw mode and scripting calibrations offline is very handy.  I simply pull the S11 and S21 traces via USB with python as .s1p or .s2p files, and apply the calibrations to them.

Basically that's all I am doing.  At least with the LiteVNA, once you connect and start reading the data, you are getting the uncalibrated data. 

I refuse to use Windows (or repeatedly click UIs like a drunken monkey), so had to re-invent some wheels in MacOS via python, scikit-rf, and numpy.

I've never seen a Mac used at any of the companies I have worked for and we pretty much were locked into Windows once NT was released.   I've never seen a drunken monkey, but will assume there are a lot of us. 

[vsilves]

Speaking of calibrations, I read that some vendors recommend full 90-minute warm-up time for accurate measurements (Keysight/Agilent), others 30-60 minutes (Rohde & Schwarz, Anritsu, Siglent, Copper Mountain), even others 30 minutes (Rigol, Siglent).

Did some measurements on my fake SVA1032X after Librecal recall and small SMAff THRU response cal, leaving the THRU on, and pulling all data remotely to avoid disturbing instrument, cables, or DUT.  Pulled S21 every 5 minutes, but only showing 10 min intervals  in attached pictures.  Hard to see anything at all on the first picture, traces have ripple and are too close to each other to appreciate what is going on.  However, using skrf to do time domain gating around the DUT shows very nicely the S21 insertion loss and phase response slow progression and settling over time (see second picture).  I interpret the second picture as the SVA1032X required a full 110 minutes to fully settle with a constant 23ºC ambient temperature (which is a whole lot longer than I ever imagined it would take).

The reason the traces start relatively flat and get worse over time is that the recalled ecal had been performed another day on a completely cold turkey instrument (within 2-3 minutes of starting equipment).  This time I took advantage of the warm instrument and did another eCal at 125 minutes and saved it for good later use.  Traces look flat as they should with the warm ecal.

[joeqsmith]

The vast majority of the time, those errors would not be big enough to cause me any concern.   

Attached photo is data from the low cost LiteVNA comparing the S21 from a cold start to after 24 hours of operation.  Below 1GHz it's very stable.