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

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

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

[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