jankae / librecal Goto Github PK

With recent build of the firmware even on old code the LibreCAL GUI freeze during connection and USB connection is lost after few seconds.
Issue description on recent Firmware built:

• The issue can be clearly seen when launching official LibreCAL GUI on Windows10 APP when it connect to the LibreCAL it freeze and the USB connection is lost, so it is impossible to use the firmware with LibreCAL GUI on Windows10 (potentially also LibreCAL GUI for Linux to be tested)

Investigation comparison with working/reference LibreCAL Firmware:

• I have rebuilt the firmware with original source code from https://github.com/jankae/LibreCAL/tree/main/Software/LibreCAL (1f512ad) and it is the same LibreCAL GUI on Windows10 freeze (it report 0 VNA port...) then USB connection is lost (It seems it is related to USB error/timeout), I cannot reproduce that issue when sending SCPI commands with Python3 script.
  • To build the Firmware I'm using Ubuntu 20.04 LTS and I'm following the steps done with the https://github.com/jankae/LibreCAL/blob/main/.github/workflows/Build.yml#L155 A strange things is my generated LibreCAL.uf2 have not the same size 368640 bytes

    • Reference working LibreCAL firmware is here https://github.com/jankae/LibreCAL/actions/runs/3991398790 (EmbeddedFirmware--v0.1.0-2023-01-23-23-14-27.zip / LibreCAL.uf2) with size 366592 bytes using git commit 1f512ad

      • Wireshark USB OK capture for reference LibreCAL-GUI_Windows10_EmbeddedFirmware-v0.1.0-2023-01-23-23-14-27_USB_OK_pcapng.zip

    • Build version done later 18 Feb 2022 the Firmware is built exactly with same steps and same source code but it is different and have issue see Issue description on recent Firmware built (like my own built version) see built version here https://github.com/bvernoux/LibreCAL/actions/runs/4210635144 (EmbeddedFirmware--v0.1.0-2023-02-18-09-54-00.zip) with exactly same git commit https://github.com/bvernoux/LibreCAL/commit/1f512ad95bb842af440e329ada94a683d7dc7734 (but build in February) size 368640 bytes this firmware have same issue as in Issue description.

      • Wireshark USB KO capture with SCPI FIRMWARE & IDN command with no answer LibreCAL-GUI_Windows10_EmbeddedFirmware-v0.1.0-2023-02-18-09-54-00_USB_KO_pcapng.zip

It will be great to add SCPI command to add COEFFICIENT header comments especially to provide details of VNA and setup used ...
The SCPI command could be named :COEFF:ADD_COMMENT with parameter containing a string for the comment up to 120 chars maximum for example

It will be great to study and implement an emulation mode for following commercial standard E-Cal:

• PicoVNA E-Cal 8.5 GHz Automated calibration kits, 2-Port (even if we are limited to <8GHz Max)
  • https://www.picotech.com/accessories/cal-and-check-standards/picovna-e-cal
• Keysight N7551A Electronic Calibration Module, DC to 6.5 GHz, 2-Port
  • https://www.keysight.com/fr/en/product/N7551A/electronic-calibration-module-ecal-dc-6-5-ghz-2-port.html
• Keysight N443x Electronic Calibration Module, DC to 13.5 GHz, 4-Port (even if we are limited to <8GHz Max)
  • https://www.keysight.com/fr/en/product/N4431D/rf-electronic-calibration-module-ecal-dc-13-5-ghz-4-ports.html
  • https://www.keysight.com/fr/en/product/N4432D/rf-electronic-calibration-module-ecal-dc-300-khz-18-ghz-4-ports.html
  • https://www.keysight.com/fr/en/product/N4433D/rf-electronic-calibration-module-ecal-dc-300khz-26-5ghz-4-ports.html
• Rohde & Schwarz R&S ZN-Z5x automatic calibration units Models up to 50 GHz, with 2 and 4 ports, configurable ports
  • https://www.rohde-schwarz.com/us/products/test-and-measurement/electronic-and-inline-calibration-units/rs-zn-z5x-automatic-calibration-units_63493-418496.html
• Other TBD ? (the most used by priority with guys which can test / validate and own the hardware)

The immediate interest will be to fully emulate other e-CAL to replace them transparently with cheaper fully open source / open hardware LibreCAL which can support up to 4-Port e-CAL

My proposal for LibreCAL Embedded Firmware is to add a limit of 10001 or 5001 calibration points per *.snp file.
That limit shall allow in worst case to create all 4 ports calibration files with enough space in flash (limited to 748KB today).

Actual limitation with default 16Mbits (2MBytes) SPI Flash for calibration:

• After some internal tests with actual default SPI Flash 16Mbits (2MBytes) with 1MBytes for each partition (LIBRECAL_R & LIBRECAL_RW) we do not have enough space to do a full calibration for the 4 ports with 1601pts and 100 comments per snp file.
  • With my test full 4 ports calibration create 18x snp files which requires a total of 1369626 bytes about 1.3MBytes when there is only 748KB available, so that means we are limited to max 801pts per *.snp file
  • For information with 1601 pts each s1p file size is about 47KB and s2p files are 131KB.

A good feature could be to log RF switch cycle count for each switch

Hi,

I'm looking to build a LibreCAL for myself and, looking through the bill of materials, I noticed that the PE426462 switch is only specified down to 10 MHz despite the overall project going down to 9 kHz. I wonder if that is an error, or do you find that the switch performs well at lower frequencies anyway despite its specs? Would you be able to share S-parameters for any prototypes, just to get an idea of how it performs?

Thanks!
Mike

I see you have pushed some precious fixes / improvements in latest LibreCAL-GUI & LibreCAL firmware commit from Jan 23 & 24, 2023 but unfortunately the LibreCAL-GUI & firmware version have not changed and they are still v0.1.0
It will be great to update them to 0.1.1 to avoid confusion with previous firmware/LibreCAL-GUI ...

LibreCAL-GUI change:

• 1f512ad "Fix expected *IDN? response"

LibreCAL firmware changes:

• 2410e34 "SCPI API adjustments"
• b41dede "Allow higher I term for temperature control in colder environments"

Especially the firmware change b41dede

• With that change it improve a lot the time to reach the 35°C temperature when the board is quite cold <= 20°C (or even outside case)

A good improvement will be to add a SCPI command to retrieve and use PC date/time
This will be a great addition to have correct date/time on files created for example to create *.snp files for calibration (Factory or users)
As today we see file date time of 2020/01/01
It seems possible to use internal RTC for that
https://www.raspberrypi.com/documentation/pico-sdk/hardware.html#hardware_rtc
http://elm-chan.org/fsw/ff/doc/fattime.html

Even if after each power off of the LibreCAL the Date/Time will be lost the idea it to update it each time it is connected to the PC when required with the SCPI API

Proposal SCPI command :DATE_TIME with parameter format YYYY/MM/DD HH:MM:SS UTC offset (UTC offset)

• Example to set Date & Time over SCPI: :DATE_TIME 2023/03/01 10:05:48 UTC+01:00 for France Time
• Example to get Date & Time over SCPI: :DATE_TIME? will return for example 2023/03/01 10:05:48 UTC+01:00

I've been reading through the SCPI API documentation and I had a few questions/comments about some of the implementation details, particularly with regards to matching the specification (IEEE 488.2) where possible.

In the introduction, it's noted that the commands are case sensitive to allow for more flexibility when naming coefficients. I didn't really understand the reasoning here as I couldn't see any examples of the coefficient name forming part of the command. I think it'd be reasonable to allow case insensitive commands, while still requiring case-sensitive parameters? It's just really convenient when typing SCPI commands on the fly to not have to worry about case.

The behaviour around remembering the position in the command tree is unusual to me. For all other instruments I've used, they don't require the leading colon and they do not remember position between lines. They only remember the position between multiple commands on the same line (separated by a semi-colon).

For example, this would not work:

TEMP:STABLE?
STABLE?

but this would:

TEMP:STABLE?; STABLE?

This isn't strictly part of the spec and is included for information only, but as far as I know it's the most common way to do it - I think it'd be best to match that to be least surprising.

One other minor thing is that the *IDN? response format is in the spec - it should return <manufacturer>,<model>,<serial number>,<firmware version>. I think it'd be worth complying with that so other tools can parse it reliably.

I noticed that the GCPW is specified as 0.295/0.2mm trace/space (which is very to close to JLC's calculator), but in practice it comes out differently because the zone clearance is set to 0.36mm. I'm not sure if that'll cause a big difference and clearly it's worked so far, but I thought I'd just let you know.

I'm planning to go ahead and get boards with the 0.295/0.2 spec and I'll post TDR/VNA measurements when I get them.

I have discovered (in https://github.com/jankae/LibreCAL/blob/main/Software/LibreCAL/src/USB/usb_descriptors.c#L50) that LibreCAL use following VID/PID:

• USB VID: 0x0483 corresponding to [STMicroelectronics]
• USB PID: 0x4122 not used officially by ST

I really doubt such USB VID / PID usage are allowed by STMicroelectronics (especially as the LibreCAL does not use any STMicroelectronics MCU) and it will be better to ask for official one from https://github.com/pidcodes/pidcodes.github.com
LibreCAL (like LibreVNA) will comply to all rules of pidcodes to obtain dedicated PID (using their VID 0x1209 ) which requires open source firmware and open source hardware

Hi Jankae,
Judging by the layout of the printed circuit board, there will be physical changes only in the fact that in the case of the truth table Off, all switches will not be disabled, since V4 is connected to GND without reworking the board, and RFC needs to be switched to the RF1 output, which remains not connected anywhere.
The changes are as follows - instead of RF4 and RF6 in pe426462, you now need to switch RF6 and RF8 in pe42482, respectively. In the truth tables in the new version, it will look like this:

Connection P1V1 | P1V2 | P1V3 | P2V1 | P2V2 | P2V3 | P3V1 | P3V2 | P3V3 | P4V1 | P4V2 | P4V3
Through_12 0 1 0 1 0 1 X X X X X X
Through_13 1 0 1 X X X 0 0 1 X X X
Through_14 0 0 1 X X X X X X 0 0 1
Through_23 X X X 0 1 0 0 1 0 X X X
Through_24 X X X 0 0 1 X X X 1 0 1
Through_34 X X X X X X 1 0 1 0 1 0

Instead of RF4 (011) now RF6 (101).

Connection | V1 | V2 | V3 |
Load 1 1 1 (instead of RF6 (101) now RF8 (111) )
Off 0 0 0 (instead of disabling all switches (110) now switching RFC to RF1 (000) ).

Best regards.

Today it is not very clear how work the Manual control towards Through Function selection and Port Select Port1/2/3/4 (checked also in latest documentation https://github.com/jankae/LibreCAL/blob/main/Documentation/manual.pdf October 3, 2022)
If I want to do manual calibration all is clear for Port Select of PORT1/2/3/4 and Function Select for Open/Short/Load
But it is not clear for Through especially as Through requires to know Source & Destination Port and it is not clear how we can select that in Manual control.

Could you clarify how it works with Manual control ?
Case Port1 & Through:

• I have Port Select => Port1
• I have Function Select => Through
• Does it imply Through is between Port1 and Port2 ? (I suspect it is default case to be confirmed)
• How does it is displayed with LEDs ?
  • Does Both Port1 & Port2 LEDs are blinking or fix... to clearly show that the Through will be between those 2 ports ?

Case Port2 & Through:

• I have Port Select => Port2
• I have Function Select => Through
• Does it imply Through is between Port2 and Port1 ? (I suspect it is default case to be confirmed)
• How does it is displayed with LEDs ?
  • Does Both Port1 & Port2 LEDs are blinking or fix... to clearly show that the Through will be between those 2 ports ?

Case Port3 & Through:

• I have Port Select => Port3
• I have Function Select => Through
• Does it imply Through is between Port3 and Port4 ? (I suspect it is default case to be confirmed)
• How does it is displayed with LEDs ?
  • Does Both Port3 & Port4 LEDs are blinking or fix... to clearly show that the Through will be between those 2 ports ?

Case Port4 & Through:

• I have Port Select => Port4
• I have Function Select => Through
• Does it imply Through is between Port4 and Port3 ? (I suspect it is default case to be confirmed)
• How does it is displayed with LEDs ?
  • Does Both Port3 & Port4 LEDs are blinking or fix... to clearly show that the Through will be between those 2 ports ?

Now the question does it is possible to select the Port Source & Port Destination for Through in Manual control ?
See following cases:

• Port1 => Through => Port3
• Port1 => Through => Port4
• Port2 => Through => Port3
• Port2 => Through => Port4
  It can be interesting to use the eCal as a Switch or to calibrate manually 4 Ports VNA

How to reproduce the issue:

• When we have some coefficients in LibreCAL and we call in LibreCAL-GUI Coefficient -> Load From Device we have an application crash at end of the coefficient loading

This issue is triggered when appwindow.cpp AppWindow::loadCoefficients() => call the code delete d; due to the fact some threads are not finished and report updated progress ... to QProgressDialog and it is deleted.

• Quick fix for that is to avoid doing delete d; and create the QProgressDialog only one time (and destruct it when closing the application)

Considering this design only goes up to 6 GHz, why not use cheaper SMA connectors?

E.g. the Linx CONSMA003.062 (18 GHz, €4) vs Amphenol 901-10510-2 (26.5 GHz, €11.5).