Siglent SVA 1032X HowTo

[dh5dan]

Could you please write me a how-to on how to prepare LibreCal for an SVA1032X?

I know there's a Python script (convert_siglent.py), but how exactly do I use it and what preparation do I need to do?
Unfortunately, the PDF only describes it very briefly.

I have the latest firmware version on the SVA V6.3R2.

I also see that when I call Ecal, S11/S21 Ecal is grayed out, which isn't the case in the video.

Is it normal that LibreCal always creates a MassStorage drive in normal mode?
I thought that only happened in BootSel mode.

Ecal SVA 1032X. You see S11/S21 Ecal ist greyed out.

Firmware Version

[dh5dan]

I've now taken a closer look at the script.

The command sequence is:
usage: convert_siglent.py /Volumes/LIBRECAL_R /Volumes/LIBRECAL_RW

So IN-DIR and OUT-Dir must be specified.
The IN-DIR must contain the Factory Cal data unpacked and not as a ZIP file.
The OUT-Dir must then be the LibreCal mass storage drive.

I've tried it, but I get an error.
Apparently, something is wrong with the parsing of the INFO.TXT file.

By the way, LibreCal was recognized as authentic during the check.

For me, the following is in there (serial number has been anonymized):

Factory calibration data for LibreCAL
Serial number: xxxxxxxxxxxx
Firmware version: 0.2.3
Timestamp: 2025-05-13T10:02:06.170564

Calibration equipment:
Agilent Technologies, E5071C, MY46524282, B.12.04

What else is wrong?

[dh5dan]

I did a little research.
The reason for this is that the script expects the lines in the info.txt file to be separated by a colon and a space.

I just noticed that there's a second folder containing the Factory Cal data.
You need to use this as IN-DIR for it to work, as the info.txt file is correctly structured there.

And now the info.txt file is correctly formatted in that folder as well.

Serial number: xxxxxxxxxxxx
Firmware: 0.3.0
Number of ports used: 4

As soon as the Siglent folder containing the data0.zip and info.dat files is present,
LibreCal automatically switches to emulation mode (ready flashes).

Then press "Load ECal" and the "S11/s21 ECal" display will no longer be grayed out.

I'll run an Ecal tomorrow because it's already very late.
I only did the USB test.

I hope this information is helpful, as the manual unfortunately doesn't describe it precisely enough. It might be updated later.
At least it's working now, and the SVA recognizes LibreCal.

Regards, Chris

[jankae]

Looks like you figured out everything already :) But just to confirm everything if it is still unclear to anyone else:

I've now taken a closer look at the script.

The command sequence is:
usage: convert_siglent.py /Volumes/LIBRECAL_R /Volumes/LIBRECAL_RW

Yes, that script needs the paths to both LibreCAL volumes because it takes the factory calibration from the read-only volume and creates the coefficients for the Siglent VNA on the read/write volume.

I've tried it, but I get an error.
Apparently, something is wrong with the parsing of the INFO.TXT file.

Looks like you have tried it with the downloaded factory calibration from the server. This does indeed have a different INFO.TXT file which contains some information about the factory calibration procedure (e.g. timestamp and the equipment being used for the calibration). Despite being named the same, the INFO.TXT file on the read-only volume contains different information and can not be used here.

You do not need to download the factory coefficients at all to create the Siglent data.

I hope this information is helpful, as the manual unfortunately doesn't describe it precisely enough. It might be updated later.

It is not described as obvious as possible but all the information should still be there. There is a section in the user manual mentioning the emulation modes and that section also points you to the script. The script itself tells you how it is supposed to be used (by mentioning the two LibreCAL volumes by name).

I actually do not want to advertise this functionality aggressively because it is just based on some reverse engineering of the Siglent protocol. It may not work in some edge cases and I also do not want the LibreCAL to compete with Siglents eCals directly.

Just consider this feature an extra goody but not one of the main features. Still easily accessible for anyone who really wants it but not something that just works out of the box. And I think bit of research and own initiative (which is really just a simple script call with the correct parameters) is acceptable for that. Basically I am trying to keep the balance between ease of access to this feature and not stepping on Siglents toes with it.

[dh5dan]

Hi Jan,

Yes, I also understood that it's a nice-to-have feature, and its original use is based on LibreVNA.

I find it very remarkable that "jwise" went to the trouble of making it available for an SVA. LibreCal has a lot of potential, so why not make it usable for other purposes?

I would therefore like to thank you for developing the LibreCal project and for making it open source. I know a lot of time and testing goes into it.

I've already had the opportunity to test it with the SVA 1032x, but I wasn't satisfied with the results. I have an F603FE CalKit here as a reference. I'll have to look into the cause when I have time. I'm still waiting for my Telegärtner N-SMA adapter to rule out any possible sources of error.

Regards, Christian

[vsilves]

Hi Christian,

I also tried the LibreCal on my SVA1032X and if I understand your concern with the results it may have to do with the return-loss and insertion-loss of the standards in the LibreCal immediately after calibration. However, I think results match the corresponding .s1p and .s2p measurements provided (for each standard), which is the only thing that matters (proper traceable standard characterization measurements). The quality of the internal standards does not matter at all, in my understanding (so long as they are properly characterized). To prove this, use a good external load, or a bad load, does not matter actually, as a DUT. Do a cal with your F603FE and then measure the DUT load. Now do e-cal with the LibreCal and then measure the same DUT load. If the two DUT load measurements do not look very similar to each other, then yes there is a concern. However, I suspect, they will be very close.

Hope this makes sense and that you can do the test and post resulting DUT load measurements (as I don't have any other traceable calkit).

Vicente

[dh5dan]

Hello Vicente,
Yes, I also read your report on the EEV-Blog ;-)

Luckily, I'm on vacation right now, so I can take a closer look at it.

I'll do a few comparison measurements, one with M-CAL (F603FE) and one with E-CAL, and then I'll get back to you.

Regards Christian

[dh5dan]

Hi Vicente,
I recently had the opportunity to perform a comparison measurement.

One was a manual calibration with an F603FE and the other via ECal with LibreCal.
I used a BPF 433 MHz as the measurement object (DUT).
Span was 100Mhz from 385Mhz until 485Mhz.
The BPF was terminated with the load from the F603FE during the S11 measurement.
The N to SMA adapter here is a Telegärtner 100024203.
The measurement cables are those from the LibreCal SS405.
The SVA 1032X had a warm-up time of about 1 hour.

#############################

Here are the measurements with the CalKit F603FE:

The image shows a completed S11 SOL calibration with the F603FE.
Note that the S11 line is exactly near by 0 dB.

The image shows a completed S21 SOLT calibration with the F603FE.
Note that the S21 line is exactly at 0 dB.

The picture shows an S11 measurement of a bandpass filter for 433 MHz.

The picture shows an S21 measurement of a bandpass filter for 433 MHz.
Note the attenuation value of -1.20 dB.

#############################################

Here we see measurements taken with LibreCal.

This is the ECAL S11 calibration.
We see a total attenuation of approximately -5.22 dB.

This is the ECAL S21 calibration.
We see a total attenuation of approximately -5.42 dB.

In the image, the Librecall has been replaced with a 0dB pass-through adapter from the F603FE.
We see a mismatch in attenuation of -3.72dB.

In this image, we see an S11 measurement with the same bandpass filter.
But somehow, nothing fits.

The image shows an S21 measurement of the bandpass filter for 433 MHz. Note the attenuation value of -4.94 dB.
After subtracting the mismatch of -3.72 dB, we obtain the actual value of -1.20 dB,
which exactly corresponds to the measurement with Mcal at -1.20 dB.

#########################################
As a reference, I only performed the S11 calibration on LibreCall and the S21 with
the PassThroug from the F603FE to see if anything changed.

Here we now see a nearly better attenuation value.
Not quite exact, but certainly better.
Target -1.20, actual -1.34.
Still a difference of 0.14 dB.

I don't see any changes in S11.

##############################

Conclusion:

We see that the attenuation value of -3.72 dB is not taken into account in Ecal.
This leads to inaccurate measurements by exactly this value.
The actual frequency response is OK and almost identical in S21, but the attenuation is not taken into account.

I can't say why almost nothing is visible in S11.

I think the S parameters in Librecalk are OK, but it seems that there may be an error in the conversion to the Siglent format that does not take this attenuation value into account, or does not take it into account correctly.

I don't have LibreVNA to test whether this is the case there, but I don't think it will be.

At least, these are my initial conclusions from what I've learned.

Regards Chris

[jankae]

Yeah, something is definitely weird. I know for sure that I took multiple calibrations (1-port, 2-port and 4-port) about 2 months ago and they all looked good (e.g. almost exactly 0 dB on S21 when connecting the cables directly to each other).

But when I now try to repeat that (just to be sure), I get completely bad calibration data. I have tried that with two different LibreCALs and during the calibration I can see that the correct standards are switched in and the traces on the Siglent (my SNA5014A shows the uncalibrated S parameters while it is calibrating) look as expected. But for some reason, the calibration is still bad.

This sounds to me like there is some problem in the siglent coefficient file. I had to create these files again just now because I had already deleted them on my LibreCALs. But as far as I am aware, there was no change in the script for generating these files nor was there a firmware update for the Siglent since I last got good calibrations. Really not sure what could have changed. I will take another look at this but it will probably take a couple of weeks.

[dh5dan]

Hi Jan,

It's good that you can reproduce something similar.
Give it your time. If you need a beta test, I'm happy to help.

Best regards, Christian

PS:
Wie sagt man so schön: Gut Ding will Weile haben ;-)

[vsilves]

Hi Christian,

I did some similar measurements with what I have and I think I was "not" able to reproduce. Used SVA1032X cold booted but did wait for LIbreCal to warm up.

First do eCal and get S11 and S21 with LibreCal port1-to-port2 THRU left on. On S21 I get about -1.70dB (representing LibreCal's port1 to port2 insertion loss).

If I replace the LibreCal for a short SMA female-female barrel I get a near perfect 0dB insertion loss.

Now measure a BPF. S11 shows near 0 IL outside filter (like you). S22 shows -2.59 IL in the center of the BPF (reference point to compare mCal later).

Now do mCal enhanced THRU response (not calkit but my NanoVNA load is darned good) and get S11 and S22 with the THRU left on. As the THRU is a short SMA barrel I see near zero insertion loss (representing mating calibration planes since I had to add that same SMA thru barrel to put the Open, Short, and Load).

Now the moment of truth. Replace with my BPF DUT and get S11/S21. Center of filter show -17.22dB on S11 (vs -17.27dB after eCal) so same (no offset). S21 shows -2.60dB (vs -2.59dB after eCal) so also same (no offset).

I am confused how you get S11=0dBm and not sure with what connected to port1 of VNA. Was it left open, or with O or S from F603FE standard plugged?

Also confused by "This is the ECAL S11 calibration. We see a total attenuation of approximately -5.22 dB." On S11 (i.e., return loss) seeing -5.22 after eCal is suspect. What was port1 of VNA looking at? eCal THRU or eCal LOAD? Either way (THRU or LOAD) the other end is well terminated/matched at 50Ω so I think not seeing something near to -20dB is suspect in the signal path (either connectors, coax, or LibreCal) but would help to know how you got a flat S11=0 after mCal also.

You getting S21=-5.42dB with the LibreCal as THRU is a bit much but would be okay if when you replace with a barrel THRU you obtained 0dB (instead of your -3.72dB). Then the S11 with BPF at -5.21 and no drop in RL of course makes no sense. Since you had the same cables for mCal it cannot be the cables or connectors, so everything points to the LibreCal. I would re-generate the siglent eCal package/folder and double check used correct S parameter files.

You could do an mCal and then manually select the LOAD on port1 of LibreCal and measure it (show what S11 looks like). Manually selecting the OPEN and show S11. Manually select the SHORT and show S11. Also select LibreCal THRU on port 1 and port 2 (both) manually with buttons and measure/show S11 and S22. If the LibreCal standards look like they are supposed to with the eyes of a good mCal, then the hardware itself is good, and it can only be the software (firmware or siglent eCal packet/folder).

Best of luck,

Vicente

P.S.: Also, did you re-load the eCal or just perform eCal S11 and S21 without re-loading eCal? I reload every time, but I think one time I did not saw something weird (need to re-test that).

[dh5dan]

Hi Vicente,

After the S11 calibration, the image showed the characteristic curve with an open end.
That's how it should be. You're calculating the cable out of the equation, so it should be 0 dB here too.

What puzzles me about the S11 Ecal is that regardless of whether I set it to Short or Load, the line remains the same.
If I set it to the top, I see some interference.

If I unplug the cable, it goes quiet again, but I have the same line with attenuation as if I set it to Load or Short on the LibeCal.
So that's a bit strange because with the Mcal, when I have the Load on, the line is somewhere > -50 dB.

So everything is behaving a bit strangely.
By the way, I have the firmware version: 6.3R2 installed, so the most recent one.
Which one do you use?

Yes, I always reload the Ecal. You can't run an Ecal if you haven't loaded the ECAL at least once.

I have a question for you.

Could you perhaps provide me with your data0.zip + info.dat files for testing?
I just want to check if I see any changes here.
That would rule out, among other things, a faulty conversion.
You can send them to me via PM on the EEv blog.
Here you answered my question about the program you used regarding the S-parameters.

Regards, Christian

[vsilves]

I also use latest 6.3R2 but my SVA1032X is genuine fake (i.e., converted from a SSA3000X+). I sent you a message in eevblog but did not see where to attach files (unlike posting) so I included a link to a zip file in my iCloud Drive. If it does not work we can try something else.

Okay, left open or short port 1 after S11 calibration should indeed be a relative flat line at 0 dBm. Short or Load giving same result definitely sounds bad. It would be informative to do the mCal (so known good calibration) and then show the S11 for the LibreCal O, S, L and S22 for the LibreCal THRU (port 1 to port 2). That way we look at known/reliable data. But it sounds like either the switch or some of the standards in the LibreCal have hardware issues (not firmware or software package).

[vsilves]

My LibreCal siglent data package for Christian. Added for him to download.
siglent.zip

[dh5dan]

Hi Vicente,
Thank you.
I'll check it out later today and report back.

Best, Christian

[dh5dan]

Hi Vicente,

I couldn't wait to at least test it briefly ;-)
You won't believe it, now I have exactly the values expected from an Ecal.
S11 = 0db and S21 with 0db PassThrough = 0db.

I'm wondering where the error is.
Can you give me the stored factory S-parameters as a reference,
so I can run them through the converter to see if the script is making a mistake somewhere.
I should then get exactly the same data0.zip with the MD5 hash.

If it's identical, then I received incorrect S-parameters
from the factory. If not, the error lies in the script itself.

Regards, Christian

S11 Ecal measurement with your S-parameter data and open end

S21 Ecal measurement with your S-parameter data and 0db Passthrough

[vsilves]

That is remarkable and unexpected I thought S-parameters were supposed to be device/unit specific (although obviously should be similar and close, but not this close I thought). Here are two ZIP files, one has the on device read-only exposed S parameters. The other contains the parameters that I downloaded online using my serial number.

Files-0.3.0 (On Device).zip
Files-Serial (Downloaded).zip

I had checked them against each other and seen that they were identical on my fancy skrf plots before. But I did not notice (until now) that the device exposed versions are fixed point floats with 6 decimals (no scientific notation), similar to the output of a NanoVNA for example (which for small details only leaves 4-significant digits in my view, and is not sufficient for a traceable standard or an eCal). The vendor provided copy uses also fixed point (no scientific notation) but 14 decimals, which compares well with the Siglent observed trace data output my scripts receive when requesting ASCII notation (scientific notation with 9 decimals in the mantissa). Now, I do not remember which of the two folders I ran the script on! But I bet I did on the vendor better quality provided one. It may be worth in your investigation to download your coefficients also (link in this GitHub readme) and try those instead of the S parameters in your device, to see if that makes a difference!

Wow, I'm surprised but all of this!

[dh5dan]

A quick update after a cup of coffee ;-)

The SVA1032x either seems to have a bug or it's intended that way.
When I run an Ecal and then start Load Ecal, I see that it takes longer to load the data from LibreCal.
If I do it again, it's faster.

But now it seems that it remembers the data here.
I tried loading my data as a test and noticed that it loads the data just as quickly when I load Ecal.
Then I compared the serial number and noticed that it was completely different from the one in the data.
You can set a preset or reset the SVA to remember the data and won't load any more after that.

A factory reset or power cycle helps, then it forgets the data and uploads new data.

I ran the converter with your stored S parameters.
The data is identical, but I noticed that the file size is different.
A binary comparison then revealed that your line separator is only 0A, while mine is OD0A.

Strangely, it wasn't accepted with 0D0A, but yours has 0D, and that worked.

I'm still trying to figure out whether that's the deciding factor here.

Regards Christian

[jankae]

Thank you both for all the tests and data! I will look into this as well and am very curious to know what is going on here.

Before I run any tests myself, a little bit of math on the resolution used in the LibreCAL:

But I did not notice (until now) that the device exposed versions are fixed point floats with 6 decimals (no scientific notation), similar to the output of a NanoVNA for example (which for small details only leaves 4-significant digits in my view, and is not sufficient for a traceable standard or an eCal).

You are correct, the LibreCAL stores its own coefficients with 6 decimals although the actual data during the factory calibration has more resolution. Here is why I think this is not an issue:

• The lowest value in dB can be expected on the LOAD and tends to be around -30 dB (give or take)
• -30 dB corresponds to a linear value of about 0.03 (e.g. -30 dB could be stored in the LibreCAL as 0.03 real + 0 imag)
• Due to the limited resolution of the data, there can be a quantization error of up to 0.0000005 (e.g. if the actual measured value would be 0.0300005, it could either be stored as 0.030000 or 0.030001)
• Translating this into dB:
  • 0.030000: -30.4576 dB
  • 0.0300005: -30.4574 dB
  • 0.030001: -30.4573 dB

Conclusion: The error introduced by the resolution is absolutely tiny and only shows up at the fourth decimal in dB (and this is for high return loss. For the SHORT, OPEN or THROUGH standard the error will be even less). This is far below the accuracy of the LibreVNA and just moving your cables a little bit will probably have a much larger impact.

[vsilves]

Translating this into dB:

• 0.030000: -30.4576 dB
• 0.0300005: -30.4574 dB
• 0.030001: -30.4573 dB

Thanks both for identifying the root cause and fixing it. It is good to know why things work or don't work. For the precision I had arrived to a similar conclusion, but here is one of the lines from the load on port 1:

1.1e-05 0.0664545254193 -0.00146159163952

As you can see -0.001462 would be the representation an in theory is enough, but in practice there are only 4 significant digits. Further more, users could be measuring better loads with -40 dBm RL. I have seen this effect a few times on my NanoVNA-F v3, with similar fixed point arithmetic and digits, where measuring some of my good loads, it sometimes flips their phase (artifact) for longs stretches of frequencies (say from 0.9GHz to 1.5GHz), which affects skrf virtual calibrations I am trying to do with them. I simply measure the loads a few times until I get a "clean" read of the parameters that does nit glitch out.

Even if the resources of the LibreCal are somehow constraint I would advise on at least using scientific notation instead of fix point if 6-digits must be kept. So something like this which would provide significantly more dynamic range:

-146159e-3 or -0.146159e-2

I suppose this only matters for the LIbreVNA as the Siglent reads the other package generated. For which, from what I can see the relevant line is:

snp_line = [float(x) for x in l.split(" ")][1:]

which I think python by default will output 64-bit floats (which I prefer as that is similar to what the Siglent uses internally). Looking at the generated data packet's Factory.csv I see scientific notation and many digits (so I am happy). Now I need to double check, generate the packet again with either of the source S parameters and see if I see any difference and if I can tell which one I actually used in my original generation.

Now, note that having traceable standards is very useful and I only have the LIbreCal standards, no other traceable standards, so I measured LibreCal port 1 standards using my uncalibrated NanoVNA and that along with the vendor ideal S parameters allows me to do off-line calibrations with scikit-rf of other NanoVNA measurements. Results are impressive, but I did have to repeat some initial raw measurements to avoid clear glitches due to low number of digits. For this kind of traceable reference measurements it is good to have lots of digits, but of course limited by NanoVNA's output still. When I do the same on my Siglent (offline with scikit-rf) it will be nice to have both the many digits from the Siglent raw measurements, and the many digits from LibreCal vendor (but then will be limited to 3.2GHz).

All in all the LibreCal is useful as eCal for Siglent, but is also useful as traceable reference standards for off-line measurements using "any" VNA, including the NanoVNA.

[jankae]

As you can see -0.001462 would be the representation an in theory is enough, but in practice there are only 4 significant digits.

Yes, it does not look that good at first glance. Consider an even more extreme example where the imaginary part happens to be even closer to zero. You may end up with just one/two significant digits in that case. But I still think it is okay. And that is because what really matters is the amplitude and phase information, not the relative error of the real/imag parts on its own.

Your example (0.0664545254193+-0.00146159163952i) is the real/imag representation of -23.54740848 dB at a phase of -1.259952316°.

The LibreCAL would store the value as 0.066455+-0.001462 due to the limited resolution. This turns out to be -23.54734531 dB at a phase of -1.260295229°. This is an error of 0.00006317 dB and 0.0003429°.

During factory calibration, the LibreCAL is either measured by a SNA5014A or a E5071C. They are specified with 0.005 dB / 0.03° and 0.004 dB / 0.035° RMS trace noise. This is a few orders of magnitude above the resolution which the LibreCAL is capable of. Sure, you could store more digits but they wouldn't have any meaning at all.

Just as a further example, here are two measurements from my SNA5014A with a LibreCAL connected. Both the SNA and the LibreCAL have been allowed to heat up and the SNA was calibrated with the LibreCAL and the LibreCAL set to LOAD afterwards. The cable between them is a Mini circuits 141-18SM+. Both measurements were taken with only a few seconds between them and no part of the setup was moved between the measurements. The SNA was set to an IF bandwidth of 100 Hz (which is slower and less noisy than the setting used for the factory calibration).
Measurement.zip

Sure, the measurements have lots of "significant" digits and use scientific notation. But look at how many digits change between them:
1st measurement:

# Hz S RI R 50
100000 5.28217621e-02 -1.90081576e-03

2nd measurement:

# Hz S RI R 50
100000 5.27667049e-02 -1.91498181e-03

In reality, these are just a lot of digits but most of them are only noise and not significant at all. The LibreCAL resolution is absolutely sufficient to store the significant part of them.

[jankae]

A binary comparison then revealed that your line separator is only 0A, while mine is OD0A.

I think that is what makes all the difference! From my tests so far, the Siglent really does not like the \r\n Windows style line endings. I can repeatedly get it to behave like this:

• Using \r\n line endings: eCal is detected and calibrates without errors but the auto port detection does not work and the calibration results in completely bad data
• Using \n line endings: eCal is detected, auto port detection works and the calibration results in good data

Personally I think this is a bad implementation on the Siglent but I guess you could also argue that they know that their eCals will never use \r\n and thus do not need to handle it.

So I guess this comes down to which operating system you used to generate the Siglent coefficients. Wirh Linux and macos you get \n line endings and everything works. With Windows you get \r\n line endings and the calibration breaks. I have now adjusted the python script to always force \n line endings no matter which operating system it is being run on. For me, this results in a valid calibration even if I generate the data in Windows. Please check on your side if you can confirm this.

I thought S-parameters were supposed to be device/unit specific (although obviously should be similar and close, but not this close I thought)

They are device specific but the differences are small between LibreCALs. Especially at low frequencies it will not make a big difference. If Christian kept using the 385 to 485 MHz span as in the first tests, you would need to look quite close to spot any changes.

I tried your working data as well all the way up to 8.5 GHz and starting at about 3-4 GHz, the line for an OPEN deviated a little bit from the ideal 0 dB.

[dh5dan]

So, I've done it now.

As Jan correctly identified, the problem was with the line separator.
It was 0D0A here. I'm using Windows and Python Portable, and
therefore the line separator was no longer compatible.

Vicente has a Mac, and that's Linux, so it was correctly 0A for him too.

The cause was the following entry in the script:
io.TextIOWrapper(outf_b) as outf:

This must be changed to:
io.TextIOWrapper(outf_b, newline='\n') as outf:

This means that the line separator is no longer determined by the operating system, but is fixed.

That was the solution.

Okay, who's aware that Python behaves a bit differently under Windows and that the Siglent S-parameters ignore everything?
You don't get an error message either, except that you end up with strange values that you can't initially explain.

Well, now we've figured out a few things and finally found a solution.

So the fact is:

• You have to adapt the conversion script once as described above.
  This will make it work regardless of the operating system.

• The S-parameters in LibreCal are OK and correct.

I'll check how the conversion script behaves when it receives the factory calibration data where the exponent notation is different.

s11 calibration with connected libreCal

s11 Calibration. Cable end open.

s21 calibration. Connected to LIbrecal.
Attenuation value -2.40 dB, as expected.

S21 calibration with 0dB passthrough adapter. Now at 0dB as expected.

[jankae]

Awesome, thank you very much for the feedback!

This must be changed to:
io.TextIOWrapper(outf_b, newline='\n') as outf:

Looks like we may have worked in parallel on that, I have already pushed a commit with that exact change: 58ff0bb (and also figured out that the Windows build toolchain broke due to a Github runner update but that only affects the LibreCAL-GUI and does not matter here).

[dh5dan]

Pair Programming ;-)

[vsilves]

Your explanation is very sound but I still have the doubt in the back of my mind (based on NanoVNA, not based on LibreCal) about using fixed 6-decimal numbers from having seen phase shifts on measurements.

Here I calculated the difference networks between the LibreCal vendor provided networks and the LibreCal firmware exposed networks, and plotted the difference using skrf.

For LogMag I can see only noise at -125 dBm so well below any measurement and completely insignificant. For the phase I see random walks from 0 to +/- 4K or 5K degrees (unwrapped). This is what worries me. A small difference in real/imag has negligible effect on magnitude but may accumulate and cause large unwrapped phase swings as phase is derived from atan2(imag, real), so even a tiny error in the low digits of real or imag can cause large phase errors when magnitude is small.

And similar for the THRU.

What do you think?

[jankae]

What do you think?

I think that I do not know exactly what the math behind the plots you shared is so please take everything in this reply with a grain of salt.

But I can make some assumptions:

• You took the touchstone files from the server (with the high resolution), lets call them Z
• You took the touchstone files from the LibreCAL (with only 6 decimals), lets call them Z'
• You performed this calculation: X = Z - Z' (or X = Z' - Z) and plotted X

I am making this assumption because you said

I calculated the difference networks between the LibreCal vendor provided networks and the LibreCal firmware exposed networks

and if you calculate the maximum difference between Z and Z' you get 0.0000005+0.0000005i which is -123 dB and your magnitude plot shows noise up to about that value, so that all makes sense.

Okay, lets get into your phase plot. What you are interested in is the phase difference between Z and Z', so phase(Z) - phase(Z'). What I believe you have plotted is the (unwrapped) phase(X) which can also be expressed as phase(Z - Z'). And that is not the same thing at all! (phase(Z) - phase(Z') != phase(Z - Z')).
Think about how X looks like here: Z and Z' are both vectors to some point in the complex plane. They are very, very similar but Z' has a little bit less resolution. You can think of Z' as taking the point of Z and snapping it to the nearest point in the plane that can be expressed with 6 decimals. This point will be very close to the original point of Z but will have moved a tiny bit in some direction.

How large can the distance between the original point and the moved point be? Up to sqrt(0.0000005^2+0.0000005^2) which is 0.0000007071 which is about -123 dB, so that takes care of the magnitude plot.

In which direction will the moved point be from the original point? Well, it can be any direction. This really only depends on whether you need to round up or down (and how much you need to round) from Z to Z'. And phase(X) is just the direction of that movement, so it will be a completely random phase value. And what do you get if you unwrap random phase values? A random walk plot with steps up to +/-180°. So that also explains your phase plot.

The problem is that your phase plot looks nice but (in my mind) is completely meaningless. We have already established that the difference between Z and Z' is just noise (as shown in the magnitude plot) with an expected value of 0+0i. And if you take the phase value of that, you will also only get noise. But the noisy phase value does not really have an expected value, it can point in any direction.

What you really should plot to compare the phases is phase(Z) - phase(Z'). And I can pretty much guarantee you that this will be very, very close to 0° over the whole frequency range with deviations of only fractions of a degree.

Again, this is all based on my assumption about your math. If you did something else, this whole reply is pretty much meaningless.

[vsilves]

Ah, your assumptions where right, just plotting [ net.plot_s_db() for net in port1_diff ] for the magnitude. For the phase you are right I was plotting the phase of the difference networks (wrong) instead of the difference of the phases (correct). Here are the corrected graphs.

Phase error is only 1/1000 to 7/1000 of a degree so negligible like the magnitude error. Now there is no longer doubt in the back of my mind. Thanks for helping me visualize this. I am only a hobbyist but still like to understand where things come from.

Vicente