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

[joeqsmith]

For my home hobby use, I have a few vintage VNAs.  Like hwalker's work, I use more than one VNA to cover the range I am interested in.   I have an HP3589A for lower frequency work.  A few years ago I picked up a Agilent PNA.  These both have their own problems but for my hobby use,  it's fine and much cheaper than the CMT. 

I looked at Pico when I bought the Agilent.  Their software is why I didn't go that route. 

I started to look at these low cost VNAs when a friend approached me about buying a VNA.  I had just seen an article about the NanoVNA and they bought me one to play with.   From there, I started to try and educate them on their use.   People who hung out on my channels got a free ride.   

[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. 

[jankae]

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

The PC isn't the bottleneck, the USB (fullspeed) interface is. But it is possible, it just requires a careful protocol without too much overhead.

Again, I am not really concerned about the your project but I have been asked about supporting it with my software.

Sorry, I think I have gotten the wrong idea earlier. I had the impression that you were complaining about my project and the lack of documentation, so I wanted to provide my point of view. I think I get it now and I very much understand that you are not particularly interested in integrating support for the LibreVNA just because some people asked for it.

My software does indeed support a few additional peripherals beyond the VNA itself including a transfer relay and some stepper motors.
[...]
I consider my software a long term science project that went off the tracks years ago.

It certainly looks impressive I am trying to keep my project on the tracks (i.e. not deviating too far from what a typical VNA does) and am rather aiming for easy integration with other measurement equipment through user scripts (thats why there is the SCPI API). But even though it is an open-source project, feature requests always outweigh contributions from users I am sure you get the same sometimes

Anyway, best of luck with your project and sorry about the misunderstanding earlier.

[joeqsmith]

The PC isn't the bottleneck, the USB (fullspeed) interface is. But it is possible, it just requires a careful protocol without too much overhead.

Maybe you will want to consider a bus you can grow with rather than having to work against it's limitations.   

Again, I am not really concerned about the your project but I have been asked about supporting it with my software.

Sorry, I think I have gotten the wrong idea earlier. I had the impression that you were complaining about my project and the lack of documentation, so I wanted to provide my point of view. I think I get it now and I very much understand that you are not particularly interested in integrating support for the LibreVNA just because some people asked for it.

I had considered getting your VNA early on but the higher cost took it out of the no brainer category.  The lower frequency was too limited and then there was the software.   We did follow its progress for some time but I really have not been paying attention in the past year.   Basically since the last time someone had asked me about supporting it.   I had seen a sort of review (ham) but I didn't get anything out of it but did see a few comments posted about needing added cooling and temperature drift.  Again, I don't have one and just go off of what I read.   

My software does indeed support a few additional peripherals beyond the VNA itself including a transfer relay and some stepper motors.
[...]
I consider my software a long term science project that went off the tracks years ago.

It certainly looks impressive I am trying to keep my project on the tracks (i.e. not deviating too far from what a typical VNA does) and am rather aiming for easy integration with other measurement equipment through user scripts (thats why there is the SCPI API). But even though it is an open-source project, feature requests always outweigh contributions from users I am sure you get the same sometimes

Anyway, best of luck with your project and sorry about the misunderstanding earlier.

No problem.   

I don't get too many requests for features.  I expect you have it far worse as you are supplying hardware and software to paying customers.  I have no paying customers and don't except donations.   There's an upside to that!     

I'll check out your multi-VNA project.  Someone had posted about using a couple of the low cost VNAs, a couple of T's and cables to make a full two port measurement rather than using a transfer relay.   My understanding was your VNA is a 2-port analyzer and I am guessing you are attempting to use them to go beyond two ports.   Maybe provide a link if you have it in a public place. 

[joeqsmith]

I read through some of the threads posted on your groups.io including the LibreVNA 2.0 Hardware Concept.    I

Lower frequency range. I know that higher frequencies sound more impressive but I still think that 6 GHz is sort of the limit for reasonable priced components and FR4.

Depending how low you could get things to work, it certainly would make it more attractive.   With the low cost VNAs I have looked at, that very first NanoVNA I tested out performs the others. 

Hi, Jan,
Another thing that might worth investigation is the possibility of some extra SW and HW modifications to add compatibility with the NanoVNA v.2 (SAA-2) serial communication protocol commands set (not so easy to do, might need integrating an extra STM32 mCU with separate USB communication port)
If possible to implement, it would extend the compatibility of the LibreVNA with 3-rd party software tools that had been developed for the NanoVNA v.2, LiteVNA, etc .

I doubt supporting what you have would be a major effort rather than trying to fit with what is there.  It appears your hardware will be much more capable anyway so I see no reason why you would consider constraining it.   

Eye Diagram for TDR

Hi Jan,
Can an Eye Diagram be added to the TDR function?
Aaron

I've been playing around with this a bit and plan to demo it soon running with the LiteVNA.  I had asked Keysight about providing a license for my vintage PNA to remove the frequency range restriction.  Both the LiteVNA and my PNA could work at 9GHz and may be fun to compare the two.   The Lite's performance is what you would expect for a $120 VNA.  You mention post processing the data to get the eye diagrams but I have not found any packages that would do this.  Keysight used to offer a program I guess.  They still allow you to download but no longer appear to provide licenses for it.   My software is written in LabView which is no speed demon. My plan is to work with the data live.  As you suggest, some of the math for this does slow things down a bit. 

Good luck with your 2.x design.   

***
Link to where I posted about my efforts to support eye diagrams.  At the time, I had not yet tried to run it with a VNA so it's a bit dated compared to what I pan to demo. 
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4460926/#msg4460926

[davethomaspilot]

I searched for Taobao calibration kits and found several with widely varying prices.

Is there a way I can buy what you tested?  URL?

Thanks!

[Mechatrommer]

@TopQuark. i plotted S11 from characterized data file of the 2 given Cal Kit Open Standard by TopQuark, the 3rd is mine.

attachment 1: PicoTech cal kit, i'm guessing measured with their more expensive PicoVNA device and Cal Kit. (provided in PICO cal kit.zip)
attachment 2: Clone 85033E cal kit, i'm guessing measured with LibreVNA calibrated with PicoTech Cal Kit. (provided in 85033E cal kit.zip)
attachment 3: my pcb based open standard measured with NanoVNA V2.2 calibrated with Kirkby Microwave Cal Kit (iirc, measured 2 years ago)

can you explain why the LibreVNA is ringy past 3-4GHz? your cable setup looks good. iirc there's discussion somewhere, this ringy thing is due to VNA's internal circuitry/pcb traces impedance mismatch. or maybe is it from Clone 85033E cal kit? i doubt it. whats the LibreVNA's software called? can anybody download and test it freely even without the VNA? i assume the SW can support characterized cal kit data as you've demonstrated. otoh iirc the last time i checked my NanoVNA and LiteVNA provided cal kit (Open and Short dust caps) they are almost 0ps delay, and the Load are quite acceptable. except the fixed rotating SMA male center pin on the Short and Load.

[TopQuark]

I searched for Taobao calibration kits and found several with widely varying prices.

Is there a way I can buy what you tested?  URL?

Thanks!

https://item.taobao.com/item.htm?id=568795988394
I have 2 of these kits now, I think they are fine for what they cost, but of course my testing of the kit is not very through nor with very good equipment. Buy at your own risk.

@TopQuark. i plotted S11 from characterized data file of the 2 given Cal Kit Open Standard by TopQuark, the 3rd is mine.

attachment 1: PicoTech cal kit, i'm guessing measured with their more expensive PicoVNA device and Cal Kit. (provided in PICO cal kit.zip)
attachment 2: Clone 85033E cal kit, i'm guessing measured with LibreVNA calibrated with PicoTech Cal Kit. (provided in 85033E cal kit.zip)
attachment 3: my pcb based open standard measured with NanoVNA V2.2 calibrated with Kirkby Microwave Cal Kit (iirc, measured 2 years ago)

can you explain why the LibreVNA is ringy past 3-4GHz? your cable setup looks good. iirc there's discussion somewhere, this ringy thing is due to VNA's internal circuitry/pcb traces impedance mismatch. or maybe is it from Clone 85033E cal kit? i doubt it. whats the LibreVNA's software called? can anybody download and test it freely even without the VNA? i assume the SW can support characterized cal kit data as you've demonstrated. otoh iirc the last time i checked my NanoVNA and LiteVNA provided cal kit (Open and Short dust caps) they are almost 0ps delay, and the Load are quite acceptable. except the fixed rotating SMA male center pin on the Short and Load.

Thanks for the analysys, I don't really have an explanation as to why the data trace is wavey, what you suggest sounds plausible. The software for the LibreVNA is freely available on github under the same name, iirc some of the functionality like viewing traces can be used without the device itself. The SW does support characterized cal kit data, which is what I used to calibrate the VNA against the pico cal kit.

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.

TBH besides the lack of time, the thing holding me back from reviewing the LibreVNA is the software crashing. I think the whole package is great for the price, it is very hard to find anything that is as capable at the price (or a few times more for that matter) . I want to give it a glowing review and good publicity but I can't when the software crashes from time to time.

I don't really want to just complain about the issue and hope someone fixes it, but I want to contribute to fixing the issue instead. I have on order an USB protocol analyser, sniffed the traffic with Wireshark and I have looked into the code for the software. I haven't sunk much time into the issue yet (working 2 jobs at the moment), and the intermittent crashes sometimes take hours to occur, means it is something that will take some time to debug. But it is something I am doing.

[jankae]

the thing holding me back from reviewing the LibreVNA is the software crashing

Sorry to hear that. It has been a while since someone mentioned irregular crashes. The thing is that I have never been able to reproduce any. I have let my software run for days (on Win10 and Ubuntu) and it didn't crash. I would really really like to fix that but I simply have no idea where to start looking. It is very much a "works on my machine" issue...

It sounds like you are prepared to spend some time with it and also have some experience. What would probably help me the most is this:
- Install the Qt IDE (QtCreator with Qt 5.15.2 and MinGW 8.1.0 64bit compiler)
- Clone the repository (preferably the latest on master but that is experimental and would mean you have to update the device firmware as well. Using 1.4.0 is probably also fine)
- Install the libusb-1.0 dependency (download libusb header and library files, place in compiler search path)
- Compile the software in QtCreator, start it in debug mode and wait for it to crash. Maybe you'll see something obvious right away but in any case I would love a screenshot of the debugger after the crash (should point to the offending line and contain variables and the call stack).

I am fairly sure that it will be a relatively easy fix once the cause of the crash has been determined. If you want to try this but run into any issues setting up the toolchain, please get in touch through j.kaeberich@gmx.de

[nctnico]

I have seen intermittant USB communication causing problems but these can be very machine dependant. Perhaps it is an idea to inject USB errors and see how the software deals / recovers from that?

[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. 

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.

jankae did end up documenting the direct interface with their LibreVNA.   I looked into how it worked and it seems pretty straight forward.   They did warn about it continuing to evolve with the project but I don't see that being much of a problem.  I suspect it would be similar to Dislord's development of the firmware for the LiteVNA. 

[Joel_Dunsmore]

@TopQuark. i plotted S11 from characterized data file of the 2 given Cal Kit Open Standard by TopQuark, the 3rd is mine.

attachment 2: Clone 85033E cal kit, i'm guessing measured with LibreVNA calibrated with PicoTech Cal Kit. (provided in 85033E cal kit.zip)

can you explain why the LibreVNA is ringy past 3-4GHz? your cable setup looks good. iirc there's discussion somewhere, this ringy thing is due to VNA's internal circuitry/pcb traces impedance mismatch. or maybe is it from Clone 85033E cal kit? i doubt it. whats the LibreVNA's software called? can anybody download and test it freely even without the VNA? i assume the SW can support characterized cal kit data as you've demonstrated. otoh iirc the last time i checked my NanoVNA and LiteVNA provided cal kit (Open and Short dust caps) they are almost 0ps delay, and the Load are quite acceptable. except the fixed rotating SMA male center pin on the Short and Load.

The ripple has the rate of about 125 MHz which suggests a reflection length of something like 1 meter.  So likely the calibration kit wasn't great, and the cable connection at the VNA was not great or the VNA source match raw changed over time, causing a mismatch ripple between the high reflection and the poor match back at the other end of the cable.  Ripples like that have to come from long things.

[joeqsmith]

... or the VNA source match raw changed over time, causing a mismatch ripple between the high reflection and the poor match back at the other end of the cable.  ....

I've seen several photos of people using large heatsinks and fans to attempt to cool the LibreVNA.   There have also been several posts about the drift.    There was some additional posts here as well.   Maybe users cal them cold and the ripple is a result of it drifting while it warms up.  Odd is people in the group.io  don't seem to care.  There was a recent change to the hardware and it still behaves like this. 

https://www.eevblog.com/forum/testgear/sub-$1000-vna-for-antenna-matching/msg4546259/#msg4546259

[Mechatrommer]

China coax and cal kit that comes free with litevna dont exhibit those ripple that bad on cheapy litevna, i have to dig some of my super crap no brand for video coax to get that kind of ripple.. my diy pcb cal kit stuff with impedance way off from 50 ohm and physical length about 10mm also dont produce such ripple. OP didnt seem to use super crap coax setip during testing either.. i'll try to simulate when i get home..

[小太]

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.

I've fitted the data with METAS VNA Tools and plotted them compared to the 85033D/E values (the same way as I did in this post).
Here are my results:

Short F	Offset Z0 (Ω)	Offset delay (ps)	Offset loss (GΩ⋅s-1)	L0 (10-12 H)	L1 (10-24 H⋅Hz-1)	L2 (10-33 H⋅Hz-2)	L3 (10-42 H⋅Hz-3)
85033D/E	50	31.785	2.36	2.0765	-108.54	2.1705	-0.01
Fitted	49.359	51.446	1.9069	-943.86	-13443	368.46	-797.77
Open F	Offset Z0 (Ω)	Offset delay (ps)	Offset loss (GΩ⋅s-1)	C0 (10-15 F)	C1 (10-27 F⋅Hz-1)	C2 (10-36 F⋅Hz-2)	C3 (10-45 F⋅Hz-3)
85033D/E	50	29.243	2.3	49.433	-310.13	23.168	-0.15966
Fitted 1*	65.983	34.636	6.2415	108.37	-3455.4	-5323.7	427.33
Fitted 2*	50	16.411	8.2849	302.54	-757.17	1433.5	-41.184
Load F	Offset Z0 (Ω)	Offset delay (ps)	Offset loss (GΩ⋅s-1)
85033D/E	50	0	0
Fitted**	50.696	38.188	-6.8213

* A full fit on the OPEN standard gave stupid numbers for offset Z₀, so I tried again while forcing it to 50Ω
** I've no idea the significance of a negative offset loss on the LOAD. But if I force it to a non-negative number, the fit is substantially worse


Both the 85033D/E and fitted values results in a good match to the SHORT and OPEN standards, and I suspect the main difference is due to the odd ringing past 3GHz.
Meanwhile the LOAD standard is wild, with 85033D/E just assuming a perfect load, and the fit being quite poor