Thanks for the post. It was a good read.
I own a modest amount of test equipment and most of it is controlled remotely. Most is from major brands. The documentation is well written and the systems are fairly bug free. For me, putting together software for them has never been easier. Its rare I need software that would say, record data from a meter. It's more common that I want to read the meter as part of a much larger setup involving other equipment all tied together.
The VNA is no different. If you look at my software, you will find it has the ability to control a linear stage. This isn't something you will normally find in any VNA software. Having the ability quickly and effortlessly change the software to run more complex experiments is really powerful.
It is certainly possible to make external calls from LabView. I would frequently use MSVC to write code that needed to execute faster or more efficiently. However, I have not had to resort to that in several years. The modern PCs are so fast I now just use LabView for anything PC related.
From my experience with that first Nano, it became apparent that with it being opened source, a lot of people were interested in making their own changes to try and improve the firmware. It seemed like it would be a never ending battle to find something that worked well enough to use. It was bad enough that I put together a simple regression test to automatically check the firmware of the week. Much of the changes were focused on features I really had no use for rather than addressing the problems.
Not surprising, none of my vintage VNAs are open source. I'm not against it but when you have people making changes who really don't understand the problems they can cause, it's doing more harm than good. In the case of the original NanoVNA, having the source allowed a few people to address the basic problems and get it working. So there can be an advantage depending on the skills of the people working on it.
At least for these low cost VNAs, my demands for the firmware and hardware are simple. Document your code, allow the software to control what ever peripherals are attached and send down good data. Getting good data off the Nano was always a problem. Not because the protocol was complex or the PC lacks performance. It was just bad firmware. Oddly, more commands were added rather than correcting the root problems which had nothing to do with the protocol. Once the locals sorted out the basic problems, there was no need to do any more with it. I am surprised that much of what I saw with the early firmware is still a problem with the latest releases.
If people want to try and run my software with the original NanoVNA, the manual is pretty clear about different firmware/hardware combos being a problem. All the software in the world isn't going to make bad firmware/hardware good. We need a solid foundation to build on.
Looking at the LibreVNA, it seems like they are having problems with their software and firmware. While the moderators of some of the groups (for example
https://groups.io/g/NanoVNAV2) have chosen to make them private (which I see it as a dick move), the LibreVNA group seems to want to sensor the posts. That was enough to turn me off of it. Hopefully OWOs team will roll something out that can measure lower frequencies, with a higher resolution (at least at lower frequencies) and an increased upper frequency range beyond the capabilities of the V2Plus4. Even if they kept it closed source, as long at the interface is documented, I would get one based on my experience with the V2Plus4. Even if they just improved the V2Plus4 to allow it to fully replace the original NanoVNA, I would get one.
I was mostly referring to the low cost ones here, I was just extending the example how the same basic "I want to measure X at frequency Y" approach is vendor / model / VNA / interface neutral and could apply to high end units or low cost ones.
I gather that the tower of babylon of both interface hardware as well as interface apis & protocols is a fairly major annoyance with respect to cross platform applications that control and access test equipment in general. It seems like it doesn't need to be so bad these days one could have a simple HTTP/REST or JSON or XML or database or something based neutral exchange layer and then the instrument driver can go off and get the data however it wants, and the client applications can fetch/use the data however they want.
So far I've just got one nanovna model and no "boat anchor" devices. But even just with that it's getting hard to keep track of what nanovna variants there
are and what the differences in their hardware capabilities are not to mention what differences exist in their protocols and firmwares with respect to how to talk to them from a client application and what works / doesn't.
Eventually I'd like to upgrade to measure to 6GHz, low frequency / narrow bandwidth crystal parameter measurement, and PDNs but given what I see in this thread and the mailing lists being full of "but X doesn't work on model Y, and Z doesn't work on firmware Q" it's seeming out of hand.
I get that they're trying to build it down to a cost level but it seems so penny wise pound foolish to have all the variants of these tiny little MCUs running mutually incompatible firmware as the interface. They could just have made it so the processor board was pluggable e.g. arduino interface or something and then one could at least upgrade the CPU and the host interface (e.g. ethernet) so one wouldn't be quite so limited in terms of MCU and interface quirks / limitations by spending a few more optional dollars on a better controller.
Anyway I'd be willing to write a wrapper and API layer for these things in spare time but I don't have nearly enough hardware variants to make it very useful in the sense I couldn't port / test things to different devices without those protocols / devices available.
And in the client end since in your code's case you run labview I take it that'd mean it'd be more oriented to a C-API + DLL or better yet something over IP/UDP/TCP/HTTP or something that'd be much more portable cross client sw / platform.
I suppose if there was a simple suite of unit / system tests and a half decent client API / protocol in a few variants that might be enough to get some of these VNA firmware developers / manufacturers to be interested enough to support it instead of making everything firmware / device unique.
One thing I don't understand is the whole firmware / protocol business. I gather that the nanovna v2 being open hardware (and open source, maybe, I think?) is something that's not representative of what other devices are / will be. So I don't even know if there's open firmware / protocol documentation for any / many of the other low cost VNAs at this point or what. I saw mention to sniffing the protocol of something or other so I guess that's one way to reverse engineer at least what the serial command / response sequences are for a given firmware/unit, though if that's really all there is to rely on for most of these devices then it's a bit sad state of affairs.
I am wondering if there is NOTHING relevant / compelling about the "boat anchor" APIs, SCPI, whatever for "lowest common denominator" basic VNAs that nobody thought practically of just reusing those protocols exactly or if needed extending them slightly vs. reinventing the wheel incompatibly....
Home
Help
Search
Login
Register
