Electronics > RF, Microwave, Ham Radio

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

<< < (5/7) > >>

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.


--- Quote ---Preparing for the LibreVNA review [...]
--- End quote ---
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.


--- Quote ---We agree about the need to run their software and no documented way to talk directly with the LibreVNA.
--- End quote ---
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.   


--- Quote ---- 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,...)

--- End quote ---

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. 


--- Quote ---- 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

--- End quote ---

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. 


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

--- End quote ---

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:

--- Quote ---I doubt supporting your VNA would be a major problem if it were well documented.
--- End quote ---
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.


--- Quote ---I am not sure how fast or how much data we are talking about.
--- End quote ---
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.


--- Quote ---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.
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version