Question on documentations

[Alex-888888]

Dear jankae,

Thank you for libreVNA and all the shared informations.
Inside DevelopperInfo section are two documents : Device_protocol_v13.pdf and USB_protocol_v12.pdf.
They are different and some USB packet (for spectrum analyser for example) are different.
Which is the reference document ?
I think Device_protocol_v13.pdf is the good one but before starting any coding, I would like to be sure.
Inside Device_protocol_v13.pdf, an Ethernet interface is described.
Is it TCP over USB or it's possible to add a physical Ethernet ?
Thank you for your answer.
Best regards,
Alex

[jankae]

Hi Alex,
version 13 is the one used in the latest firmware, see also here:

LibreVNA/Software/VNA_embedded/Application/Communication/Protocol.hpp

Line 13 in 2bbb879

static constexpr uint16_t Version = 13;

Version 12 was in use in an older firmware (and versions 1-11 have also been used in even older firmwares but they are not documented).

Inside Device_protocol_v13.pdf, an Ethernet interface is described.
Is it TCP over USB or it's possible to add a physical Ethernet ?

It is possible to add physical Ethernet (the GUI fully supports it already) but that has only been implemented on a non-published prototype of mine. If you want to go that route, you are on your own - at least for now.

[Alex-888888]

Dear Jan,

Thanks for your answer.
If it's possible for you to send more information on how to add a physical Ethernet, it would be nice.
Protocol of Communication is the same ?
Best regards,
Alex

[jankae]

The protocol is the same. There are some additional things that happen with Ethernet (e.g. discovery of LibreVNA over the SSDP protocol) but this is all described in the documentation for protocol v13 (section 2.2).

Adding Ethernet to the LibreVNA requires significant changes. You would need to use a different µC (or add an Ethernet MAC) and also change a lot in the firmware (at least a lot of the low-level stuff, once you get to the point where your Ethernet-Stack sends and receives packets according to the protocol description the high-level stuff can stay the same).

I am sorry but I can't share any details of my implementation, it was a customer project and I was just re-using some ideas from the LibreVNA and thought that adding TCP support to the GUI at that point would be a good idea for the future.

The general idea for implementing Ethernet is this:

• Pick a different STM32 with an Ethernet controller peripheral
• When you set up the project in CubeMX, enable the Ethernet and lwip
• Configure lwip in the code to listen at the correct ports (described in the protocol description document)
• Throw received data into the packet parsing functions (the same that are already used by the USB stack)
• Send encoded packets through the lwip socket instead of through USB

Depending on your level of experience this might either be an easy task or a completely impossible project. The good news is that you "only" need to change the hardware and firmware, the GUI software is already handling its side of the communication.

[Alex-888888]

Dear Jan,

Thanks for all the shared informations.
I will think about all.
Best regards,

Alex

[Alex-888888]

Dear Jan,

One last question.
Is it possible to reduce the number of point for the sweep in SA mode trough the SCPI server ?
Best regards,

Alex

[jankae]

You can find the VNA_embedded.elf (not bin, but I think this should also work for comparison) in the firmware files for each commit. E.g. here from the latest one: https://github.com/jankae/LibreVNA/actions/runs/7948406082

[Alex-888888]

Thanks,
Compilation is not correctly working on windows for the moment.
I have the following warnings and error...

dwarf line number information for .data ignored
leb128 operand is an undefined symbol: .LVU16

I will go to linux to try to rebuild µC

[Alex-888888]

Dear Jan,
It's also impossible to build the uC from linux with the latest release of CubeIde.
Which release have you used to build the project?
Alex

[jankae]

I am still using 1.8.0. It is a bit old but works fine for me. I just tried it with 1.14.1 and get the same error as you. Some googling shows that it is likely a binutils bug(?), it doesn't seem to like executable code in the .data section combined with compiling for debug.

I need the executable .data for the firmware update, so the only option is to disable the -g option in the compiler:

Once I do that, I can build it with 1.14.1 as well. I guess this would make debugging a bit more difficult, so I will be staying on 1.8.0 for now.

[Alex-888888]

Jan,
Thanks for your help.
In this way I can also build the project.
Googling never point me to a binutils bug.
I spent some days trying to rebuild the project from many ways.
I without your answer i was in the point to recreate project from scratch.
I will continue to search to find a way to enable the -g option in the compiler.
Thank you