You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The LibreCAL only works because each individual unit is measured and has the results from the measurement stored (the factory calibration coefficients).
The measurement is done by a script which not only takes these measurements but also checks some limits and writes them to the LibreCAL.
And unfortunately these limit checks were not sufficient and quite a few LibreCAL devices were send out with wrong factory calibration coefficients. Here are the details:
Each LibreCAL is measured by a 4-port VNA to characterize it
This VNA needs to be calibrated before the measurement
The calibration kit definition in the VNA did not match the actual calibration kit used. This means that the calibration of the VNA was not correct and these errors transfer to the LibreCAL
This was not immediately obvious, because the calibration kit definition was only wrong in one spot: the delay of the THRU standard
As a consequence, there are LibreCALs out there which have the wrong THRU standard delay as well. So far the bad news. The good news: the amount of this error is precisely known and the factory calibration coefficients can be corrected without needing to measure each LibreCAL again.
How can I check if my LibreCAL is affected?
Depending on how meticulous you verify your calibration, you may not have noticed the mistake so far. It only affects transmission measurements, reflection measurements were always correct.
Starting from version 0.2.3, the LibreCAL-GUI will notify you about the bad coefficients if you connect to an affected LibreCAL. But if you want to check based on your own measurements, this is how to do it:
Calibrate the VNA with the LibreCAL
Connect both ports to each other with a known through connector (you need to know the delay of it). You may see something like this:
The phase value is rising towards higher frequencies. This would indicate a connector with negative delay which is of course impossible. The error comes from the bad LibreCAL factory coefficients. If your through connector is too long, it may still show up with a falling phase. In this case, you need to know the actual delay of your through connector to check:
Add a port extension to port 1 and enter the delay of your through connector
If your calibation is good, you should have a constant phase value of zero (or very close to it):
If your calibration is bad, your phase will either rise or fall towards higher frequencies.
Summary:
Connect a short through connector after the calibration
If the phase goes positive -> your LibreCAL is affected
If the phase goes negative -> your LibreCAL might be affected, check with the port extension if you know the delay of your connector
What was done to prevent something like this from happening again?
The error in the calibration kit definition has been identified and corrected. Additionally, the factory calibration scripts have been adjusted to catch something like this in the future.
How can I fix my LibreCAL?
Thankfully it was possible to identify the exact error and calculate new factory calibration coefficients based on the bad coefficients and the known error. To fix your LibreCAL, you just need to update the factory calibration coefficients stored on it. To do that, follow these steps:
Download the latest version of the LibreCAL-GUI and the LibreCAL firmware (at the time of writing this issue, that is version 0.2.3)
Update the LibreCAL firmware
Start the LibreCAL-GUI and connect to your LibreCAL
If your LibreCAL has bad factory coefficients, this window will pop up:
Click yes. The factory coefficient update window will open:
Keep Update coefficients from manufacturing server selected
Click Update Factory Coefficients
The corrected coefficients will be downloaded from the server and written to your LibreCAL:
Updating the factory coefficients at any point (even if your LibreCAL was not affected) is possible over here:
You can also download the factory coefficients as a Zip file directly from the server here.
I am sorry for having missed the problem until now and hope that it has not caused any serious issues.
The text was updated successfully, but these errors were encountered:
What happened?
The LibreCAL only works because each individual unit is measured and has the results from the measurement stored (the factory calibration coefficients).
The measurement is done by a script which not only takes these measurements but also checks some limits and writes them to the LibreCAL.
And unfortunately these limit checks were not sufficient and quite a few LibreCAL devices were send out with wrong factory calibration coefficients. Here are the details:
As a consequence, there are LibreCALs out there which have the wrong THRU standard delay as well. So far the bad news. The good news: the amount of this error is precisely known and the factory calibration coefficients can be corrected without needing to measure each LibreCAL again.
How can I check if my LibreCAL is affected?
Depending on how meticulous you verify your calibration, you may not have noticed the mistake so far. It only affects transmission measurements, reflection measurements were always correct.
Starting from version 0.2.3, the LibreCAL-GUI will notify you about the bad coefficients if you connect to an affected LibreCAL. But if you want to check based on your own measurements, this is how to do it:
The phase value is rising towards higher frequencies. This would indicate a connector with negative delay which is of course impossible. The error comes from the bad LibreCAL factory coefficients. If your through connector is too long, it may still show up with a falling phase. In this case, you need to know the actual delay of your through connector to check:
If your calibration is bad, your phase will either rise or fall towards higher frequencies.
Summary:
What was done to prevent something like this from happening again?
The error in the calibration kit definition has been identified and corrected. Additionally, the factory calibration scripts have been adjusted to catch something like this in the future.
How can I fix my LibreCAL?
Thankfully it was possible to identify the exact error and calculate new factory calibration coefficients based on the bad coefficients and the known error. To fix your LibreCAL, you just need to update the factory calibration coefficients stored on it. To do that, follow these steps:
yes
. The factory coefficient update window will open:Update coefficients from manufacturing server
selectedUpdate Factory Coefficients
Updating the factory coefficients at any point (even if your LibreCAL was not affected) is possible over here:

You can also download the factory coefficients as a Zip file directly from the server here.
I am sorry for having missed the problem until now and hope that it has not caused any serious issues.
The text was updated successfully, but these errors were encountered: