Clone 85033E VNA cal kit measured against PICO cal kit using LibreVNA

[TopQuark]

A while back I purchased a LibreVNA after deciding I've outgrown what my nanoVNA can do. I have been pretty happy with it and I might review it proper later.

However, like most low cost VNAs, the calibration kit that comes with the LibreVNA is basically a set of glorified dust covers along with a cheap terminator. There are people in the community that have characterized the LibreVNA cal kit with more professional equipment against proper standards, but the low cost nature of the kit means there's no guarantee for the consistency of the cal kit manufacturing process (the only thing that makes characterization data transferrable between kits). Furthermore, it is near impossible to screw in the cal kit pieces without rotating the center pin, as the piece that holds the short pin barely protrudes out from the rotating nut. For a VNA, garbage in = garbage out is especially true at high frequencies, and bad (or lack of) cal kit offset delay data makes impedance matching at high frequencies an exercise in vain. Long story short, I wanted something better to calibrate my VNA.

I decided to get two sets of 3.5mm female kits. One is the premium 3.5mm female cal kit from Pico technologies (859 USD, ouch) , the other one a Chinese clone of the 85033E female cal kit purchased from Taobao (165 USD, good match for my LibreVNA). I avoided SMA kits as IMO 3.5mm connectors are manufactured with tighter tolerances and more stable. The big difference between the two kits is the Pico kit comes with individually characterized data (calibration artefact + traceable touchstone data), whereas the clone 85033E kit just says "85033E" on the item listing (calibration artefact, no traceable data). The idea is to use the Pico kit as the lab reference standard, then characterize the clone 85033E and use it as the lab working standard.

My hope is the clone 85033E kit actually matches the real 85033E kit in terms of offset delay and calibration coefficients, failing that, I would just save the touchstone measurement files of the clone 85033E kit and use those as the cal kit data.

Note the clone 85033E kit only comes with short, open and load. The 3.5mm through adapter (25 USD) and the 2 SMA terminators (15 USD each) used for isolation calibration is purchased separately, also from Taobao.

To make the best measurements I can, I am using 3.5mm phase stable test leads, being careful not to bend them much between measurements, 0.9Nm torque wrench for every single connection, and have warmed up my LibreVNA for about an hour to let its temperature stabilise before any measurements.

[TopQuark]

First step is to calibrate my LibreVNA using the Pico cal kit with the cal data provided by Pico.

The data comes in a USB stick containing a single .kit file for the SOLT artefact standards. The .kit file is basically all four touchstone files cramped into a single file with some extra formatting stuff for the picoVNA software. It is easy to determine which chunk of the file belongs to which of the SOLT standards by just looking at the value of the data.

I extracted the data and separated them into individual touchstone files for the LibreVNA software to read. I have attached the original .kit file and the separated touchstone files for anyone interested.

[TopQuark]

After calibrating the LibreVNA, I immediately moved on to measure the clone 85033E kit. I have attached the measurement files for the SOLT pieces as measured.

After a brief play with the data in Simsmith, I am pleasantly surprised by the quality of the clone 85033E kit.

As I am only measuring the kit to 6GHz, I decided to compare the measured data to the published cal coefficients for the 85033D kit, the 6GHz rated version of the kit.

I modelled the open as an air transmission line with a parallel capacitor with capacitance 49.43 fF (C0 ×10−15 F), and the short as an air transmission line with a series inductor with inductance of 2.0765 pH (L0 × 10−12 H). I then tuned the length of the transmission line until the modelled short and open matches the measured data trace.

With this crude exercise, I eye-balled the open offset delay to be 29.43ps (vs 29.243ps of original 85033D), and the short offset delay to be 31.86ps (vs 31.808ps of original 85033D). This is an incredibly close match from a first pass estimation.

The load standard of the kit is also quite good compared to the corrected Pico load, measuring below 1.030 VSWR at 6G. This mismatch is low enough that I would trust it as a calibration load considering connector to connector mismatch can easily exceed that anyways.

I have attached the raw measurement data of the clone 85033E kit, along with Simsmith screenshot of my open and short models. Feel free to play with the data and see what you can make out of it.

All in all, I am really happy with the Chinese clone 85033E kit. Had I known it's close match with the real deal, I would have skipped purchasing the pico kit and just used the 85033D coefficients. But at the end of the day, measuring is knowing, and without this new found knowledge, the clone 85033E kit would not have been useful as a cal kit.

[joeqsmith]

A while back I purchased a LibreVNA after deciding I've outgrown what my nanoVNA can do. I have been pretty happy with it and I might review it proper later.

I stopped following the LibreVNA development a few years ago and would be very interesting in seeing your review on it.   The first thing I noticed was the large chunk of aluminum.  Until I read what you posted, I had no idea what that box was.     Obviously your not making any use of the sinks surface area the way you are using it but maybe this suggests this is more for show than actually an oversight by the designers?

[TopQuark]

You are not wrong about the peculiar "thermal solution", I have been experimenting with different ways to manage the temperature induced drift of the LibreVNA. I have been toying with different ideas and including sticking a heatsink with fan on the aluminium lid, a more effective use of sink area for sure. The fan is hooked up to the 5v USB supply.

I am still debating on whether I should use a big block of aluminium like in the original photo and have the temperature stabilized against a big thermal mass, but having to wait a while for the temperature to settle, or use a heatsink + fan to bring the device temperature to room temperature. My room temperature can fluctuate quite a bit due to the poor bang bang temperature control of the AC unit.

The goal is not to cool the VNA to ambient, but rather hold the temperature stable enough to minimize the error between calibration and measurement of the DUT. Hell, I've even thought about heating and controlling the temperature of the lid to 60C, just don't like the idea of needing an extra power source.

[joeqsmith]

I assume the document talks about a warmup time.   Even if not, I would assume a half hour.   Sounds like the claim is the VNA continues to drift some unacceptable amount?  Good stuff to cover in your review (what the specs claim vs how yours performs).   

Yes, I would think you would add some heaters to the case run it closed loop above your ambient.  Easier than trying to cool it plus no condensation problems.  Still, I'm surprised it's an issue. 

Last I knew, they were talking about another hardware revision.  Has this happened?   Did they ever open up the protocol to control the VNA directly or do you still have to use their software?   Sorry for pulling you off topic.  Just curious.   

[TopQuark]

Might as well use this thread for discussion for the LibreVNA, the project doesn't seem to have an active thread here anyways.

I assume the document talks about a warmup time.   Even if not, I would assume a half hour.   Sounds like the claim is the VNA continues to drift some unacceptable amount?  Good stuff to cover in your review (what the specs claim vs how yours performs). 

I haven't had the time to formally characterize temperature drift vs temperature of the LibreVNA, due to the long time constants involved and the lack of tooling to automate and log temperature vs s param drift. From my observation, S12 and S21 up to 3GHz doesn't drift much with temperature, but past 3Ghz S12 and S21 can swing by +- 1dB in logmag, going from room temperature to 55-60ish deg C, which is where it settles without thermal management.

I might rig together to properly characterize the drift if I decide to review things proper, but for now the thermal mods you see are more driven by my tendency to hack and fiddle with my gear to "improve" things, rather than pursuing a certain spec goal.

Last I knew, they were talking about another hardware revision.  Has this happened?

I don't follow the development tightly, I just occasionally browse their user group. From what I gather, there was a revision b that changed the stack-up from 4 layers to 6 layers, which apparently improved port isolation slightly, data is a bit sparse (or I haven't looked deep enough). The 6 layer revision has already been available for a while now, at least when purchased from our neck of the woods.

Then there's some rough plans for a completely redesigned v2 in the works, no ETA as far as I know. Still up to 6 GHz, but improved dynamic range at both ends of the spectrum, modular front-ends so up to 4 ports possible. 2 ADC per channel. You can read about it here: https://groups.io/g/LibreVNA-support/topic/89858084

Did they ever open up the protocol to control the VNA directly or do you still have to use their software?

I wouldn't use the term "open up" myself, as far as I'm aware the project has been and is still completely open source, including hardware, firmware, gateware and software, so I personally don't think there was ever an attempt to close down the protocols.

You can talk SCPI to the LibreVNA through their software, or you can just look at how the communication between the software and firmware is done in the code to write something compatible, or just fork their github repo, remove what you don't like, and glue your own code to their codebase.

I personally think "Inflexible", "Not well documented" could be used to describe the situation even though I don't see things that way particularly, and I think even then it is out of limited time, interest and resources, but not ill will.

[joeqsmith]

That's higher drift than I was expecting to hear.   Ever look into the cause?  Maybe there is a better way to compensate for it. 

Are you aware if there been any other software developed to run it?   I've had a few people ask me about porting my software but I couldn't find any documentation on how to directly control it.   

IMO, it was a shame they didn't start with the protocol used with the V2Plus4.   They could have had the software basically for free as there's a few open sourced projects supporting it.  I'm guessing there was a reason for having a unique interface.   

[TopQuark]

I recall reading the drift has something to do with the PLLs, didn't investigate proper.

I think architecture-wise the hardware of the libreVNA is a bit different than the nanoVNAs out there, and some of the functions (2x thru de-embedding, TRL calibration) probably only make sense on the LibreVNA software.

I mean the software that comes with the LibreVNA is a bit quirky, things are a bit hidden and has some learning curve, but I think it is pretty powerful when you learn it. For example you can do TDR -> time gating -> DFT, or embedding port-matching elements for fixture removal (ref to ch. 11.5, 11.6 of Handbook of Microwave Component Measurements) in the libreVNA software. These are features that even next-tier-up VNAs like the minicircuit eVNA or the PicoVNA don't support as far as I am aware.

[TheSteve]

Do you have a gauge set to check the physical properties of the kits? I am guessing for the price the clone is is not using PSC connectors?

[hwalker]

"IMO, it was a shame they didn't start with the protocol used with the V2Plus4.   They could have had the software basically for free as there's a few open sourced projects supporting it.  I'm guessing there was a reason for having a unique interface. "

   Just to clarify, the LibreVNA uses a well-documented industry standard SCPI command set, so it's really the V2Plus4 that has a unique register-based interface. 

[joeqsmith]

"IMO, it was a shame they didn't start with the protocol used with the V2Plus4.   They could have had the software basically for free as there's a few open sourced projects supporting it.  I'm guessing there was a reason for having a unique interface. "

   Just to clarify, the LibreVNA uses a well-documented industry standard SCPI command set, so it's really the V2Plus4 that has a unique register-based interface.

That's news to me. Anything I saw documented was talking to their supplied software using their command set not direct like we are discussing. 

***
I checked their Github account and this still seems to be the case.   Maybe you didn't understand.  If there is documentation on how to control it directly with SCPI or other, post a link and I'll have a look. 

[hwalker]

"That's news to me. Anything I saw documented was talking to their supplied software using their command set not direct like we are discussing.

***
I checked their Github account and this still seems to be the case.   Maybe you didn't understand.  If there is documentation on how to control it directly with SCPI or other, post a link and I'll have a look. "


   Nope, I understood what you were saying.  I've been using the LibreVNA for a while now and written scripts in both Python and C# to control it's VNA, spectrum analyzer and RF generator modules.  The LibreVNA is a nifty  instrument for those on a budget needing an economical general all-purpose 100kHz - 6GHz test device.  The main drawback is it is tied to a computer (PC, Linux and MAC are supported) and, as previously posted, the case gets uncomfortably warm.  Most users add some type of additional cooling to reassure themselves (heat kills).

   Jankae, the developer, is very responsive to users on his LibreVNA support group (much more than I can say about the V2Plus4 developer) and frequently pushes improvements to the firmware and software on GitHub. The users on his support site are knowledgeable "techies", which you would expect from someone willing to fork out $400+ for a piece of test equipment.  If you're still having problems locating the SCPI programming manual, you can find it at the following link.

   https://github.com/jankae/LibreVNA/blob/master/Documentation/UserManual/ProgrammingGuide.pdf

  The LibreVNA is controlled through its USB port using TCP network protocol. Having seen your posted assortment of lab equipment, the libreVNA is not a casual purchase you would make (again, the $400 USD price tag).  But for someone on a budget, it provides a 2-port VNA useable from 100k -6GHz, along with spectrum analyzer and RF generator capability in the same package.  I know longer do much design work and find myself using its spectrum analyzer and RF generator modules more often than its main VNA module.

[TopQuark]

Do you have a gauge set to check the physical properties of the kits? I am guessing for the price the clone is is not using PSC connectors?

Indeed they are not PSC, but an more ordinary 4-slot 3.5mm female connector. I have a general purpose depth gauge somewhere but I'd guess that gauge is not a good match for the job.

To be honest for this price at 6 GHz, I rather have this style of center pin, rather than having them half-arse imitate a PSC center pin.

[joeqsmith]

"That's news to me. Anything I saw documented was talking to their supplied software using their command set not direct like we are discussing.

***
I checked their Github account and this still seems to be the case.   Maybe you didn't understand.  If there is documentation on how to control it directly with SCPI or other, post a link and I'll have a look. "


   Nope, I understood what you were saying.  I've been using the LibreVNA for a while now and written scripts in both Python and C# to control it's VNA, spectrum analyzer and RF generator modules.

...
 If you're still having problems locating the SCPI programming manual, you can find it at the following link.

   https://github.com/jankae/LibreVNA/blob/master/Documentation/UserManual/ProgrammingGuide.pdf
...
  The LibreVNA is controlled through its USB port using TCP network protocol.
 

The section I copied was from the manual you linked.  I have looked at it.  I am not clear what you are saying.   You can talk to the VNA directly without their software?   The manual you linked seems to state otherwise.  Which is it?

The LibreVNA is a nifty  instrument for those on a budget needing an economical general all-purpose 100kHz - 6GHz test device.  The main drawback is it is tied to a computer (PC, Linux and MAC are supported) and, as previously posted, the case gets uncomfortably warm.  Most users add some type of additional cooling to reassure themselves (heat kills).

   Jankae, the developer, is very responsive to users on his LibreVNA support group (much more than I can say about the V2Plus4 developer) and frequently pushes improvements to the firmware and software on GitHub. The users on his support site are knowledgeable "techies", which you would expect from someone willing to fork out $400+ for a piece of test equipment. Having seen your posted assortment of lab equipment, the libreVNA is not a casual purchase you would make (again, the $400 USD price tag).  But for someone on a budget, it provides a 2-port VNA useable from 100k -6GHz, along with spectrum analyzer and RF generator capability in the same package.  I know longer do much design work and find myself using its spectrum analyzer and RF generator modules more often than its main VNA module.

The $400 dollars wasn't the problem.  It was the 100kHz lower end and I wanted the interface to talk directly with the VNA well documented.  Again, direct meaning without their software being installed.   Once they announced newer hardware,  I thought we would wait and see what they came up with.   Users posting pictures of their added heat sinks wasn't giving me a lot of confidence in the hardware design.   Then the group.io would not allow me to post anything which was really the end of my tracking it.   I understand the group was moved to a new area but I never joined up.

I'm looking forward to seeing TopQuark's review of it.   

[TheSteve]

It's tempting to buy a set just to experiment with and compare against the real thing and see how it does above 6/9 GHz.

[hwalker]

"I am not clear what you are saying.   You can talk to the VNA directly without their software?   The manual you linked seems to state otherwise.  Which is it?"

Yes, Jankae's program has to be active in the background to act as a server for TCP communications. That hasn't been an issue for me using Python or C#, but I only write scripts to automate data collection and not full-blown programs. Jankae recently stated that TCP communications are too tightly coupled for him to change anything, so if that was the deal breaker for you before it has not changed. For others who may be interested, the following link has several examples written in Python for controlling the LibreVNA with SCPI commands.
 
https://github.com/jankae/LibreVNA/tree/master/Documentation/UserManual/SCPI_Examples

Even commercial VNA's struggle to get below 100kHz.  My company had to purchase a special low end VNA (HP3577??) just to cover the range below 300kHz that our HP8753C was not capable of.

[TopQuark]

It's tempting to buy a set just to experiment with and compare against the real thing and see how it does above 6/9 GHz.

I don't mind sending my kit your way for a while to play with it, perhaps after I review the LibreVNA in a couple of weeks.

Again, direct meaning without their software being installed.

I can understand the current arrangement isn't ideal for 3rd party software developers, having developed firmware and PC software for USB/LAN controlled equipment myself, this is not how I would have done things personally. If I have the time (which I probably don't), I might look into writing some "glue" layer to translate the LibreVNA protocol to the nanoVNA protocol just to contribute back to the LibreVNA project.

Note that the GUI can be hidden with the SCPI server still running depending on how you launch the LibreVNA software, so the software can be viewed as a headless SCPI server handling the communications between 3rd party software and the device. Is that a compromise you find reasonable?

[joeqsmith]

I agree that if you need to work at lower frequencies, it limits your choices. 

The old 8753 could achieve 30k
https://www.keysight.com/us/en/product/8753D/network-analyzer-30-khz-to-3-ghz.html

From what I have seen, the original $50 NanoVNA  will far out perform the other low cost VNAs I have picked up at lower frequencies. 

If I could afford it for home use, this would be my choice.
https://coppermountaintech.com/vna/s5065-2-port-6-5-ghz-analyzer/

We agree about the need to run their software and no documented way to talk directly with the LibreVNA.   It may not be that big of a deal but the time I would need to invest into evaluating it makes it less attractive.   As long as their software is open sourced, as suggested it could be reverse engineered.  I would have overlooked the cost and lack of a documented interface had the unit been able to do something beyond what I can achieve today. 

[TopQuark]

My Siglent SDS2504X HD + SDG2122X bode plot setup will work from 10Hz to 120MHz. I find that enough for characterizing systems below 100MHz.

If I could afford it for home use, this would be my choice.
https://coppermountaintech.com/vna/s5065-2-port-6-5-ghz-analyzer/

Same here, I've looked at PicoVNA (can't stand their software), miniCircuit eVNA (missing TRL cal, gating among other things), and the CMT unit seems the best out of the mid range VNA market. Just a bit too expensive for my personal use.

I would have overlooked the cost and lack of a documented interface had the unit been able to do something beyond what I can achieve today.

Few things the LibreVNA can do today, that nanoVNAs may or may not be able to do (I don't follow nanoVNA software developments closely):
 - 6GHz operation, or even higher using harmonics (people have pushed up to 18GHz with mixed results). I don't need to measure up to 6GHz, but higher frequency means higher resolution in the time domain.
 - Time gating. Ability to bandpass or notch filter responses in the time domain, and transform the time domain data back into frequency domain, removing responses along the signal path that are not of interest.
- Full 2-port characterisation of devices, plus the ability to embed / de-embed devices on the signal path with the measured .s2p file. Useful when the test port is the wrong sex for the DUT, and you have to use an adapter. You can fully characterise the adapter then measure the DUT while removing the effect of the adapter.
- 2 x thru de-embedding
- TRL calibration

[TopQuark]

Preparing for the LibreVNA review, I whipped up a board for testing the 2xthru and TRL cal capabilities of the LibreVNA, and just to have a handy board for testing DUTs. It has:

 - TRL, TRM standards
 - SOLT standards
 - Beatty line
 - Reflect, series thru, shunt thru fixtures for 0603 components
 - 2.4G PCB antenna from TI app note SWRU120D, with PI network at the feed port for tuning

Designed with microstrip for JLCPCB 4 layer process.

Should arrive in a week and will have a few spare boards. If it works as intended, I don't mind giving out the design files and sending spare boards out to anyone interested.

[jankae]

I just found this thread, as mentioned I am more active on the groups.io for this project.

Preparing for the LibreVNA review [...]

Interesting, please let me know if you run into any issues I'd love to read what you think about the LibreVNA when the review is finished.

We agree about the need to run their software and no documented way to talk directly with the LibreVNA.

Yes, that is still the current situation (and I have no plans to change that). Just for clarification, there are two protocols:
1. The USB protocol between the LibreVNA and the LibreVNA-GUI. It is not documented (but of course it is "open" as in open-source).
2. The SCPI protocol between the LibreVNA-GUI and user scripts. That one is fully documented.

I can understand the frustration about not being compatible with the NanoVNA but please consider these reasons:
- I do most of the advanced math in the GUI. The LibreVNA only reports receiver amplitudes and phases. Ditching the GUI means losing all that functionality (calibration, de-embedding,...)
- The LibreVNA produces more data than the NanoVNA. That is both due to performing full 2 port measurements and sweeping much faster. As I am not familiar with the NanoVNA protocol, I am not sure if it would still be suitable for that
- I really do not like (Virtual-) COM ports for devices, so I implemented a custom USB class (no more manual port selection). Of course I could have used the NanoVNA protocol on top of that...

I also agree that the documentation is a bit lacking. As someone has guessed that is mostly due to the limited amount of time I have for this project - I'd rather spend it on bug fixes or new features. But I guess an update to the user manual is overdue...

If anyone has any questions or feature requests, please feel free to contact me, preferably by:
- Opening an issue on Github
- Posting to the groups.io
- Writing me an email directly

I will probably not read every post in this forum, sorry.

Best regards
Jan

[joeqsmith]

Jankae,

The low cost VNAs I have looked at use basically two different protocols.   One is older and used for the NanoVNA, H4 (others).  When the V2Plus4 was released, they used a new protocol.   The latest VNA (LiteVNA) I have been playing with uses an extended version of this protocol.   

- I do most of the advanced math in the GUI. The LibreVNA only reports receiver amplitudes and phases. Ditching the GUI means losing all that functionality (calibration, de-embedding,...)

The low cost VNAs I mentioned are sending raw data to the PC as well and allow access to the various peripherals.   I perform all the math in my software. 

- The LibreVNA produces more data than the NanoVNA. That is both due to performing full 2 port measurements and sweeping much faster. As I am not familiar with the NanoVNA protocol, I am not sure if it would still be suitable for that

I am not sure how fast or how much data we are talking about.   I can tell you that the LiteVNA is fast enough that I can connect a wire to port 2 and directly decode audio from nearby radio stations.   Granted, it is very poor quality.   Attached video should provide some idea of the speed. 

- I really do not like (Virtual-) COM ports for devices, so I implemented a custom USB class (no more manual port selection). Of course I could have used the NanoVNA protocol on top of that...

Before the low cost VNAs were available, I had written software for an old HP VNA I own.  Much of this is the same software I still use today.  I not only use it with these low cost VNAs over a virtual COM port but also over Ethernet and GPIB.   I am not a fan of using USB on any test equipment due to the poor common mode but it certainly has some advantages.   

The VNAs I own have different unique features.   One is also a spectrum analyzer.  The PNA is a full 2-port 4 receiver system.  I have separate programs for each VNA but now days use a common code base to minimize my efforts.   For the low cost VNAs, anymore I only develop for the LiteVNA.  The same software supports the V2Plus but there are features that only the Lite offers.   

I doubt supporting your VNA would be a major problem if it were well documented.   I have seen people posing about how unstable your software is and there is no way I would want that wedged between my software and the VNA. 

[jankae]

I doubt supporting your VNA would be a major problem if it were well documented.

No, but it would restrict future development of the protocol. I am still extending it when I add new features (e.g. the most recent functionality of combining multiple devices into a single multi-port VNA). It is not so much about the documentation (that could probably be done fairly quickly and to be honest you could also just grab the communications layer from my software and build the rest yourself), but what happens if I make an update to the protocol that breaks your software? That wouldn't be a good user experience either.

I am not sure how fast or how much data we are talking about.

We are talking about 640kB/s of raw payload for the highest sweep rate. That is without any protocol overhead. Maximum theoretical throughput over USB fullspeed is about 1MB/s. Seems easily doable but from my experience it actually doesn't leave a lot of room.

I have seen people posing about how unstable your software is and there is no way I would want that wedged between my software and the VNA.

Well, the software certainly crashed at some point in the development. But which software doesn't? If you are that concerned about stability I would like it much more if you would run it yourself and report possible problems instead of repeating what other people said about it in earlier versions. I am absolutely not claiming that it is without bugs (again, what software is?) but personally I have not witnessed a crash during normal operation for quite some time.

But even if the LibreVNA-GUI where perfectly bug free, I wouldn't recommend it to you as an intermittent layer. It looks to me as if you are building a GUI for different devices as well and the SCPI API is really intended for automating measurements and not for realtime data extraction.

[joeqsmith]

I doubt supporting your VNA would be a major problem if it were well documented.

No, but it would restrict future development of the protocol. I am still extending it when I add new features (e.g. the most recent functionality of combining multiple devices into a single multi-port VNA). It is not so much about the documentation (that could probably be done fairly quickly and to be honest you could also just grab the communications layer from my software and build the rest yourself), but what happens if I make an update to the protocol that breaks your software? That wouldn't be a good user experience either.

The firmware for the low cost VNAs isn't stagnant.   I had worked with Dislord, or at least they tolerated my input and as a result, I added more features to my software so support their efforts.   Lucky for me, they have continued to maintain backward compatibility.   The bigger problem early on was finding any firmware that stable enough to use.  I have not seen too many problems with Dislords firmware for the LiteVNA. 

I am not sure how fast or how much data we are talking about.

We are talking about 640kB/s of raw payload for the highest sweep rate. That is without any protocol overhead. Maximum theoretical throughput over USB fullspeed is about 1MB/s. Seems easily doable but from my experience it actually doesn't leave a lot of room.

That's not a lot for a typical modern PC and shouldn't pose any problems.     

I have seen people posing about how unstable your software is and there is no way I would want that wedged between my software and the VNA.

Well, the software certainly crashed at some point in the development. But which software doesn't? If you are that concerned about stability I would like it much more if you would run it yourself and report possible problems instead of repeating what other people said about it in earlier versions. I am absolutely not claiming that it is without bugs (again, what software is?) but personally I have not witnessed a crash during normal operation for quite some time.

Running any tests would require I obtain one.   Good to hear that you're personally not seeing any problems.  Again, I am not really concerned about the your project but I have been asked about supporting it with my software.

But even if the LibreVNA-GUI where perfectly bug free, I wouldn't recommend it to you as an intermittent layer. It looks to me as if you are building a GUI for different devices as well and the SCPI API is really intended for automating measurements and not for realtime data extraction.

My software does indeed support a few additional peripherals beyond the VNA itself including a transfer relay and some stepper motors.   The steppers are used for a delay line experiment I ran and also a two axis antenna rotor to test my pork and bean cans waveguide with.    

I consider my software a long term science project that went off the tracks years ago.   There is no long term plans for it.  If I want to run a new experiment,  I just add the code to do it.   That's been going on for about 20 years now and it shows.  I doubt there is more than a handfull of users and I certainly do not promote it or recommend it to anyone.