Support for other VNA hardware

[miek]

I noticed in the GUI software that there's some limited support other VNA hardware. I assume it was maybe for factory test, but I wanted to see if there's any interest in having support for other hardware.

I picked up an older HP VNA recently and its firmware is a bit limited, so I plan to use it mostly remotely. It'd be great to have all the features from the LibreVNA GUI and I'd be down to write support for it, but before doing the work I wanted to ask if that is something you'd be interested in merging upstream?

[jankae]

Yes, I would absolutely merge this.

Your starting point for implementing this is https://github.com/jankae/LibreVNA/blob/master/Software/PC_Application/LibreVNA-GUI/Device/devicedriver.h
That file has reasonable good comments, so I hope adding a new driver is not too complicated. And of course I am here if you need help with something in the software. You can also look at the example drivers I have added already. But they are fairly rudimentary and I only implemented them to the point where they were useful for some experiment I was running at that time.

[miek]

Great, thanks!

I made a start on it this weekend and got first traces! Here's a quick test measuring a check standard from a cal kit:

and comparing the time domain transform against some TDR measurements I made some time ago:

So it's looking good :) I really appreciate all the work you've put into making some great VNA software.

I've put my work-in-progress branch up here based off the SNA5000A driver: https://github.com/miek/LibreVNA/tree/hp87xx_support & will put in a PR when it's tidied up some more.
The only slight issue I ran into is that this VNA only supports a limited set of "number of points" values. I've partially implemented support for that in my branch but I'd be curious to know if that's a reasonable thing to have in the API and if you have any thoughts about how best to implement it.

[jankae]

Awesome, that is some quick progress.

I was not aware that there are VNAs out there with such limited "number of points". I think your approach of adding the allowed value to the DeviceDriver::Info class is a good solution. For now this looks like it should work good enough to control the VNA. Once your driver is fully working, I might adjust the toolbar to switch between the QSpinBox for the number of points (which it could use for VNAs with arbitrary number of points) and a QComboBox (dropdown menu, would only offer you the supported values). This has a couple of more implications because the number of points can be set via a SCPI command as well. Not completely trivial to handle all possible situations, but I think a good solution is possible.