EEVblog Electronics Community Forum
Electronics => RF, Microwave, Ham Radio => Topic started by: joeqsmith on July 22, 2019, 11:54:25 am
-
Table of Contents
For those unable to use the search, the following links should help guide you
Installing the software:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4037716/#msg4037716 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4037716/#msg4037716)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4041214/#msg4041214 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4041214/#msg4041214)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4055866/#msg4055866 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4055866/#msg4055866)
Software not finding the lvsound2.dll:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4095544/#msg4095544 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4095544/#msg4095544)
Adding a Transfer Relay:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4058836/#msg4058836 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4058836/#msg4058836)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4060027/#msg4060027 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4060027/#msg4060027)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4060045/#msg4060045 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4060045/#msg4060045)
Running the software on high resolution monitors (resize):
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/?topicseen#msg3617154 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/?topicseen#msg3617154)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813608/?topicseen#msg3813608 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813608/?topicseen#msg3813608)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621361/?topicseen#msg3621361 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621361/?topicseen#msg3621361)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3616560/?topicseen#msg3616560 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3616560/?topicseen#msg3616560)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4038201/#msg4038201 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4038201/#msg4038201)
cyp_eev's non-contact Q measurement test fixture:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4132957/#msg4132957 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4132957/#msg4132957)
****************** The beginning **************************
Is there a document that describes the communications for the NanoVNA?
-
I have started working on the communications and have a simple Smith chart now working.
-
Hm, there is the official GitHub repository which should allow at least reverse engineering:
https://github.com/ttrftech/NanoVNA
-
It's never a good sign when you have to reverse engineer something. Someone had started a list of commands and someone else posted the BAUD. It's easier for me to just sniff it. All seems fairly basic so far.
-
Isn't sniffing another way of reverse engineering? Anyway, all the communication commands seem to be implemented in main.c (array "commands"). So that might have been worth a look.
-
Isn't sniffing another way of reverse engineering? Anyway, all the communication commands seem to be implemented in main.c (array "commands"). So that might have been worth a look.
You bet it is. Did I post something otherwise? Ideally, it would have been documented. Of course, you could say the code "IS" the document.
-
Another alternative is groups.io
https://groups.io/g/nanovna-users
support by a seller who sell nanovna in aliexpress.
-
I signed up before it arrived. This is where the few people posted the list of commands and BAUD rate. I've been asking them a few questions as I go. So far things are pretty intuitive. I was a bit concerned when I saw them use the third harmonic for anything above 300MHz but the group claims it's normal. Bug wise, it's the only real problem I have seen so far beyond the cheap rocker switch. I would like to replace it with something better but the touchscreen handles most of it.
-
Made some progress. There's a 100pF capacitor attached.
-
I made an attempt to get the S21 working but ran into a snag sorting out channel 1. I took a step away from it for a few days and will have another look. A couple of paragraphs of detailed documentation would have gone a long way to help this project.
Most of the channel 0 measurements are now sorted out. The plan will be to have the graph change modes so the SWR will eventually be shown on the main graph in place of the Smith chart.
Shown for the most part with a bad SOLT using a 200ohm resistor.
-
Walking away for a while helped. Both channels are now sorted out. Next step is to add the remaining cursor readouts, finish up the graphs and add the ability to store some references.
Shown looking at a Showa crystal filter.
-
Are you going available? I am a bit unsatisfied with the VNA Sharp but lack the skills to write anything better myself.
73, KC3EKL Curtis
-
I havn't thought about it. The reason I started working on it is because the included software wouldn't work. The cursor readouts would be blank or flash. It just wasn't usable.
-
Short demo showing the current status of my LabView interface for the NanoVNA.
https://www.youtube.com/watch?v=DDvHN2v1gTg (https://www.youtube.com/watch?v=DDvHN2v1gTg)
-
The software is almost good enough. I finally added the return loss readout plus support for a couple of storage references and a few other features. It needs a few more features and I may restructure the communications before wrapping it up. It's getting close.
I plan to make some sort of video on the NanoVNA. Not so much a review but more of a demo showing the basics of how to use it. I don't plan to dive into all the math or make it too detailed at this point. If there is anything you want to see, feel free to ask. I doubt I will get to it until next weekend so there is plenty of time.
-
Any video would be interesting. Thinking about getting one of these myself. Does it require a LabVIEW licence to run your custom software¿
-
It would be an EXE just like any other program, no license required.
-
Great news
-
Ended up restructuring my software and now have a decent platform to build on. The original design was a single process where it now has three. Breaking up the code makes it a lot more flexible.
With the software now working, I'll start working on the video this weekend as planned. My goal is to make some sort of beginners guide on how to use it to make some practical measurements.
-
I'm kind of tempted to buy one just to see how it compares to my Keysight VNA's. It is much more tempting if there will be good software to use with it.
-
I'm kind of tempted to buy one just to see how it compares to my Keysight VNA's. It is much more tempting if there will be good software to use with it.
What don't you like about the included software?
-
Just curious can the graph show one by one.
-
Just curious can the graph show one by one.
What do you mean by showing one by one? Are you asking about my software, or what's included with the VNA?
-
Just curious can the graph show one by one.
What do you mean by showing one by one? Are you asking about my software, or what's included with the VNA?
yes its about Your software.
can we choose to show one big graph like only the smith chart alone ?
-
Just curious can the graph show one by one.
What do you mean by showing one by one? Are you asking about my software, or what's included with the VNA?
yes its about Your software.
can we choose to show one big graph like only the smith chart alone ?
I am still not sure what you are asking. If you watched the above video, you can see how it cycles through the different retangular, Smith and polar plots. If you want to know if I support displaying retangular and Smith chart on a single graph, then the answer is I do not. I just don't have a need for it. If you are asking if I can make the Smith chart take up the full screen with nothing else displayed, currently the graphs size and location are fixed. The three plots on the right will be moved to a separate page or I may remove them all together.
-
What don't you like about the included software?
I've just bought one to have a bit of a tinker. The s/w I have is OKish, probably the only gripe I have is the Smith chart is a bit fuzzy. It's just a grey-on-white bitmap and the resolution's not that great.
Yours is looking pretty neat Joe :-+
-
Nali, I am curious now that you have yours working, when you look at the Smith chart, as you have it shown, do the cursor readouts work? Do they go blank, flash? Can you even use them?
If they work correctly, what OS are you using? Version? Service packs? Video card?
If that one feature worked, I wouldn't have gone down this path.
-
Yes they do work, they come up as a floating "hint box". They do flash, it looks like if the cursor moves just by a pixel then the whole box is redrawn. E.g. the screen shot snippet is from a 10MHz sweep centered on 433MHz, with a rubber duckie whip directly on port 0.
This is on W10 x64 build 1903 with AMD Radeon HD-7700 & I7-4770K CPU. If it helps, the exe file is timestamped 26/4/2019 (sorry 04/26/2019 to you!) 04:14 AM and 154624 BYTES
EDIT: I think this is the link to the software download as far as I remember (I normally download things like this in incognito to avoid cookies so it's not in my browser history)
http://myosuploads3.banggood.com/products/20190527/20190527043616NanoVNA.rar (http://myosuploads3.banggood.com/products/20190527/20190527043616NanoVNA.rar)
HTH :)
-
I looked at the date but I think it's when it was download and unpacked. There isn't a version in the About page as you would normally find in a released program.
With mine, I can't get the box to stop flashing. Sometimes the thing will just go blank. It's impossible to read the values being displayed. I plan to show it as part of my demo.
-
I downloaded the one from your link and unpacked it. It has a different size than the one I tried to use. Your's does appear to be older, but may actually work. I'll give it a try and let you know.
Thanks for checking.
****
Upper left corner, v1.01 vs 1.03. The new one has an about page, where yours doesn't. I didn't spend much time looking at it. As soon as I saw the cursors did not work, I set it aside and started working on my own.
-
I don't want to pretend to have more than a minimum knowledge about high frequency design but in some group about the EU1KY analyzer (aka Mini600/Mini1300), it was discussed that the resistive bridge of the nanoVNA would limit its ability to measure Z > 1000Ohm and result in unstable measurements around 50Ohm while the bridge with a Balun in the EU1KY would allow much better accuracy in the 0..2000Ohm range.
So while I appreciate the effort put into an optimized PC program, I wonder if this is really worth it if the measurements are not very precise anyway`
-
I don't want to pretend to have more than a minimum knowledge about high frequency design but in some group about the EU1KY analyzer (aka Mini600/Mini1300), it was discussed that the resistive bridge of the nanoVNA would limit its ability to measure Z > 1000Ohm and result in unstable measurements around 50Ohm while the bridge with a Balun in the EU1KY would allow much better accuracy in the 0..2000Ohm range.
So while I appreciate the effort put into an optimized PC program, I wonder if this is really worth it if the measurements are not very precise anyway`
You don't need to be too concerned with how I spend my personal time. That said, I am very sensitive to how much time I am willing to put into this project as I have no plan of actually using it. As you can see, I have not been working on it for months. It's only been a few days. This is the main reason I use LabView.
-
Just curious can the graph show one by one.
What do you mean by showing one by one? Are you asking about my software, or what's included with the VNA?
yes its about Your software.
can we choose to show one big graph like only the smith chart alone ?
I am still not sure what you are asking. If you watched the above video, you can see how it cycles through the different retangular, Smith and polar plots. If you want to know if I support displaying retangular and Smith chart on a single graph, then the answer is I do not. I just don't have a need for it. If you are asking if I can make the Smith chart take up the full screen with nothing else displayed, currently the graphs size and location are fixed. The three plots on the right will be moved to a separate page or I may remove them all together.
Sorry if my Java-English made You confuse, The Nali screenshot is exactly what I mean
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=800451 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=800451))
some times only display one graph a time can help if You using a small screen like in laptop but if You dont need or like, its no problem I can live with it.
btw the real designer of nanoVNA made some update in the github I know nothing about what its done maybe You can take a look
https://github.com/flyoob/NanoVNA-F (https://github.com/flyoob/NanoVNA-F)
-
Just curious can the graph show one by one.
What do you mean by showing one by one? Are you asking about my software, or what's included with the VNA?
yes its about Your software.
can we choose to show one big graph like only the smith chart alone ?
I am still not sure what you are asking. If you watched the above video, you can see how it cycles through the different retangular, Smith and polar plots. If you want to know if I support displaying retangular and Smith chart on a single graph, then the answer is I do not. I just don't have a need for it. If you are asking if I can make the Smith chart take up the full screen with nothing else displayed, currently the graphs size and location are fixed. The three plots on the right will be moved to a separate page or I may remove them all together.
Sorry if my Java-English made You confuse, The Nali screenshot is exactly what I mean
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=800451 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=800451))
some times only display one graph a time can help if You using a small screen like in laptop but if You dont need or like, its no problem I can live with it.
btw the real designer of nanoVNA made some update in the github I know nothing about what its done maybe You can take a look
https://github.com/flyoob/NanoVNA-F (https://github.com/flyoob/NanoVNA-F)
Oh, you were wondering if it would fit on a small screen or not. I havn't been paying attention to the size of the graphics and if it would run on my 8" tablet or not. My guess is it's close the way it is now.
-
I tried the older version of the software and have the same effect. Without moving the cursor, the impedance will flash quickly making it next to impossible to use. I will show both versions in the demo video.
-
I tried both versions of software on my Laptop. Windows 7 64-bit i7 gen 1 vs 10 64-bit xeon e5-1650 on the desktop. Both nvidia controllers. Old laptop flickers badly but I can see the readout. Beware of epilepsy seizures. :-DD Like the desktop, it flickers if data collection is turned off and the mouse is stable.
-
Sorry to post but did you tried to change Windows version compatibility for another version eg windows xp?
-
The NanoVNA.
https://www.youtube.com/watch?v=mKi6s3WvBAM (https://www.youtube.com/watch?v=mKi6s3WvBAM)
-
Measuring antenna resonance and SWR
https://www.youtube.com/watch?v=_drx7ORUDWI (https://www.youtube.com/watch?v=_drx7ORUDWI)
-
Requested plots show fundamental and harmonics at 1MHz and 350MHz CW. Note above 300MHz, uses 3rd harmonic.
-
joeqsmith, there are at least 3 versions of nanoVNA with different pcb layout on aliexpress:
https://github.com/hugen79/nanovna_900
Which one you're using exactly?
-
Thanks for pointing that out. I noticed black vs. white, but didn't realize that there were two different black ones. The "bad" one doesn't appear to have any shielding in the listing photos.
-
Just to get this thread on my list...
Got me a NanoVNA, too. Have not really used it, yet, as I need to better understand what it actually does. So far I know it measures resistance and capacitance of A/C over frequency --> Impedance.
I am interested in writing my own software in VB .net, as I already did for the SMA/NWT Spectrum analyser developed by BG7TBL.
Is there any document to start with, explaining the serial communication protocol?
Questions to joeqsmith:
- What version of LabView are you using?
- Is the HOME version worth the purchase (discussed in a different thread on this forum - a HOME version for personal use at 49 US$)?
- Does it come with all required components/toolboxes?
- Are you allowed to distribute the compiled version done with HOME version for free? Or would that be against "personal use"?
- How big is the time saving in doing your software in LabView as opposed to .net (C# or VB)?[/li][/list]
Regards,
Vitor
-
joeqsmith, there are at least 3 versions of nanoVNA with different pcb layout on aliexpress:
https://github.com/hugen79/nanovna_900
Which one you're using exactly?
Exactly the one that is sitting on my desk now. I doubt there is another exactly like it. Mine has my fingerprints on it which I am pretty sure make it even more unique.
For a more general idea, I did post 2 videos showing it, one with it apart. Beyond providing this level of detail, I can't be of much help.
-
Just to get this thread on my list...
Got me a NanoVNA, too. Have not really used it, yet, as I need to better understand what it actually does. So far I know it measures resistance and capacitance of A/C over frequency --> Impedance.
I am interested in writing my own software in VB .net, as I already did for the SMA/NWT Spectrum analyser developed by BG7TBL.
Is there any document to start with, explaining the serial communication protocol?
Not that I am aware of. I did search and ask the group prior to starting.
Questions to joeqsmith:
- What version of LabView are you using?
For home, I have a Pro license for 2011, along with the 2014 Home license.
- Is the HOME version worth the purchase (discussed in a different thread on this forum - a HOME version for personal use at 49 US$)?
You may as well ask me about houses, cars and handheld DMMs. There is no way I would know if the Home is worth the purchase for you personally. Obviously I felt it was worth it for me or I wouldn't have purchased it.
- Does it come with all required components/toolboxes?
You may have asked me if you car requires four doors or two. Again, I don't know what your requirements would be. But as I stated in the other thread you mention, you can run free one week trials on the tools to determine if they fit your needs or not. And again, they will extend these times. If your question is if I can run the code I developed for the Nano with the Home edition as supplied, then the answer yes.
- Are you allowed to distribute the compiled version done with HOME version for free? Or would that be against "personal use"?
http://sine.ni.com/nips/cds/view/p/lang/en/nid/213095 (http://sine.ni.com/nips/cds/view/p/lang/en/nid/213095)
You may share your work only for noncommercial, nonindustrial, and nonacademic purposes.
- How big is the time saving in doing your software in LabView as opposed to .net (C# or VB)?[/li][/list]
I had someone post about it being a pity that I did it in LabView rather than Python. When I first looked at the supplied software, I knew it couldn't be used for the demo which is why I decided to roll my own. I didn't waste a lot of time complaining about the problems but rather posted I was going to write my own in LabView, then proceeded to write it in LabView, then made a couple of videos showing the LabView code running it. All in the course of about a week. This included the time reversing the protocol.
Obviously, I am not doing anything to hinder this poster from showing us some Python code or posting about how long they took to develop it. You could certainly could show us another language and post your development time as well. Beyond some experts like yourself actually doing something like this, I can't really offer you any data on a time saving metric. I did however post how I exclusively use LabView for PC software development because of the time it has saved me.
-
I thought about adding Touchstone support and putting together some sort of demo using LTSPICE. Some time ago there was a conversation about SPICE and I had asked about LTSPICE supporting a blackbox model. It appears that this feature never was implemented.
https://www.eevblog.com/forum/projects/what-can-pspice-better-than-ltspice/msg928319/#msg928319 (https://www.eevblog.com/forum/projects/what-can-pspice-better-than-ltspice/msg928319/#msg928319)
I had looked at another simulator that had hopes of supporting S-parameters but they went under. It appears Orcad still owns PSPICE. Maybe the student version would handle it. I'll look into it.
-
QucsStudio supports touchstone files and can plot smith charts etc. Very easy to use
-
Nice find. Thanks. The current price of PSPICE is $6400USD and the student version wouldn't support it. I'll have a look at this simulator. If it looks like I can sort out some sort of demo, I'll go ahead and add Touchstone support.
Thanks again.
-
joeqsmith, there are at least 3 versions of nanoVNA with different pcb layout on aliexpress:
https://github.com/hugen79/nanovna_900 (https://github.com/hugen79/nanovna_900)
Which one you're using exactly?
Exactly the one that is sitting on my desk now. I doubt there is another exactly like it. Mine has my fingerprints on it which I am pretty sure make it even more unique.
For a more general idea, I did post 2 videos showing it, one with it apart. Beyond providing this level of detail, I can't be of much help.
Based on the current title image of this video, he has the good one:
https://www.youtube.com/watch?v=mKi6s3WvBAM (https://www.youtube.com/watch?v=mKi6s3WvBAM)
-
The current price of PSPICE is $6400USD and the student version wouldn't support i. I'll have a look at this simulator. If it looks like I can sort out some sort of demo, I'll go ahead and add Touchstone support.
Thanks again.
Another option is the Microcap software which recently has become free:
https://www.eevblog.com/forum/projects/microcap-12-is-free-(as-in-beer)-now/ (https://www.eevblog.com/forum/projects/microcap-12-is-free-(as-in-beer)-now/)
-
@joeqsmith: Thanks for your extensive reply - much appreciated.
Kind regards,
Vitor
-
How can you tell which the good ones are?
-
I don't know, but I can tell you this:
I ordered the CHEAPEST one i found on eBay (https://www.ebay.de/itm/Nanovna-50KHz-900MHz-Vector-Network-Analyzer-UHF-HF-VNA-UV-VHF-Antenna-Analyzer/133112732589 (https://www.ebay.de/itm/Nanovna-50KHz-900MHz-Vector-Network-Analyzer-UHF-HF-VNA-UV-VHF-Antenna-Analyzer/133112732589)) and it looks like a mixture of both the black pictures: the PCB and shields look like the "best" one, while the lettering on the case is more similar (but not the same) as the "worst" one.
Note that I mean cheapest, but complete: with the "calibration kit" - which consists on three SMA caps: open, closed and 50 ohm, as whell as two pairs of SMA cables and a male-male SMA connector.
The device came in a nice plastic case, which I did not actually expect.
I think that it is just a case of someone having posted these pictures without a real explanation on what/why one devices are supposed to be better than others. The pictures are rubbish and the only visible difference is the "NanoVNA" print next to the screen, which is bolder on the "good" device and thinner on the "worst" device. I call it rubbish.
From what I have read before ordering mine is that the white ones may come without the battery and older black ones had less/no shielding inside. Also, you might be buying just the device without accessories, so make sure you get them, too.
Regards,
Vitor
-
The only way to know for sure is to buy it only from the originator's store, which is on Taobao. Buying from unauthorized resellers always carries some risk. You can't be sure that the photos match what they're selling on any given day or if they even understand what they're selling in order to answer your question about which one they have in stock.
The one Bicurico bought is the good one. The font matches the one on the author's github page and you can see the shielding in the pic taken of the front edge. Of course, since any reseller can "borrow" photos, it's not a guarantee that you'll get that, but those are the characteristics to look for.
-
I think that it is just a case of someone having posted these pictures without a real explanation on what/why one devices are supposed to be better than others. The pictures are rubbish and the only visible difference is the "NanoVNA" print next to the screen, which is bolder on the "good" device and thinner on the "worst" device. I call it rubbish.
The author could've done a better job of explaining what to look for in his comparison pics, but they're not rubbish. There are clear differences after you examine them and some eBay listings.
Glad to hear you got a good one. What does the case look like?
-
@joeqsmith: Thanks for your extensive reply - much appreciated.
Kind regards,
Vitor
Glad to help.
The current price of PSPICE is $6400USD and the student version wouldn't support i. I'll have a look at this simulator. If it looks like I can sort out some sort of demo, I'll go ahead and add Touchstone support.
Thanks again.
Another option is the Microcap software which recently has become free:
https://www.eevblog.com/forum/projects/microcap-12-is-free-(as-in-beer)-now/ (https://www.eevblog.com/forum/projects/microcap-12-is-free-(as-in-beer)-now/)
Thanks. I will have a look at it as well.
***
It does appear to support it as well. I would think between the two versions of SPICE, I should be able to get something working. Thanks again.
-
I tried installing both SPICE programs and started to play with them a bit. It looks very promising so I have added the ability to import a s1p file into my Nano software and want to verify the results.
Is anyone aware of any free tools used to process Touchstone files? I am basically just needing something like AppCAD but am looking for something that can plot inductance (and other) directly.
Plan is to take a component that I have a touchstone file for, import it and make some measurements. Then test the actual part and compare the results. Once that works, I will go ahead and add the ability to export. Then attempt to use the S-parameters from the Nano in SPICE.
All seems doable but not trusting my math skills.
-
Would any of this program suits your needs?
https://www.rfpage.com/free-tools-to-analyze-and-plot-s-parameters-file/ (https://www.rfpage.com/free-tools-to-analyze-and-plot-s-parameters-file/)
https://www.ag-rf-engineering.de/products/software/s-parameter-viewer/ (https://www.ag-rf-engineering.de/products/software/s-parameter-viewer/)
-
This part was produced by E F Johnson. Here you can see AppCAD showing the Touchstone file created using a slightly higher end VNA. Also shown is the same file imported with the Nano software. Cursors were set at 1.6MHz and 8.7MHz. Part was installed on my BK meter as a sanity check. The part attached to the Nano, sweeping from 1 to 10MHz and cursors were set at roughly the same location.
Obviously, the Nano is never going to replace a higher end VNA you would use in the lab. Still, at $50ish dollars, I am having a hard time finding a reason to bash it. If you wanted to learn about VNAs, I still think this is one of the best investments out there.
Odd, attachments didn't load....
-
And, just for fun comparing $20,000+++ with $???? (whats an 8754A worth today) and $50. Three VNAs, three answers, just like DMMs.
-
Exporting from the Nano and reading with AppCAD.
Time to read a few SPICE manuals.
-
I ended up installing the Micro-Cap simulator. Like the Nano, the cost was so low (free to download), it's going to be hard to find any fault with it.
I made up a simple circuit with the 1 port model. I then imported a Touchstone file from the Nano fully expecting it to crash, started the simulation. It actually converged!!
It's way too early to say if it can spit out any useful data but the fact it's doing anything at all is impressive. I'm keeping my expectations low.
-
Just for a simple easy sanity check, I swept a 50 ohm resistor from 50K to 900MHz and stored that into a Touchstone file. I then imported that into AppCad. No problem. Then I imported that same file into MicroCap and using a source with 50 ohms output impedance, ran a sweep up to 900MHz and plotted the loss. Looks like -6dB to me.
I would say we have some meaningful data for S11. The next step is to get S21 working, then add a transfer relay to the Nano. Oh wait, the relay would cost 10X more than the Nano. :-DD
****
I have attached the Touchstone file which would be renamed before using. The MicroCap software is smart enough to identify touchstone files but it does not automatically calculate the number of data points.
-
Joe,
any plans to release the LabVIEW interface?
-
Joe,
any plans to release the LabVIEW interface?
While a few people have now asked, I have no plans to release it at this time. The problem is lack of time to support the few people that would actually try it. It's really what I would call an engineering tool, not what I would consider an end product.
So while I appreciate the effort put into an optimized PC program, I wonder if this is really worth it if the measurements are not very precise anyway`
Oxdeadbeef seems very much aware of the problem. While it's not their time, I appreciate their comment. It's a great little unit for the beginner IMO, but just how much time do I want to invest in it. Someone wrote me about creating something in Python and it not being much more effort. Another wanted something for LINUX. I wouldn't be at all surprised if we don't start seeing different software for it.
I still plan to make one last video for the Nano and will show the latest software for it.
-
Micro Cap SPICE simulation with the NanoVNA
https://www.youtube.com/watch?v=v01lSgWo904 (https://www.youtube.com/watch?v=v01lSgWo904)
-
For software programmers a flowchart of you current release SW and maybe serial data protocol could get them on the road for a multi-platform GUI written on python, java, etc ... By the way the mug looks nice, but is it filled?
-
I don't understand why there are so many separate community efforts to develop VNA GUI software but none are open source, leading to fragmentation and duplication of efforts. If you are serious about this project please just post it on GitHub. There doesn't seem to be much software skill on this forum and putting the code out there gives real software developers a chance to look at it and possibly develop it further, possibly developing into a generic VNA GUI that can easily support new devices. There is nothing to be gained by keeping the source closed, it will just render your project obsolete as soon as you stop working on it. To me releasing a .exe is the same as not releasing anything at all.
-
Joe has built this for himself alone. He doesn't want or need it to be a solution for anyone else.
Besides, i doubt there are many developers that would want to jump in on a project based on LabVIEW.
I would love to see a good Open source GUI though. There is no reason it could not support multiple VNAs including the big expensive Keysight and R&S units via scpi. Maybe then they would stop charging an arm and a leg for simple features like TDR(it's just an IFFT ffs).
-
I must say I can understand joeqsmith choice. There is indeed always the expectation when somebody has gone through the “trouble” of compiling/installing your software and it doesn’t work, the developer chimes in to provide some support. And this can cost quite a bit of the spare free time we all have to play around. For successful apps with wide community support this gets somewhat better, but a software package like this is unlikely to get this status. Also, like many of us we are interested in a certain topic only for a certain period, and then we move on to the next interesting subject. When making software available it is more difficult to leave the topic because there is the expectation to fix bugs and continue development.
Also, as stated correctly above, this is not a programming forum, so this means not so many people will go to the trouble to actually read the source code, most will just run the exe and hope it will work, and ask question on the forum if it doesn’t, especially for a low cost device like this.
I find some of the above comments sounding like joeqsmith is doing us a disfavour, by not posting his software online, while off course the opposite is true, by making the informative videos and comparisons with a real VNA and also showing what is possible with some additional effort.
-
this is his right to not publish his source code. Some bad people may use his published source code, remove copyright and claim it like this is their own development. They can insult him and trolling just for fun. Some of them may use it in their commercial projects. And the author will loss interest for this project, will stop development and abandon it. And the project will die. I catch similar issues on several popular projects which I published as open source in the past. These things may happens when your project may affect some other commercial projects. Since you publish it for free these guys who make money on the similar projects will start to fight against you. So, now I don't publish source code of my projects which is interested for me for further development. I can publish some parts which is not interested for me anymore, but not these which I'm still working on.
Just think - he may not publish it at all. I have several projects which I never published and I know many people will be interested in it. But I will not publish even binaries of it, due to different reasons. So, if he decided to share just a binary, just say thanks to him. This is his work and he can decide what part of his work to share or not to share. This is better than nothing at all :)
I think joeqsmith doing good job, he sharing his experience and knowledge with other users, he even shared his tool. If you want source code to make something similar, then just make your own. No needs to blame someone for not sharing something that you're needs. There may be reason for this.
-
I don't understand why there are so many separate community efforts to develop VNA GUI software but none are open source, leading to fragmentation and duplication of efforts. If you are serious about this project please just post it on GitHub. There doesn't seem to be much software skill on this forum and putting the code out there gives real software developers a chance to look at it and possibly develop it further, possibly developing into a generic VNA GUI that can easily support new devices.
If there really are separate efforts as you suggest, I would suspect it has to do with the various communities having different objectives. Some want LINUX support, some want Python, some C#, some VB, some want it running on Apple products. My goal was just to put some sort of demo together to help show how to use the Nano.
I reversed the protocol and put together the main program in a couple of days. Reading about Touchstone, installing and leaning a little about Micro-Cap added a few days. Actually changing the code to support Touchstone and adding the state machine to perform the narrow sweep was a few hours. It's hardly what I would consider a major effort compared with some of my other home projects.
I will be the first to admit that I am not a "real software developer". I suspect these experts you mention would have it done in half the time with twice the features. I'm certainly not impeding anyone's efforts and if anything, have offered a few details about my software.
There is nothing to be gained by keeping the source closed, it will just render your project obsolete as soon as you stop working on it.
I would say the opposite is true in that I have nothing to gain by releasing it. Maybe you think the fame and recognition of having a few people use it is important to me. It's not. The gain in not releasing it is the time I don't spend supporting it.
To me releasing a .exe is the same as not releasing anything at all.
I doubt I would have made this last demo had Micro Cap not released their simulator. I could care less if they released the source or not.
I suggest you personally step up and show the community how it's done. Lead by example.
-
That narrow-band sampling feature was very cool, Joe. Thanks for adding it to your demo. Even though it takes time to run, it certainly adds to the potential value of the NanoVNA platform. Hopefully the Nano developer can enhance the included software like that, too.
-
That narrow-band sampling feature was very cool, Joe. Thanks for adding it to your demo. Even though it takes time to run, it certainly adds to the potential value of the NanoVNA platform. Hopefully the Nano developer can enhance the included software like that, too.
I couldn't come up with an better solution. The latest software has a quasi log sweep where it takes the start, stop and samples per decade, then calculates a series of start and stop segments. The Nano still performs a linear sweep over each segment but the overall effect is a log.
Without the transfer relay, and me being far too lazy to flip the part, I just fudged S12 and S22 to get the Touchstone working. Shown is a 500MHz lowpass being swept on the Nano. The Touchstone is then read by AppCad. They don't seem to have a dual vertical axis option and I couldn't seem to get it to plot in a linear format but it's obviously working. Also shown is the 2-port file imported to Micro-Cap and running an AC analysis.
So, it seems the basics all work.
I may have some old, low frequency RF transistors floating around. I could try and find the manufactures S-parameters for them and see if I could come up with the similar numbers with the Nano. Build and amp and try to simulate that. A bit more complex but something a little more real world.
-
Joe
Just discovered your work here....very nice! Maybe this question has been asked and answered: Are you going to release it into the wild so others can use it?
Keep up the great work!
Joe
W3JDR
-
Joe
Just discovered your work here....very nice! Maybe this question has been asked and answered: Are you going to release it into the wild so others can use it?
Keep up the great work!
Joe
W3JDR
Yes, it's been answered. Maybe read the last 10 posts or watch the last video.
-
Anyone know if/where the NanoVNA communications interface protocol is documented?
Joe
W3JDR
-
Anyone know if/where the NanoVNA communications interface protocol is documented?
Joe
W3JDR
Maybe read the first 5 posts.
-
Thanks for the reply.
Yes, I've seen all of those but none offer a direct or conclusive solution. I'm looking for something that describes the message structure in both directions so I can try to roll my own application, probably in VB.
Joe
W3JDR
-
Then you know that I have asked and was unable to locate such a document. Assuming you took the time to watch that first video where I described what I saw with the BAUD rate and protocol, and you looked at the document containing the list of commands, you should be all set. Is there something specific you are not understanding?
If you havn't tried communicating with it, I suggest you just open a dumb terminal and send it the "info" command and see if that works. Once you have that working, replicate it in what ever language and build from there.
-
Something is really wrong in the attached picture....
-
This list of commands can be sent from a serial terminal program set for 9600 baud and the results will be displayed. Courtesy of the Google Groups site:
NanoVNA Console Commands:
=========================
help – prints most of the following commands (below) – some are not enabled but appear in the source code
exit – exits and then restarts console mode and prints command prompt
info – prints firmware info:
Kernel: 4.0.0
Compiler: GCC 5.4.1 20160919
Architecture: ARMv6-M
Core Variant: Cortex-M0
Port Info: Preemption through NMI
Platform: STM32F072xB Entry Level Medium Density devices
Board: NanoVNA
Build time: May 5 2019 - 08:54:38
echo - Usage: echo "message"
systime – outputs binary time from 1/1/1980: eg: 81225068
threads
reset - Performing reset
freq - frequency(Hz)}
offset - frequency offset(Hz)}
time – get the time in: timespec.year+1980, timespec.month, timespec.day, timespec.millisecond
dac - usage: dac {value(0-4095)}
saveconfig - saves current configuration - and prints "Config saved".
not sure what in total it saves - need to go through source code.
clearconfig - usage: clearconfig {protection key}
where key is predefined as “1234”
and wrong input gives: “Key unmatched” error.
Correct key gives: “Config and all cal data cleared”
data - usage: data [array]
dump - (if enabled) outputs dump buffer
gamma – Prints gamma[0]& gamma[1]
frequencies – prints a long list of all the sweep points from start to stop
port – Sets port of DSP tlv320aic3204
usage: port {0:TX 1:RX}
stat – outputs processor status:
average: -138 -137
rms: 3597 8
callback count: 9126700
awd: 27
gain – sets gain of DSP tlv320aic3204
usage: gain {lgain(0-95)} [rgain(0-95)]
power - usage: power {0-3}
sweep - usage: sweep {start(Hz)} [stop] [points]
if no inputs: then prints current setup eg:300000000 500000000 101
otherwise, can force new sweep settings using the following commands:
start
stop
center
span
cw
set – sets sweep points
start
stop
test – unknown how to use – appears to set freq span from 10MHz to 90MHz and involves one of the LEDs and touchscreen input
touchcal – produces calibration touch points in the upper left and lower right corners
outputs: "first touch upper left, then lower right...")
"done”
"touch cal params: A B C D (upper left and lower right x-y co-ords)
touchtest – test touch accuracy – touch, hold and drag pointer
pause – pause LCD display output
resume – resume LCD display output
cal - usage: cal [load|open|short|thru|isoln|done|reset|on|off|in]
save - save {id} where ‘id’ is from 0 to 4
recall - recall {id} where ‘id’ is from 0 to 4
trace – prints status of either 2 or 4 traces depending on F/W version used:
0 SWR CH0 1.000000000 0.000000000
1 LOGMAG CH1 1.000000000 7.000000000
2 SMITH CH0 1.000000000 0.000000000
3 PHASE CH1 1.000000000 4.000000000
marker – Usage: marker [n] [off|{index}]
edelay – electrical delay in picoseconds
-
"This list of commands can be sent from a serial terminal program set for 9600 baud and the results will be displayed. "
:-DD
-
Why do you find this amusing?
-
Why do you find this amusing?
Then you know that I have asked and was unable to locate such a document. Assuming you took the time to watch that first video where I described what I saw with the BAUD rate and protocol, and you looked at the document containing the list of commands, you should be all set.
-
Huh??.
I asked you directly if you had a protocol document. The answer I got seemed snippy, snooty and indirect, but I dismissed it and found what I was looking for elsewhere. I thought others might find it useful, so I posted it here. Mea culpa for my ignorance. I won't trouble you any further.
-
Huh??.
I asked you directly if you had a protocol document. The answer I got seemed snippy, snooty and indirect, but I dismissed it and found what I was looking for elsewhere. I thought others might find it useful, so I posted it here. Mea culpa for my ignorance. I won't trouble you any further.
I thought my response was direct. To make it more clear, I have no such document. Again, I had asked and wasn't able to find such a document. The only document I found was the list of commands, which you have included.
The BAUD rate in the document you posted needs more explication. I explained I had created a video which covered what I had found in case others wanted to create their own software. In case of the BAUD rate, for this application it serves no purpose. If it did, 9600 would not come close to matching the performance required.
Based on your frustration, I assume these answers were not what you were looking for. Sorry, I can't help with that.
-
I found that adjusting the baud rate in the terminal program had no affect. Being a CDC USB connection, it goes as fast as it can. Anyway, I hope the list allows others here to jump-start their efforts. I tested every one of the commands and they work as descibed, so no reverse engineering required. So everyone, the race is on! Get those apps going.
BTW, some nice additional features in a new app would be a signal generator mode and a power meter mode.
-
I found that adjusting the baud rate in the terminal program had no affect. Being a CDC USB connection, it goes as fast as it can.
Pretty much verbatim of what I had stated in the video. Good to see you are on your way.
-
Other wish-list features would be capacitor/inductor measurement at a user--specified spot frequency with digital readout including ESR/EPR resistance values
I found that adjusting the baud rate in the terminal program had no affect. Being a CDC USB connection, it goes as fast as it can. Anyway, I hope the list allows others here to jump-start their efforts. I tested every one of the commands and they work as descibed, so no reverse engineering required. So everyone, the race is on! Get those apps going.
BTW, some nice additional features in a new app would be a signal generator mode and a power meter mode.
.
-
Looks like this person tried connecting a transfer relay. This is pretty much where I am heading with the 2-port Touchstone. The problem I see with their setup is they do not perform a full calibration which could be part of the errors they show. It seems like they could use the basic cal, then flip the cables, or run two cals and select between the two when switching the transfer relay.
In my previous picture, you can see the Nano is running without a calibration. I have a short attached and my software is showing a short. At this stage, I had pushed the SOL down into my software. I just finished up with the full SOLT that will handle all four S-parameters. The software could tell the Nano to switch between cals as it can store more than one, but putting it in the software means that there is no delay when switching.
https://www.youtube.com/watch?v=HYlQHwDb9fA (https://www.youtube.com/watch?v=HYlQHwDb9fA)
Looking at Pasternack, you get some idea on the cost. I have an old relay similar to what this person shows in their video, but it would be nice to use something lower cost and readily available. It may be cheaper to buy DPDT RF relay common to scopes and such and layout a board for it.
https://www.pasternack.com/medium-power-transfer-electromechanical-relay-switches-category.aspx (https://www.pasternack.com/medium-power-transfer-electromechanical-relay-switches-category.aspx)
-
Joe
Can you explain the return data pairs in the data array? Eg, if you send "data 1" you get a 2-wide array that corresponds row-by-row with the "frequencies" array. What does each value in a pair represent? It seems that the first value is the raw magnitude of S21 before the 20log scaling is applied. I thought the second value might be the phase of S21, but I'm having a difficult time understanding the scaling.
-
It's good that I found this thread.
Hopefully the developers will fix their SW. After all that's their product/job.
joeqsmith
Running Windows SW using Linux is OK for most of the time, the key is Wine. There can be still issues with Linux like printing and proprietary drivers (e.g. related to HW like WiFi) but that's typically not a show stopper for an app.
It's a pity that you've decided not to release your SW, as in my view the difficulty is not developing communication towards the equipment or GUI but knowing the use cases and making sensible user interface for that. That's a lot more than to be able to interpret Smith chart and only few people can do that, typically not those who are good at SW development.
I also acknowledge that it's a real risk that someone does the real work and other people make profit out of it so your decision is understandable. Probably even GPL helps little in this.
-
edigi
I agree with JoeQ that releasing his source might be of little value to us except to illustrate how it could be done, though that in itself might have value to others. One of the problems I see is that he developed in a proprietary rapid development environment (I think LabView) that is closed and expensive. To develop with a team requires a license that costs thousands for each developer, so getting his code would have only academic use for most of us. Nonetheless, I don't see this as a difficult project if you have the right toolkit. I've done several similar applications and I think something functional could be knocked out in days if you work in a more general and open rapid development environment. I'm thinking vb.net. There are only 2 things preventing me from diving into this: 1) I'd like not to have to re-invent the Smith Chart GUI and, 2) I already have too many other unfinished projects and little spare time.
JoeR
-
Joe
Can you explain the return data pairs in the data array? Eg, if you send "data 1" you get a 2-wide array that corresponds row-by-row with the "frequencies" array. What does each value in a pair represent? It seems that the first value is the raw magnitude of S21 before the 20log scaling is applied. I thought the second value might be the phase of S21, but I'm having a difficult time understanding the scaling.
Yes, I obviously could explain the data format. There's an old saying, "You can lead a horse to water but you can not make it drink" or as I like to say, "You can lead a whore to culture but you can not make her think". Today you can walk someone to the edge of the water, and they not only refuse to drink but take offense to it. The few that drink jump up and down yelling, "look at me, I discovered the ocean!" :-DD
I will say that I've had to blow out a few cobwebs while working the equations for the Nano but it's been a lot of fun.
With that link I provided to the home edition of LabView including the application builder being offered for $50, I am seeing even less of a reason to ever use another language to develop Windows apps.
Good luck with your project.
-
It's good that I found this thread.
Hopefully the developers will fix their SW. After all that's their product/job.
joeqsmith
Running Windows SW using Linux is OK for most of the time, the key is Wine. There can be still issues with Linux like printing and proprietary drivers (e.g. related to HW like WiFi) but that's typically not a show stopper for an app.
It's a pity that you've decided not to release your SW, as in my view the difficulty is not developing communication towards the equipment or GUI but knowing the use cases and making sensible user interface for that. That's a lot more than to be able to interpret Smith chart and only few people can do that, typically not those who are good at SW development.
I also acknowledge that it's a real risk that someone does the real work and other people make profit out of it so your decision is understandable. Probably even GPL helps little in this.
At this time, I am not too concerned with the financial aspect of it. For me, it's just a hobby. It does appear though that the person driving the sales and development is not the original designer. They have a store setup and I assume are profiting from the creators work.
I too would really like to see the developers continue to improve the software they supply. They are certainly free to copy any of the ideas I have thrown out to the public and profit from them. I would actually be happy if the did as their users would benefit.
-
It appears Mini-Circuits offers a few transfer relays. The cost is still about 6X higher than the Nano.
https://www.minicircuits.com/WebStore/Switches.html (https://www.minicircuits.com/WebStore/Switches.html)
It appears that the unit I have matches the schematic in the manual from Hugen79. P2 allows access to VDD, ground and the JTAG signals. I havn't looked into yet but it seems like the JTAG could be used for general purpose I/O once the part is configured. Adding the ability to use these pins for a simple SPI port or even just two simple on/off controls, under software control may make adding peripherals to Nano more integrated.
I would like to make a small PCB with a transfer relay and a couple of bias T's on it along with a place holder for a fixed attenuator. Babbling and havn't thought it through. First step is to sort out if the firmware for the Nano is available an see if using these pins is even an option without having to involve the current designers.
Part of yesterday's efforts, showing the 10dB attenuator using my software's SOLT routines and shutting off the Nano's calibration.
-
If your making your own board there are plenty of RF relays available.
E.g
https://www.mouser.co.uk/ProductDetail/Omron-Electronics/G6ZK-1FE-DC3?qs=sGAEpiMZZMt%2FATQILEa77R5xBUwBD43UVicKLmkegz0%3D (https://www.mouser.co.uk/ProductDetail/Omron-Electronics/G6ZK-1FE-DC3?qs=sGAEpiMZZMt%2FATQILEa77R5xBUwBD43UVicKLmkegz0%3D)
-
If your making your own board there are plenty of RF relays available.
E.g
https://www.mouser.co.uk/ProductDetail/Omron-Electronics/G6ZK-1FE-DC3?qs=sGAEpiMZZMt%2FATQILEa77R5xBUwBD43UVicKLmkegz0%3D (https://www.mouser.co.uk/ProductDetail/Omron-Electronics/G6ZK-1FE-DC3?qs=sGAEpiMZZMt%2FATQILEa77R5xBUwBD43UVicKLmkegz0%3D)
I would like to see some sort of breakout board about this size with the bias T's and attenuator build up area. A small cable to connect it to the Nano. It would be nice to machine up a metal case that would hold the whole assembly including the nano. Bolt the SMA bulkheads right to the metal case. Maybe some of MACOMs GaAs switches.
Then again..... it's a $50 unit.
-
Does this mean that you will or that you won't help me by explaining the data array values?
-
Does this mean that you will or that you won't help me by explaining the data array values?
It means I obviously could explain the data format but I see no reason to add to your frustration of having to deal with me. You also made it clear when you wrote "I won't trouble you any further." that you really don't need my help anyway. So again, good luck with your math project. Looking forward to seeing what you come up with.
-
Wow! What a great guy.
-
Wow! What a great guy.
At least you have figured out that I'm not here to wipe your nose and give you a participation trophy.
-
Somebody get a hose (https://wiki.lesswrong.com/wiki/Crocker%27s_rules).... ::)
-
Somebody get a hose (https://wiki.lesswrong.com/wiki/Crocker%27s_rules).... ::)
There is a fair bit of math involved in understanding a VNA. Without a higher level education you may have a steep learning curve. Then again, they did provide the source code which would perform all the basic calculations so it would seem like even someone with no background in math but decent code skills should be able to get the job done.
So, maybe an education would be more valuable than your recommended hose.
-
Prototype of the GaAs transfer relay with bias Ts for the Nano.
-
Pictures showing the back and side of the prototype. I spent some time comparing the two schematics and looking for the source for current firmware. I don't think it would be too difficult to control the relay from the nano but without the source, I would need to create another fork from the original source. In the end, the problem I see is the slow communications rates which caused me to move the calibration to LabView. The new plan is to just use a second USB interface for the relay. Simple, fast switching and keeps the nano stock.
-
Hi,
Here is my quick update...
I have returned from the first part of my holidays, so I had this afternoon to sit at my shack and try the NanoVNA.
Coming from pure spectrum analysis, the VNA is totally new to me, so here is what I understood so far and I welcome any correction. I write this as if thinking out loud and to allow others to learn from the little insight I got so far. Again, please do correct me (hopefully in a friendly manner - this is just a hobby, I am not a RF engineer by education or trade).
1) The VNA can be used to tune antennas. The idea is that you want as little as possible of the outgoing wave to be reflected by the antenna - this causes the signal to travel back into the device. There are two problems with this: a) If the signal is reflected instead of being transmitted, it is not transmitted! This is kind of useless... b) The signal going back into the the device might actually break the device.
When measuring the antenna, we want to determine the minimum reflection of the wave at a given frequency. Any antenna is typically tuned for a specific frequency. The S11 logarithmic measurement will show a notch at this frequency. By making the antenna longer or shorter or whatever, you can increase the loss of signal return (=maximum transmission of the signal) - the notch will become greater. And, you can especially move the frequency of the notch. This is what is called antenna tuning.
2) Resistance and Capacitance at AC behave differently from DC: they vary with frequency and a capacitor actually acts as a resistor. Plus: it lets the AC flow through it!
By plotting the variation of the capacitance through frequency, we can analyse the behaviour of the DUT. One way to represent this is by means of a SMITH chart, which plots the data in a polar diagram, considering the complex number nature of capacitance/phase vs frequency. Sorry - at this point I am lost... What do you ACTUALLY measure? Why and what for?
3) S11 and S21: this is easy to explain: there are two ports on the NanoVNA: Port 1 and Port 2. When you only use port 1, you send out a signal on port 1 and then read the reflection of this signal back into port 1. So you measure 1-->1 = S11. S21 means that you generate a signal at port 2 and send it through a DUT. From the output of the DUT you read the signal in port 1: 2 --> 1 = S21. My guess is that S11 = measure antennas and/or signal reflection / SWR. S21 allows to measure how a DUT messes up a signal: phase (due to delay?), attenuation?
Regarding writing a custom PC software:
1) The NanoVNASharp software works without any problem for me, so I wonder why people are so motivated to write their own software? The reason I ask is to understand what OTHER measurements COULD be implemented. Also, what functionality is missing that would be required?
2) The connection to the NanoVNA, as already discussed, is fairly simple: just open Putty, configure the respective COM port and off you go. Type "help" and you can see all commands. Their output is quite self explanatory and the data (literally "data") can be easily copy&pasted to Excel for initial tests.
The data consists 101 samples made of the two components of a complex number, x and y, as usual with impedance measurement.
To represent the data in a polar chart (Freq/Vector):
Vector= 180/PI*Atan2(y, x)
To represent the data in a linear Freq/dB chart:
dB = Sqrt(x^2+y^2)
To represent the data in a logarithmic Freq/dB chart:
dB = 20*Log10(Sqrt(x^2+y^2))
I am not 100% sure this is correct, but first tests look good.
The "frequencies" command will output the frequency matching each of the 101 samples, which is nice, as you don't have to calculate them yourself (which would not be a big deal anyway).
I did not figure out what the "dump" command outputs.
Hope this helps and I am with joeqsmith: let's see what comes out! Again, I am at this point unsure on how to improve the NanoVNASharp software, so my personal desire to make my own software is not so big right now - I don't even know all the applications of the NanoVNA in the first place.
I, personally, don't believe in freeware/open source, btw. Any work done for free is normally to be considered "worthless" by those using it...
@joeqsmith: Can you explain what a GaAs transfer relay is and what purpose it has? I tried to google it without success, as the results want to show a GAS relay. So much about AI.
Regards,
Vitor
-
@joeqsmith: Can you explain what a GaAs transfer relay is and what purpose it has? I tried to google it without success, as the results want to show a GAS relay. So much about AI.
Regards,
Vitor
I assume you watched the video I posted where the person demonstrated a mechanical transfer relay. I also assume you watched the first video I made where I talked about the use of a transfer relay. GaAs, Gallium Arsenide is the technology used in my relay. You can find information about that in Wiki.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2616768/#msg2616768 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2616768/#msg2616768)
https://en.wikipedia.org/wiki/Gallium_arsenide (https://en.wikipedia.org/wiki/Gallium_arsenide)
The signal going back into the the device might actually break the device.
The VNA is designed to handle 100% reflected. Obviously if you are testing PAs, all bets are off. You could easily destroy it with the forward power as well.
I wonder why people are so motivated to write their own software?
As I stated before and demonstrated during the video, I started out because of the flicker when using the cursors.
-
Here is my take (or guess if you like) how NanoVNA operates, it requires no higher education, although it helps if you know quadrature signals.
For that you may check https://dspguru.com/files/QuadSignals.pdf (https://dspguru.com/files/QuadSignals.pdf) (it contains a lot more than needed here but it never hurts to know more).
I re-iterate that may be know already from elsewhere:
There is a clock chip with 3 outputs that beyond clocking the ADC and MCU chips (with the same clock) outputs 2 RF signals (one for downmixing, one for reference) with a small difference between them (that falls into audio range where the ADC can operate after mixing).
One of the RF signals is used to down mix to audio band and there are 3 double balanced mixers that share the same RF signal for downmixing:
- 1 mixer for the signal that is used to feed a resistor bridge (the reference RF signal)
- 1 mixer for the middle of the bridge (that measures unbalance)
- 1 mixer for the input of the VNA (RX)
In the resistor bridge instead one of the resistors the output of the VNA connected (TX).
If the VNA output is impedance matched (meaning pure resistive 50 Ohm), there is no signal in the middle of the bridge as it's balanced.
If the output is mismatched but still pure resistive there is signal in the middle of the bridge but it's phase aligned with the reference (that is feeding the bridge).
If the output is totally mismatched (meaning also reactive component) the middle of the bridge will show a phase shifted signal.
Checking in the source dsp.c file the ADC output of the downmixed signal is correlated with sine and cosine (5 periods in 48 samples, meaning like 5kHz difference between the RF signals with 48kSa/s that is my take or 10kHz with 96kSa/s with no practical difference) both for the signal being checked and the reference. The phasor difference between them is calculated and stored in rectangular form.
This is done for all the points in the scanned frequency range and plotted in the form that is desired (starting around line 430 of plot.c).
The same phasor difference is done for the input port in case of S21 measurement.
Like Bicurico already wrote, with S11 you can check the frequency dependent characteristic of a component (antenna included) what resistive and reactive part it has at various frequencies.
With S21 you can check what transfer characteristic of a component like filter, amplifier etc. has again at various frequencies.
In the what could be enhanced part for me the range extension occurred first. The clock chip is just 200MHz that is extended with many already documented tricks till 900 MHz but that is still not that high and due to the extension dynamic range is compromised as well...
Luckily the whole thing is open source (and very far from worthless) so anyone can enhance, correct.
Note: there are different sources, one from the original Japanese author (trftech) and then who makes this product:
https://github.com/ttrftech/NanoVNA (https://github.com/ttrftech/NanoVNA)
https://github.com/hugen79/NanoVNA-H (https://github.com/hugen79/NanoVNA-H)
-
Today I made up a USB cable to control the transfer relay and finished up the software to support it. Switching happens automatically when running a calibration or a 2-port sweep.
Sadly the prototype has proven to be worthless. I was hoping that the Nano's performance was poor enough that the error from the GaAs switches would be negligible but this wasn't the case. This would have a been a fairly low cost solution. If you are curious about the T check, Rohde Schwarz published a paper on it that may be worth the read.
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_application/application_notes/1ez43/1ez43_0e.pdf
-
If you are curious about the T check, Rohde Schwarz published a paper on it that may be worth the read.
do you have T-check results for nanoVNA?
-
If you are curious about the T check, Rohde Schwarz published a paper on it that may be worth the read.
do you have T-check results for nanoVNA?
I'm not sure what you are asking as a T-check for the Nano wouldn't make sense as it can't measure all four S parameters. The reason I added this basic metric to my software is to help validate the transfer relay (and bias Ts).
If you read the document I posted and understood it, looking at the picture I had attached, notice that the Function is set to 2-Port T-Check. I am sweeping from 1 to 150MHz which is the X-axis of the graph. The Y-axis it is in percent deviation from a perfect system, as shown in the Rohde Schwarz paper. Even at just 150MHz, you can see it is already 15% low which is a fail. It gets much worse.
As I mentioned, I have an old transfer relay that I could easily drop in and use but my goal wasn't to just show an old relay connected to the Nano like the video I had linked. That video doesn't show anything about how it is actually used and I doubt many people would want to see me just connect a relay. I would like to sort out something cost effective that could be replicated.
The end goal would be one last video showing how it could be used to create a full 2-port Touchstone file for a more complex device (RF transistor) and use it as part of an amplifier circuit modeled in SPICE.
I was looking at that Siglent setup but it looks like it suffers from the same problems. Being a modern system and over $1000, I was expecting more. I was actually hoping they had a low cost test set as I can't believe anyone would disturb their cables when making measurements, let alone swap them. Had they, and if it was cost effective, maybe adapt it to the Nano.
Oh well, strike one.
-
The plan is to switch to a mechanical relay like hagster had pointed out. Teledyne and others make some that have some decent specs. The ones used in my DSO have a very low profile. I would like to keep the size down like the first attempt. It will take another week or so to get something together to try.
It's too bad that they didn't offer this as an accessory. Maybe it's getting too specialized.
A few people have been asking me about the PCBs used for the cal standards. I don't have a store where I try to sell anything but again, maybe this is another opportunity for the people making the Nano.
-
I'm not sure what you are asking as a T-check for the Nano wouldn't make sense as it can't measure all four S parameters. The reason I added this basic metric to my software is to help validate the transfer relay (and bias Ts).
If I understand correctly, T-check can be done with 2-port. But I'm not sure what are meaning of these S21* and S12* (marked with star) on equation (12) in the document (see page 5).
If I understand correctly, S11 and S21 are measured on usual T-connector with some dummy load on a third port.
Technically we can measure S22 and S12 by just turn T-connector in different direction. But since we're using symmetric T-connector, the result should be almost the same, so we can assume that S22 = S11 and S12 = S21. Is it correct?
But what means S21* and S12* (with star)? How to measure it?
-
I'm not sure what you are asking as a T-check for the Nano wouldn't make sense as it can't measure all four S parameters. The reason I added this basic metric to my software is to help validate the transfer relay (and bias Ts).
If I understand correctly, T-check can be done with 2-port. But I'm not sure what are meaning of these S21* and S12* (marked with star) on equation (12) in the document (see page 5).
If I understand correctly, S11 and S21 are measured on usual T-connector with some dummy load on a third port.
Technically we can measure S22 and S12 by just turn T-connector in different direction. But since we're using symmetric T-connector, the result should be almost the same, so we can assume that S22 = S11 and S12 = S21. Is it correct?
But what means S21* and S12* (with star)? How to measure it?
https://en.wikipedia.org/wiki/Complex_conjugate
-
ok, thanks, I will try to measure it when I get nanoVNA.
So the last screenshot in the post #110 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2625981/#msg2625981) is ct value multiplied by 100 for 1..150 MHz range, measured on your nanoVNA? Is it correct?
I'm just confused because there is a word "Gain", so I thought this is something other in dB... :)
15% error at 150 MHz looks much worse than example from T-check document. Is it really so bad?
What is usual error of other amateur VNA?
-
ok, thanks, I will try to measure it when I get nanoVNA.
So the last screenshot in the post #110 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2625981/#msg2625981) is ct value multiplied by 100 for 1..150 MHz range, measured on your nanoVNA?
If swapping the cables, there's no need for the full 2-port cal, no need for the transfer relay, no need for the T-check. Of course, ideally you would want to mechanically lock everything down when making measurements.
Yes, like in the Rohde Schwarz paper, I have multiplied by 100. Yes, 1 to 150MHz. Yes, measuredish on my Nano. Ish, meaning that I am not taking the time to torque things or taking care to keep things from moving. More of a check to see if it was even worth spending any time with. It wasn't.
I'm just confused because there is a word "Gain", so I thought this is something other in dB... :)
You have just discovered first hand the reason for not releasing the software. It's really an engineering tool. These little details like "Gain" vs something like "T-Check Percent (see RS paper.....)" would eat up a lot of time trying to explain and clean up for the general user.
I suspect that most people will have no need for a full 2-port setup or want to play with things like Touchstone files and SPICE.
missing word
-
15% error at 150 MHz looks much worse than example from T-check document. Is it really so bad?
What is usual error of other amateur VNA?
The NanoVNA is really my only reference for a cheap amateur VNA so I really can't say what to expect. The problem I see with the cheap systems, like the Nano or the Siglent is there is no test set. Which again.... see my last post. So, if I ever get something I feel is good enough to use for a video, you will have at least one data point. Still, this will be custom one-off hardware, so there is a lot at play. Right now, I would say your guess is as good as mine.
Yes, 15% is pretty bad, especially when you consider that the full working range of the Nano is 900MHz. It's just the first prototype. Hopefully rev 2 will be better.
-
Running the Nano for about 5 minutes after SOLT cal. Then with the 50 ohm standard applied, let it run for roughly 18 minutes. The histogram is for every sample. So 101 samples per sweep multiplied by the 1600 sweeps, or 160K. I suspect if I were to do this for 0-300Mhz, it would look gaussian.
The software just records the raw data for both channels and the frequency. I can then calculate what ever I want to look at from that even though there are only six parameters listed.
-
Zooming into the 300MHz area, I suspect the reason we are seeing a pattern still is the lack of points.
The scatter plot is showing the mag phase for the 50 ohm standard. If it were perfect, we would just see a line from 0,0 at 50KHz to 0,0 at 900MHz.
-
The nanoVNA switches to harmonics mode when measuring above 300MHz. (see this code)
if (freq > 900000000) {
freq /= 5;
ofreq /= 7;
} else if (freq > 300000000) {
freq /= 3;
ofreq /= 5;
}
My own build VNA using SI5351 and 3 SE612 uses the same aproach
This switching to 3rd and 5th harmonic when using above 300MHz is relatively ok because of the relative phase and amplitude measurement but as the main signal drops more then 10dB it is a interesting test for the linearity of the onboard ADC.
Even when using a high end USB audio input the transition to harmonic mode its still observable
-
My own cables and calibration set is insufficient to do a good TEE test. (My VNA uses the same measurement approach and has many same components except ADC and controller)
(http://athome.kaashoek.com/public/eevblog/Tee%20test.PNG)
OK till about 600Mhz but deteriorating at higher frequencies.
Mind you, calibrating a standard 50 ohm load and measuring from 0.1 till 900MHz gives a very repeatable outcome at the accuracy level I am interested in. But then I am measuring with 24bit 192kHz ADC instead of the nanoVNA 16bit 48kHz ADC
-
The nanoVNA switches to harmonics mode when measuring above 300MHz. (see this code)
if (freq > 900000000) {
freq /= 5;
ofreq /= 7;
} else if (freq > 300000000) {
freq /= 3;
ofreq /= 5;
}
My own build VNA using SI5351 and 3 SE612 uses the same aproach
This switching to 3rd and 5th harmonic when using above 300MHz is relatively ok because of the relative phase and amplitude measurement but as the main signal drops more then 10dB it is a interesting test for the linearity of the onboard ADC.
Even when using a high end USB audio input the transition to harmonic mode its still observable
Covered a long time ago but yes.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2566308/#msg2566308 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2566308/#msg2566308)
-
Looks good. What language did you use?
-
According to application icon this is .net. :)
https://github.com/erikkaashoek/Tapr-VNA
-
Yes. PC software to control hw similar to nanovna
-
Is your plan to port it to the NanoVNA?
-
The nanoVNA appears to be based on a kit, the Vector Impedance Analyzer, produced by the Austin QRP Club. The website on which this kit was available (currently sold out), https://www.qsl.net/k5bcq/Kits/Kits.html, (https://www.qsl.net/k5bcq/Kits/Kits.html,) has considerable documentation which might be of use.
-
I tried running a narrow band sweep, set to 909 data points rather than 101. The standard deviation is still not real good.
-
Cleaned all the connectors, torqued everything then repeated the test with the same settings. It had a fairly dramatic effect.
-
The website on which this kit was available
You had an extra comma in the URL which caused it to totally fail. It took me a few mins to figure it out since the main page has no links to this stuff.
https://www.qsl.net/k5bcq/Kits/Kits.html (https://www.qsl.net/k5bcq/Kits/Kits.html)
-
Is your plan to port it to the NanoVNA?
No, as I do not own a nanoVNA, but its sub 50$ price makes it tempting.
All HW dependencies in my SW are in the USB_EZ_interface files. Main part is setting the VNA do to a scan (the "Sweep" function) and retrieving the data (the "ReadWrite" function), just like the nanoVNA commands
-
Maybe someone else will port it over. It looks like it would be a decent interface as is, or as a minimum a good start to one. Actually, what they have for the Nano wouldn't be too bad if they would fix the readout.
A while ago, I was playing with a TI 32-bit ADC and put this box together for it. The plan is to run a longer narrow sweep (same setup as the last test) from a cold start with the nano in this box.
SP
-
The NanoVNA is rather immune to EMC as the DSP IQ demodulator is only sensitive to one very narrow frequency (couple of Hz around the measurement frequency). However when scanning the complete range you may run into spurs from the CPU or SI5351 clock right at the measurement frequency and that translates to impedance deviations
I added a "spectrum analyzer" in my own SW where I disabled the test signal output of the SI5351 and only run the demodulator LO and measure the power present on the selected frequencies. You have to modify the measurement SW in the VNA for this as there is no longer a reference signal to compare to.
This spectrum analyzer mode will quickly show if there are relevant spurs interfering with the impedance measurement. And its useful as a (rather bad) spectrum analyzer
-
Plots representing over 5 hours of data, using the same settings. Unit was calibrated while inside the case, everything torqued. It appears there could be some gains to letting it warm up for a little while. Standard deviation is just under half.
All of this data was taken using the Nano's internal calibration.
-
If we only look at the 4 - 150MHz region, basically removing the two ends were it starts to have trouble, the noise is much closer to a gaussian distribution and the standard deviation is 5x lower. I may try repeating this test using my own calibration routines and see if I can flatten it out.
-
I am very impressed! :-+
-
The mechanical relay and some new end launch connectors just arrived for the second attempt at a transfer relay for the Nano. The plan is to keep the case size the same. Maybe this one will work good enough to show.
-
Do you talking about these 600+ USD mechanical relay?
https://www.pasternack.com/sma-electromechanical-transfer-switch-18ghz-35watts-24-32volts-f-pe7150-p.aspx (https://www.pasternack.com/sma-electromechanical-transfer-switch-18ghz-35watts-24-32volts-f-pe7150-p.aspx)
-
Do you talking about these 600+ USD mechanical relay?
https://www.pasternack.com/sma-electromechanical-transfer-switch-18ghz-35watts-24-32volts-f-pe7150-p.aspx (https://www.pasternack.com/sma-electromechanical-transfer-switch-18ghz-35watts-24-32volts-f-pe7150-p.aspx)
The mechanical relay and some new end launch connectors just arrived for the second attempt at a transfer relay for the Nano. The plan is to keep the case size the same. Maybe this one will work good enough to show.
From the datasheet:
Length 2.63 in [66.8 mm]
Width/Diameter 2.16 in [54.86 mm]
Height 1.36 in [34.54 m
Looks like it may not fit. :-DD :-DD That said, the Mini-circuits part I linked was half the price. Both would get the job done.
As I mentioned, I have an old transfer relay that I could easily drop in and use but my goal wasn't to just show an old relay connected to the Nano like the video I had linked. That video doesn't show anything about how it is actually used and I doubt many people would want to see me just connect a relay. I would like to sort out something cost effective that could be replicated.
That cost effective part is up in the air. $600+, seems a bit excessive. :-DD
-
@joeqsmith - nice thread
my unit just got here - I've only had time to take it apart ( i's missing the RF section shields ) and run some basic checks
I'll look over the python interface for linux, but the next weeks will be overloaded.
(an idea - make it as an attachment for a RPI3 + LCD -> make a hand-held unit with a nice display - i can duplicate the board without the LCD and make it fit the RPI extension header footprint)
-
Hi Joe,
is it possible to get Gerber-files ior KiCad sources of your attenuator PCBs ?
I watched youe video about MiniVNA and was very imptressed. Great job !
Martin DL9SAD
-
While the gain on the SA612 mixers are temperature compensated, it is not perfect temperature compensation. Furthermore, unless they used C0G capacitors and the like, the capacitance is also likely to have temperature variation as well. So for best results, plugging it in and waiting for the device to thermally equilibrate is best for the most accurate results.
Also, you can check out my VNA at
http://www.github.com/profdc9/VNA (http://www.github.com/profdc9/VNA)
It is similar to the NanoVNA, but you can assemble it yourself, and it may offer some advantages in accuracy because I actively lock into the intermediate frequency. But it still requires a thermal warmup period.
-
Isolation is better but still poor compared with the Nano. However, it may be good enough to do something with. I was hoping that the isolation specs would have been ultra conservative. If you want good isolation, it seems you are going to have to pay for it. :-DD
I was looking at the poor input match of the Nano but doubt I will try to do anything with it. I ran a cal using a 1-150MHz sweep, then repeated the T-check without the switch as before. It smooths it out a bit, which we would expect with more data points but it's a wash. Errors I suspect are me not taking care to torque it. But that mismatch is really bad for running these two port tests. My guess is most people don't care. After all, its a $50 analyzer, not $50,000.
I think the thing to do is run the T-check over a 50MHz sort of range using the my full 2-port calibration and see what we come up with.
-
Hi Joe,
is it possible to get Gerber-files ior KiCad sources of your attenuator PCBs ?
I watched youe video about MiniVNA and was very imptressed. Great job !
Martin DL9SAD
Sorry, I don't sell any products nor do I open source any code or designs. I will say that AppCad does have a built in strip line calculator that you may be interested in. The tool is free to download.
-
is it possible to get Gerber-files ior KiCad sources of your attenuator PCBs ?
some pcb for attenuators and filters, may be it will be useful for you:
https://oshpark.com/profiles/K8VFO
-
Picture showing the test setup.
The components for the bias Ts have been added to the transfer relay. I engraved the copper plate because the steal case is very thin and easy to cut through.
Using the new transfer relay as shown, I ran a full 2-port cal from 1 to 500MHz and then ran a T-Check. It's pretty poor but believe it or not, this is much better performance than I saw with the first prototype.
For those playing along, I am using an OMRON G6K RF DPDT relay. These are about $20 USD in singles. As I mentioned earlier, it behaves like a $20 relay, not a $600 relay.
****
Added picture of the setup mentioned.
-
I repeated the full 2-port calibration, this time sweeping from 10 to 50MHz. I'm just wanting to work in a less error prone region.
The attached shows the results of repeating the T check. Even with this narrow span, we can see it's still +/-8% error.
-
This is looking at S21 after the 2-port cal, using the thru standard.
A new reference feature was then added to the software to allow me to easily measure the gain from a 0dB reference. The second plot is showing the two MidWest Microwave 10dB attenuators attached (shown in the setup picture). You can find information on these here:
https://www.mouser.com/ProductDetail/Midwest-Microwave-Cinch-Connectivity-Solutions/ATT-0290-10-HEX-02?qs=kRS0rR9cfpUxbNsiwYNf9w%3D%3D (https://www.mouser.com/ProductDetail/Midwest-Microwave-Cinch-Connectivity-Solutions/ATT-0290-10-HEX-02?qs=kRS0rR9cfpUxbNsiwYNf9w%3D%3D)
-
I haven't measured how much input power the Nano can handle before it starts to compress. Looking at the output signal with a calibrated SA, it was fairly close -9 to -13dB called out in the manual. It's far from flat.
The transistor will have a gain of 14dB or so. -20dB should keep me from out of the non-linear region.
Replacing the thru section of the cal standard with our test transistor and increasing the bias, we can measure the the gain.
-
I don't know the specs but the price seems right and they are from a serious RF company. Could they possibly be useful?
https://www.ebay.com/itm/Anritsu-MM700022A-Microwave-Switches-Lot-of-2/173844545453 (https://www.ebay.com/itm/Anritsu-MM700022A-Microwave-Switches-Lot-of-2/173844545453)
-
I don't know the specs but the price seems right and they are from a serious RF company. Could they possibly be useful?
https://www.ebay.com/itm/Anritsu-MM700022A-Microwave-Switches-Lot-of-2/173844545453 (https://www.ebay.com/itm/Anritsu-MM700022A-Microwave-Switches-Lot-of-2/173844545453)
Maybe. Someone would need to look up the datasheets for them. If you read the posts, again I have a transfer relay that I could easily bolt on but that's not the goal.
As I mentioned, I have an old transfer relay that I could easily drop in and use but my goal wasn't to just show an old relay connected to the Nano like the video I had linked. That video doesn't show anything about how it is actually used and I doubt many people would want to see me just connect a relay. I would like to sort out something cost effective that could be replicated.
****
Cleanup....
I'm not sure how you would use them. This is more like what you would want if you were looking for used. Again, you would need to find the datasheet. Then being used, it may no longer meet the specified performance.
https://www.ebay.com/itm/RF-Transfer-Relay-with-Suppress-Switch-CS-37S10-DM/163664843937?hash=item261b2f54a1:g:74QAAOSw9Mtcwcod (https://www.ebay.com/itm/RF-Transfer-Relay-with-Suppress-Switch-CS-37S10-DM/163664843937?hash=item261b2f54a1:g:74QAAOSw9Mtcwcod)
-
Just a dumb question, sorry if it is stupid.
From what I understood, you want to switch S1 and S2 for different measurements, without having to screw the cables on/off.
Wouldn't a cheap DiSEqC-switch as used for satellite TV reception do the job? The controller that implements the DiSEqC switching could be replaced by some simple logic (press button or whatever).
These switches are optimized for 950MHz-2150MHz, but will handle lower frequencies for sure. They come in all shapes and forms (2 in - 1 out up to 16 in - 1 out or even 16 in - 16 out).
https://en.wikipedia.org/wiki/DiSEqC
Again, sorry if this does not make sense, if so, please explain in a friendly way.
Regards,
Vitor
-
Sorry: just remembered that TV/CATV/SAT is 75 Ohm and not 50 Ohm.
Regards,
Vitor
-
My old antique 70's HP VNA may be a relic but it has some nice features, like a DC-3GHz step attenuator. Sadly, I don't have one just laying around.
Wanting to get some idea where things start to compress (nano + amp) one attenuator was removed from the drive but it had little effect. The second 10dB attenuator was then swapped out for a 3dB part and the test was repeated. We can see it's now about 2dB low.
-
I suspect the compression is not the DUT but the Nano being over driven. The Nano would be putting out somewhere below 10dB which shouldn't be a problem for our DUT. I didn't see in the Nano's manual where they talk about at what point it starts to go nonlinear. I doubt people care about it.
To sort it out, this is the crappy setup. The whole thing is really a bad outside of a great setup for learning the basics. It's not something you would want to try and use. To see if the Nano is compressing, I would like to add a 10dB attenuator after the bias T and see if we get our 16dB back.
So this nightmare of error prone mess was placed between the DUT and transfer relay. Ideally I would characterize it, but I really just want to know it we get our gain back. The large part is a commercial bias T followed by a Midwest BNC style 10 dB attenuator.
I ran this with the thru and stored that as my reference then repeated the test using our DUT.
Hard to say how the different flavors of Nanos behave or what would be a safe region to use.
-
Just a dumb question, sorry if it is stupid.
From what I understood, you want to switch S1 and S2 for different measurements, without having to screw the cables on/off.
....
Again, sorry if this does not make sense, if so, please explain in a friendly way.
Regards,
Vitor
Yes, I want to flip the cables without disturbing the test setup in order to measure all four S parameters. This is the job of the transfer relay. If you want to use two coaxial SPDT relays, you will need to sort out how to combine the signals. The stub may burn you as well.
Looking at the picture showing the inside of my HP test set, you can see the transfer relay and step attenuator. Sitting between them is a SPDT relay. This relay will terminate the unused pin rather than float it. Point being if you are going to buy some used relays to make some sort of test set, make sure you locate and read the datasheets first.
-
Corrected post to include the picture showing the test setup.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2638257/#msg2638257 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2638257/#msg2638257)
-
I located the original articles I mentioned that talk about using the S-parameters with SPICE.
-
The first attached graph shows S21 while sweeping the collector current . A bit odd as the gain dips sharply when the current is very low. There is no amplification until roughly sweep 112.
The second graph is the same setup but driving the DUT a bit harder and zooming in. The datasheet shows the 1dB compression at 100MHz is roughly 17.5dB. You can clearly see it has started to compress at 19.
-
If I make no mistake interpreting the nanoVNA schematic and the datasheets of the SA612 and the ADC you have to stay below about -10dBm for P2.
The SA612 amplifies about 17dB (below 500MHz). The max input level to the ADC is about 0dBm and the resistor network at P2 reduces the level with about 6dB. Or am I making a mistake?
-
If I make no mistake interpreting the nanoVNA schematic and the datasheets of the SA612 and the ADC you have to stay below about -10dBm for P2.
The SA612 amplifies about 17dB (below 500MHz). The max input level to the ADC is about 0dBm and the resistor network at P2 reduces the level with about 6dB. Or am I making a mistake?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2598729/#msg2598729 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2598729/#msg2598729)
-
I was not aware the output spec is the same as the input spec. Please ignore my post :-[
-
I was not aware the output spec is the same as the input spec. Please ignore my post :-[
... I didn't see in the Nano's manual where they talk about at what point it starts to go nonlinear. I doubt people care about it.
...
Hard to say how the different flavors of Nanos behave or what would be a safe region to use.
It should be safe to say it supports a thru without distortion or what would be the point of running a SOLT. From playing with that transistor, we can get some idea but I haven't looked into it any further. Staying below the output level should be safe but the dynamic range of the Nano is pretty limited. My low cost transfer relay certainly doesn't help with this.
-
Plot showing all four S parameters. This data was collected automatically using the low cost transfer relay, after running a full 2-port calibration. The T-check was installed as the load.
-
1000 mating cycles, I like that.
https://youtu.be/U3Fabnw9U04?t=40
-
I just started following this thread since I'm interested in getting a nanoVNA, and you've done such an impressive work. Thanks for sharing all the research and tests you've done on this device!
-
I just started following this thread since I'm interested in getting a nanoVNA, and you've done such an impressive work. Thanks for sharing all the research and tests you've done on this device!
No problem. Glad you are finding them of interest.
In the attached plot, the Nano is used to monitor the effects of applying corona dope to a 5 pole low-pass filter and watching it dry.
The filter was attached to the transfer relay after cal, then used as a baseline. The plot is the deviation from that baseline.
The first few sweeps (towards the back), it is reasonably flat with a clean PCB. The deep blue is after applying the liquid dope. As it slowly drys, I would expect it to return to normal once fully cured.
-
Hello,
Can You tell me what "CORRECTION" does to NanoVNA, plase?
It seems that it is something like 10 dB attenuator, but I am not sure.
"CORRECTION" is in "CAL" menu.
Thanks
-
Hello,
Can You tell me what "CORRECTION" does to NanoVNA, plase?
It seems that it is something like 10 dB attenuator, but I am not sure.
"CORRECTION" is in "CAL" menu.
Thanks
It's just an easy way to enable / disable the correction factors created after the unit was calibrated.
-
Thanks
-
I have made comparison between Rohde Schwarz and NanoVNA.
The same homemade VHF Helical Band-Pass filter was measured with both instruments.
The results was amazing!
Here is the pictures:
-
Looking good.
-
Someone had asked me about making one more video for the Nano. As I said in the attached, I am not apposed to it if there is some interest. Feel free to chime in if there is something else you would like to see.
-
Dear All,
It look like a issue with the calibration procedure, or the calibration method is "simple".
I found some description about VNA project, with the issue of the simple method. http://hforsten.com/improved-homemade-vna.html (http://hforsten.com/improved-homemade-vna.html)
It could be some track for improve the software in this device.
Best regards
Roland
-
Instead of GaAs pin diodes you could use this: https://www.psemi.com/pdf/datasheets/pe4250ds.pdf (https://www.psemi.com/pdf/datasheets/pe4250ds.pdf) which supposedly has better performance up to 3 Ghz
Jerry NY2KW
-
The topic should have been called Private Software.
-
Instead of GaAs pin diodes you could use this: https://www.psemi.com/pdf/datasheets/pe4250ds.pdf (https://www.psemi.com/pdf/datasheets/pe4250ds.pdf) which supposedly has better performance up to 3 Ghz
Jerry NY2KW
I don't see how that would ever work. You would need to sketch out how you would use them as I am lost.
-
The topic should have been called Private Software.
As my software continues to evolve, I start thinking maybe it's something that could be useful for others, but then comments like yours bring me back to reality. So thanks for that wake up call.
SP
-
Inspired by Joe's great YouTube videos on the NanoVNA, I went ahead and botched together a little Python app that does some of the same things (most importantly, multiple sweeps to increase the amount of data points.)
It's open source and on github, as "NanoVNA-Saver" (because I initially just made it to save s1p/s2p files). I daren't post a link in my first post on this forum though :-)
Thanks Joe for the inspiration, and I hope some of the rest of you may find it useful.
-
Inspired by Joe's great YouTube videos on the NanoVNA, I went ahead and botched together a little Python app that does some of the same things (most importantly, multiple sweeps to increase the amount of data points.)
It's open source and on github, as "NanoVNA-Saver" (because I initially just made it to save s1p/s2p files). I daren't post a link in my first post on this forum though :-)
Thanks Joe for the inspiration, and I hope some of the rest of you may find it useful.
Welcome to the forum.
I just released a viewer Q&A video for the Nano that you may be interested in as well.
https://www.youtube.com/watch?v=GJNMnq8eD0E (https://www.youtube.com/watch?v=GJNMnq8eD0E)
-
The topic should have been called Private Software.
As my software continues to evolve, I start thinking maybe it's something that could be useful for others, but then comments like yours bring me back to reality. So thanks for that wake up call.
SP
Thats sad .. One guy ruined it for the rest of us :(
I truly appreciate your hard work and attention to detail ..
You have a lot of awesome videos . ( is it working? lol )
You truly do though ..
Would love to play with that software ..
Can I trade you for a few mini-circuits SMA style attenuators? ;)
I used to program .. but it was awhile ago .. retired USAF TSgt ..
So have some extra time to play and try to keep my mind active ..
Just bought the NanoVNA .. and still learning ..
Ham radio operator - N2CUA
Either way .. thanks so much for all your great info ..
-
The topic should have been called Private Software.
As my software continues to evolve, I start thinking maybe it's something that could be useful for others, but then comments like yours bring me back to reality. So thanks for that wake up call.
SP
Thats sad .. One guy ruined it for the rest of us :(
I truly appreciate your hard work and attention to detail ..
You have a lot of awesome videos . ( is it working? lol )
You truly do though ..
Would love to play with that software ..
Can I trade you for a few mini-circuits SMA style attenuators? ;)
I used to program .. but it was awhile ago .. retired USAF TSgt ..
So have some extra time to play and try to keep my mind active ..
Just bought the NanoVNA .. and still learning ..
Ham radio operator - N2CUA
Either way .. thanks so much for all your great info ..
Thank you for your service to our country.
I'm glad you enjoyed the videos and thread. This was put together for a friend of mine who wanted to learn a little more about VNAs and I decided to try and help them along. Their use of the VNA is more for PCB design. Personally, electronics has been one of my hobbies for many years. I have been in a continual state of learning but still know hardly anything about it.
I've never understood where certain people came up with the idea that I owe them. It's not what I would expect from a technical community and I'm sure it's obvious that my threshold is fairly low when dealing with them. :-DD
-
Yeah I never got that concept either ..
My sister is a bit like that .. but she's family so I just accept it for what it is and try to find ways to make her see ( gently ) that its just not the case .. Takes time ... but I think she is coming around .. a bit of tough love though ..
I hope you change your mind at some point .. but thats your call of course..
Thanks for the kind words .. :)
You would think with all the available data on the USB bus coming from the VNA that there would be a more robust interface ..
But still ... for the price its great and I dont have to lug my Rigol spectrum analyzer around when helping friends with their antennas ..
Randy
-
Thanks to the OP joeqsmith.
Your videos are very educational and well put together :)
Then thanks 5q5r for your nanovna - saver app, it quite a treat playing with it :D
Kind regards
Keep the information coming!
ZS1SCI
-
5q5r
I tried your prebuilt EXE on Windows 10. It connected to the Nano and I was able to get it to plot the data without any problems. It looks like a very good start. So far, I think you are the only one who has stepped up and shown something other than lip service. With the number of people asking for open source, Python code, you are making a lot of people very happy.
-
Yeah I never got that concept either ..
My sister is a bit like that .. but she's family so I just accept it for what it is and try to find ways to make her see ( gently ) that its just not the case .. Takes time ... but I think she is coming around .. a bit of tough love though ..
I hope you change your mind at some point .. but thats your call of course..
Thanks for the kind words .. :)
You would think with all the available data on the USB bus coming from the VNA that there would be a more robust interface ..
But still ... for the price its great and I dont have to lug my Rigol spectrum analyzer around when helping friends with their antennas ..
Randy
I'm a bit surprised myself that the PC software was released in its current state. You could have a look at 5q5r's code. Obviously they are just getting started but it looks promising.
https://github.com/mihtjel/nanovna-saver
-
I haven't been following this thread, but if anyone is interested:
Here are some examples of offline calibrations, comparative tests with my HP 8753 and another NanoVNA, and a TDR example.
https://github.com/hendorog/nanovna_test
This uses the free Jupyter Notebook which you need to install if you want to play on your machine with this code.
Apologies in advance as the comments are pretty sparse, most were done as part of conversations on groups.io.
Note, I am not grabbing the data automatically yet, this is just for offline analysis at the moment. I have been using the NanoVNA C# app to get the s1p files to date.
-
hendorog, what mixers are used in your nanovna version - SA602 or SA612?
Can you take S1P for some load different than 50 Ohm?
For example 500 Ohm (SWR=10.0) will be a good choice for testing nano vna precision.
You can create such dummy load with SMA connector and two 1k SMD resistors soldered on it.
Such dummy loads - 500 Ohm and 5 Ohm is a must have for VNA testing and calibration. They both should give SWR=10.
-
hendorog, what mixers are used in your nanovna version - SA602 or SA612?
Can you take S1P for some load different than 50 Ohm?
For example 500 Ohm (SWR=10.0) will be a good choice for testing nano vna precision.
You can create such dummy load with SMA connector and two 1k SMD resistors soldered on it.
Such dummy loads - 500 Ohm and 5 Ohm is a must have for VNA testing and calibration. They both should give SWR=10.
The last graph on this page https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20test.ipynb (https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20test.ipynb) shows nanovna and 8753 measurements of a reference attenuator provided with my cal compared with reference data provided by Dr Kirkby.
(Note the 8753 was intentionally setup to match the nanovna, without any cal kit information. When properly configured for the cal kit, the 8753 will match the green line closely)
This gives a good idea of the out of the box accuracy of the device using its own (uncharacterised) cal kit against an independently measured standard above 50MHz.
Will do some more tests for you, but if I don't get it done tonight it might be a while due to other commitments.
My two devices (white gecko and black hugen) both have 602 mixers. I have read that the two models of mixers are internally identical but no idea if that has been confirmed.
-
Also, just to add there is a known bug in the released NanoVNA sharp application when using it to do calibrations.
The measurement of the other standards are discarded unless the Short is the first standard measured.
This is because the Short button click event in the NanoVNA sharp app does a call to the 'cal_reset' operation - which wipes any earlier measurements out.
So if you do a cal in Open Short Load order using the NanoVNA sharp application, there will be an error of about 0.3dB - not much, but significant enough to be important when doing comparisons as can be seen in the attached pic.
First pic attached showing the effect of doing OSL cal order.
Second pic attached which is the same as in the previous post, showing the workaround of doing SOL cal order.
-
Inspired by Joe's great YouTube videos on the NanoVNA, I went ahead and botched together a little Python app that does some of the same things (most importantly, multiple sweeps to increase the amount of data points.)
It's open source and on github, as "NanoVNA-Saver" (because I initially just made it to save s1p/s2p files). I daren't post a link in my first post on this forum though :-)
Thanks Joe for the inspiration, and I hope some of the rest of you may find it useful.
Would you be up to helping me set up my Python on windows 10? Its installed but having issues with installing PyQT5. Python is completely new to me .. Not sure if its worth all this just to have a better interface .. :(
-
My two devices (white gecko and black hugen) both have 602 mixers. I have read that the two models of mixers are internally identical but no idea if that has been confirmed.
It looks that SA612A works much better. My NanoVNA have SA602A mixers. Here is my 500 Ohm terminator measurement:
Series RLC:
[attach=2]
Parallel RLC:
[attach=3]
Also see S1P file for SA602A version with 500R terminator on CH0 in attachment.
Here is also screenshot for 500R terminator from another user, who have NanoVNA with SA612A:
[attach=4]
As you can see, SA612A looks much better and works almost up to 900 MHz with above 200 Ohm result. While SA602A is going below 200 Ohms at just 160 MHz. But I'm not sure. May be this is just quality issue with my NanoVNA (for example bad soldering or something like that).
It will be good if you can confirm that your SA602A version also has bad performance on Series RLC screen. So, if SA602A is the root of cause for that, then it probably can be fixed by replacement SA602A mixers with SA612A :)
-
Inspired by Joe's great YouTube videos on the NanoVNA, I went ahead and botched together a little Python app that does some of the same things (most importantly, multiple sweeps to increase the amount of data points.)
It's open source and on github, as "NanoVNA-Saver" (because I initially just made it to save s1p/s2p files). I daren't post a link in my first post on this forum though :-)
Thanks Joe for the inspiration, and I hope some of the rest of you may find it useful.
Would you be up to helping me set up my Python on windows 10? Its installed but having issues with installing PyQT5. Python is completely new to me .. Not sure if its worth all this just to have a better interface .. :(
I got it working .. Just have to learn PYTHON now .. lol
-
My two devices (white gecko and black hugen) both have 602 mixers. I have read that the two models of mixers are internally identical but no idea if that has been confirmed.
As you can see, SA612A looks much better and works almost up to 900 MHz with above 200 Ohm result. While SA602A is going below 200 Ohms at just 160 MHz. But I'm not sure. May be this is just quality issue with my NanoVNA (for example bad soldering or something like that).
It will be good if you can confirm that your SA602A version also has bad performance on Series RLC screen. So, if SA602A is the root of cause for that, then it probably can be fixed by replacement SA602A mixers with SA612A :)
Interesting - based on the hint I mentioned, I searched and found this story on the internet:
https://soldersmoke.blogspot.com/2009/06/na5n-on-ne602.html
I'll do that test, tonight if I have time, and I will also sweep the loads on my 8753 for comparison.
-
it seems that my NanoVNA with SA602A may be OK. Probably this measurement error caused by 1 cm SMA-M to SMA-M adapter (https://www.aliexpress.com/item/32818446366.html). I tried to add two adapters on another VNA and got similar measurement error.
Just incredible, 1 cm SMA to SMA adapter leads to so high measurement error... :)
-
it seems that my NanoVNA with SA602A may be OK. Probably this measurement error caused by 1 cm SMA-M to SMA-M adapter (https://www.aliexpress.com/item/32818446366.html). I tried to add two adapters on another VNA and got similar measurement error.
Just incredible, 1 cm SMA to SMA adapter leads to so high measurement error... :)
Can you try a calibration with all cables and connectors that will be used in place ?
Other than the needed calibration items of course
-
A greeting to the whole group.
I'm a new user.
I tried to follow all the Treead, but I don't read English well, (I'm Italian).
I would like to ask you if anyone can kindly tell me where to recover this software "Custom Lab View for Nano VNA"
THANK YOU ANTICIPATEDLY WHO WILL MAKE ME AID ... :) :) :)
-
A greeting to the whole group.
I'm a new user.
I tried to follow all the Treead, but I don't read English well, (I'm Italian).
I would like to ask you if anyone can kindly tell me where to recover this software "Custom Lab View for Nano VNA"
THANK YOU ANTICIPATEDLY WHO WILL MAKE ME AID ... :) :) :)
Hello Flynt, for the moment ;) this software is not available for download. It was developed by joeqsmith to show what is possible with the Nanovna, to make some educational youtube video's about the NanoVNA and to inspire others to make apps of their own (which has worked already, thanks to 5q5r)
-
Thanks Wim
I've already written a private message to joeqsmith, to know how to get it ... :)
I'm not able to program... :-\
-
I think this software is a good alternative to what joeqsmith has made:
https://github.com/mihtjel/nanovna-saver
-
The executable can be downloaded from here if you do not want to run it in phython (download the zip file)
https://github.com/mihtjel/nanovna-saver/releases
-
Can you try a calibration with all cables and connectors that will be used in place ?
Other than the needed calibration items of course
The problem here is that all calibration loads should be connected through the same length as 500 Ohm terminator.
Here is my calibration kit and 500 Ohm terminator:
[attach=1]
As you can see, it's about 15 mm longer than calibration terminators. It leads to additional delay in wave propagation and as result it leads to measurement error.
You can check my previous S1P file for 500R terminator, see Group Delay S11, it's about 0.25 ns.
Now I tried to setup ELECTRICAL DELAY = 247 picoseconds (see SCALE menu in NanoVNA) to get software correction for that delay. I tried different values and 247 ps give me the best result. So it seems like these 15 mm leads to 247 ps delay. And now, with 247 ps delay correction, I get much better result :)
Series RLC:
[attach=2]
Parallel RLC:
[attach=3]
Group Delay S11:
[attach=5]
S11:
[attach=6]
VSWR:
[attach=7]
-
Here is another finding. When I tried to get the same measurement (with electric delay 247 ps) for 500R terminator with no connection to PC (powered from accumulator), it shows 500 Ohm and VSWR=10 almost up to 900 MHz.
For example:
600 MHz: Rs = 550 Ohm, VSWR = 11.07
700 MHz: Rs = 501 Ohm, VSWR = 10.03
800 MHz: Rs = 478 Ohm, VSWR = 9.62
900 MHz: Rs = 462 Ohm, VSWR = 9.08
So, it seems that USB connection to PC affects measurements...
Tried more tests about that. When I connect it to powered off power bank, there is no influence, but after power on, there is a change in measurement above 500 MHz. It seems that external power supply leads to increase power supply voltage and it affects measurement.
I tried to calibrate it with external power supply, but it seems, that calibration cannot eliminate measurement error which appears with external power supply. So, the only way to get the best measurement is to disconnect device from external power supply. Very strange. Any idea how to fix it?
-
I checked the pinout of the STM32F303CCT6 with 48 KB of RAM and 256 KB of flash today and it should be a drop-in replacement for the existing STM32F072CBT6. The 3x increase in RAM and 2x increase in flash would allow a substantial increase in features such as TDR, storing multiple calibration ranges, etc. The groups.io list is a firehose of activity.
I was going to do the chip swap myself, but one of the sellers, hugen, has offered to provide a unit with the '303 part. I expect that will be very popular with people wanting to write FW with additional features. So I'm hoping for an announcement that '303 based units are available for an extra $5-10 US. In quantity 2400 from Digikey, the price differential is $1.28 US. $1.92 vs $3.20 for the MCU. That makes it an attractive change for an OEM if it allows more features.
The 16 KB memory of the current versions is a significant limitation. An important application for the additional memory is TDR from VNA data. There are already multiple implementations for producing TDR traces from VNA data being done on a PC, but no room for it on the device.
The existing FW should run on the larger part unaltered, so buying a unit with the STMF303 part makes it easy for a buyer who is not interested in writing FW to do updates as things develop. This is the RF version of the $20 LCR-transistor tester. Hang on to your hats!
Have Fun!
Reg
-
Here is another finding. When I tried to get the same measurement (with electric delay 247 ps) for 500R terminator with no connection to PC (powered from accumulator), it shows 500 Ohm and VSWR=10 almost up to 900 MHz.
For example:
600 MHz: Rs = 550 Ohm, VSWR = 11.07
700 MHz: Rs = 501 Ohm, VSWR = 10.03
800 MHz: Rs = 478 Ohm, VSWR = 9.62
900 MHz: Rs = 462 Ohm, VSWR = 9.08
So, it seems that USB connection to PC affects measurements...
Tried more tests about that. When I connect it to powered off power bank, there is no influence, but after power on, there is a change in measurement above 500 MHz. It seems that external power supply leads to increase power supply voltage and it affects measurement.
I tried to calibrate it with external power supply, but it seems, that calibration cannot eliminate measurement error which appears with external power supply. So, the only way to get the best measurement is to disconnect device from external power supply. Very strange. Any idea how to fix it?
My first guess would be EMI coming in on the power cable. Does the cable you're using have chokes?
-
The sweep width and the few data points available is also a significant limitation on accuracy. Joe showed this earlier where the interpolation with so few points had it drawing a series of straight lines on the Smith chart.
The user needs keep this data point limitation firmly in mind and use a sweep width that's appropriate and a heap of averaging if necessary.
-
My first guess would be EMI coming in on the power cable. Does the cable you're using have chokes?
I also thought about it. But this is not the case. I can connect any length of cable and it doesn't affect measurement. Also I tried to connect cable to power bank with disabled output and it doesn't affect measurement. But when I press power on button on power bank, it leads to measurement error. So, the the issue appears when external voltage is applied and don't depends on the cable.
-
After some period of time I found that cable influence disappears. ??? May be it happens when battery is charging. And when battery is full this effect disappears.
Here is 500 Ohm terminator measurement with 247 ps correction for wave propagation delay in SMA-SMA adapter:
[attach=2][attach=3][attach=4]
Now it looks great ^-^
By the way, my NanoVNA has 3.7V 450 mAh battery and can work from battery up to 130 minutes.
-
You probably should probe the output of U3 with a scope and DMM and see what Vdd looks like with and without external power.
The +5 V connection on terminal 3 of U3 looks as if it would power the whole board any time the USB had 5 V unless it's an unconnected power input. But it looks to me as if it is coming from the USB. So I'm a bit puzzled by the schematic.
-
Confirmed. Measurement is affected when battery is charging.
When charge LED stops flashing, measurement error disappears.
I tried to measure voltage between GND and VDD on ST-LINK connector.
When powered from the battery: 3.3350 V
When external power connected: 3.3306 V
After some time with ext. power: 3.3325 V (measurement error is still present)
When charge LED stops flashing: 3.3339 V (measurement error disappears)
-
Someone had posted this comment about torque wrenches. This is my super expensive torque wrench calibration station. The bolt that holds the scale and hex standoff is mounted on two ball bearings that were clamped in the Panavice. The steal is very close to 1lb. Lower right, you can see the screwdriver style and my modified deep wall socket. Also my ultra thin spanner that is used to hold some of the SMA parts, when using the torque wrench.
After reading their comment, I would be very interested in knowing how much other SMA torque wrenches vary as they describe. As I note, mine is about 1" and you need to choke up on the rubber to get to 8". I could see more error in the technique used if you didn't follow the instructions.
-
Confirmed. Measurement is affected when battery is charging.
When charge LED stops flashing, measurement error disappears.
I tried to measure voltage between GND and VDD on ST-LINK connector.
When powered from the battery: 3.3350 V
When external power connected: 3.3306 V
After some time with ext. power: 3.3325 V (measurement error is still present)
When charge LED stops flashing: 3.3339 V (measurement error disappears)
Very interesting discovery. I had not heard of that and it might explain a few issues people are having comparing similar devices.
I'll try and replicate as all of my testing has been done with the devices plugged in.
-
Choking up on the wrench should make no difference to the breakover torque. That's the whole idea behind a torque wrench.
That said, it does make a subtle difference regarding how the force is applied. There is one right way and (numerous) wrong ways to use a torque wrench (actually two wrenches) on high-grade connectors. A great operator training guide was created for UC Berkeley students at one point but I couldn't find a straightforward .PDF edition, just a bunch of skeevy links to "slide sharing" sites and (with some effort) the original PowerPoint file. I went ahead and printed it to a .PDF, linked here (http://www.ke5fx.com/VNA_equipment_calibration_connector_handling_care.pdf) (61 pages, 6 MB).
Highly recommended reading even if (like me) you blow off 80% of these guidelines in day-to-day use. At least you will know what you're doing wrong. >:D
-
Choking up on the wrench should make no difference to the breakover torque. That's the whole idea behind a torque wrench.
That said, it does make a subtle difference regarding how the force is applied. There is one right way and (numerous) wrong ways to use a torque wrench (actually two wrenches) on high-grade connectors. A great operator training guide was created for UC Berkeley students at one point but I couldn't find a straightforward .PDF edition, just a bunch of skeevy links to "slide sharing" sites and (with some effort) the original PowerPoint file. I went ahead and printed it to a .PDF, linked here (http://www.ke5fx.com/VNA_equipment_calibration_connector_handling_care.pdf) (61 pages, 6 MB).
Highly recommended reading even if (like me) you blow off 80% of these guidelines in day-to-day use. At least you will know what you're doing wrong. >:D
https://www.youtube.com/watch?v=RsMxtEx0uik (https://www.youtube.com/watch?v=RsMxtEx0uik)
-
I had mentioned in the last video I made about the limited resolution (distance) when making TDR measurements. I talked a bit about how you may be able improve it but with it being a $50 unit, I don't see much of a point. Well except for the pure fun of it.....
So I talked it over with a friend of mine and we had a good laugh about the whole project. He offered one idea that should help improve the setup but it's all a guess if the Nano can actually be used this way and get any useful information from it. Of course, cost will need to be ignored which is part of the humor....
First baby step, modify my software to support the range extender. It may not look like anything is going on in the attached plot, but what you see the Nano using Channel 1 for S11. That's not a misprint. Granted, it's only 100MHz. :-DD Like I said, baby step.
***
Should mention, yes, it is indeed a 100 ohm resistor.
-
If you read the document you linked, on page 14, they show the hand placement. That is the marking that the person commenting on my video mentions. He is absolutely correct that it will have an effect which is why this training manual talks about it. Page 15, they show the damaged connector after the person chokes up on the wrench.
What I would like to know is how much of an effect various wrenches have. I only have the one click type.
-
If you read the document you linked, on page 14, they show the hand placement.
Yes, together with the completely bogus reasoning that it has anything to do with the grasping point along the moment arm.
It's still a good document, IMO, despite that.
That is the marking that the person commenting on my video mentions. He is absolutely correct that it will have an effect which is why this training manual talks about it. Page 15, they show the damaged connector after the person chokes up on the wrench. What I would like to know is how much of an effect various wrenches have. I only have the one click type.
I've always found that I can apply pretty much whatever torque I want by holding it in a certain (incorrect) way, whether dealing with a ratchet or an open-ended torque wrench. The angle at which you apply the force is important, but the distance along the handle considered by itself is not.
-
Again, you can lead the horse to water.... But I can't help you.
-
If you read the document you linked, on page 14, they show the hand placement.
Yes, together with the completely bogus reasoning that it has anything to do with the grasping point along the moment arm.
It's still a good document, IMO, despite that.
That is the marking that the person commenting on my video mentions. He is absolutely correct that it will have an effect which is why this training manual talks about it. Page 15, they show the damaged connector after the person chokes up on the wrench. What I would like to know is how much of an effect various wrenches have. I only have the one click type.
I've always found that I can apply pretty much whatever torque I want by holding it in a certain (incorrect) way, whether dealing with a ratchet or an open-ended torque wrench. The angle at which you apply the force is important, but the distance along the handle considered by itself is not.
Hmm, I am not so sure. I think that the position of the force you apply to the handle will matter - because of the construction of the wrench. The breaking 'knuckle' is offset from the centre of rotation of the nut.
So there are two levers involved- one from your hand to the nut, and a shorter one from your hand to the knuckle.
If you were to use the wrench and measure the exact force to the end of the handle to break the knuckle, then:
Reduce the hand-knuckle lever length to 10% of what it was, then obviously you will need to apply 10 times more force to break the knuckle. Force x distance.
Now 10 times more force is being applied to the end of the hand-nut lever. The lever is shorter than it was, but it is not 90% shorter because of the nut-knuckle distance hasn't changed.
That is also the case - but with a smaller nut to knuckle distance - in the posted video.
-
That is also the case - but with a smaller nut to knuckle distance - in the posted video.
But that's a different moment arm than the one shown in the document.
As long as you hold the torque wrench somewhere along the actual handle (i.e., the red part shown here (https://www.fairviewmicrowave.com/sma-fixed-torque-wrench-click-st-sma3-p.aspx), using the model of torque wrench I have here as an example) you will be able to deliver the specified torque or something very close to it. It (should) go without saying that if you grab the wrench just behind the knuckle, you can apply pretty much whatever force you want in whatever direction you want.
-
I like this website for practical information:
https://www.microwaves101.com/encyclopedias/torque-wrench (https://www.microwaves101.com/encyclopedias/torque-wrench)
https://www.microwaves101.com/encyclopedias/connector-care (https://www.microwaves101.com/encyclopedias/connector-care)
-
It seems that CH1 on my NanoVNA has not so good VSWR, is it ok?
[attach=1][attach=2]
-
That is also the case - but with a smaller nut to knuckle distance - in the posted video.
But that's a different moment arm than the one shown in the document.
Same principle applies, just different dimensions.
As long as you hold the torque wrench somewhere along the actual handle (i.e., the red part shown here (https://www.fairviewmicrowave.com/sma-fixed-torque-wrench-click-st-sma3-p.aspx), using the model of torque wrench I have here as an example) you will be able to deliver the specified torque or something very close to it. It (should) go without saying that if you grab the wrench just behind the knuckle, you can apply pretty much whatever force you want in whatever direction you want.
Makes sense to me - as long as it's designed for that usage, so that it stays it in the torque range its spec'd for - or at least not far enough out of range to break stuff if you aren't doing critical stuff.
-
Confirmed. Measurement is affected when battery is charging.
When charge LED stops flashing, measurement error disappears.
I tried to measure voltage between GND and VDD on ST-LINK connector.
When powered from the battery: 3.3350 V
When external power connected: 3.3306 V
After some time with ext. power: 3.3325 V (measurement error is still present)
When charge LED stops flashing: 3.3339 V (measurement error disappears)
My NanoVNA creates zig-zags on the display between 295 and 300 MHz when the battery is low or charging. Not a surprise that it's sensitive to supply voltage in that frequency range, as per datasheet the clock chip supposed to operate till 200 MHz...
I heavily suspect that the random lines occasionally appearing is also not just a drawing error but a consequence of this.
As for the torque wrench I don't think that the low frequency range and precision of NanoVNA justifies it (it's more like a waste of money and time for this level), the SMA connector can be tightened without it quite well but NanoVNA is just the perfect tool to check this.
Replacing the MCU is an interesting idea. What would be even more interesting if clock chip could be replaced with something that allows operation up till 2-3 GHz range (means mixer replacement as well...). Probably the resistor bridge would not cut it till 6 GHz but still if clocking (test signal generation) could be improved it would be a significant improvement (sure, not in this price range as significantly more expensive chips would need to be used...).
Note: When there is integer relationship between the clock source of the clock chip and its output signal is quite OK, but when I set 800MHz it's not so clean anymore (it uses 3rd harmonic, so in reality chip is set to 266.6...MHz or so)..
-
My NanoVNA creates zig-zags on the display between 295 and 300 MHz when the battery is low or charging.
Is your NanoVNA has these zig-zag spikes at 300 MHz with low battery only? ???
My one always have these 300 MHz spikes... Sometimes it higher, sometimes lower, but it always here...
Here is CH0 and CH1 both terminated with 50 Ohm:
[attach=2]
What is your CH1 SWR at 900 MHz? (just connect CH0 to CH1 with good cable to measure it)
My CH1 SWR is 1.31. Measured with 15 cm RG405:
[attach=1]
Cable delay is 1550 ps. I entered it into ELECTRICAL DELAY, and it shows Rs = 41 Ohm at 900 Mhz...
-
joeqsmith,i Sent You a PVT Message....
TANKYOU VERY MUCH
-
As long as you hold the torque wrench somewhere along the actual handle (i.e., the red part shown here (https://www.fairviewmicrowave.com/sma-fixed-torque-wrench-click-st-sma3-p.aspx), using the model of torque wrench I have here as an example) you will be able to deliver the specified torque or something very close to it. It (should) go without saying that if you grab the wrench just behind the knuckle, you can apply pretty much whatever force you want in whatever direction you want.
Makes sense to me - as long as it's designed for that usage, so that it stays it in the torque range its spec'd for - or at least not far enough out of range to break stuff if you aren't doing critical stuff.
Which if you read my response, it pretty much what I had stated. Looking at the error of the torque wrench shown, using a knife blade and going from one end of the handle to the other, the variance is about 1" lb. Still well within spec no matter where you hold it.
Obviously the torque is dependent on the position but my question is how much do different wrenches vary. I assume many of you have them and would know or at least be able to measure them within some degree of accuracy.
-
joeqsmith,i Sent You a PVT Message....
TANKYOU VERY MUCH
I appreciate your enthusiasm for the Nano and your wanting to try other software. As you were told by _Wim_ and I have stated a few times in this thread, mentioned in my videos and answered numerous time in the comments, the answer is the same.
Your persisting to SPAM my inbox after clearlying being told no, is part of the reason I won't release it. I just don't have the time to support it.
***
As _Wim_ mentioned, you should look at some of the other software being offered here. It seems that they are off to a very good start and could use some encouragement.
-
:'( :'( :'(
joeqsmith, I apologize, for what you call "SPAM", but I didn't get any of your Rejection messages, and as I wrote you, I don't read English well and I can't program ... I just needed your software, to work and I was even willing to give you a donation.
I can't use a Translator to convert 10 pages of trhead ...
Okay it does nothing, I will use the original software. :-\ :-\ :-\
Thanks anyway, even if it didn't cost you anything send it to me ...
-
It seems that CH1 on my NanoVNA has not so good VSWR, is it ok?
(Attachment Link) (Attachment Link)
I think this is caused by the input impedance of channel 2 in your method, not by channel 1. If you connect your calibration load to ch1 (and preferably calibrate the NanoVNA with a smaller bandtwidt, for example 800M to 900M) you can achieve a VSWR or 1.02 (S11 of -40dB) for 800M<->900M, and even better for lower frequencies.
-
My CH1 SWR is 1.31. Measured with 15 cm RG405:
It's roughly the same (1.33) here.
For the price though there is still nothing to complain.
_Wim_
NanoVNA has CH0 and CH1 and what is meant is what you describe (just naming is different).
-
_Wim_
NanoVNA has CH0 and CH1 and what is meant is what you describe (just naming is different).
|O
Mine is indeed also simular than. When calibrated with a 100Mhz span it drops a little to 1.28.
-
As long as you hold the torque wrench somewhere along the actual handle (i.e., the red part shown here (https://www.fairviewmicrowave.com/sma-fixed-torque-wrench-click-st-sma3-p.aspx), using the model of torque wrench I have here as an example) you will be able to deliver the specified torque or something very close to it. It (should) go without saying that if you grab the wrench just behind the knuckle, you can apply pretty much whatever force you want in whatever direction you want.
Makes sense to me - as long as it's designed for that usage, so that it stays it in the torque range its spec'd for - or at least not far enough out of range to break stuff if you aren't doing critical stuff.
Which if you read my response, it pretty much what I had stated. Looking at the error of the torque wrench shown, using a knife blade and going from one end of the handle to the other, the variance is about 1" lb. Still well within spec no matter where you hold it.
Obviously the torque is dependent on the position but my question is how much do different wrenches vary. I assume many of you have them and would know or at least be able to measure them within some degree of accuracy.
Cool, I was responding to KE5FX, no sorry I didn't see your response or question at the time.
Another option is to work that effect out just from dimensions of the wrenches which might be easier info to get from people.
-
joeqsmith, it seems that you have professional vector analyzer and other equipment.
Could you please measure CH1 input impedance of NanoVNA?
Two sweeps for 1-300 MHz and for 1 MHz - 1.5 GHz will be nice to see how it can be used with direct mode (1-300 MHz) and with extended mode (1-1.5 GHz).
It seems that CH0 has pretty good performance, but CH1 going to SWR=1.32 at 900 MHz which may affect measurements. What is your thoughts about it?
-
:'( :'( :'(
joeqsmith, I apologize, for what you call "SPAM", but I didn't get any of your Rejection messages, and as I wrote you, I don't read English well and I can't program ... I just needed your software, to work and I was even willing to give you a donation.
I can't use a Translator to convert 10 pages of trhead ...
Okay it does nothing, I will use the original software. :-\ :-\ :-\
Thanks anyway, even if it didn't cost you anything send it to me ...
I just assumed from your acknowledgment to _Wim_ that you understood what they wrote and did not require any further response from me.
Hello Flynt, for the moment ;) this software is not available for download. It was developed by joeqsmith to show what is possible with the Nanovna, to make some educational youtube video's about the NanoVNA and to inspire others to make apps of their own (which has worked already, thanks to 5q5r)
I do not ask for donations, do not enable ads, have no Pateron's, nor do I beg people to join my channel.
Suggesting that my making the software available to you wouldn't cost me anything is a naive view. Considering that you required a personal response from me even though someone else had provided you with an answer, I doubt that by handing you the software that your questions would subside. Even if I made it free, with no support implied, I suspect you and others would request support. I would hope you are not suggesting that my time is worth nothing.
Again, I suggest you support the people who are willing to invest their time to to create an open source platform.
-
joeqsmith, it seems that you have professional vector analyzer and other equipment.
Could you please measure CH1 input impedance of NanoVNA?
Two sweeps for 1-300 MHz and for 1 MHz - 1.5 GHz will be nice to see how it can be used with direct mode (1-300 MHz) and with extended mode (1-1.5 GHz).
It seems that CH0 has pretty good performance, but CH1 going to SWR=1.32 at 900 MHz which may affect measurements. What is your thoughts about it?
I suspect that you are correct that the match may not be all the great. I mentioned that in the last video where I show that T-check. But it's just $50 and I can't really bitch about it at that price.
Sadly, I just don't use a VNA enough in my electronics hobby to justify getting a newer system. Now if Keysight, RS or Copper Mountain wanted to donate a new 2-port 6GHz system, I may have to change my stance on donations. :-DD Imagine the fun one could have with a modern higher end VNA..
-
joeqsmith, it seems that you have professional vector analyzer and other equipment.
Could you please measure CH1 input impedance of NanoVNA?
Two sweeps for 1-300 MHz and for 1 MHz - 1.5 GHz will be nice to see how it can be used with direct mode (1-300 MHz) and with extended mode (1-1.5 GHz).
It seems that CH0 has pretty good performance, but CH1 going to SWR=1.32 at 900 MHz which may affect measurements. What is your thoughts about it?
This app note has good info on the effect that Port 2 (Port 1 on the Nano) load match has on measurements. It can usually be mitigated with a good attenuator, at the cost of some dynamic range.
http://anlage.umd.edu/Microwave%20Measurements%20for%20Personal%20Web%20Site/5965-7709E.pdf (http://anlage.umd.edu/Microwave%20Measurements%20for%20Personal%20Web%20Site/5965-7709E.pdf)
-
Just tested, with 10 dB attenuator it is usable up to 200 MHz (SWR=1.01). With 20 dB attenuator up to 700 MHz (SWR=1.03).
But it reduces dynamic range... Is it possible to fix CH1 input to get swr=1.00 up to 300 MHz?
Currently it drops down to 45 Ohm at 300 MHz.
-
I had mentioned in the last video I made about the limited resolution (distance) when making TDR measurements. I talked a bit about how you may be able improve it but with it being a $50 unit, I don't see much of a point. Well except for the pure fun of it.....
So I talked it over with a friend of mine and we had a good laugh about the whole project. He offered one idea that should help improve the setup but it's all a guess if the Nano can actually be used this way and get any useful information from it. Of course, cost will need to be ignored which is part of the humor....
First baby step, modify my software to support the range extender. It may not look like anything is going on in the attached plot, but what you see the Nano using Channel 1 for S11. That's not a misprint. Granted, it's only 100MHz. :-DD Like I said, baby step.
***
Should mention, yes, it is indeed a 100 ohm resistor.
A distance resolution of 1 mm requires timing to 5 ps, 10 ps for a reflection. At 900 MHz 1 degree is 3 ps. So if the nanoVNA reads phase to even 10 bits of accuracy, 1 mm resolution for a broadband reflection is not a problem. Just do a linear fit to the phase in the frequency domain.
It gets more complicated if there are multiple reflections of different bandwidths, however, a sparse L1 aka basis pursuit can reliably solve that. Though it might take a fairly powerful desktop to do that in less than several minutes.
I'm trying to squeeze TDR into the nanoVNA MCU with a swap out for an STM32F303CCT6 part with 48 KB of RAM and 256 KB of flash. That's a completely different can of worms.
BTW What do you mean by "range extender" is this frequency or time?
Reg
-
Just tested, with 10 dB attenuator it is usable up to 200 MHz (SWR=1.01). With 20 dB attenuator up to 700 MHz (SWR=1.03).
But it reduces dynamic range... Is it possible to fix CH1 input to get swr=1.00 up to 300 MHz?
Currently it drops down to 45 Ohm at 300 MHz.
When you say usable, I am not sure if you are talking about the effect of that SWR on the error corrected measurement, or just the SWR of the port itself.
SWR of 1.03 is 30dB RL, which is outstandingly good and will have a very minor effect. In the doc I posted they are talking about improving 18dB RL for the VNA port - which is about 1.3 SWR. And remember that was an HP document, so a high value instrument, and we are talking about a $50 device here.
The OP posted earlier about his 'range extender' and showed an S11 measurement on port 1 and he has posted before about a transfer switch.
I don't know exactly what he has there, but it is pretty interesting. If it still permits capturing S11 on port 0, then a full 2 port cal is possible which does correct for load match.
There may be other mathematical approaches, such as 1 port 2 path, which might be able to cancel out some or all of that error, I don't know for sure if they do.
Here is an implementation, which is part of the lib I have been using. It does say '...can be fully corrected...'
https://scikit-rf.readthedocs.io/en/latest/api/calibration/generated/skrf.calibration.calibration.TwoPortOnePath.html#skrf.calibration.calibration.TwoPortOnePath
-
Is it possible to calculate chart like this from S1P data (magnitude and phase per frequency)?
[attachimg=1]
What is the math behind it?
-
When you say usable, I am not sure if you are talking about the effect of that SWR on the error corrected measurement, or just the SWR of the port itself.
SWR of 1.03 is 30dB RL, which is outstandingly good and will have a very minor effect. In the doc I posted they are talking about improving 18dB RL for the VNA port - which is about 1.3 SWR. And remember that was an HP document, so a high value instrument, and we are talking about a $50 device here.
I'm not sure what SWR for VNA input port is acceptable. But as I know it may affect filter response measurement, because filter is intended for 50 Ohm termination.
My primary interest in the frequency range 1...500 MHz. My NanoVNA CH1 (second port for S21) has RL = 23 dB at 500 MHz (SWR = 1.15). Is it acceptable for filters measurement? What error level it may cause? (for filter measurement S11, S21)
-
Is it possible to calculate chart like this from S1P data (magnitude and phase per frequency)?
(Attachment Link)
What is the math behind it?
The maths is an inverse FFT.
rhb is a guru in that subject. I'm not, I just use a library. That makes it a one line operation. Example here:
https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20TDR.ipynb
One line at a time:
#Load a directory full of s1p files
duts = rf.read_all('data/measured/')
#Select one of them
s11 = duts['nano calibrated attenuator attempt 2']
#Convert from freq domain to time domain
s11_gated = s11.time_gate(center=0, span=100)
# Plot frequency and time-domain
figure(figsize=(8,4))
subplot(121)
s11.plot_s_db()
s11_gated.plot_s_db()
title('Frequency Domain')
subplot(122)
s11.plot_s_db_time()
s11_gated.plot_s_db_time()
title('Time Domain')
tight_layout()
When you say usable, I am not sure if you are talking about the effect of that SWR on the error corrected measurement, or just the SWR of the port itself.
SWR of 1.03 is 30dB RL, which is outstandingly good and will have a very minor effect. In the doc I posted they are talking about improving 18dB RL for the VNA port - which is about 1.3 SWR. And remember that was an HP document, so a high value instrument, and we are talking about a $50 device here.
I'm not sure what SWR for VNA input port is acceptable. But as I know it may affect filter response measurement, because filter is intended for 50 Ohm termination.
My primary interest in the frequency range 1...500 MHz. My NanoVNA CH1 (second port for S21) has RL = 23 dB at 500 MHz (SWR = 1.15). Is it acceptable for filters measurement? What error level it may cause? (for filter measurement S11, S21)
See the app note I attached earlier, it shows examples of measuring a filter, and shows roughly what your uncertainties will be. Your CH1 RL is a bit better than what they use in their example, but you are in the ball park.
I am not 100% sure on this, but I think that the built in NanoVNA transmission calibration is just a normalisation - i.e 'Response Calibration'.
Using a PC and the library I used in the examples above, you could improve that by doing an Enhanced Response Cal. That corrects for source match error (which is mismatch on Port 0). Mismatch on Port 1 remains uncorrected.
Then you could improve on that further using an attenuator to improve the Port 1 load match, but you sacrifice a bit of dynamic range as you know.
To improve further on that you need a two port calibration.
-
I had mentioned in the last video I made about the limited resolution (distance) when making TDR measurements. I talked a bit about how you may be able improve it but with it being a $50 unit, I don't see much of a point. Well except for the pure fun of it.....
So I talked it over with a friend of mine and we had a good laugh about the whole project. He offered one idea that should help improve the setup but it's all a guess if the Nano can actually be used this way and get any useful information from it. Of course, cost will need to be ignored which is part of the humor....
First baby step, modify my software to support the range extender. It may not look like anything is going on in the attached plot, but what you see the Nano using Channel 1 for S11. That's not a misprint. Granted, it's only 100MHz. :-DD Like I said, baby step.
***
Should mention, yes, it is indeed a 100 ohm resistor.
A distance resolution of 1 mm requires timing to 5 ps, 10 ps for a reflection. At 900 MHz 1 degree is 3 ps. So if the nanoVNA reads phase to even 10 bits of accuracy, 1 mm resolution for a broadband reflection is not a problem. Just do a linear fit to the phase in the frequency domain.
It gets more complicated if there are multiple reflections of different bandwidths, however, a sparse L1 aka basis pursuit can reliably solve that. Though it might take a fairly powerful desktop to do that in less than several minutes.
I'm trying to squeeze TDR into the nanoVNA MCU with a swap out for an STM32F303CCT6 part with 48 KB of RAM and 256 KB of flash. That's a completely different can of worms.
BTW What do you mean by "range extender" is this frequency or time?
Reg
Frequency (with a lot of issues). It would be for a very narrow band experiment if I do anything with it.
Starting on page 29:
http://literature.cdn.keysight.com/litweb/pdf/5989-5723EN.pdf (http://literature.cdn.keysight.com/litweb/pdf/5989-5723EN.pdf)
-
That's the Raleigh criterion for separating two events. I was referring to identifying the location of a discontinuity. Very different problems.
I've viewed the TDR aspect as "Where is the bad spot in my cable?" and "Where is the impedance discontinuity in my PCB trace?"
Once you want to look at the reflection from the the SMA side of an SMA to N connector separately from the N side, you have to have 20 GHz or more BW. And even at 20 GHz in the time domain, it's not easy. I've been doing a lot of it testing RF connectors using a Tek 11801 & SD-24.
However, I'm fairly certain that, if you have a well defined problem such as the mismatch at either end of an SMA to N adapter, you can solve the problem of the timing to better than the Rayleigh criterion using basis pursuit. However, doing this would require mastering the ugliest and most complex math I ever came across in my life. It's simple to do in practice, but the logic of how and why it works is painful. David Donoho has a proof of a single theorem which takes 15 pages!
I'd like to note that I have serious technical issues with that application note. It poses a lot of "problems" which are trivial to solve, but presented as proprietary to HPAK despite being sufficiently well known to be basic DSP 101 examples and homework. I've not read all of it, but much of it is in Dunsmore's book which I *have* studied very closely. At present I don't know if the issue is terminology and notational conventions, substantive errors or marketing FUD. While the reflection seismology community has been doing DSP for 20 years longer than the EE community, the EE community chose not use the mathematics community lexicon adopted in geophysics. Same words, but *very* different meanings. Having worked in several seismic processing shops, my experience is that it takes about 6 months to map the words people use at lunch to the correct equations. If it's that difficult in geophysics, going between that and electronics engineering is *much* worse.
In sum, this quickly turns into a major communications problem. I've seen a lot of arguments which amounted to nothing more than different meanings for the same words.
Have Fun!
Reg
-
Have Fun!
With no fear of doing something so bad that I would need to mortgage the house to recover, it opens the doors for a major fun fest.
Playing with the Nano now, up converting to 5GHz and back down. Oddly enough, it seems to sort of do something. Using the home made standards to run the SOL, then attaching the 100ohm load.
I can't see it being useful in anyway outside of the fun factor.
Have fun with your soldering and coding. It sounds like a fun project as well.
-
I'm not sure what SWR for VNA input port is acceptable. But as I know it may affect filter response measurement, because filter is intended for 50 Ohm termination.
My primary interest in the frequency range 1...500 MHz. My NanoVNA CH1 (second port for S21) has RL = 23 dB at 500 MHz (SWR = 1.15). Is it acceptable for filters measurement? What error level it may cause? (for filter measurement S11, S21)
Google for "mismatch uncertainty".
-
The maths is an inverse FFT.
rhb is a guru in that subject. I'm not, I just use a library. That makes it a one line operation. Example here:
https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20TDR.ipynb
One line at a time:
#Convert from freq domain to time domain
s11_gated = s11.time_gate(center=0, span=100)
Is this python? Unfortunately I don't familiar with this language. :(
Could you please give me the link to the source of that s11.time_gate() function?
-
The maths is an inverse FFT.
rhb is a guru in that subject. I'm not, I just use a library. That makes it a one line operation. Example here:
https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20TDR.ipynb
One line at a time:
#Convert from freq domain to time domain
s11_gated = s11.time_gate(center=0, span=100)
Is this python? Unfortunately I don't familiar with this language. :(
Could you please give me the link to the source of that s11.time_gate() function?
I don't know much python either. Its pretty simple to get started, and the few lines of code you see on my repository is all that you need.
That function is built into the scikit-rf package, so its free and the source is on github if you really want to go there.
Just install the latest Python (3.7) and tick the box to add to your PATH. That will also install pip.
Then install Jupyter notebook, which is a nice GUI and just makes it easy.
https://jupyter.readthedocs.io/en/latest/install.html
I think it is simpler to use pip instead of conda as it is one less thing to wrangle.
So something like this should get you started:
pip3 install --upgrade pip
pip3 install jupyter
pip3 install scikit-rf
# Now start it up, this will run it and display it in a browser.
jupyter notebook
There are other options, e.g. Matlab, or Octave or Labview, but this is as flexible, or more flexible and not really any more difficult.
-
Google for "mismatch uncertainty".
I found this article: https://www.microwavejournal.com/articles/6166-calculating-mismatch-uncertainty (https://www.microwavejournal.com/articles/6166-calculating-mismatch-uncertainty)
But I'm not sure... If I understand correctly, mismatch uncertainty depends on VSWR source and VSWR load.
Does it means that when any of these VSWR is 1, then mismatch uncertainty also will be zero?
For exampel:
Source VSWR=1,
Load VSWR=1.32 (this is what NanoVNA CH1 have at 900 MHz).
ρload = 0.1379
ρsource = 0
Does it means that mismatch uncertainty is zero?
-
Google for "mismatch uncertainty".
I found this article: https://www.microwavejournal.com/articles/6166-calculating-mismatch-uncertainty (https://www.microwavejournal.com/articles/6166-calculating-mismatch-uncertainty)
But I'm not sure... If I understand correctly, mismatch uncertainty depends on VSWR source and VSWR load.
Does it means that when any of these VSWR is 1, then mismatch uncertainty also will be zero?
For exampel:
Source VSWR=1,
Load VSWR=1.32 (this is what NanoVNA CH1 have at 900 MHz).
ρload = 0.1379
ρsource = 0
Does it means that mismatch uncertainty is zero?
Mismatch uncertainty can be corrected in a VNA - the exact details depend upon the calibration and that is documented in the AN 1287-3 I referenced.
That is one of the advantages of a Vector Network Analyser as opposed to a Scalar Network Analyser - such as a Spec An + TG + Bridge.
The VNA is able to correct for its own inadequacies. The SNA cannot, and so the SNA's analog performance must be much better to get the same performance.
Hence this device we are talking about - a very cheap VNA - actually has quite respectable performance - particularly if you extract the data to a PC - because of the error corrections which can be applied.
-
:'( :'( :'(
joeqsmith, I apologize, for what you call "SPAM", but I didn't get any of your Rejection messages, and as I wrote you, I don't read English well and I can't program ... I just needed your software, to work and I was even willing to give you a donation.
I can't use a Translator to convert 10 pages of trhead ...
Okay it does nothing, I will use the original software. :-\ :-\ :-\
Thanks anyway, even if it didn't cost you anything send it to me ...
I just assumed from your acknowledgment to _Wim_ that you understood what they wrote and did not require any further response from me.
Hello Flynt, for the moment ;) this software is not available for download. It was developed by joeqsmith to show what is possible with the Nanovna, to make some educational youtube video's about the NanoVNA and to inspire others to make apps of their own (which has worked already, thanks to 5q5r)
I do not ask for donations, do not enable ads, have no Pateron's, nor do I beg people to join my channel.
Suggesting that my making the software available to you wouldn't cost me anything is a naive view. Considering that you required a personal response from me even though someone else had provided you with an answer, I doubt that by handing you the software that your questions would subside. Even if I made it free, with no support implied, I suspect you and others would request support. I would hope you are not suggesting that my time is worth nothing.
Again, I suggest you support the people who are willing to invest their time to to create an open source platform.
Joeqsmith, you didn't understand anything ...
I HAVE NEVER THOUGHT THAT YOUR TIME DOES NOT APPLY, I ONLY REQUEST THE INSTALLER OF A PROGRAM YOU DEVELOPED ...
I think you didn't understand my intentions, and I'm not able to program.
However, not but nothing, the Gentile helped me
Radioman ...
On the other hand, these are the Americans ... We in Italy, among radio amateurs, help each other.
Bye Bye :( :( :(
-
Joeqsmith, you didn't understand anything ...
I HAVE NEVER THOUGHT THAT YOUR TIME DOES NOT APPLY, I ONLY REQUEST THE INSTALLER OF A PROGRAM YOU DEVELOPED ...
I think you didn't understand my intentions, and I'm not able to program.
However, not but nothing, the Gentile helped me
Radioman ...
On the other hand, these are the Americans ... We in Italy, among radio amateurs, help each other.
Bye Bye :( :( :(
I'm glad we finally understand one another. It's too bad that your not getting my work for free upsets you to the point you feel the need to make such ignorant comment about an entire country but it speaks of your character.
You do bring up a valid point that what I have been doing is of no help to you. Others have posted similar comments, which is something I can live with.
Take care.
-
joeqsmith ,
I may have missed it , but do you provide a PAID service .
I have not picked up any computer language / and no programing .
So would be interested in paying for programing .
If I understand normal , similar to this , a one time fee for a program to run the nanoVNA , and then any future service is separate fees , or a package of services & fees ?
Or your not interested in any of the above ;)
I'm a free-market / libertarian type , kinda [ I have not found answers to all questions from the libertarian perspective , but agree with lots ] .
I can not work for free either , picking up electronic repair as [ maybe ] the last trade at 65 disabled from pervious trades construction , auto repair , welding , machining / gun-smithing , and now electronics repair / ham radio , most trades started as hobbies & can not seem to just buy off the shelf ;)
A tool-jones forces me into building , repairing everything I own .
Even if I occasionally buy something new - I have to open it up and look under the hood , more fun .
-
I have no connection with @joeqsmith. I've never even watched his YouTube videos. I just wandered in here because I bought a nanoVNA and have been sucked into a black hole. I have 20+ years of software support experience.
Badgering him like this is completely unreasonable.
If you want the sort of software that @joeqsmith is playing around with, buy a VNWA or learn to program. Tom Baier spends a *lot* of time providing support for his software. You only need to read the VNWA mailing list to see how much work it is. A staggering amount of the traffic on the VNWA list is trying to help people who did not read the manual, do not know anything about using a VNA and often very little about RF. Yes, it is 10x the price, but it's also more capable. However, very little of that is the hardware. It's mostly the cost of the software support.
There are plenty of people working on open source programs for the nanoVNA. As @joeqsmith suggested, give them some money. Or learn to program and help out. Join nanovna-users@groups.io.
In any case, @joeqsmith is not responsible for your lack of ability. He chose to invest his time and money in learning how to do something. Those who are able are not the slaves of those who are not able.
Reg
-
I have no connection with @joeqsmith. I've never even watched his YouTube videos. I just wandered in here because I bought a nanoVNA and have been sucked into a black hole. I have 20+ years of software support experience.
Badgering him like this is completely unreasonable.
If you want the sort of software that @joeqsmith is playing around with, buy a VNWA or learn to program. Tom Baier spends a *lot* of time providing support for his software. You only need to read the VNWA mailing list to see how much work it is. A staggering amount of the traffic on the VNWA list is trying to help people who did not read the manual, do not know anything about using a VNA and often very little about RF. Yes, it is 10x the price, but it's also more capable. However, very little of that is the hardware. It's mostly the cost of the software support.
There are plenty of people working on open source programs for the nanoVNA. As @joeqsmith suggested, give them some money. Or learn to program and help out. Join nanovna-users@groups.io.
In any case, @joeqsmith is not responsible for your lack of ability. He chose to invest his time and money in learning how to do something. Those who are able are not the slaves of those who are not able.
Reg
Well put Reg. :-+
Joe's IP is his to do with as he pleases and if he chooses not to share it, tough titty.
He's developed these skills over many years and presumably his bike console is not shared either so to not give competitors an even footing when Joe races.
Nothing at all wrong with that.
-
I have no connection with @joeqsmith. I've never even watched his YouTube videos. I just wandered in here because I bought a nanoVNA and have been sucked into a black hole. I have 20+ years of software support experience.
Badgering him like this is completely unreasonable.
If you want the sort of software that @joeqsmith is playing around with, buy a VNWA or learn to program. Tom Baier spends a *lot* of time providing support for his software. You only need to read the VNWA mailing list to see how much work it is. A staggering amount of the traffic on the VNWA list is trying to help people who did not read the manual, do not know anything about using a VNA and often very little about RF. Yes, it is 10x the price, but it's also more capable. However, very little of that is the hardware. It's mostly the cost of the software support.
There are plenty of people working on open source programs for the nanoVNA. As @joeqsmith suggested, give them some money. Or learn to program and help out. Join nanovna-users@groups.io.
In any case, @joeqsmith is not responsible for your lack of ability. He chose to invest his time and money in learning how to do something. Those who are able are not the slaves of those who are not able.
Reg
Well put Reg. :-+
Joe's IP is his to do with as he pleases and if he chooses not to share it, tough titty.
He's developed these skills over many years and presumably his bike console is not shared either so to not give competitors an even footing when Joe races.
Nothing at all wrong with that.
Seconded. Motion carried. :clap:
There is a heap of free and/or open software and lots of information for the nano and vna's in general.
All the info is out there now, whereas only a few years ago it was not.
-
Are you saying asking to pay for service is " Badgering " ?
-
Are you saying asking to pay for service is " Badgering " ?
More importantly, its a waste of your time to even try .. lol
:-DD
-
I'm quite in awe of the nanoVNA. @erik on the groups.io list has added an arbitrary scan function that will return a series of samples of arbitrary length and sampling via the console. So a piece of cake to write a simple script to pull data off the nanoVNA, correct it and plot it with gnuplot. Gnuplot will produce publication quality figures, so that's not shabby even if it's not the instant gratification that so many demand today.
A GUI such a @joeqsmith wrote is a *lot* of work. Just designing the window layout takes weeks of work. But reading a bunch of numbers from the serial port and graphing them is not much trouble. If someone is not willing to learn to do that I don't have much sympathy.
The audio codec chip has a unique 96 bit ID. So it would be easy to sell 3rd party software for the nanoVNA which was locked to a particular device. Of course, if your device dies, then so does your software license. And realistically, such SW would cost more than the HW. Is it likely that a $200 software package for a $35 device is a viable commercial venture? I very much doubt it. But once you have sold *one* copy you're stuck with the support problem or a lot of bad mouthing for not working for pennies per hour.
After putting $100K in labor into developing a seismic processing program I abandoned attempting to sell it because it because it quickly became apparent I was going to have to do $10K in free consulting to do an on site demo. No guarantee of a sale and no way to get paid for configuring a Beowulf cluster for the demo in 1999 when not many people knew how.
Personally, I think that the nanoVNA should be pure OSSW/OSHW. If I were to develop the sort of software @joeqsmith has, I'd design HW with more dynamic range once I had the software done. If you do the HW first, you risk it being obsolete before you finish the SW. Over 90% of the software is completely HW agnostic.
Reg
-
I have no connection with @joeqsmith. I've never even watched his YouTube videos. I just wandered in here because I bought a nanoVNA and have been sucked into a black hole. I have 20+ years of software support experience.
Badgering him like this is completely unreasonable.
If you want the sort of software that @joeqsmith is playing around with, buy a VNWA or learn to program. Tom Baier spends a *lot* of time providing support for his software. You only need to read the VNWA mailing list to see how much work it is. A staggering amount of the traffic on the VNWA list is trying to help people who did not read the manual, do not know anything about using a VNA and often very little about RF. Yes, it is 10x the price, but it's also more capable. However, very little of that is the hardware. It's mostly the cost of the software support.
There are plenty of people working on open source programs for the nanoVNA. As @joeqsmith suggested, give them some money. Or learn to program and help out. Join nanovna-users@groups.io.
In any case, @joeqsmith is not responsible for your lack of ability. He chose to invest his time and money in learning how to do something. Those who are able are not the slaves of those who are not able.
Reg
Sorry what is the point of posting about a software but not making it available? I genuinely do not understand, can someone explain.
-
Sorry what is the point of posting about a software but not making it available? I genuinely do not understand, can someone explain.
Have I been following a different thread? I have never done much RF and I did get myself a nanoVNA and I have been finding joeqsmith's posts absolutely brilliant.
The graphics stuff is the glitzy fluff. The principal thing is the nanoVNA is a measurement device that outputs a list of measurements via USB serial interface. joeqsmith has shown us what you can do with the measurements that the nanoVNA is capable of. An incredible series of posts.
You do not even need to build your own graphical program - you can do anything joeqsmith did with fairly simple python scripts and you could output to a csv file or similar. Perhaps then number crunch in a spreadsheet if you want.
-
Just another option for those that might prefer Java to hack on. It is a hack job, but it works on Linux for me. It should also work on Windows, Mac.
https://github.com/tvelliott/jNanoVNA
-
Sorry about the drama.
With a lack of torque wrench data and it being fairly common for me to see suggestions that torquing is not required, I thought I would have some fun. My goal was to see how repeatable I could hand tighten an SMA. As it turns out, I just don't have the knack and was unable to fool the $50 Nano. Well, not at 4.75 to 5.0GHz anyway. :-DD
The first 1200 or so sweeps where I am not moving anything, it seems to be fairly stable.
If you look at the second set of data, this is 2X 1206 resistors, of course the cal was done with the home made standards that use 1206 parts. There are a slew of other problems. So, just to be clear, I am not even remotely suggesting that the data has any meaning or that there is any point to what I am doing beyond my own amusement.
While sorting out some of my junk to put this test together, I came across my old transfer relay I mentioned. I'm fairly certain that this came from the test set for my old HP VNA.
-
There is a good open source VNA GUI here that I will be porting to the NanoVNA (most likely only NanoVNA V2 which will have a more capable command interface): https://github.com/xaxaxa-dev/vna/tree/master/vna_qt
I have also fed back the tip about the STM32F303 and most likely V2 will come with a F303CCT6 by default (most likely a GD32).
EDIT: fix typo
-
joeqsmith ,
I may have missed it , but do you provide a PAID service .
I do not. Anything I offer in the way of videos, test data and other information is for free as my way of giving back to the community and promoting the hobby.
If you were serious about hiring me, in all honestly I would suggest you pick out what ever top of the line Keysight, RS or any other brand you like. Don't hold back. The sky's the limit. In the end you will have a very nice system, and be much further ahead.
-
Just to reiterate, for those who might not have seen it: Myself and others have made a Python program for doing a number of the same things as Joe's software, fully open source and available to use and modify. It's available here: https://github.com/mihtjel/nanovna-saver
There are pre-built releases for Windows - for other platforms, download the code and run it using Python.
All potential contributors are very welcome to contact me directly, and requested features are pushed onto the project TODO list, from which I grab items to work on.
I hope this provides some use for members of the community.
-
if I understand correctly, TDR can be obtained by make IFFT applied to S1P. Is it correct?
It seems that it works, but the most confusing thing here is how to calculate proper time for points. ???
Here is 0.5 meters RG316 with open end, measured with NanoVNA (it's real back and forth delay is about 0.495 ns):
[attach=1]
Here is 10 meters RG316 with open end, measured with NanoVNA (don't know it's real delay, but 98.4 ns looks very close to velocity factor 0.66):
[attach=2]
It shows signal magnitude after IFFT. Don't take attention to ST/ED/BW values on screenshot, these are rudiments from debugging :)
Is it correct way? :phew:
Is it possible to calculate impedance instead of this unknown unit magnitude?
-
Here is more interesting measurement :)
SMA => 0.5 meters RG316 => SMA to PL adaptor => 1 meter LMR195 => PL to BNC adaptor => 1 meter RG58 => BNC to SMA adaptor => OPEN:
Red = magnitude
Green = re
Blue = im
[attach=1]
The same with 50 Ohm load at the end:
[attach=2]
It seems that these Chinese SMA-PL and PL-BNC adapters are crap :D
Any idea on how to convert this magnitude into impedance value?
-
Hi,
Yesterday I had a bit time and started my "VMA NanoVNA Tool".
At this point it does not much and is of little use, except that it allows to export the data to Excel as a *.CSV file.
It may have bugs and does not look nice at all, but you can just run the executable and get your CSV file. No installation, no garbage files and no garbage on the Registry.
The reason I am uploading it here is to get some feedback on this eternal question of mine: "What is wrong with the supplied NanoVNASharp software?"
To me that software looks just fine and implements all graphs (mine does not do it correctly at this moment). The only thing it does not do, is to export data in CSV format for further Excel work. Would adding this feature solve the demand for alternative software (at least for most people)?
I understand that joeqsmith did his software because he did not like the graphics and refresh rate of NanoVNASharp. Plus he is free to do whatever he likes! :)
But what I really would like to understand and I have asked and got no reply (I know, I am dumb): what other functionalities do you guys want/need?
Also, the issue I have in further developing my software is that I simply have not understood VNA measurements: what do you read out of the charts and why and what else you would want to calculate based on the data. I only figured out the tuning of antennas. Reading the posts leaves me with many questions and, shame on me, I have not fully watched/rewatched joeqsmith great videos, due to total lack of time (I have been busy implementing a full error map compensation algorithm to my "VMA Simple Spectrum Analyzer" software).
Regarding the much discussed open source, freeware, shareware, what so ever:
1) If I was to develop my software further up to a level where no doubts you would prefer it over NanoVNASharp, then I would apply the same kind of licensing scheme as I have currently on my "VMA Simple Spectrum Analyzer" software. It will never be open source and not freeware, either. Except these initial versions which really don't add much to what already exists.
2) I don't believe in giving away work for free. Work done for free is, in my opinion and as the name implies, worthless. My work has a value, at least to me.
3) There is a lot of work and time involved in any of these developments. Based on my "VMA Simple Spectrum Analyzer", I can confirm that there are literally hundreds if not thousands of hours spent in development. Note that development is not only time spent typing code, but countless hours thinking on how to solve a particular problem. Add to this the years spent learning how to program, how to use (in this example) spectrum analyzers, development of actually new measurements and functionality. On top of this the money spent in equipment: in order for me to develop a spectrum analyzer software, I have actually purchased different spectrum analyzers (SSA3021X, R&S CMU200, R&S CRTU, HP8594E, HackRF One, ADALM Pluto, SMA, D6, LTDZ, ...)! So, indeed, there is a lot of investment involved, even if this is a non-profit hobby. Other than Flynt said "It would have cost you nothing" - it DID COST A LOT!!! Of course, replicating an executable on a computer does not cost much. But then, why doesn't Microsoft give free copies of their software? THAT would not cost anything, right: just making the software available for download? Or, wait a moment: it would cost them all the ROY and profit! Not being able to recognize the COST of software development is indeed a problem and I fully support joeqsmith's decision.
4) The much discussed software of joeqsmith has a problem (to those asking for it - certainly not for him), by the way: It was developed with the HOME version of LabVIEW. This version, while affordable for hobby use, does explicitly not allow to use the resulting applications for any commercial use. Independently if joeqsmith is worried about this or not: if it was me, I would not make the software public, for the following reasons:
a) I could not prevent any organisation to download and use the software for commercial purposes, thus not complying with the LabVIEW terms. I *think* it would not be a problem for me, but anyhow, why risk something when there is no personal gain at all?
b) I could not sell or accept donations for the software, as this is against the LabVIEW terms. It means that I would have to give out the software for free.
c) This would mean that I would get no return for my work, but instead, Chinese sellers of cloned NanoVNA would include my software (without even asking) and make profit, while I would be left as the dummy handling all support issues - for free.
Kind regards,
Vitor
-
Here is an example CSV file, generated with my software.
Regards,
Vitor
-
Here two pictures:
One of the software and one of Excel showing the graphs (not formatted, just a quick test).
Vitor
-
Bicurico, S1P file already compatible with Excel. Just copy-paste. :)
-
Hi,
....
The reason I am uploading it here is to get some feedback on this eternal question of mine: "What is wrong with the supplied NanoVNASharp software?"
To me that software looks just fine and implements all graphs (mine does not do it correctly at this moment). The only thing it does not do, is to export data in CSV format for further Excel work. Would adding this feature solve the demand for alternative software (at least for most people)?
I understand that joeqsmith did his software because he did not like the graphics and refresh rate of NanoVNASharp. Plus he is free to do whatever he likes! :)
But what I really would like to understand and I have asked and got no reply (I know, I am dumb): what other functionalities do you guys want/need?
My only problem with the Sharp software was what I had shown with the cursors being unusable. This was really the catalyst for where I am now.
While my software has many basic features that you will find on most VNAs, these are a few that my current software supports that you may not find with Sharp:
Support control of external bias power supply
Support for an external transfer relay
Full 2-port calibration
Automatic T-check
Automatically collect all four S-parameters
Create full 2-port Touchstone files
Segmented sweeps (both log and linear are supported)
Record data for post processing over extended periods and there is some built-in post processing capability (3-D viewing, histograms, scatter....)
Supports external mixers and directional couplers using CH1 for S11
Basic TDR measurements (time, distance, impedance, Beatty standard....)
I would like to point out that member RHB's posts did not fall on deaf ears. It's an interesting topic.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2668785/#msg2668785 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2668785/#msg2668785)
...
4) The much discussed software of joeqsmith has a problem (to those asking for it - certainly not for him), by the way: It was developed with the HOME version of LabVIEW. This version, while affordable for hobby use, does explicitly not allow to use the resulting applications for any commercial use. Independently if joeqsmith is worried about this or not: if it was me, I would not make the software public, for the following reasons:
...
Kind regards,
Vitor
You had asked about this before:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2599500/#msg2599500 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2599500/#msg2599500)
I did not develop my software with the Home edition as you have stated. If you look at screen shots or videos I have posted, the lack of a watermark should have been the tell tail. There is nothing from a legal aspect that would prevent me from providing the software for profit as again, I have a professional license. The software will indeed run on the Home edition. It could be built into an EXE with an installer like any other application using the Home edition but using this for profit would be a licensing problem as you suggest.
A pro license doesn't cost too much. Somewhere around $3000. If I were planing to use it for profit, I would just sort out the license costs as part of the sale price. I wouldn't try and sell 3001 copies at $1.00 USD to make $1 in profit. :-DD Hope this clears things up.
-
@joeqsmith: Sorry, I thought you were using the HOME version.
Anyway, I guess my thoughts still apply regarding the development of such software (or software to support other devices) using the HOME version of LabVIEW, which was discussed in a different thread.
But to stay on topic: I will now continue to monitor this thread and see if I can learn something about VNA measurements and see if this motivates me to continue developing the software.
@radiolistener: Thanks! It did not occur to me to verify that S1P files are actually just CSV files...
Regards,
Vitor
-
@joeqsmith: Sorry, I thought you were using the HOME version.
I did buy the $50 Home edition and am using it but not to develop the code for the Nano. At $50, with the application builder it was a very good deal for anyone wanting to learn the tools or in my case, hobbyist looking for a low cost upgrade. Sure, it's not designed to be a cheap tool for people to profit from but they do offer licenses for that. I wonder just how much they have invested in that tool. It's really advanced over the years.
-
FYI to anyone working on alternative software for the NanoVNA: it's a good idea to abstract out the hardware interfacing part of your code and separate it from your UI code because the command interface is going to be completely reworked in V2. It will be a more simple low level (and binary rather than text) protocol to improve performance and sweep rate. The other thing I know about V2 is it will cover at least 1 to 2500 MHz (without harmonic tricks). V1 is very noisy above 300MHz because of the use of the third harmonic and the SA612 mixer which both mean a very weak signal.
-
What is the confidence level of this information?
Any expected date?
Actually harmonic usage is not that a bad idea, in fact I've checked with SA till 1.5 GHz and maybe even that could be used (at least for S11).
Mixer is definitely limiting (500 MHz by the spec if I remember correctly).
Also due to overdrive of the clock chip stability around 300 MHz is not the best, low battery is one issue but I could provoke it also with hair dryer (so summer high temperature can be also an issue; the 800 MHz code version is not there by accident...).
A more efficient data transfer is definitely a good idea even if it breaks compatibility with other devices (not an issue for me and probably for many but I heavily suspect that joeqsmith has not developed his SW only because of NanoVNA but probably same SW is used with other devices). A good compromise could be that the VNA could be forced back to the slower but more compatible mode but by default it could use a more efficient one.
-
It will be a more simple low level (and binary rather than text) protocol to improve performance and sweep rate. The other thing I know about V2 is it will cover at least 1 to 2500 MHz (without harmonic tricks).
Very nice!! I was very surprised to see them sending ASCII. 2.4GHz without the harmonics would be a very welcome addition as well. Currently, I limit the sweep to 300MHz while playing around with mixing the signals.
A more efficient data transfer is definitely a good idea even if it breaks compatibility with other devices (not an issue for me and probably for many but I heavily suspect that joeqsmith has not developed his SW only because of NanoVNA but probably same SW is used with other devices).
I started out thinking I could port the code I wrote for my old HP but there were two problems. First, I wrote the program many years ago and have learned better techniques over the years. The other problem was the data format. That HP has clear plastic overlays that attach to the CRT with the various scales, like polar and smith. You would mark on these with your grease pencil with the data you collect (primitive storage). The data had to be translated through three different systems. It was a real nightmare. I did like the look and feel of the software and decided to follow that same sort of scheme. I reused my graphics and the techniques I came up with for plotting the data but that's about it. One day I would like to replace the old HP with something less than 20 years old :-DD
https://www.amazon.com/COLOR-MARKERS-PEEL-OFF-GREASE-PENCIL/dp/B00XJ1FRRI?ref_=fsclp_pl_dp_7 (https://www.amazon.com/COLOR-MARKERS-PEEL-OFF-GREASE-PENCIL/dp/B00XJ1FRRI?ref_=fsclp_pl_dp_7)
Pictures of the 50 ohm home made standard with mixers drifting a bit. Also shown is a 3.4GHz low pass, both compliments of the $50 Nano. My confidence is about at that $50 level... Maybe lower.
****
Playing with the scatter plot, 3.4GHz LP filter....
https://www.youtube.com/watch?v=F8bUZMEElyk&feature=youtu.be (https://www.youtube.com/watch?v=F8bUZMEElyk&feature=youtu.be)
-
if I understand correctly, TDR can be obtained by make IFFT applied to S1P. Is it correct?
It seems that it works, but the most confusing thing here is how to calculate proper time for points. ???
Here is 0.5 meters RG316 with open end, measured with NanoVNA (it's real back and forth delay is about 0.495 ns):
(Attachment Link)
Here is 10 meters RG316 with open end, measured with NanoVNA (don't know it's real delay, but 98.4 ns looks very close to velocity factor 0.66):
(Attachment Link)
It shows signal magnitude after IFFT. Don't take attention to ST/ED/BW values on screenshot, these are rudiments from debugging :)
Is it correct way? :phew:
Is it possible to calculate impedance instead of this unknown unit magnitude?
The frequency spacing determines how long the time domain trace is. The Nyquist frequency determines the sampling. If you sweep to 900 MHz at 1 MHz spacing you have data for 1 microsecond. If you pad the end of the frequency series to raise Nyquist to 2 GHz you will have 250 ps sampling.
Doing an FFT from time to frequency, padding with zeros and inverse transforming is the standard way to resample data to finer sampling rates. There are other ways of doing it, but the FFT is the fastest.
I wrote an arbitrary resampling routine which would resample any sample rate to any other sample rate by FFT around 20 years ago. You have to pad the series so that m*dtT1 = n*dT2. If you don't you will get a phase error near the end. That cost me 2 weeks of misery to figure out. It's clearly stated, "The DFT is defined on the semi-closed interval from [-Pi:Pi)." But it's easy to overlook that little detail.
I've presented some time domain connector testing here:
https://www.eevblog.com/forum/rf-microwave/testing-rf-connectors-and-cables/msg2640531/#msg2640531 (https://www.eevblog.com/forum/rf-microwave/testing-rf-connectors-and-cables/msg2640531/#msg2640531)
using a Tek 11801 and 20 GHz SD-24 TDR head.
Chinese SMA and N connectors are OK to about 1 GHz. BNC males are often completely useless. It's really a function of the tolerances on the make collar.
Have Fun!
Reg
-
Hi,
I have the following question, which is probably obvious for you all, but not for me:
1) Port S11: Is it correct to assume that this port internally combines a TG, RF IN, DUT with a SWR bridge?
2) Port S21: Is it correct to assume that this port internally acts just as a TG?
3) Both TG and RF IN are synchronized, allowing for phase measurements, as opposed to SWR measurements carried out with a spectrum analyzer and SWR bridge, where no phase information is available?
If I am am measuring with S21, where I connect S21->DUT->S11, will the device internally "switch off" the SWR bridge, which would (in my opinion) no longer be needed?
If so, what would happen if I configure a S21 measurement, but then only connect DUT->S11, without using S21 at all? Wouldn't the result be similar to a regular spectrum analyzer?
Thanks,
Vitor
PS: Am I correct to assume that UK English writes "spectrum analySer" and USA English writes "spectrum analyZer"?
-
Hi,
I have the following question, which is probably obvious for you all, but not for me:
1) Port S11: Is it correct to assume that this port internally combines a TG, RF IN, DUT with a SWR bridge?
2) Port S21: Is it correct to assume that this port internally acts just as a TG?
3) Both TG and RF IN are synchronized, allowing for phase measurements, as opposed to SWR measurements carried out with a spectrum analyzer and SWR bridge, where no phase information is available?
If I am am measuring with S21, where I connect S21->DUT->S11, will the device internally "switch off" the SWR bridge, which would (in my opinion) no longer be needed?
If so, what would happen if I configure a S21 measurement, but then only connect DUT->S11, without using S21 at all? Wouldn't the result be similar to a regular spectrum analyzer?
Thanks,
Vitor
PS: Am I correct to assume that UK English writes "spectrum analySer" and USA English writes "spectrum analyZer"?
I have always written Z (unless I would make a mistake, which I often do) All of my test equipment use Z on their markings.
Yes, channel 0 has two ADCs for the reference and return (S11) while channel 1 has one ADC for the thru (S21). Phase relative to the reference is available from both channels.
This gets a bit odd when you consider using channel 1 for S11 while up and down converting the signal from channel 0. While I am mixing it with a signal that is asynchronous to the reference, once it it down converted everything is back to normal. The calibration handles the phase errors.
There is no switching off. The signals are hardwired. It's up to you to decide what to do with the data. You can pull just the channel 0 or the channel 1 data. For example, when I collect S11, there is no reason to read channel 1 and there is certainly no reason to read the frequency. This is why my software runs so much faster as the Sharp software pulls everything down. (no, not at 9600 BAUD. I thought I had drove the final spike in that coffin).
Your last question is a bit tricky. I understand what you are asking and the basic answer is yes!!! If I connect my RF generator to channel 1, set the analyzer to read S21, with nothing on channel 0, you can see this sort of spectrum analyzer result in the attached graph. Everything is asynchronous so the phase is nothing but noise but you can clearly see the magnitude peak at the frequency the RF generator is set to which in this case is 20MHz.
But there's a catch which I talked about in that very first video I made. You only have 101 samples to work with. Say you have an RF generator with VERY low phase noise set to CW. Would you be able to see it using a wide band sweep? Most likely not. You will need to know what you are looking for and zoom in around that area.
Think about it, what's 900MHz / 101. Try looking a 7.968MHz oscillator with that.
While you could calibrate out the errors in amplitude, I doubt you would be happy with the performance. The graph shows what happens when I use a 20MHz center frequency and 100KHz span. Someone may look at that and say, that Joe Smith has one really poor excuse for an RF generator. Of course, attaching it to something other than a $50 instrument tells a whole different story.
-
The frequency spacing determines how long the time domain trace is. The Nyquist frequency determines the sampling. If you sweep to 900 MHz at 1 MHz spacing you have data for 1 microsecond. If you pad the end of the frequency series to raise Nyquist to 2 GHz you will have 250 ps sampling.
So, the time interval after IFFT is from 0 to 1/[frequency step] is it correct?
I'm looking at scikit-rf library (https://github.com/scikit-rf/scikit-rf) for python, and there is also interesting function delay(d, unit,...) in network.py [line 2514] (https://github.com/scikit-rf/scikit-rf/blob/master/skrf/network.py):
def delay(self, d, unit='deg', port=0, media=None,**kw):
'''
Add phase delay to a given port.
This will cascade a matched line of length `d/2` from a given `media`
in front of `port`. If `media==None`, then freespace is used.
Parameters
----------
d : number
the length of transmissin line (see unit argument)
unit : ['deg','rad','m','cm','um','in','mil','s','us','ns','ps']
the units of d. See :func:`Media.to_meters`, for details
port : int
port to add delay to.
media: skrf.media.Media
media object to use for generating delay. If None, this will
default to freespace.
'''
if d ==0:
return self
d=d/2.
if self.nports >2:
raise NotImplementedError('only implemented for 1 and 2 ports')
if media is None:
from .media import Freespace
media = Freespace(frequency=self.frequency,z0=self.z0[:,port])
l =media.line(d=d, unit=unit,**kw)
return l**self
But I don't understand python syntax well, so I cannot understand what happens here? Especially at these 3 lines:
media = Freespace(frequency=self.frequency,z0=self.z0[:,port])
l =media.line(d=d, unit=unit,**kw)
return l**self
If I understand correctly, "l =media.line(..." represents impedance transformation of transmission line. And it someway applied to S11 parameters. And result represents S11 parameters at the end of transmission line. Is it correct?
What means "**" operator in python? According to google, this is power operator (2^3=8 equals to 2**3=8 in python), but the second argument is S11 matrix... What means power operator for matrix? ???
Tried to google such operation (S11 matrix correction for specific electronic delay in transmission line), but didn't find anything... Can someone suggest some literature, where such operation for S11 matrix is explained?
-
There are some quite good docs.
https://scikit-rf.readthedocs.io/en/latest/tutorials/Introduction.html
"Element-wise mathematical operations on the s-parameters are accessible through overloaded operators."
"Cascading and de-embeding 2-port Networks can also be done though operators. Cascading is done through the power operator, **."
-
hendorog, thanks. But what it means still is not clean for me. Needs reverse engineering of skrf source code, because python syntax very tricky. For example, it is not clean where IF statement ends... Also, algorithms are smeared through different classes and overloaded operators and it's hard to understand what is going on here with no need to diving into the rest of the code :)
Any literature about math which is used under the hood in skrf?
-
joeqsmith - May I abuse your patience and ask:
When using the DATA command I always get X and Y values. Are you doing it differently?
Yes, the frequency list is not necessary - one can compute it without having to download it. It is just (Fend-Fstart)/samples*step
What does X and Y really represent. This is the toughest question and possibly the most annoying to you. Sorry - I am still a noob in terms of VNA.
Regarding the low sample rate of just 101 samples per sweep, I have not tested if the SWEEP command accepts the sample number different than 101 as the third parameter.
If not my plan is to increase the sweep to 500 samples by just dividing the frequency span by 5 and getting the 101 samples for each of the 5 frequency segments.
Of course this will slow down the sweep rate by a factor of 5 but I have learned that refresh rate is not everything and there are quite expensive professional test equipment with rather slow sweep rates (a joke in my opinion - but that is another story).
It is not yet clear to me how to software-wise configure the NanoVNA to do S21 measurement so that I just hook the DUT on Port 0 and get a spectrum reading.
Regards
Vitor
-
What does X and Y really represent. This is the toughest question and possibly the most annoying to you. Sorry - I am still a noob in terms of VNA.
These X and Y are real and imaginary parts of S11 value (for CH1 S21). It is represented in complex form (https://en.wikipedia.org/wiki/Complex_number).
For exampel:
1.000334382 -0.012819038
means:
re (real part) = 1.000334382
im (imaginary part) = -0.012819038
So, it means that S11 = 1.000334382 - j0.012819038.
If you want, you can translate it to polar coordinate system (https://en.wikipedia.org/wiki/Polar_coordinate_system) in the following way:
magnitude = sqrt(re * re + im * im);
angle = 180 * atan2(im, re) / pi;
atan2(im, re) calculates angle, but the result represented in radians, so you're needs to convert it to degree by multiplying it with 180 / pi
S11 is very useful value, for exampel you can calculate VSWR value:
rr = re * re + im * im;
if (rr >= 1) then VSWR = infinite;
else VSWR = (1 + sqrt(rr)) / (1 - sqrt(rr));
Regarding the low sample rate of just 101 samples per sweep, I have not tested if the SWEEP command accepts the sample number different than 101 as the third parameter.
you can pass any number in sweep command. NanoVNA just ignore it. It always works with 101 points and there is no way to change it. I think this is memory limit of this microcontroller.
It is not yet clear to me how to software-wise configure the NanoVNA to do S21 measurement so that I just hook the DUT on Port 0 and get a spectrum reading.
Do you mean console commands? Just use data command:
data <channel>
for exampel, this command will get data for CH0:
data 0
and this command will get data for CH1:
data 1
it's pretty easy :)
In order to setup frequencies, you can use sweep command:
sweep <start> <stop>
for exampel, this command will setup sweep range from 1 MHz to 150 MHz:
sweep 1000000 150000000
You can download PUTTY (https://www.putty.org/) (this is terminal, it allows to connect to Serial port) and play with it. It's pretty easy. You're needs to specify Serial port for connection and com port name. Here is putty session for exampel:
help
Commands: help exit info echo systime threads reset freq offset time dac saveconfig clearconfig data dump frequencies port stat sweep test touchcal touchtest pause resume cal save recall trace marker edelay
ch> info
Kernel: 4.0.0
Compiler: GCC 5.4.1 20160919
Architecture: ARMv6-M
Core Variant: Cortex-M0
Port Info: Preemption through NMI
Platform: STM32F072xB Entry Level Medium Density devices
Board: NanoVNA
Build time: Jul 22 2019 - 16:26:51
ch> sweep 1000000 30000000
ch> sweep
1000000 30000000 101
ch> data 0
1.000334382 -0.012819038
1.000619411 -0.014043334
1.000123381 -0.015157566
1.000514984 -0.016093827
1.000436782 -0.017410092
1.000501394 -0.018344996
1.000151395 -0.019588120
1.000253081 -0.020322881
0.999891698 -0.021273871
0.999914824 -0.022288246
0.999868750 -0.023332940
0.999770462 -0.024202115
0.999884128 -0.025404103
0.999833703 -0.026232335
0.999632596 -0.027013938
0.999499559 -0.028223698
0.999637365 -0.028801376
0.999387919 -0.029435977
0.999631226 -0.029972538
1.002218246 -0.029391391
1.004171252 -0.032068528
1.001608490 -0.034094724
1.000858068 -0.035458635
1.000560522 -0.036200754
1.000125050 -0.037087496
1.000095486 -0.038230843
1.000262737 -0.039139334
0.999750494 -0.039976678
0.999891042 -0.041104275
0.999784827 -0.042336892
0.999971687 -0.043484516
0.999799907 -0.045150741
0.999982059 -0.046216718
0.999493658 -0.047426808
0.999777674 -0.048748057
0.999688148 -0.049898017
0.999597012 -0.051182426
0.999525427 -0.052349578
0.999216139 -0.053816296
0.999178647 -0.054883997
0.999005794 -0.056154955
0.998820781 -0.057684507
0.999015092 -0.058685358
0.998871505 -0.059900578
0.998757004 -0.061241392
0.998712182 -0.062616705
0.998695135 -0.063646942
0.998613953 -0.064931072
0.998556375 -0.066254936
0.998585581 -0.067580714
0.998366594 -0.068778082
0.998310446 -0.070160925
0.998090565 -0.071184404
0.998218178 -0.072452932
0.998082041 -0.073820449
0.997873008 -0.075051650
0.997672736 -0.076362192
0.997864961 -0.077377557
0.997722983 -0.078763738
0.997510135 -0.080164059
0.997572302 -0.081403687
0.997310221 -0.082679249
0.997066974 -0.083944469
0.997346639 -0.085386037
0.997254550 -0.086459428
0.997277498 -0.087772250
0.997081696 -0.088958740
0.997002899 -0.090456649
0.996815264 -0.091620504
0.996773242 -0.092930428
0.996567785 -0.094331786
0.996562242 -0.095199465
0.996507167 -0.097060345
0.996266543 -0.097908206
0.996095418 -0.099269963
0.996342182 -0.100541479
0.995806276 -0.101831674
0.995640277 -0.103128492
0.995647966 -0.104465112
0.995308578 -0.105523049
0.995393931 -0.106829814
0.995034158 -0.108262822
0.995196044 -0.109290048
0.994729876 -0.110772430
0.995051443 -0.112008184
0.994862079 -0.113100029
0.994484126 -0.114403992
0.994411051 -0.116048157
0.994243025 -0.117027558
0.994225263 -0.118228457
0.994016349 -0.119506403
0.993956506 -0.120835222
0.993702173 -0.122295558
0.993651926 -0.123540185
0.993369281 -0.124662227
0.993133306 -0.125806242
0.992927193 -0.127351313
0.992799878 -0.128284811
0.992875814 -0.129809200
0.992461144 -0.130973890
0.992346584 -0.132136657
ch> data 1
0.000022881 -0.000034072
-0.000044930 -0.000003006
0.000001353 -0.000019715
-0.000053841 -0.000043194
-0.000004344 -0.000006963
0.000001772 -0.000007370
-0.000000086 -0.000014207
-0.000005251 0.000030388
0.000011967 -0.000017351
-0.000020198 0.000030180
-0.000004857 -0.000045057
-0.000020909 0.000002008
0.000010476 -0.000008191
0.000004981 -0.000037762
-0.000053258 0.000006323
-0.000023624 0.000023545
-0.000021935 -0.000011593
-0.000025896 -0.000000449
-0.000039536 -0.000018117
0.000018417 0.000040691
-0.000015518 -0.000064735
-0.000022360 -0.000048622
-0.000014705 0.000005838
0.000012554 -0.000030298
-0.000035040 -0.000004715
0.000017032 -0.000023722
-0.000012310 -0.000016603
0.000024222 -0.000042020
-0.000050025 -0.000037519
-0.000024725 -0.000024864
0.000012915 -0.000024808
0.000015194 -0.000008572
0.000012409 -0.000028297
0.000032538 0.000017843
0.000026463 -0.000013021
-0.000001025 -0.000037424
-0.000019795 -0.000044200
-0.000013177 -0.000036966
-0.000016448 -0.000019061
0.000003270 0.000000127
0.000045834 -0.000063594
-0.000008657 -0.000003194
0.000010901 0.000005717
0.000023127 -0.000009332
-0.000012275 0.000016109
0.000015946 -0.000023457
0.000012786 0.000031161
0.000002111 0.000011889
0.000023851 0.000024347
-0.000001895 0.000019804
0.000021308 0.000006177
0.000027474 -0.000015023
-0.000020845 -0.000027184
-0.000019241 -0.000042736
0.000046159 -0.000022540
-0.000023773 -0.000018934
0.000017447 0.000030827
0.000032983 -0.000004683
0.000000493 -0.000022111
-0.000006937 0.000028902
0.000043825 -0.000022563
0.000062209 0.000005554
0.000046276 -0.000050153
-0.000017177 -0.000012213
0.000033449 -0.000046718
-0.000002024 0.000019626
0.000041615 -0.000019849
0.000026992 -0.000000219
0.000014502 -0.000004934
0.000015049 0.000002597
-0.000033414 0.000004811
-0.000033238 -0.000052053
0.000026538 0.000015010
0.000009085 -0.000022117
-0.000025025 -0.000017477
-0.000002855 -0.000049975
-0.000008924 -0.000026126
-0.000000627 -0.000041066
0.000014821 0.000012632
0.000008421 0.000025136
0.000020770 -0.000022932
0.000021408 0.000012013
-0.000002280 -0.000019163
-0.000031954 0.000019613
-0.000012588 0.000018006
0.000011647 0.000022847
0.000030014 0.000008953
-0.000044193 0.000000472
0.000014898 -0.000047376
0.000015692 -0.000035619
-0.000000117 -0.000035395
0.000010286 -0.000003112
-0.000038924 -0.000028851
-0.000023267 -0.000004298
-0.000060468 -0.000020690
-0.000024815 0.000003858
-0.000012520 -0.000020648
-0.000003775 -0.000013356
-0.000001176 -0.000004715
-0.000015004 -0.000030841
-0.000015286 -0.000069948
ch>
-
Joeqsmith, you didn't understand anything ...
I HAVE NEVER THOUGHT THAT YOUR TIME DOES NOT APPLY, I ONLY REQUEST THE INSTALLER OF A PROGRAM YOU DEVELOPED ...
I think you didn't understand my intentions, and I'm not able to program.
However, not but nothing, the Gentile helped me
Radioman ...
On the other hand, these are the Americans ... We in Italy, among radio amateurs, help each other.
Bye Bye :( :( :(
I'm glad we finally understand one another. It's too bad that your not getting my work for free upsets you to the point you feel the need to make such ignorant comment about an entire country but it speaks of your character.
You do bring up a valid point that what I have been doing is of no help to you. Others have posted similar comments, which is something I can live with.
Take care.
(TAKE CARE):Pay attention to what ?? To you'??? Should I be Afraid ???
:-DD :-DD :-DD
I didn't want your job, for free, I also wrote you that I was ready to give you a Donation ...
We ITALIANS, we are not like that and among Radio Amateurs & Makers we help each other Free ...
And then a private reply message, you could send it !!! :=\ :=\ :=\
Don't worry, thanks to the lovely RADIOLISTENEN User, I Solved ...
GOODBYE :-X :-X :-X
-
Joeqsmith, you didn't understand anything ...
I HAVE NEVER THOUGHT THAT YOUR TIME DOES NOT APPLY, I ONLY REQUEST THE INSTALLER OF A PROGRAM YOU DEVELOPED ...
I think you didn't understand my intentions, and I'm not able to program.
However, not but nothing, the Gentile helped me
Radioman ...
On the other hand, these are the Americans ... We in Italy, among radio amateurs, help each other.
Bye Bye :( :( :(
I'm glad we finally understand one another. It's too bad that your not getting my work for free upsets you to the point you feel the need to make such ignorant comment about an entire country but it speaks of your character.
You do bring up a valid point that what I have been doing is of no help to you. Others have posted similar comments, which is something I can live with.
Take care.
(TAKE CARE):Pay attention to what ?? To you'??? Should I be Afraid ???
:-DD :-DD :-DD
I didn't want your job, for free, I also wrote you that I was ready to give you a Donation ...
We ITALIANS, we are not like that and among Radio Amateurs & Makers we help each other Free ...
And then a private reply message, you could send it !!! :=\ :=\ :=\
Don't worry, thanks to the lovely RADIOLISTENEN User, I Solved ...
GOODBYE :-X :-X :-X
https://dictionary.cambridge.org/dictionary/english/take-care-of-yourself (https://dictionary.cambridge.org/dictionary/english/take-care-of-yourself)
https://www.fluentu.com/blog/english/say-goodbye-english/ (https://www.fluentu.com/blog/english/say-goodbye-english/)
-
joeqsmith - May I abuse your patience and ask:
...
Of course this will slow down the sweep rate by a factor of 5 but I have learned that refresh rate is not everything and there are quite expensive professional test equipment with rather slow sweep rates (a joke in my opinion - but that is another story).
It is not yet clear to me how to software-wise configure the NanoVNA to do S21 measurement so that I just hook the DUT on Port 0 and get a spectrum reading.
Regards
Vitor
Interesting you say that about the speed. I have a very old Tektronix SA that still uses analog filters that is very slow. The old HP shown in the picture that I am using to compare with the Nano uses digital IF filtering. From the plot you could see with a 100KHz span and RBW of 580Hz using the swept spectrum mode requires 154ms.
If I were to adjust the RBW to something lower, say 73 Hz, it would take 1880 seconds. At the lowest RBW (1.1 Hz) it would require 1,720,000 seconds to sweep. This analyzer has a narrow band mode that can improve the sweep time. For example using the same 100KHz span and a 360Hz resolution it requires 10mSec.
The HP uses 401 samples for all modes compared with the 101 of the Nano. Looking at the same signal with the Signal Hound using the sweep mode requires 70mSec but it collects 5243 samples.
As far as setting up the Nano, CH1 would be set to thru, then LogMag. In the case of this demo, the Stimulus is set to a Center of 20MHz and the Span set to 100K. With it being a relative measurement, just ignore the calibration. Based on the bit of testing I did, keep the power below 0dBm to avoid compression and you should be fine.
****
Forgot to mention that the old HP uses GPIB which is fairly slow where the Signal Hound is using USB3. The Signal Hound can spit data out fast enough that they have a note in the manual that talks about if you plan to write your own software that you will need to keep up. With the HP, I don't think that would ever be a concern.
-
@radiolistener: Thanks for your valuable explanations.
If you notice my previous posts, I do know some parts of it, like the DATA command, but I did not know that I could use the 0/1 argument to get only the required data. That is great and now I understand what joeqsmith meant.
Also, while I do understand that the X/Y data that is received with the DATA command represent a complex number, with real and imaginary component.
What I do NOT understand at this point is for instance how to calculate the dB figure that the NanoVNA shows on the LCD for CH1.
Finally, one of the things I want to achieve is to use the NanoVNA as a spectrum analyzer. I understand it was not designed for this, but I got the impression that it would be a possible thing to do. It is here where I need help!
The communication part is already working, as can be tested with my tool, though it is an initial draft implementation.
I will bear in mind to separate communication from processing, as suggested by OwO.
@Owo: Do you know further details, like retail price, LCD size and resolution, additional functionality (like spectrum analyzer)?
Kind regards,
Vitor
-
The HP uses 401 samples for all modes compared with the 101 of the Nano. Looking at the same signal with the Signal Hound using the sweep mode requires 70mSec but it collects 5243 samples.
...
Forgot to mention that the old HP uses GPIB which is fairly slow where the Signal Hound is using USB3.
I own a HP8594E (actually I own three units, but two are lacking a working PSU).
I made a special version of my "VMA Simple Spectrum Analyser" software for this series (HP/Agilent 859x) and indeed they use 401 samples per sweep and you are right, using GPIB to transfer these samples takes quite some time, compared for instance with the R&S CMU200/CRTU.
Feel free to take a look at my blog and download the software, in case your HP is of the 859x series. You will require a free license.
I am considering adapting this software for the NanoVNA, in order to use it as a spectrum analyzer (first goal) and then eventually add VNA measurements to my software. So that is the big picture.
And once again, because VNA is totally new to me, I might be wrong about what I imagine is possible to do, but unless I understand that it is indeed impossible, I will try as time allows.
Also note, that hobby-wise I come from TV/CATV/SAT, reception, multiplexing, broadcasting and of course field meters, got into spectrum analysis and am now looking at VNA, which is a bit of a different field to what I am used to.
regards,
Vitor
-
What I do NOT understand at this point is for instance how to calculate the dB figure that the NanoVNA shows on the LCD for CH1.
dB figure is a just magnitude of that complex number in logarithmic scale:
magnitude = sqrt(re*re + im*im);
dB = 20 * log10( magnitude );
magnitude value is a Linear S11 plot
dB value is a Logmag S11 plot
The same for S21.
-
Thanks!
I was being stupid - I somehow was thinking in dBm and not dB.
Anyway, I was doing some hacking and indeed the stitched sweep works!
My software now uses 500 samples (505 to be exact), by running the sweep/data commands 5 times in sequence to cover the selected frequency range.
Speed wise it is OKish - right now I am doing one sweep on every button click. For a continuous mode, I would optimize my code, so that the trace is updated with each individual segment, which would give the illusion of higher sweep rate (much like my VMA Simple Spectrum Analyser software does it for the cheap ADF4351 devices).
Note how the curves are much smoother on the graph and please ignore the rudeness and wrongness of the graph!
Regards,
Vitor
-
The HP uses 401 samples for all modes compared with the 101 of the Nano. Looking at the same signal with the Signal Hound using the sweep mode requires 70mSec but it collects 5243 samples.
...
Forgot to mention that the old HP uses GPIB which is fairly slow where the Signal Hound is using USB3.
I own a HP8594E (actually I own three units, but two are lacking a working PSU).
I made a special version of my "VMA Simple Spectrum Analyser" software for this series (HP/Agilent 859x) and indeed they use 401 samples per sweep and you are right, using GPIB to transfer these samples takes quite some time, compared for instance with the R&S CMU200/CRTU.
Feel free to take a look at my blog and download the software, in case your HP is of the 859x series. You will require a free license.
I am considering adapting this software for the NanoVNA, in order to use it as a spectrum analyzer (first goal) and then eventually add VNA measurements to my software. So that is the big picture.
And once again, because VNA is totally new to me, I might be wrong about what I imagine is possible to do, but unless I understand that it is indeed impossible, I will try as time allows.
Also note, that hobby-wise I come from TV/CATV/SAT, reception, multiplexing, broadcasting and of course field meters, got into spectrum analysis and am now looking at VNA, which is a bit of a different field to what I am used to.
regards,
Vitor
That's a nice setup with the tracking generator. The HP shown is a 3589A. Where you have 2.9GHz to play with, this one is limited to 150MHz. HP calls it a spectrum/network analyzer. It's a bit of a hybrid. You can use it with an external coupler and it has software to support down conversion.
Pictures showing my home made 50 ohm standard with Mini-Circuits coupler. They did offer a test set for this instrument.
Also shown for fun is two signal generators connected to a splitter and to the 3589A. The generators are set to 10MHz, separated by 100Hz and 10dBm. Using the swept mode, you can see it requires 104.86 seconds to sweep. Using the narrow mode requires 1.28 seconds. Note the resolution does change but its never caused me a problem.
For my electronics hobby, I really can't justify the cost of new TE in most cases. I do a fair amount of projects below 100MHz into the KHz and this system works really well for this.
-
Would you mind explaining the calibrator? The short, open, load and thru are obvious, but I don't understand the 5th. There appears to be a "pi" network of some type. Is that an attenuator?
-
Yes, 10dBish.
-
joeqsmith, could you please explain some details about your cal kit design?
The distance between ground and signal wire is not the same along signal wire path. For example, there is too small gap between resistors and the ground on the left side (according to photo orientation). It definitely should affect impedance, isn't it?
Also, there is too small gap between signal wire on PCB and ground on SMA connector...
-
Hey Rune .. can you clear some items from your inbox on here so I can send you that list? ;)
( Sorry for this being kind off topic, but the list does relate to the nanovna software being developed in python )
-
The frequency spacing determines how long the time domain trace is. The Nyquist frequency determines the sampling. If you sweep to 900 MHz at 1 MHz spacing you have data for 1 microsecond. If you pad the end of the frequency series to raise Nyquist to 2 GHz you will have 250 ps sampling.
So, the time interval after IFFT is from 0 to 1/[frequency step] is it correct?
If by "time interval" you mean Tzero to Tmax, yes.
-
joeqsmith, could you please explain some details about your cal kit design?
Depends
The distance between ground and signal wire is not the same along signal wire path. For example, there is too small gap between resistors and the ground on the left side (according to photo orientation). It definitely should affect impedance, isn't it?
Yes
Also, there is too small gap between signal wire on PCB and ground on SMA connector...
A better question is, does any of this cause a problem in the frequency range I use them at. The board was designed using Sana many years ago. There was a tradeoff staying with this geometry. The goal was to use the boards at 1G max, which they have been fine for. I've used them a little over this. I would never suggest they would perform at the higher frequencies I have been showing, which is why I posted that disclaimer a few times.
-
I have been thinking about the Nano TDR and if there is a way to combine the phase information. I think the problem is going to be noise. In all but a worst case condition where we have a lot of signal being returned, I'm not sure there would be enough information in the phase to use it. I have yet to try any sort of experiment but my later post showing the RF signal generator attached to channel 1 gives me an idea that it wouldn't work very well.
Maybe I am missing something, which would be the norm.
-
Depends on the nature of the noise. If it is random, it's not a problem. You can significantly increase the dynamic range by summing measurements. It the noise is not random it gets more complex, but if you can accurately characterize the noise you can suppress it. The reflection seismic community has a vast array of tricks for suppressing noise in multichannel data.
I once walked a Scripps PhD candidate through suppressing noise which was probably 40-60 dB *greater* than the signal. I was quite blown away by his final result as all I had done was demonstrate the rudiments of the process. Once he grasped the concept, he did an exquisitely meticulous job of it.
I'm jammed up with an HVAC repair today, so not sure I'll have time to play. First order test is to do a cal, attach a cable and read the magnitude and phase for S & O. In theory they should be 180 degrees out of phase, but with a linear delay equal to twice the electrical length of the cable.
Then try some loads which are not 50 ohms and see how small a reflection it can detect.
I *think* that if the test cable has an adjustable attenuator in series, that by placing a S & O at the end and adjusting the attenuator one can directly measure the dynamic range for TDR. It should be 2x the attenuator setting as the reflection passes through the attenuator twice.
I'm a seismic guy, so at times I bungle the translation from elastic to electromagnetic waves. Also I'm used to going from time to frequency rather than from frequency to time. So I generally take a time case, transform to frequency and then transform back. That way I start with the answer I'm looking for.
Have Fun!
Reg
-
This is my TDR results taken with NanoVNA :)
SHORT and LOAD terminators from cal-kit
[attach=1][attach=2]
500 Ohm and 5 Ohm terminators through SMA-SMA adaptor (adaptor delay is 0.247 ns):
[attach=3][attach=4]
This is CH0 => cable => T adaptor with 50 Ohm terminator => cable => CH1. I'm used two 0.32 meter cables which came with NanoVNA. So, in total we have 25 Ohm in the middle of transmission line. This result may be affected with CH1 input impedance, which drops down to 40 Ohm at 900 MHz, so needs to perform it again with good 50R terminator at the end of line.
[attach=5]
Now let's try more complex transmission line, here is a sequence:
1) 0.5 meters RG316 (SMA-SMA)
2) SMA to SO239 adaptor
3) 1 meter LMR195 (PL259-PL259)
4) SO239 to SMA adaptor
And this is how it works with open end. And with 50R terminator on the end:
[attach=6][attach=7]
Here is zoomed and commented last image (50R at the end of sequence):
[attach=8]
-
It's late, I've had a couple of drinks and am headed for bed, but that looks very reasonable.
A triangle window in frequency will suppress the sinc(t) sidelobes a lot, so I suggest trying that. Squaring the sidelobes makes them rather small. All window functions have side effects. At the moment, I prefer a triangular aka Bartlett window as being the best compromise, at least for TDR work.
I'd also suggest preserving the sign of the time domain amplitude so that it's easy to tell capacitive and inductive discontinuities apart.
Have Fun!
Reg
-
A triangle window in frequency will suppress the sinc(t) sidelobes a lot, so I suggest trying that. Squaring the sidelobes makes them rather small. All window functions have side effects. At the moment, I prefer a triangular aka Bartlett window as being the best compromise, at least for TDR work.
This is comparison for Rectangular, Triangular, Blackman and Blackman-Harris-7 window functions:
[attach=1][attach=2][attach=3][attach=4]
This picture shows complex components with Blackman window
[attach=5]
It seems that the Blackman window is the best choice here, because all other window function have high side lobe distortions.
Note: all these pictures are the same reflections from connectors and adapters between different pieces of cables connected together in a line with 50 Ohm load on the end (taken from the last test, see my previous post).
I'd also suggest preserving the sign of the time domain amplitude so that it's easy to tell capacitive and inductive discontinuities apart.
If I understand correctly, in time domain we have reflection coefficient Γ in complex representation. So, I just calculated VSWR in the following way:
VSWR = (1 + |Γ|) / (1 - |Γ|)
And it works pretty good. But I'm not sure, is it correct?
If you're talking about |Γ| it is always have positive sign. So I'm not sure what did you mean with "time domain amplitude"?
I want to get a chart with absolute impedance along the transmission line. Something like this:
[attach=6]
Is it possible?
-
That's a very nice comparison. The price for the Blackman window is the inability to separate adjacent reflections. There are a great many different windows, each having particular strengths and weaknesses. I thought I knew *all* the windows until I looked at the wikipedia entry.
The Fourier transform of the last figure exists. So all that is needed to do it is to acquire that data in the frequency domain and find a good heuristic for the DC component. A sparse L1 (aka basis) pursuit should do an excellent job of solving for DC.
If you compare a TDR trace for an open and short you will see what I mean about preserving the sign of the reflection coefficient. Knowing that the impulse response is a series of impulses of alternating sign tells you that one discontinuity is inductive and one is capacitive. This makes it possible to measure the values of the discontinuities.
Have Fun!
Reg
BTW I'd like to suggest using inline full size figures for things like the window comparison. That would let people see all of them by scrolling up and down.
-
The data shown seems about right for time/length. If you wanted to compare software with others, you may want to consider using a standard test file that you could then share with other to compare your results, rather than using the Nano and cables. Or maybe stay with the bits included with the Nano.
As far as the windows, currently I have everything fixed in my software for the Nano but it's not problem to overlay the standard ones in LabView. Shown with the data I had taken off that small section of coax I used to make my Beatty standard for that last video.
I haven't tried to do anything more with the Nano. I have no doubt that the phase would be very sensitive to an open/short and I am sure if you wanted to do a relative long cable measurement for an open cable it would be fairly simple. But measuring a mm on a 10meter cable is an interesting problem to try and tackle.
-
joeqsmith, how did you calculated that figure?
S1P => apply window => IFFT => ? ? ? => plot
Here is my test S1P file for pictures above:
-
pad to ifft to lp to plot
**
That's LP impulse. For step, its the integral. Found most of this in HP app notes. Still could be wrong.
-
The frequency spacing determines how long the time domain trace is. The Nyquist frequency determines the sampling. If you sweep to 900 MHz at 1 MHz spacing you have data for 1 microsecond. If you pad the end of the frequency series to raise Nyquist to 2 GHz you will have 250 ps sampling.
Doing an FFT from time to frequency, padding with zeros and inverse transforming is the standard way to resample data to finer sampling rates. There are other ways of doing it, but the FFT is the fastest.
.......
Have Fun!
Reg
I need to say, I owe you a big thanks for posting this little bread crumb. This technique was shown in those last couple of plots. I added it to my Nano program as well and tried it out with hardware. The is a really nice improvement. Google came through with the linked article.
https://dspguru.com/dsp/howtos/how-to-interpolate-in-time-domain-by-zero-padding-in-frequency-domain/
-
The key to high quality scientific software is identifying cases for which a precise analytic answer is available. Actually doing that can be staggeringly difficult.
I have spent many days wracking my brain looking for even one. And I can think of many cases where none is known. Wave propagation in anisotropic media is staggeringly difficult to verify correctness.
If you cannot solve the analytic equation, why should you trust the numerical solution? This problem dominated my career in the oil industry. Once in a great while you wake up in the morning and realize that there is a problem with a known answer that you can use to test a numerical simulation. But such mornings are depressingly rare. This is very seriously difficult. A complete novice can pose a test case that an expert with many years of experience never thought of.
If you're trying to validate the results from a program on which a $100 million decision is going to be made it will drive you crazy.
Reg
BTW Joe, that was a very basic breadcrumb. I had the good fortune to be abused by several old men into learning it ;-)
-
pad to ifft to lp to plot
I know that, but my question is what you're doing with data after IFFT?
This is just a sum of real and imaginary part?
-
I have no problem with it being basic for you. Its still a very nice bit of information, at least for me. So a big thanks for that one. The only down side is that I didn't have it implement it before making any videos.
Test jig for trying out some of these bones you're tossing out.
***
Resolution should be sub 0.001".
-
pad to ifft to lp to plot
I know that, but my question is what you're doing with data after IFFT?
This is just a sum of real and imaginary part?
Note, it's backwards from what you had posted. After LP, I just plot it.
-
After LP, I just plot it.
Could you please share S1P file for this screenshot (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2682558/#msg2682558)?
Or just another S1P and screenshot with TDR impedance for this S1P...
For step, its the integral. Found most of this in HP app notes. Still could be wrong.
what HP app note exactly you're talking about?
-
I know that, but my question is what you're doing with data after IFFT?
This is just a sum of real and imaginary part?
After the IFFT you should have a purely real response, i.e. the imaginary part should be zero - so you will need to plot just the real part.
Your frequency-domain data (S-parameters) are complex data and when you do an IFFT on them you need to input also the negative frequencies part, as the complex conjugate of the positive frequency data you have, so that the IFFT results will be real.
-
After the IFFT you should have a purely real response, i.e. the imaginary part should be zero - so you will need to plot just the real part.
Both input and output of FFT or IFFT are complex.
Your frequency-domain data (S-parameters) are complex data and when you do an IFFT on them you need to input also the negative frequencies part, as the complex conjugate of the positive frequency data you have, so that the IFFT results will be real.
The input (S-parameters) are complex, so the information about negative frequency is already present. And the output of IFFT is complex value with real and imaginary part.
Here is example of IFFT output for S1P that I shared here (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2682027/#msg2682027) (LMR195-RG31605-LMR195-RG58-LOAD.s1p). This is measurement of three different piece of coax cable connected together through adapters and terminated with 50 Ohm at the end of transmission line.
-
After LP, I just plot it.
Could you please share S1P file for this screenshot (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2682558/#msg2682558)?
Or just another S1P and screenshot with TDR impedance for this S1P...
For step, its the integral. Found most of this in HP app notes. Still could be wrong.
what HP app note exactly you're talking about?
See attached
-
You may find this app note of interest as well.
-
See attached
Thanks, but I'm failed to get the same result, I cannot get such picture like your from this s1p ???
Could you please show also picture with IFFT result (before LPF and other processing) for this s1p file? Just a plot of real and imaginary parts...
Also what is units along X axis on your picture? If these are nanoseconds, it seems that they are multiplied by two for some reason.
I see that the pulses in provided S1P file are located at 13.762 ns and 18.679 ns. Isn't it?
-
There are many possible reasons for this. There could be bugs on both sides and miscommunications on both sides.... Certainly what I am showing shouldn't be considered a gold standard. We almost need someone with a known working setup to provide some test cases that people could then use to validate their math.
The Touchstone file I provided was from the current setup which is different from the previous plots. There is a phase trimmer between the Beatty standard and the Nano. The Beatty standard was terminated to 50 ohms. I assumed you just wanted to see the 50-25-50 ohm transitions which this file would have, assuming there isn't a bug.
On previous plots, the X-axis is in samples or inches. I'm not sure where the phase was set for the file I sent but is is not so long as to be outside of the window. The Beatty is about 22ish inches of 25 ohm.
-
Real to complex and complex to real in place FFTs are very popular because the negative frequencies are the complex conjugate of the positive frequencies. Back when room size computer had 4 MB of memory and multiple users, these were essential to seismic processing. But there are lots of FFTs which do *not* fill in the complex conjugate part. So it matters what algorithm you use.
I'll post TDR to 20 GHz BW using an 11801 & SD-24 later. Setup will be SMA-M to BNC-F cable open, same with Chinese 50 ohm BNC-M terminator, then SMA-F to BNC-F cable to BNC-M to SMA-M cable to SMA-F to N-F adapter and Anritsu 50 ohm N-M calibrator load. The cables are very high quality made for me by a friend. So it will be a canonical test case. I can also sweep them to 3 GHz on an 8560A w/ TG option in addition to my nanoVNA results.
The SMA to BNC cables are about 10-12" so it gives good separation in the time domain.
For testing software, multiply a complex series with a real part of 1.0 and an imaginary part of 0.0 by exp(j*2*pi*f*t) for t equal to 1/2 the reciprocal of the frequency spacing. Do this with the DC part [0,0] and with the DC part [1.0,0]. In both cases you should get a spike in the middle of the TDR trace. Without the DC, the base of the spike will be offset from zero.
Another canonical test is a cosine in frequency. That will be a pure real spike in time. A sine wave will be a pure imaginary spike in time.
I've got some headaches to take care of, so it might be a day or two before I have time to do the physical tests.
Attached below are a few pages from Bracewell with pictures of important transforms in both domains. Most of these are excellent test cases as both domains are obvious. Some are more complex, but I thought I'd leave them.
What matters are impulse, sine, cosine, "boxcar" (sinc) and some of the variations.
-
Ran a quick check to try out the stage with the added math. showing 0.1" increments and a total travel of 2.0". It may be basic but it sure is impressive.
-
Another article on TRL calibration: https://coppermountaintech.com/design-calibration-of-a-trl-calibration-kit/
-
Another article on TRL calibration: https://coppermountaintech.com/design-calibration-of-a-trl-calibration-kit/
One more, same source: https://coppermountaintech.com/trl-calibration/
-
Ran a quick check to try out the stage with the added math. showing 0.1" increments and a total travel of 2.0". It may be basic but it sure is impressive.
Very nice. That's the way to do it. I'm planning on making a picosecond level stage once I get all my machine tools set up for such work. Rather fiddly if you want a clean response.
-
I'm not too concerned with the absolute numbers. 40 steps, 0.050" per step. The top is showing the histogram. It moves around a bit too much but certainly proves the concept.
-
joeqsmith, it's better to use nanoseconds. It doesn't depends on cable type :)
-
joeqsmith, it's better to use nanoseconds. It doesn't depends on cable type :)
No doubt people have their opinions.
Currently my software supports metric, English, time and samples for the graphing units. Most likely it will include phase as well. Much like the filter settings, the units are hard coded and changed depending on the test I am running. In this case, I am working with a stage where I am dealing with distance. Being from the USA where we can't seem to make the leap to metric, I normally work in English.
If I had a desire to make the software public, it would include a way to change the units and also store the default settings. At the present time, I'm more interested in experimenting with the Nano than making polished bit of software for public use. The software evolves as my requirements change.
That said, the time/distance will have the same profiles. No matter what units you like, the error is still the same.
-
I know this thread is for complaining about not getting free software when there is free software and complaining about not having your questions answered even though they are answered :-DD, I thought I'd add this interesting write-up that takes pains to explain some of the math that I found to be a useful refresher.
https://mightydevices.com/index.php/2019/08/complex-impedance-matching-using-scalar-measurements-math-and-resistors/ (https://mightydevices.com/index.php/2019/08/complex-impedance-matching-using-scalar-measurements-math-and-resistors/)
I have ordered both the least expensive and most expensive nanoVNA clones on Amazon and will post some photos of the PCBs, etc. at a later date.
Thank you Joe for your videos, I am watching my way through all of them and learning a lot!
- Joshua
-
I know this thread is for complaining about not getting free software when there is free software and complaining about not having your questions answered even though they are answered :-DD,
....
It does seem like this from time to time.
I thought I'd add this interesting write-up that takes pains to explain some of the math that I found to be a useful refresher.
https://mightydevices.com/index.php/2019/08/complex-impedance-matching-using-scalar-measurements-math-and-resistors/ (https://mightydevices.com/index.php/2019/08/complex-impedance-matching-using-scalar-measurements-math-and-resistors/)
I have ordered both the least expensive and most expensive nanoVNA clones on Amazon and will post some photos of the PCBs, etc. at a later date.
Thank you Joe for your videos, I am watching my way through all of them and learning a lot!
- Joshua
You are very welcome. I'm glad to hear a few people have found them helpful.
I still only have the one Nano. If they produce the gen 2 unit that's been mentioned, I may pick one up to help quench my thirst.
Looking at the error, I discovered a major problem (race condition) with my software design that I have now corrected. This could cause the data to be corrupt. Sadly, it didn't help with the error. What's interesting is plotting the change in distance during the test, we get this sort of U shape. This is reproducible.
-
Using the same setup but not moving the stage, the signal is very stable. I suspect the home made phase trimmer is the cause of the majority of my problems.
-
Replacing the home made trimmer with a commercial one made by Sage and manually adjusting it.
-
Going back to the home made phase trimmer with the Beatty cable I show with the Sage, and using roughly the same step size.
-
Definition of insanity
1 dated : a severely disordered state of the mind usually occurring as a specific disorder
2 law : unsoundness of mind or lack of the ability to understand that prevents one from having the mental capacity required by law to enter into a particular relationship, status, or transaction or that releases one from criminal or civil responsibility
3a : extreme folly or unreasonableness the insanity of violence His comments were pure insanity.
b : something utterly foolish or unreasonable the insanities of modern life
Let's see, I'm looking at a $50 Chinese VNA with a $1000 phase trimmer attached to it with a $200 torque wrench. Why? Because a $500 stage with the $30 home made phase trimmer wouldn't let me play with some basic algorithm.
-
Hi
If they produce the gen 2 unit that's been mentioned, I may pick one up to help quench my thirst.
It may be this one : https://www.aliexpress.com/wholesale?SearchText=nanovna-f (https://www.aliexpress.com/wholesale?SearchText=nanovna-f)
Rgds
-
It may be this one : https://www.aliexpress.com/wholesale?SearchText=nanovna-f (https://www.aliexpress.com/wholesale?SearchText=nanovna-f)
this is the same NanoVNA, but pcb redesigned for large IPS display, more powerful MCU and large 5000 mAh battery. :)
-
Someone was posting about a 2.4GHz version without using harmonics and at the same cost, plus improved communications. I've been using the Nano headless for the most part but have tried it with my 8" tablet.
I made an attempt to improve the home made delay line. Stepping 0.01"ish for 150 steps or 1.5"ish total travel. Shown also is the absolute phase and distance.
-
I'd really appreciate more construction details of your phase shifter as I intend to build at least one and possibly more. I can resolve delays to picosecond levels on the 11801 & SD-24 combination.
I actually need 8 short (~10-20 ps maximum) phase shifters to phase match the cables from an FPGA board to my Tek 11801 w/ four 2 channel SD-26 sampling heads. That's for measuring adder-multiplier bit skew for various DSP topologies for use in a FOSS DSO based on Zynq 7010 or 7020 FPGAs.
Making stuff like that is the justification for having a lathe and mill. I have a Chinese 7" x 14" mini-lathe completely disassembled awaiting new bearings and scraping to make a precision toolmaker's lathe out of it. As sold they are just a set of parts assembled at the factory to make sure they don't leave any parts out of the kit.
I'm confused by the axis labels on your displays, particularly the Y axes on the display with 3 plots. In an earlier post you showed the sidelobes of the sinc(x) changing. It would be helpful to know more about that data. I spent my career doing oil industry DSP. My instincts are that your "error" is actually exactly what you should be getting, but I need to know more about the data.
The best test of your software is to construct synthetic test cases. For example, to test solving for the length, create several series which are exactly exp(j*2*pi*t) for various values of t. If t is not an integer multiple of the sample interval dT, then you'll see a sinc(x) for dT = 1/(2*Fn). If dT is a small faction of that you will always see the sinc(x). When it is exactly at Nyquist, the time samples all fall at the zero crossings in sinc(x).
Have Fun!
Reg
-
Consider the very top graph of the set of three, where I use the terms Amplitude, Distance and Length to describe the vertical axis. This is showing the change in distance per step. For example, looking at post 333, I an moving the stage in 0.1" increments. The Nano is showing it from 0.101" down to 0.042". That was using the home made phase trimmer.
Looking at post 334, where the stage is not moving, the change is +/-0.002".
Looking at post 335, where the home made trimmer was replaced with the Sage commercial part where I am adjusting it by hand, it shows between 0.224 and 0.271"
Post 336 was an attempt to do an A/B compare between the home made trimmer and the commercial part by stepping roughly the same amount. The was between 0.174
and 0.280".
Post 340, the stage is incremented by 0.01" (its really 0.01000976... as it is not an even divisor). The software reports a mean of 0.0103". The stage moves 150 steps and show move 1.501465" compared with the reported 1.5314". I zoomed into the side lobes to show the spacing and we can see they are not uniform.
The middle graph is just the histogram of the step sizes. Or how many times the step size falls into a bucket.
The trimmer is brass. Your local hobby shop should have all sorts of shapes and sizes to choose from. There is also McMaster Carr.
-
My question about the phase trimmer was about dimensional and construction details. The photos I looked at looked like copper pipe with SMA-F to N-F connectors at the end. I'd expect tube on tube and tube on wire for the line. I was wondering what the dimensions you chose were and what the measured and calculated impedances were. What's the reflection at the SMA-F/N-F adapter to adjustable air line look like?
The vertical axes in the first PNG of #340 are "Length" ,"Score" and "Impedance". The horizontal axes are "Samples", "Length" and "Length". I know from inspection that the bottom figure is reflection coefficient vs time. If you take magnitude and phase, convert to a complex series and Fourier transform you get the band limited reflection coefficient on the Y axis and the travel time on the X axis.
In the 2nd PNG of #340, "angle" only has meaning at a single frequency. If you are comparing change in line length and the time domain relationship that is time change, "dT". As a consequence, I have no idea what it describes.
Your work is very interesting, but you've omitted so many details that I am unable to evaluate it.
-
The vertical axes in the first PNG of #340 are "Length" ,"Score" and "Impedance". The horizontal axes are "Samples", "Length" and "Length". I know from inspection that the bottom figure is reflection coefficient vs time. If you take magnitude and phase, convert to a complex series and Fourier transform you get the band limited reflection coefficient on the Y axis and the travel time on the X axis.
Length is inches, not time. Peak is at roughly 20 inches.
In the 2nd PNG of #340, "angle" only has meaning at a single frequency. If you are comparing change in line length and the time domain relationship that is time change, "dT". As a consequence, I have no idea what it describes.
Angle data was collected at 900MHz for each step. Samples refers to the number of steps, which was 150 for both PNG1&2. Trimmer moved from 19.8" to 21.3" in 150 steps.
My question about the phase trimmer was about dimensional and construction details. The photos I looked at looked like copper pipe with SMA-F to N-F connectors at the end. I'd expect tube on tube and tube on wire for the line. I was wondering what the dimensions you chose were and what the measured and calculated impedances were. What's the reflection at the SMA-F/N-F adapter to adjustable air line look like?
There is no wire as you expect. 55.7 ohms, 18.2pf / 56.7nH per meter.
-
My question about the phase trimmer was about dimensional and construction details. The photos I looked at looked like copper pipe with SMA-F to N-F connectors at the end. I'd expect tube on tube and tube on wire for the line. I was wondering what the dimensions you chose were and what the measured and calculated impedances were. What's the reflection at the SMA-F/N-F adapter to adjustable air line look like?
There is no wire as you expect. 55.7 ohms, 18.2pf / 56.7nH per meter.
Calculated or measured? You are either a *very* poor communicator or being deliberately obtuse. I asked for physical dimensions and construction details. You furnished *nothing* useful.
I asked a simple question about the construction of your delay line. A linear adjustable length air dielectric delay line must of necessity have inner and outer conductors which telescope. One *might* get acceptable results by sliding an inner conductor through an end termination, but I'm doubtful. I'd expect significant issues with stray capacitance and inductance if you did that. You are being willfully mysterious.
Sadly, I'm forced to conclude this thread is a waste of time. It's just joeqsmith pimping his ego.
-
My question about the phase trimmer was about dimensional and construction details. The photos I looked at looked like copper pipe with SMA-F to N-F connectors at the end. I'd expect tube on tube and tube on wire for the line. I was wondering what the dimensions you chose were and what the measured and calculated impedances were. What's the reflection at the SMA-F/N-F adapter to adjustable air line look like?
There is no wire as you expect. 55.7 ohms, 18.2pf / 56.7nH per meter.
Calculated or measured? You are either a *very* poor communicator or being deliberately obtuse. I asked for physical dimensions and construction details. You furnished *nothing* useful.
I asked a simple question about the construction of your delay line. A linear adjustable length air dielectric delay line must of necessity have inner and outer conductors which telescope. One *might* get acceptable results by sliding an inner conductor through an end termination, but I'm doubtful. I'd expect significant issues with stray capacitance and inductance if you did that. You are being willfully mysterious.
Sadly, I'm forced to conclude this thread is a waste of time. It's just joeqsmith pimping his ego.
These values were calculated based on the telescoping brass tubes that were used.
https://www.eevblog.com/forum/rf-microwave/sma-phase-adjuster-construction/msg2315619/#msg2315619 (https://www.eevblog.com/forum/rf-microwave/sma-phase-adjuster-construction/msg2315619/#msg2315619)
Your original post on the trimmers was from back in April and it seems you have not made any headway.
https://www.eevblog.com/forum/rf-microwave/testing-rf-connectors-and-cables/msg2640531/#msg2640531 (https://www.eevblog.com/forum/rf-microwave/testing-rf-connectors-and-cables/msg2640531/#msg2640531)
You had mentioned having ADD and I wonder if your last comment is from your frustrations with your own personal lack of progress.
You may find the following article helpful.
https://hackaday.io/project/162998-the-rise-and-fall-of-pulses (https://hackaday.io/project/162998-the-rise-and-fall-of-pulses)
Personally, I would have just ordered up some tubing and started trying some things out rather than lashing out at others.
-
Dear friend, I congratulate you for the work you did with that software. It makes it easier for us radio amateurs that we like to experience every day with all kinds of antennas! In particular I like to manufacture HF and VHF antennas for me qth! I wanted to ask you a question? Do you have the software you made? Or do you share it experimentally for radio amateurs? why I wish I could have it installed on my PC! I have the new version of NanoVNA-F 4: 3 inch screen! Best regards from Lima Peru I leave my email to see if you can send me the software there! oa4ldr@gmail.com a hug and greetings to all! 73s atte OA4LDR
-
Dear friend, I congratulate you for the work you did with that software. It makes it easier for us radio amateurs that we like to experience every day with all kinds of antennas! In particular I like to manufacture HF and VHF antennas for me qth! I wanted to ask you a question? Do you have the software you made? Or do you share it experimentally for radio amateurs? why I wish I could have it installed on my PC! I have the new version of NanoVNA-F 4: 3 inch screen! Best regards from Lima Peru I leave my email to see if you can send me the software there! oa4ldr@gmail.com a hug and greetings to all! 73s atte OA4LDR
-
These values were calculated based on the telescoping brass tubes that were used.
For which you provided *no* information. There is not much burden in stating what size tubing you used and other basic construction details. Not handing out software I fully understand. Not providing the dimensions of the airline I don't.
https://www.eevblog.com/forum/rf-microwave/sma-phase-adjuster-construction/msg2315619/#msg2315619 (https://www.eevblog.com/forum/rf-microwave/sma-phase-adjuster-construction/msg2315619/#msg2315619)
Your original post on the trimmers was from back in April and it seems you have not made any headway.
Well, if you don't work on a project, nothing happens. Tuesday I replaced a A/C condensor fan motor. Friday I had to deal with replacing a 5 ton compressor and condensor and evaporator coil. Today I investigated the linearity of the timebase interpolation of my 11801 for which the factory cal constants were lost. If they actually existed. In light of the results, I question whether they might not be mythical.
https://www.eevblog.com/forum/rf-microwave/testing-rf-connectors-and-cables/msg2640531/#msg2640531 (https://www.eevblog.com/forum/rf-microwave/testing-rf-connectors-and-cables/msg2640531/#msg2640531)
You had mentioned having ADD and I wonder if your last comment is from your frustrations with your own personal lack of progress.
I have more projects than I have time left on this earth. In most cases I also have no reason to prefer one over the other. Things like HVAC repairs for tenants do take priority.
I had planned to write new FW for the nanoVNA today until a post on the 11801 showed up on TekScopes. The 11801 was the smaller project, so I did that.
You may find the following article helpful.
https://hackaday.io/project/162998-the-rise-and-fall-of-pulses (https://hackaday.io/project/162998-the-rise-and-fall-of-pulses)
I did almost as well 25+ years ago without having a sampling scope and just using a generic prototype board. Leo Bodnar does <40 ps with a BNC and less with better connectors.
Personally, I would have just ordered up some tubing and started trying some things out rather than lashing out at others.
Actually, I'd have started by calculating the impedances for airlines made from stock components rather than engaging in random activity. I'd been hoping to be spared that tedium.
As you are unwilling to state the relevant dimensions, I stand by my comment. You're a waste of time. But..
Have Fun!
Reg
I'm out of here.
-
For which you provided *no* information. There is not much burden in stating what size tubing you used and other basic construction details. Not handing out software I fully understand. Not providing the dimensions of the airline I don't.
....
As you are unwilling to state the relevant dimensions, I stand by my comment. You're a waste of time. But..
Have Fun!
Reg
I'm out of here.
While I could pull apart the test setup, measure the parts, look up part numbers and suppliers and provide you with a BOM with simulation data, then reassemble the setup and get back to my projects. Sure, maybe a half hour to sort all this out is all. You may feel this time is not much burden on me and you deserve it but I value my time.
-
Dear friend, I congratulate you for the work you did with that software. It makes it easier for us radio amateurs that we like to experience every day with all kinds of antennas! In particular I like to manufacture HF and VHF antennas for me qth! I wanted to ask you a question? Do you have the software you made? Or do you share it experimentally for radio amateurs? why I wish I could have it installed on my PC! I have the new version of NanoVNA-F 4: 3 inch screen! Best regards from Lima Peru I leave my email to see if you can send me the software there! oa4ldr@gmail.com a hug and greetings to all! 73s atte OA4LDR
At this time I have not released any software but check out https://groups.io/g/nanovna-users
There are a few people there making open source programs for the Nano. I am not sure if they are an improvement over what was offered with the Nano.
-
https://youtu.be/eMsdejYM-08
-
After all, I done it :-DMM
Here is TDR from S1P file that joeqsmith shared here (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2683290/#msg2683290):
-
Nice. Looking at the shape of the 25ohm section, it seems right except that the width appears to be about 2X wider than I would expect. It looks like you show a FWHH of about 5ns where I was thinking it should be about 2.5. The start at 14ns also seems like it's double. Keep in mind, this could very well be a problem on my side. If you don't find anything obvious, let me know and I will double check my work.
-
I tested time axis by compare with Group Delay, it shows correct time.
Here is picture with better resolution for 25 ohm section.
-
My guess is that you are looking at the round trip where I am trying to find the distance to the disturbance, so half that. If that makes sense, I think we have the same numbers. Of course, we both could be wrong. :-DD
-
Please, is this the latest NanoVNA Firmware? Kernel: 4.0.0, Build time: May 5 2019 - 08:54:38
If not, I would appreciate knowing what the latest is.
Thank you in advance for any assistance, Ted
-
no, this is outdated version. You can find the latest version here: https://drive.google.com/drive/folders/1IRz6E1wlkRyV0u7sbqj0lhWST-GV1szY
-
no, this is outdated version. You can find the latest version here: https://drive.google.com/drive/folders/1IRz6E1wlkRyV0u7sbqj0lhWST-GV1szY
Thank you very much, Ted
Edit: Can you please advise which file here is for the latest NanoVNA Firmware. I assume that it is NanoVNA_edy555_0.1.1.9.zip ???
With my firmware being dated May 5 2019 - 08:54:38, is it likely that the Hardware is the latest and/or also compactable with the current Firmware. I'm asking because I just ordered this VNA and received it yesterday. The first thing that I noticed is that the LEDs are Green, and NOT Blue. So this was my motivation for checking on the current Firmware.
Thanks again for any assistance or advice, Ted
-
Edit: Can you please advise which file here is for the latest NanoVNA Firmware. I assume that it is
There are two ways to update firmware: DFU and ST-LINK. So, it depends on what method you're want to use.
1) DFU update. This is simple but not reliable way. If something will going wrong, you may brick your NanoVNA with this method and the only way to restore it is to update firmware with the second method. DFU method doesn't requires any special hardware and you can update it just through USB.
For DFU method, you will need the file with DFU extension: nanoVNA_900_ch_20190920.dfu
In order to upload it into NanoVNA you will need DfuSe software (https://www.st.com/en/development-tools/stsw-stm32080.html).
You will need to power-off your NanoVNA, connect USB to PC, short BOOT jumper with tweezers and power on NanoVNA. It will be booted in DFU mode. The display will be white. Now you can release BOOT jumper and then use DfuSE Demo tool to upload firmware file into NanoVNA.
2) ST-LINK update. This is native and reliable way. But it requires ST-LINKv2 dongle (https://www.aliexpress.com/item/32839270086.html). This dongle allows to flash even bricked device and also allows to use in-circuit debugging.
For ST-LINK update, you will need the file with HEX or BIN (any of these) extension: nanoVNA_900_ch_20190920.hex
In order to upload it into NanoVNA you will need ST-LINK Utility software (https://www.st.com/en/development-tools/stsw-link004.html).
You will need to connect ST-LINK to NanoVNA with 4 wires:
- 3.3V to VDD,
- GND to GND,
- SWDIO to SWDIO,
- SWCLK to SWCLK
There is no need to solder, you can just connect wires to the pads and press it with finger during upload. Then you will need to use ST-LINK Utility tool with the following memory parameters:
- Address: 0x08000000
- Size: 0x20000
- Data Width: 8 bits
I strongly recommend to save your current firmware before update. Just in case. Both software tools allows it.
-
With my firmware being dated May 5 2019 - 08:54:38, is it likely that the Hardware is the latest and/or also compactable with the current Firmware.
All existing hardware for NanoVNA is compatible with firmware. The LED color may be random, it depends on what LED color is installed by manufacturer.
For a new firmware you may need to install diode on the pcb in order to get working battery indicator. With no diode the battery indicator will always show empty battery.
[attachimg=1]
-
Hello radiolistener: I sent a message to my EBay seller telling him that I want to return it for either a full refund, or a current replacement unit. Because this one has obsolete Firmware, Green LEDs where they are normally Blue, and only 2 Traces are available where as it should be 4.
1) All devices that you may buy on the market has outdated firmware. If you want fresh firmware you're needs to update it by self. You cannot find device with fresh firmware on the market. The update process is pretty easy. Just click on the button "Choose" at the upgrade section of DfuSE Demo tool. And select file with firmware. That's it. Two mouse clicks and your firmware is updated.
2) All devices on the market have different LED color, there is no standard color. You can find exactly the same NanoVNA with red, blue or green LED. They all the same. Just random color of LED.
3) two traces come with old firmware. Just update it and you will have 4 traces. It takes for about 1-2 minutes. Nothing difficult.
-
1) All devices that you may buy on the market has outdated firmware. If you want fresh firmware you're needs to update it by self. You cannot find device with fresh firmware on the market. The update process is pretty easy. Just click on the button "Choose" at the upgrade section of DfuSE Demo tool. And select file with firmware. That's it. Two mouse clicks and your firmware is updated.
2) All devices on the market have different LED color, there is no standard color. You can find exactly the same NanoVNA with red, blue or green LED. They all the same. Just random color of LED.
3) two traces come with old firmware. Just update it and you will have 4 traces. It takes for about 1-2 minutes. Nothing difficult.
[/quote]
----------------------------------------------------------------------------------------------------------------------------------
OK Great, that is good news. I will go ahead and update the FW. Tnx again
-
2) ST-LINK update. This is native and reliable way. But it requires ST-LINKv2 dongle (https://www.aliexpress.com/item/32839270086.html). This dongle allows to flash even bricked device and also allows to use in-circuit debugging.
For ST-LINK update, you will need the file with HEX or BIN (any of these) extension: nanoVNA_900_ch_20190920.hex
Thanks for the tutorial radiolistener, I am getting a NanoVNA soon and I just ordered the ST-Link according to your instructions so I can get the firmware updated as needed.
:-+
-
OK Great, that is good news. I will go ahead and update the FW. Tnx again
Before update, save your current firmware. Just in case if you will want to rollback to old one.
-
Hello radiolistener: I just removed my NanoVNA's bottom cover to locate the 'Boot Jumper'. I found it, although the label for it is under a white nylon plug for the Battery (that I haven't seen on any other unit's in the YouTubes(?)). But the big thing I noticed is that there are no Internal Shields on my PCB as all the other units have (as shown here in the picture from a YouTube). Again my unit has no shielding where you see it here. This seems potentially serious(?). What do you think? Ted
Edit: I added a picture below of my unit without any shields.
So now of course I wonder if I have a 1. Older unit, 2. Newer unit, 3. Unfinished Older unit, or 4. Unfinished Newer unit?
-
So now of course I wonder if I have a 1. Older unit, 2. Newer unit, 3. Unfinished Older unit, or 4. Unfinished Newer unit?
It is pretty close to the layout of the one I have.
The shielding problem is easily fixed.
Just buy some thin shim brass. You can cut it with scissors (as long as it is not someone's prized sewing scissors!) and it is pretty cheap. A dollar or two. Any machinist supply shop or ebay has it.
The bigger shield is in two parts - I have attached a photo.
Richard
-
I had upgraded the firmware when I first received the Nano but it had a few problems. One in particular was causing me some problem where every now an then, the data was corrupt. When I wrote my software, I was seeing the problem more frequently than with their software.
Basically, it seems the firmware could be running a sweep at the same time they were dumping the data and it would corrupt the packet. Throttling the data rates helps which may be why they chose to run the supplied software so slow. Even with slower rates, there were modes I could get the firmware into where it was very unreliable. If I pushed it too hard, the screen would go white and require a power cycle.
If seems that the person creating the firmware was aware of this problem and changed how the unit handles the messages. I have spent several hours testing the new firmware and it has yet to glitch. These tests were with my software running unimpeded. The screen updates are faster now. They also added some very nice features to the new firmware. Well worth the time to upgrade.
I'm not sure if they have added any new commands but it seems compatible with my software and I am guessing it's backwards compatible. I wonder if they did not also correct the screen artifacts as I haven't noticed it since the upgrade.
I also designed this simple driver to control that old Transco transfer relay I had. The relay is a latching type that runs from 28V. So the board is a DC-DC boost converter and a couple of one-shots made out of a hex inverter. It just runs from the same FTDI TTL cable. This relay works really well. Isolation is no longer a problem. They are fairly common in the used market for under $100. PN is 700C70200.
-
There is fixed spike at 300 MHz for measurements in the latest firmware.
Also now it allows to measure up to 1500 MHz. It has higher error above 1200 MHz, but still can be used for antenna tuning.
Also added battery indicator. It shows empty battery, if you want to use it, you're needs to install diode on the pcb. See picture above.
Also I hear that there is added command which allows to get raw data with any desired point count, but with no calibration. It can be used for measurements on PC with custom calibration process. But I'm not sure if this command is present in this firmware (didn't test it yet), may be it will be available in the next release.
-
So now of course I wonder if I have a 1. Older unit, 2. Newer unit, 3. Unfinished Older unit, or 4. Unfinished Newer unit?
I know about this version. People install home made shielding and it works the same as other units. But no shielding may affect measurement results.
So, you can ask partial refund for missing shielding and make it self. This version even better, because it has continuous shielding pads around mixers area, while old units have just small pads (it leads to worse shielding).
-
I received the following link from the seller of my NanoVNA: https://github.com/ttrftech/NanoVNA?tdsourcetag=s_pcqq_aiomsg
I don't see how he would think that this would be of any interest to me, but perhaps it is to a software guy(?). Its a public post, so probably nothing new to those that follow this web site.
-
I have yet to try running it above 900M. The calibration would not be a problem as I do this with the PC. Running a T-check above 500MHz even with the higher quality Transco relay doesn't yield good results. I have a few filters that work in that 900M to 1.5G region that I'll try with it.
I'll look into their higher resolution scanning. I had just assumed this was a limit due to the hardware. I assume it proportionally slows down the scans but it may be faster than my segmented scanning.
For now I am more interested in seeing them fix some of the problems. After watching the Nano's display, it appears the artifacts (left over segments from a previous scan) are still there. However, the new firmware continues to be glitch free. By far, this was the best change IMO they made to the firmware.
The unit I have always had a problem at 300MHz. Above 300 the results are pretty much what you would expect from a $50 unit.
Showing data I had collected using the July firmware compared with with the Sep release. The data was collected using the same cables and 50 ohm load. Note that the instability around the 300MHz is reduced.
-
I'll look into their higher resolution scanning. I had just assumed this was a limit due to the hardware. I assume it proportionally slows down the scans but it may be faster than my segmented scanning.
the new command doesn't apply calibration to the result. It returns just a raw measurements. You're needs to calculate calibration coefficients and apply it on the PC.
The unit I have always had a problem at 300MHz. Above 300 the results are pretty much what you would expect from a $50 unit.
My unit also had a high spike at 300 MHz. With the latest firmware from 20 september it is fixed.
-
I'll look into their higher resolution scanning. I had just assumed this was a limit due to the hardware. I assume it proportionally slows down the scans but it may be faster than my segmented scanning.
the new command doesn't apply calibration to the result. It returns just a raw measurements. You're needs to calculate calibration coefficients and apply it on the PC.
From my previous post:
The calibration would not be a problem as I do this with the PC.
This is how I was able to use the transfer relay to perform full 2-port measurements. As I stated, it's really no problem. The attached pictures show an interdigital filter being swept above 900M. Seems to work. I'll play with it more later.
The unit I have always had a problem at 300MHz. Above 300 the results are pretty much what you would expect from a $50 unit.
My unit also had a high spike at 300 MHz. With the latest firmware from 20 september it is fixed.
From your previous post,
There is fixed spike at 300 MHz for measurements in the latest firmware.
I interpreted fixed to mean recurring or stationary at 300M, not meaning they improved it. Good to know that your unit also shows improvements.
-
I made an attempt to try the Scan command using the comments below. The Nano responds with a "?" which suggests that it does not understand the command or the syntax is invalid. I've been avoiding looking at the firmware but it appears that this is really the only source of documentation for it. Github seems to be down at the moment but I'll have another look later.
I added one command to the eddy firmware to enable on demand scans of
arbitrary length (yes, you can scan with one million steps or much more if you want)
Usage:
First pause the continuous scanning with "pause" and the use the "scan" command
to scan [from frequency in Hz] [increment frequency in Hz] [number of steps]
The frequency increment step is for now an integer
The scan command outputs
start
frequency s11_real s11_imag s21_real s21_imag
done
during the scan the calibration is NOT used so the output are uncalibrated numbers
allowing alternative calibration strategies
Example:
ch> pause
ch> scan 5000000 20 5
ch> start
5000000 0.001503840 0.000420701 -0.306770563 0.018568072
5000020 0.000695601 0.000503197 -0.306792527 0.018579231
5000040 0.000532656 0.000520238 -0.306793421 0.018573865
5000060 0.000495833 0.000512704 -0.306819111 0.018593480
5000080 0.000520689 0.000523833 -0.306812644 0.018576323
done
ch>
-
Typing Help, Scan is not listed as a valid command. Makes sense. Github was back up so I downloaded the source and had a look at Main.c
{ "gain", cmd_gain },
{ "power", cmd_power },
{ "sample", cmd_sample },
//{ "gamma", cmd_gamma },
//{ "scan", cmd_scan },
{ "sweep", cmd_sweep },
{ "test", cmd_test },
{ "touchcal", cmd_touchcal },
So while it looks like they may have considered adding this feature, it is not supported. There may have been no benefit to something like this versus using my segmented approach. Still, the upgrade is well worth it just for that one bug fix. The system is now fairly stable.
-
yeah, just tested, it is missing from the firmware 20-SEP-2019, so it will be added in the next release
-
After adding 900M-1.5G into the mix, the noise from 500M to 900M doesn't seem so bad. :-DD
Video clip showing the scatter plot:
https://www.youtube.com/watch?v=1xzNyqJ1T30&feature=youtu.be (https://www.youtube.com/watch?v=1xzNyqJ1T30&feature=youtu.be)
-
I have some abilities to filter the data. Shown with a simple smoother. There no penalty for the screen update rate as it ran across individual scans.
https://www.microwaves101.com/encyclopedias/smoothing-is-cheating (https://www.microwaves101.com/encyclopedias/smoothing-is-cheating)
I should mention that I have yet to try averaging the data. The problem is how slow the Nano is. Early on, I had tried a few things, like turning off all the traces to try and improve the sweep rates but it appeared to be fixed. With the new firmware, it's slightly faster because I no longer have to throttle the data rate to keep the Nano from sending bad data. Still, the improvements are not significant enough to try and average the data.
-
"NANOVNASAVER SOFTWARE WALKTHROUGH + NANOVNA FIRMWARE UPDATES BRING 1.5 GHZ MAX RANGE"
https://www.rtl-sdr.com/nanovnasaver-software-walkthrough-nanovna-firmware-updates-bring-1-5-ghz-max-range/ (https://www.rtl-sdr.com/nanovnasaver-software-walkthrough-nanovna-firmware-updates-bring-1-5-ghz-max-range/)
https://github.com/mihtjel/nanovna-saver (https://github.com/mihtjel/nanovna-saver)
https://github.com/ttrftech/NanoVNA (https://github.com/ttrftech/NanoVNA)
-
I compiled the firmware - not tested, yet - and it does compile without errors.
Attached for everyone's convinience.
Update: Just noticed i can't flash this, as it is not a DFU file! The instructions are wrong for compiling/flashing this. Don't want to use the ST-LINK V2 right now... :(
The FW that was linked a few posts earlier already increases apparently up to 1500MHz - I just did not try.
Also, while compiling works, I end up with a *.bin file instead of a *.dfu file. The difference is of course that teh DFU mode expects a file with the the corresponding headers, which are not present in the *.bin file. How do I compile a DFU file?
Regards,
Vitor
-
People still ask for my LabView interface but I'm not sure why. The open sourced Python seemed to really be what people were asking for and it certainly seems like they have made a progress with it. Anytime I've asked what features they are missing, I never get a response. They may just not be aware of the open source project.
-
That's the point: I first saw people asking for feature and considered it an opportunity to write a donation-based software.
But then I looked at the existing applications and found them to be of a pretty high quality, so I asked people what they were unhappy with.
The only one responding was you, mentioning the not so nice screen refreshing. Other than that, I got no reply.
Then I thought I could implement the single feature I was not seeing: being able to sweep with more than 101 points. While I did implement that (slow), I noticed that this project I linked today, already does that, too! And there are FW forks to implement the sweep command you mentioned.
This is why I basically gave up on developing anything for this device: there are already too good alternatives!
Regards,
Vitor
-
I added that narrow band or what I now call segmented sweep to increase the number of data points when I was working with SPICE and trying to get a decent demo going for that third video. It will be very interesting to see if this new high resolution sweep will improve things or is it going to be so slow it is useless (much like my segmented sweep).
I noticed they appear to have information about building the source with Windows but I haven't tried it. I did however get the screen to go white again today and had to power cycle the unit. So it's more robust but still could use some improvements.
Sigilent's website shows them taking orders for their new VNA. $3400 or so USD, without the cal kit, no TDR and no VNA software included. Look like you more into the $5K when it's all said and done. Plus you still have the problem of it not being a full 2-port system. Hoping this time around that they give the unit to people who can actually show the practical justification of the higher cost when compared with this $50 unit. :-DD
https://siglentna.com/spectrum-analyzers/sva1000x-spectrum-vector-analyzer/
-
TOKO America, PC# 4DFB-915E-10=P
Description Value
Maximum Insertion Loss 2.7 dB
Cut-off/Nominal Frequency Upper Range 800 to 1000 MHz
Cut-off/Nominal Frequency 915 MHz
Impedance 50 Ohm
Maximum Pass Band Ripple 1 dB
Operating Temperature -40 to 85 °C
Category Filter Misc
Manufacturer TOKO America
https://www.digchip.com/datasheets/parts/datasheet/484/TDFM2B-915E-10_P-pdf.php (https://www.digchip.com/datasheets/parts/datasheet/484/TDFM2B-915E-10_P-pdf.php)
-
I spoke too soon. While playing around with this filter, I had the screen once again turn white which required a power cycle to recover. Worse, I am once again seeing corrupt data sets. This is not just my software. I see it happen on the Nano's screen as well. Slowing it down does appear to help. Maybe it has something to do with the span, or the fact I am straddling the 900MHz region.
Oh well, I was being too optimistic. Hopefully the people working on the firmware can get something robust.
-
Sigilent's website shows them taking orders for their new VNA. $3400 or so USD, without the cal kit, no TDR and no VNA software included. Look like you more into the $5K when it's all said and done. Plus you still have the problem of it not being a full 2-port system.
You get what you pay for. Anyway standalone SA with S11+S21 3GHz VNA for $4000 is hellova good offer.
Hoping this time around that they give the unit to people who can actually show the practical justification of the higher cost when compared with this $50 unit.
Perhaps manufacturers which are looking for dependable instrument having better than 60 70dB dynamic range? ;) Not even mentioning freq range. Of course - many hobbyists are fine with nanoVNA, but not every buyer of VNA is hobbyist.
[edit] Comparison of $50 vs $50000 VNA: https://nuclearrambo.com/wordpress/comparing-nanovna-with-the-keysight-fieldfox-n9952a/ (https://nuclearrambo.com/wordpress/comparing-nanovna-with-the-keysight-fieldfox-n9952a/)
-
Sigilent's website shows them taking orders for their new VNA. $3400 or so USD, without the cal kit, no TDR and no VNA software included. Look like you more into the $5K when it's all said and done. Plus you still have the problem of it not being a full 2-port system. Hoping this time around that they give the unit to people who can actually show the practical justification of the higher cost when compared with this $50 unit. :-DD
https://siglentna.com/spectrum-analyzers/sva1000x-spectrum-vector-analyzer/
You are an optimistic man if you think the Nano will get to 3.2 GHz :)
The nano is a nice 300MHz device.
Also you might have missed this:
"Vector Network Analysis from 10 MHz – 1.5 GHz / 100 kHz – 3.2 GHz (Now included as standard)"
-
3.2 GHz is good. But 1.5 GHz for 50 USD is good enough for a radio amateurs
-
[edit] Comparison of $50 vs $50000 VNA: https://nuclearrambo.com/wordpress/comparing-nanovna-with-the-keysight-fieldfox-n9952a/ (https://nuclearrambo.com/wordpress/comparing-nanovna-with-the-keysight-fieldfox-n9952a/)
That review raises an interesting point. They observe that the nano performs worse when used in full span. I've noticed this as well.
A user on another forum explained it in SA terms. Where a narrow span on an SA has a lower noise floor due to a narrow RBW being used.
That theory makes no sense. There is no variable filtering in the nano and the sampling is the same regardless of span as far as I can tell.
However wider spans with the same number of points take larger frequency steps. I wonder if the Si chip needs a longer time to settle when making larger frequency jumps? Maybe simply increasing the wait time prior to sampling will improve things in wide spans?
-
Yes, all PLL synthesizers take longer to settle when the frequency jump is larger. And yes, the nanoVNA will eventually reach 3GHz (and at a similar price I've heard). I know definitely that it's going to be based on the adf4350 + si5351.
-
Yes, all PLL synthesizers take longer to settle when the frequency jump is larger. And yes, the nanoVNA will eventually reach 3GHz (and at a similar price I've heard). I know definitely that it's going to be based on the adf4350 + si5351.
Good point - I was referring to the current hardware obviously.
I expect the adf4350 version will be far superior to the current one above 300MHz.
Edit: But still not in the same class as the SVA family.
-
And yes, the nanoVNA will eventually reach 3GHz (and at a similar price I've heard). I know definitely that it's going to be based on the adf4350 + si5351.
To me "same price" seems to be way too optimistic. ADF4350 is expensive, VNA needs two. SA612 (3pcs) also have to be replaced with better mixers, like LT5560 or similar. Where we can follow information about next generation of nanoVNA? Any pointers?
-
I wonder if the Si chip needs a longer time to settle when making larger frequency jumps?
yes, large frequency jump needs to reset PLL, it takes some time for PLL lock. But it works fast enough.
-
ADF4350 costs about $0.4 each. I've seen the design and the 3 mixers are replaced with one higher spec mixer that is switched between the 3 channels. A variable gain amplifier is added at baseband using one opamp and switched feedback resistors for improved dynamic range. Audio codec is removed and the stm32 built in ADC is used instead. So overall there are quite a few components removed compared to V1 but I heard the performance should be comparable or better.
EDIT: mixer is probably going to be the ad8342.
-
Audio codec is removed and the stm32 built in ADC is used instead.
This change will reduce ADC dynamic range from 100 dB to 70 dB. So, it seems that the new NanoVNA will be worse...
-
ADF4350 costs about $0.4 each.
Where exactly you can get (genuine & new) ADF4350 for 0.4$? AD web: $6.05 @1000+
I've seen the design and the 3 mixers are replaced with one higher spec mixer that is switched between the 3 channels.
Right, MiniVNA Tiny. Existence of such design does not mean it is good. Problem with such approach - leakage through switches. Search this forum to see how bad this VNA actually is.
A variable gain amplifier is added at baseband using one opamp and switched feedback resistors for improved dynamic range. Audio codec is removed and the stm32 built in ADC is used instead.
Again - do not agree to such design decision. ADC of stm32 have barely 11 bit ENOB and 69dB SNR. Such VGA-augmented ADC will have worse linearity and temperature stability comparing to literally any generic audio ADC. Not to mention that VGA acting as part of ADC may slow sampling speed down because some/many points needs to be sampled at least 2 times while correct VGA gain is found.
-
ogden, there is also nightmare to capture samples with proper sample rate and low jitter with integrated ADC.
-
ogden, there is also nightmare to capture samples with proper sample rate and low jitter with integrated ADC.
This is not audio application, thus "right" sample rate is not required. Just pick closest to target number sample rate (round to ADC clock) and that's it. Yes, clock PLL of stm32 have inherent jitter which may ruin your day in high sample rate ADC applications, yet in this case it is low <= 50KSPS, ENOB of ADC is low. So ADC aperture jitter (https://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4466.html) is not an issue. Yet anyway it is good idea to use new generation "stm32" IC's with improved clock jitter specs, rather than for example stm32l072 with it's +/- 600ps.
-
Sigilent's website shows them taking orders for their new VNA. $3400 or so USD, without the cal kit, no TDR and no VNA software included. Look like you more into the $5K when it's all said and done. Plus you still have the problem of it not being a full 2-port system.
You get what you pay for. Anyway standalone SA with S11+S21 3GHz VNA for $4000 is hellova good offer.
Hoping this time around that they give the unit to people who can actually show the practical justification of the higher cost when compared with this $50 unit.
Perhaps manufacturers which are looking for dependable instrument having better than 60 70dB dynamic range? ;) Not even mentioning freq range. Of course - many hobbyists are fine with nanoVNA, but not every buyer of VNA is hobbyist.
[edit] Comparison of $50 vs $50000 VNA: https://nuclearrambo.com/wordpress/comparing-nanovna-with-the-keysight-fieldfox-n9952a/ (https://nuclearrambo.com/wordpress/comparing-nanovna-with-the-keysight-fieldfox-n9952a/)
For my hobby, I would most likely buy a used 8753. Siglent isn't on the radar yet.
I would have expected the people making reviews for the Siglent products to compare them against these low cost analyzers. Instead, all the videos I saw for Siglent were fairly basic. I am suggesting they up their game.
-
For my hobby, I would most likely buy a used 8753. Siglent isn't on the radar yet.
Oh.. Fine choice indeed. I believe that you have to get extremely lucky to find such in working condition for a "hobbyist-friendly price".
I would have expected the people making reviews for the Siglent products to compare them against these low cost analyzers. Instead, all the videos I saw for Siglent were fairly basic.
Considering that Siglent is new kid in the VNA block, perhaps their reviewers are such as well :D
-
3.2 GHz is good. But 1.5 GHz for 50 USD is good enough for a radio amateurs
It does seem that most people who have written me are indeed amateur radio operators. I would have guessed 300MHz would have covered most of their needs. No doubt that the Nano does seem to fill some void for that group. When Dave made his Siglent review, he makes a point about the amateurs being a potential market.
If Siglent wants to gain some of that market, they need to make videos showing practical reasons why an amateur would buy their product over a $50 Nano.
Sigilent's website shows them taking orders for their new VNA. $3400 or so USD, without the cal kit, no TDR and no VNA software included. Look like you more into the $5K when it's all said and done. Plus you still have the problem of it not being a full 2-port system. Hoping this time around that they give the unit to people who can actually show the practical justification of the higher cost when compared with this $50 unit. :-DD
https://siglentna.com/spectrum-analyzers/sva1000x-spectrum-vector-analyzer/
You are an optimistic man if you think the Nano will get to 3.2 GHz :)
The nano is a nice 300MHz device.
Also you might have missed this:
"Vector Network Analysis from 10 MHz – 1.5 GHz / 100 kHz – 3.2 GHz (Now included as standard)"
I didn't notice that they now include the VNA software.
I'm not sure where they are heading with the Nano or next generation. My friend bought these just for learning. From my own home use, I would more than likely pull the trigger on a used HP to replace my 1970s one. 3GHz would not be a problem.
However wider spans with the same number of points take larger frequency steps. I wonder if the Si chip needs a longer time to settle when making larger frequency jumps? Maybe simply increasing the wait time prior to sampling will improve things in wide spans?
I wonder if this is part of the problem I saw with that last test. I would assume most noticed that that data was always corrupt in the area leading up to 900MHz. Once it reached 900, the data was stable. Hopefully the people putting the firmware together are aware of these problems and are able to solve them.
-
For my hobby, I would most likely buy a used 8753. Siglent isn't on the radar yet.
Oh.. Fine choice indeed. I believe that you have to get extremely lucky to find such in working condition for a "hobbyist-friendly price".
I would have expected the people making reviews for the Siglent products to compare them against these low cost analyzers. Instead, all the videos I saw for Siglent were fairly basic.
Considering that Siglent is new kid in the VNA block, perhaps their reviewers are such as well :D
For my personal use, the $5K USD spent on a Siglent would cover the cost of a used HP that would more than fit my needs. But I am used to buying used TE and restoring it. Actually, my antique HP still fits most of my needs which is why I have not replaced it.
I would say that your last statement is spot on. IMO, this is not how you want to market your new line of products.
-
However wider spans with the same number of points take larger frequency steps. I wonder if the Si chip needs a longer time to settle when making larger frequency jumps? Maybe simply increasing the wait time prior to sampling will improve things in wide spans?
I wonder if this is part of the problem I saw with that last test. I would assume most noticed that that data was always corrupt in the area leading up to 900MHz. Once it reached 900, the data was stable. Hopefully the people putting the firmware together are aware of these problems and are able to solve them.
Possible explanation in nanovna-users@groups.io post:
hugen@...Aug 5 #719
The si5351 manual shows that the internal VCO operates at a maximum of 900MHz and a 4-divide-frequency output with a maximum frequency of 225MHz. In order to output a frequency of 300MHz, the internal VCO needs to be overclocked to 1200MHz. Not every si5351 can be stably overclocked to 1200MHz. As the temperature increases, the internal VCO operating limit frequency of the si5351 will decrease. If you notice a significant spike(>0dB) in your nanoVNA at 300 MHz or 900 MHz, I recommend that you use the 800MHz firmware.
-
This change will reduce ADC dynamic range from 100 dB to 70 dB. So, it seems that the new NanoVNA will be worse...
No, the VGA will extend dynamic range to 100dB, plus ADC dynamic range is nowhere near being the bottleneck anyway.
Where exactly you can get (genuine & new) ADF4350 for 0.4$? AD web: $6.05 @1000+
Not my decision. I just heard this from the internal chat group.
Right, MiniVNA Tiny. Existence of such design does not mean it is good. Problem with such approach - leakage through switches. Search this forum to see how bad this VNA actually is.
Please do not jump to conclusions before you've seen the design. There are 3 stages of switches between the reflection path and the receiver, for a total switch isolation of 90dB.
The bottleneck of the dynamic range is actually the common mode inductance of the two edge mount SMA connectors, and this can't be improved much other than separating the two ports as far as possible. All low cost USB VNAs on the market currently suffers from this problem and is why they are all limited to a dynamic range of around 70dB < 1GHz and 50dB at 3GHz.
Again - do not agree to such design decision. ADC of stm32 have barely 11 bit ENOB and 69dB SNR. Such VGA-augmented ADC will have worse linearity and temperature stability comparing to literally any generic audio ADC. Not to mention that VGA acting as part of ADC may slow sampling speed down because some/many points needs to be sampled at least 2 times while correct VGA gain is found.
See above - ADC dynamic range is far from being the bottleneck. If the ADC is sampling at 1Msps and the VBW is 1kHz, a 60dB ADC dynamic range leads to a 90dB measurement dynamic range, which is more than sufficient. What makes you think autoranging is slow? A typical measured transfer function is fairly smooth and in practice you likely won't ever see more than 5 to 10 autoranging events per sweep, which is equivalent to adding 10 points to a 100 point sweep.
-
And before you jump in and say RF switches are expensive - https://item.szlcsc.com/270817.html
-
If the ADC is sampling at 1Msps and the VBW is 1kHz, a 60dB ADC dynamic range leads to a 90dB measurement dynamic range, which is more than sufficient.
Oversampling cannot eliminate non-linear distortions of a cheap ADC. If you will be able to get good results with integrated ADC it will be nice win, none can do it. This is why all using external codec.
-
Where exactly you can get (genuine & new) ADF4350 for 0.4$? AD web: $6.05 @1000+
Chinese clones are much cheaper :)
-
I have a prototype of a NanoVNA variant using the built in ADC on the stm32. The measurements using it are nearly identical to the audio codec variant. The reason all NanoVNAs on the market do not use this version is because of software compatibility.
-
I just got more info about the baseband VGA design; a RFIC switch is used to switch the shunt resistor in the feedback path. The switch is basically "transparent" because the off state capacitance is in the femtofarad range (it is an RF switch) which is negligible at the IF frequency. The on state resistance is small compared to the resistors being switched in. Since the amplifier gain is mainly dictated by the feedback network, and the switch is "transparent", there is nothing other than the tempco of the physical resistors that can cause a temperature dependence. The RFIC used is the same as for the receiver RF switch, and it turns out all the maxscend switches do not have the shunt diode problem (most RF switch ICs have parasitic diodes from RF input to ground which will start to conduct at lower frequencies), so it has no theoretical lower frequency limit and can be applied at the IF frequency. This is a big improvement over using normal analog switch ICs which have capacitance in the pF range.
EDIT: also asked about linearity. The answer is that the code will perform a calibration of each VGA step on boot up. Since there is no temperature dependence the calibration only needs to happen once.
-
Here is a preliminary block diagram of the design:
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=841782;image)
-
The bottleneck of the dynamic range is actually the common mode inductance of the two edge mount SMA connectors, and this can't be improved much other than separating the two ports as far as possible.
I am not sure about this one, but whatever... as you they say. At least put connectors on the long edge of the device.
All low cost USB VNAs on the market currently suffers from this problem and is why they are all limited to a dynamic range of around 70dB < 1GHz and 50dB at 3GHz.
Not all. Here's one with 90dB dynamic range with close enough connectors, thou those do not seem like edge mount: https://www.sdr-kits.net/introducing-DG8SAQ-VNWA3 (https://www.sdr-kits.net/introducing-DG8SAQ-VNWA3) 95dB: https://www.megiq.com/products/vna-0440 (https://www.megiq.com/products/vna-0440)
If the ADC is sampling at 1Msps and the VBW is 1kHz, a 60dB ADC dynamic range leads to a 90dB measurement dynamic range, which is more than sufficient.
Oversampling is solution, agreed. Thou at 1Msps you run into ADC aperture jitter problems that adds phase noise to measurements unless you run all stm32 clocks from XO, let's say at 24MHz w/o any PLL.
[edit] I do not buy "common mode inductance of SMA connectors". Most likely they blame connectors while actual problem is internal leakage/reflections. Look how close are connectors for Keysight P5008A which have 140dB dynamic range and better than 140dB crosstalk figures up-to 26GHz.
Where do we sign-up for beta testing?
-
All low cost USB VNAs on the market currently suffers from this problem and is why they are all limited to a dynamic range of around 70dB < 1GHz and 50dB at 3GHz.
Not all. Here's one with 90dB dynamic range with close enough connectors, thou those do not seem like edge mount: https://www.sdr-kits.net/introducing-DG8SAQ-VNWA3 (https://www.sdr-kits.net/introducing-DG8SAQ-VNWA3)
Covering 1 kHz to 1.3 GHz and powered from a PC USB-bus, the VNWA 3 offers a dynamic range of 90dB up to 500 MHz and better than 50dB above 500 MHz.
That sounds about right. It's either common mode inductance or radiated leakage from the exposed center pin depending on your point of view (they are two sides of the same phenomenon which is that E fields wander to the outer face of the coaxial shield). It's pretty well known to anyone designing network analyzers. IIRC the xaVNA full two port version had some solder between the SMA connector body and a shield can to reduce this leakage path, but even then it only got to something like 60-70dB dynamic range at 3GHz. Below 1GHz it's easy to hit 90-100dB dynamic range. The solution is a specific kind of surface mount SMA connector where the center conductor is fully enclosed.
-
I had a play with a certain full two port VNA prototype once, and was surprised how much of the leakage I can remove just by grabbing the outer body of the SMA connector. The leakage floor can go down by 20dB (to 90dB dynamic range) at >3GHz if you grab both connectors. OTOH if you touch both connectors to a piece of metal (just the outer body - the center pin is unconnected) you can see the leakage shoot up 10-20dB. From that it's pretty obvious the leakage path has to do with currents travelling on the outer face of the coax structure.
-
All low cost USB VNAs on the market currently suffers from this problem and is why they are all limited to a dynamic range of around 70dB < 1GHz and 50dB at 3GHz.
Not all. Here's one with 90dB dynamic range with close enough connectors, thou those do not seem like edge mount: https://www.sdr-kits.net/introducing-DG8SAQ-VNWA3 (https://www.sdr-kits.net/introducing-DG8SAQ-VNWA3)
Covering 1 kHz to 1.3 GHz and powered from a PC USB-bus, the VNWA 3 offers a dynamic range of 90dB up to 500 MHz and better than 50dB above 500 MHz.
That sounds about right. It's either common mode inductance or radiated leakage from the exposed center pin depending on your point of view (they are two sides of the same phenomenon which is that E fields wander to the outer face of the coaxial shield).
No. Mainly it's because of harmonics mode above 500Mhz because signal source is DDS. Of course leakage could be contributor as well. Main problem of those "DIY" or "commercial low cost" VNA's that can't reach 90dB isolation - insufficient shielding and failure to follow even basic RF design/layout rules. Screaming example of how not to design VNA is already mentioned MiniVNA Tiny. I really hope design of next gen nanoVNA will not fall into same traps.
-
I had a play with a certain full two port VNA prototype once, and was surprised how much of the leakage I can remove just by grabbing the outer body of the SMA connector. The leakage floor can go down by 20dB (to 90dB dynamic range) at >3GHz if you grab both connectors. OTOH if you touch both connectors to a piece of metal (just the outer body - the center pin is unconnected) you can see the leakage shoot up 10-20dB. From that it's pretty obvious the leakage path has to do with currents travelling on the outer face of the coax structure.
That's PCB design (layout/shielding), not connector "common mode" problem. Get access to proper VNA like Keysight or R&S to see that touching connectors do not change ANYTHING. Also you are advised to check Signal Path youtube episodes of VNA teardowns (https://youtu.be/665-hwI8reQ?t=1268) - those instruments are riddled with connectors and cables, yet still reach significant dynamic range.
-
No, I do not need to spend $$$ to see what is easily shown with a simple test board. The professional test equipment do not use this style of edge mount SMA connector, and that is exactly why low cost network analyzers have trouble reaching high dynamic range. I have prototypes and test boards that show plain evidence of connector leakage, and I can assure you the NanoVNA team know what they are doing.
EDIT: V2 has far better PCB layout design compared to V1, and I can guarantee you the bottleneck is not going to be internal leakage.
-
See here:
Notice the mounting of the connector. Details like this do matter and with just one bad leakage path you are not going to get >50dB dynamic range at 3GHz no matter how good your PCB design is. The xaVNA full two port is a testament to this as it has very little internal leakage (proven by removing all connectors) but the dynamic range with connectors and inside its enclosure is not that great. Ironically the dynamic range is improved when you remove the board from the aluminum enclosure (the creators even admit this); do you know why this is?
-
The professional test equipment do not use this style of edge mount SMA connector, and that is exactly why low cost network analyzers have trouble reaching high dynamic range.
They mostly use flange mount connectors for internal modules, yet performance of those do not differ from edge-mount/edge-launch SMA connectors when latter are properly shielded. Manufacturers obviously just pick right connector and do not invent shielding transition for connector which is not made for such. Whatever. - Why don't use angled trough hole mount connectors then?
I have prototypes and test boards that show plain evidence of connector leakage
Nah. I see plain evidence that horizon is flat, so what? [kidding] - Unlikely you have chamber and equipment for leakage measurements.
EDIT: V2 has far better PCB layout design compared to V1, and I can guarantee you the bottleneck is not going to be internal leakage.
Good to hear that. How many PCB layers? Where do we sign for beta testing? :)
-
The xaVNA full two port is a testament to this as it has very little internal leakage (proven by removing all connectors) but the dynamic range with connectors and inside its enclosure is not that great.
Indeed. It is clear that he missed to put (legs of) connectors in the shield. Port1 and port2 have connector center legs, some components and quite a transmission line length in common cavity which is main enclosure. That is "no no". I will say it last time - shielding can of particular channel shall cover everything including legs of the connector. [edit] Unfortunately xaVNA is also example of how not to design VNA.
Ironically the dynamic range is improved when you remove the board from the aluminum enclosure (the creators even admit this); do you know why this is?
Reflections. They forgot to put RF/microwave absorber foam inside aluminium enclosure.
(https://xaxaxa-dev.com/images/vna_tr_2.jpg)
-
Commercial VNA's do not have any TX or RX component or trace or even connector leg exposed into enclosure or outside world. RF PCB is covered by CNC-machined shield of many submodule cavities from both sides.
https://youtu.be/HxBcQDooAYs?t=1333 (https://youtu.be/HxBcQDooAYs?t=1333)
Relevant article:
https://www.edn.com/electronics-blogs/the-practicing-instrumentation-engineer/4418080/Shields-are-your-friend--except-when- (https://www.edn.com/electronics-blogs/the-practicing-instrumentation-engineer/4418080/Shields-are-your-friend--except-when-)
-
Hi,
I am still new to VNA measurements and started yesterday to do a calibration of my device.
I have the latest FW installed and I can understand some of the steps in calibration, but not all:
OPEN --> connect open header to CH0
SHORT --> connect storted header to CH0
LOAD --> connect 50 Ohmn terminator header to CH0
ISOLN --> what do I have to do here?
THRU --> my guess is I straight connect CH1 to CH0?
DONE --> finish!
Why do I have to do a RESET first? So that measurements are done without any previous calibration? Makes sense, I guess...
Am I correct that CAL should be performed using the same cables that will be used for measurement? Makes sense, because the length will/can determine phase shifts, right?
If these questions are too basic for this thread, I can ask them in a separate topic - I don't want to hijack this nice thread, but I thought that it does generally fit in here.
Thanks,
Vitor
-
Hi,
I am still new to VNA measurements and started yesterday to do a calibration of my device.
I have the latest FW installed and I can understand some of the steps in calibration, but not all:
OPEN --> connect open header to CH0
SHORT --> connect storted header to CH0
LOAD --> connect 50 Ohmn terminator header to CH0
ISOLN --> what do I have to do here?
THRU --> my guess is I straight connect CH1 to CH0?
DONE --> finish!
Why do I have to do a RESET first? So that measurements are done without any previous calibration? Makes sense, I guess...
Am I correct that CAL should be performed using the same cables that will be used for measurement? Makes sense, because the length will/can determine phase shifts, right?
Yes always try and calibrate at the end of the test cable _and adapters_ you will connect to the DUT. Not always possible of course - if you don't have cal kits for Male and Female you will need to use an adapter. Then you are exposed to any phase and amplitude effects of the adapter. It is possible to correct for that and different methods can be used which have different levels of accuracy.
The Reset clears the data arrays on the device. It's generally a good idea as the firmware isn't perfect, and it also allows you to ignore the ISOLN step if you want to. Otherwise it would probably apply the ISOLN correction from the last cal you did.
For ISOLN you are supposed to put a terminator (load) on both ports. That correction is only applied to the thru measurements - S21.
For a 1 port measurement (CH0) you only need to do Short, Open and Load then Done.
If using the original NanoVNA app _on a PC_, then it is important to do it in the sequence Short Open Load for the best accuracy. Because the Short button also does a Reset. So if you do the Open first and the Short second, then the Open sweep is discarded. This results in a 0.3 dB error approximately.
Middle chart in this link shows this issue: https://github.com/hendorog/nanovna_test/blob/master/NanoVNA%20test.ipynb
-
Ok, dumb question (but serious). I've never owned or used state-of-the-art equipment, but what kind of application requires the ability to measure better than 50dB of return loss? Best I've used is probably 70dB. If I can achieve 20 dB S11 over a wide operating frequency, I'm pretty happy. I can understand if you are doing some kind of advanced science experiment, that you would need >90dB of measurement range, but aside from that, what practical use is it? Examples?
-
However wider spans with the same number of points take larger frequency steps. I wonder if the Si chip needs a longer time to settle when making larger frequency jumps? Maybe simply increasing the wait time prior to sampling will improve things in wide spans?
I wonder if this is part of the problem I saw with that last test. I would assume most noticed that that data was always corrupt in the area leading up to 900MHz. Once it reached 900, the data was stable. Hopefully the people putting the firmware together are aware of these problems and are able to solve them.
Possible explanation in nanovna-users@groups.io post:
hugen@...Aug 5 #719
The si5351 manual shows that the internal VCO operates at a maximum of 900MHz and a 4-divide-frequency output with a maximum frequency of 225MHz. In order to output a frequency of 300MHz, the internal VCO needs to be overclocked to 1200MHz. Not every si5351 can be stably overclocked to 1200MHz. As the temperature increases, the internal VCO operating limit frequency of the si5351 will decrease. If you notice a significant spike(>0dB) in your nanoVNA at 300 MHz or 900 MHz, I recommend that you use the 800MHz firmware.
If you look at the data it's not a spike at 300/900 as this person describes. It appears more like random noise leading up to 900MHz, then it clears up once it goes beyond 900MHz. Considering the amount of time I ran below 900MHz without a problem, I suspect it has something to do with the frequency range being swept but I haven't had time to look into it further.
I made an attempt to get the Windows tools setup, unsuccessfully.
-
They mostly use flange mount connectors for internal modules, yet performance of those do not differ from edge-mount/edge-launch SMA connectors when latter are properly shielded. Manufacturers obviously just pick right connector and do not invent shielding transition for connector which is not made for such. Whatever. - Why don't use angled trough hole mount connectors then?
Yes so that is my point too; with these common edge mount connectors there is NO way to fully shield it, but all low cost VNAs (under $500) on the market uses these. The through hole SMA connectors have a worse problem - the center pin is long and sticks out which creates an antenna.
Be realistic and don't suggest milled enclosures. You know that is a no-go at this price point. We have to work with commodity parts with reasonable cost, so specialized connectors designed for shielding are also a no-go. If you think you can do a better job then go design and sell your own VNA.
That picture you posted is not the full two port version; the only pictures that exist of it are in a few kickstarter updates. You can see the shielding that covers the two SMA connectors, but even that's insufficient entirely because of that tiny slot between the connector body and the shield can. That is where they added a blob of solder in production.
-
The V2 PCB is 4 layers. The schematics will be posted soon, at the same time as the launch on taobao, but you can DM me if you want to see it right now.
-
Indeed. It is clear that he missed to put (legs of) connectors in the shield. Port1 and port2 have connector center legs, some components and quite a transmission line length in common cavity which is main enclosure. That is "no no". I will say it last time - shielding can of particular channel shall cover everything including legs of the connector.
How exactly do you put those things inside a shield? As I said earlier simply putting the shield over the connector legs is not sufficient (found experimentally), and you actually have to form a connection between the connector body and shield can body. It's easy to say "you must achieve this" but have you actually tried designing a fully shielded VNA while keeping BOM cost below $100 and have it be manufacturable? Point me to a VNA below $500 that does it correctly as you say. Or are you saying all low cost network analyzers on the market are crap?
Edit: so we are arguing the same point, which is that leakage from the SMA connector center pin trace is significant (assuming the PCB is designed correctly and everything else is shielded). Where I disagree is I think none of the edge mount SMA connectors on the market are actually fully shieldable, and that is why high end test equipment do not use edge mount connectors. If you can find me a picture of a shielded edge mount connector on a PCB that would be great.
-
Indeed. It is clear that he missed to put (legs of) connectors in the shield. Port1 and port2 have connector center legs, some components and quite a transmission line length in common cavity which is main enclosure. That is "no no". I will say it last time - shielding can of particular channel shall cover everything including legs of the connector.
How exactly do you put those things inside a shield?
For example - by using trough-hole mount angled connector (attach), mounting it from bottom side so legs can be fully covered by shield lid. If angled SMA for any reason cannot be used and you want to use ultracheap edge mount by all means - order shielding can lid with cutout for connector legs (read below).
The through hole SMA connectors have a worse problem - the center pin is long and sticks out which creates an antenna.
It is no concern considering that you put it's legs under shield. That 1mm does not do much for planned frequencies anyway, owner or naked nude virgins can cut it if any concerns. Siglent did not care about it in front connector board of VNA (picture you posted).
As I said earlier simply putting the shield over the connector legs is not sufficient (found experimentally), and you actually have to form a connection between the connector body and shield can body. It's easy to say "you must achieve this" but have you actually tried designing a fully shielded VNA while keeping BOM cost below $100 and have it be manufacturable? Point me to a VNA below $500 that does it correctly as you say.
NanoVNA-F. Only thing to improve - add EMI shielding braid between connector shield and can, or just generous amount of solder.
-
OWO,
I haven't seen any info about what screen size the NanoVNA 2 will be using. Hugen has posted in the past about prototyping with a 3.5-inch LCD and I would expect something that size or larger to keep up with the nanoVNA-F that is now being sold. Do you have any information you can share?
TKs, Herb
-
ISOLN --> what do I have to do here?
connect two 50 ohm terminators on both connectors.
If you don't have two, then connect one to CH1 and leave CH0 open.
THRU --> my guess is I straight connect CH1 to CH0?
yes
Why do I have to do a RESET first?
To clear old calibration and avoid mistake.
Am I correct that CAL should be performed using the same cables that will be used for measurement? Makes sense, because the length will/can determine phase shifts, right?
yes
-
I had some time to play with the tool chain again. I was able to rebuild Hugen79's source and program the image into the Nano using both a Windows 7 and Windows 10 system. The VNA reports the same version and as expected has the same problems as the image I downloaded. I was concerned about having a header with exposed pins hanging off the side and used these lower profile pins. I thought about running it vertical and notching the case but decided to go this route instead.
I spent some time reading the GNU license a few times along with the FAQ because I am sure that will come up at some point.
-
I tried several tests and it seems with my particular Nano, it will always fail at the frequencies leading to 900MHz. When sweeping below 900M, it seems to be VERY stable. When sweeping above 900M, it appears I can change the start to any value and the data will become corrupt. It seems to have nothing to do with my software (will happen stand alone). It tried to straddle 300M, 600M and 800M with a 100M span and saw no problems. It appears unique to 900M.
It will be difficult to understand how they derived some of their code with the sparse comments. It's also impossible for me to know if anyone else is seeing this problem. I randomly tried a few things and it appears that the problem could be improved. Shown with the original code (about 200 sweeps, several corrupt data sets) and last mods (roughly 1000 sweeps, first data set corrupt only.). Note that I had replaced the filter with a thru and I am not using any sort of calibration. Everything is set to the defaults with an 850 start and 950 stop. If your's has this same problem it is easy to reproduce. Just watch the screen for a few minutes.
I'll see if I can narrow the problem down further so maybe the real firmware guys can correct it. Then again, if it's just this one unit, it's hardly worth going after.
-
joeqsmith, I can suggest you to try the original NanoVNA firmware written by edy555:
https://github.com/ttrftech/NanoVNA
It works different. It seems that hugen79 removed some part of calibration calculations for some unknown reason. Also it uses different gain and frequency modes.
At a glance, original firmware from edy555 works with a much less noise. Also it seems more stable and has no flickering.
-
Just looked at (original) nanovna PCB to find out that decoupling capacitor is way too far from power pin, connecting trace is thin. This is popular decoupling error of many hobby projects using particular chip. In this application it may be critical. I suggest to add decoupling capacitor (sideways standing) between two red dots marked in attachment pic. I can't promise any performance improvements, yet you can try - who knows. There are few more improvements regarding si5351 which I would rather tell only in PM.
[edit] In case you are soldering sharpshooter, you can try to put decoupling cap directly between power and ground pins, they are pin7 & pin8.
-
I'll see if I can narrow the problem down further so maybe the real firmware guys can correct it. Then again, if it's just this one unit, it's hardly worth going after.
It seems like hardware problem (that may be fixable in software or not). Noticeably there are many traces w/o glitch. Then suddenly one or more traces have huge noise. We see that problem occur above 800MHz only when there are huge VCO tuning jumps. Seems like PLL is struggling to lock for some reasons in overclocking freq range or software do not wait long enough for PLL to lock, continue with measurement disregarding unlocked PLL. I have not seen source code - are there any PLL lock checks at all? I say that huge VCO freq jumps shall be followed by direct PLL lock status polling and only small steps shall be done using timeouts.
-
https://e2e.ti.com/blogs_/b/analogwire/archive/2019/08/23/so-what-is-a-vna-anyway?eloquaCampaignId=2522&utm_campaign=asc-dc-hsc-adc12dj5200RF-articleseries-wwe&utm_medium=email&utm_source=Eloqua#
-
FWIW, I just compiled the latest state of this repository https://github.com/ttrftech/NanoVNA . I had to get rid of 32 bytes of "info" text to prevent overflow when compiling. After installing the calibration was messed up. I did a cal. Looks great now. No glitches. I think the dynamic range @ 900 MHz might have improved.
[edit] I've attached a binary if someone else wants to test this build.
[edit] Forgot to mention a couple of other changes I made to compile the attached image:
Changed this:
static const I2SConfig i2sconfig = {
NULL, // TX Buffer
rx_buffer, // RX Buffer
AUDIO_BUFFER_LEN * 2,
NULL, // tx callback
i2s_end_callback, // rx callback
0, // i2scfgr
2 // i2spr
};
To This:
static const I2SConfig i2sconfig = {
NULL, // TX Buffer
rx_buffer, // RX Buffer
AUDIO_BUFFER_LEN * 2,
i2s_end_callback, // rx callback
0, // i2scfgr
2 // i2spr
};
Also, in the Makefile:
Changed from:
USE_OPT = -O2 -ggdb -fomit-frame-pointer -falign-functions=16 --specs=nano.specs -fstack-usage
To This:
USE_OPT = -O2 -ggdb -fomit-frame-pointer -falign-functions=16
And from:
USE_PROCESS_STACKSIZE = 0x200
To This:
USE_PROCESS_STACKSIZE = 0x1a0
[edit] I found that I needed to add D2 diode to get the new battery status indicator (added to repository on Sept 9th) in this firmware working.
-
radioactive, there is no need to make any changes in order to compile it with gcc. Probably you're using incorrect ChibiOS config
-
radioactive, there is no need to make any changes in order to compile it with gcc. Probably you're using incorrect ChibiOS config
That may be true. I was just documenting what I did. The firmware image I attached is definitely better on my device. I haven't seen any glitchy traces with this image. That could just be all the new changes that are in the repository. Once thing I could not get to compile was the I2SConfig struct as is.
Here is the error:
main.c:448:3: note: (near initialization for 'i2sconfig.i2scfgr')
main.c:448:3: error: initializer element is not computable at load time
main.c:448:3: note: (near initialization for 'i2sconfig.i2scfgr')
main.c:450:3: warning: excess elements in struct initializer
I'm using 'gcc-arm-none-eabi-7-2018-q2-update' toolchain.
[edit]
The change I made to the struct was based on looking at the definition for that struct. I'm not saying it definitely makes a difference or fixed any issues or even that it is correct. I needed to change it to get it to compile though.
-
I'll see if I can narrow the problem down further so maybe the real firmware guys can correct it. Then again, if it's just this one unit, it's hardly worth going after.
It seems like hardware problem (that may be fixable in software or not). Noticeably there are many traces w/o glitch. Then suddenly one or more traces have huge noise. We see that problem occur above 800MHz only when there are huge VCO tuning jumps. Seems like PLL is struggling to lock for some reasons in overclocking freq range or software do not wait long enough for PLL to lock, continue with measurement disregarding unlocked PLL. I have not seen source code - are there any PLL lock checks at all? I say that huge VCO freq jumps shall be followed by direct PLL lock status polling and only small steps shall be done using timeouts.
I believe this is the case. There is a lock flag but they do not appear to use it. Instead they appear to sprinkle delays in the code. How these delays were calculated does not appear in the comments. My simple view is that they should leverage that status bit but they may have some reason not to use it. With the code not being well documented, it's just a pure guess.
Looking at the data I show where the unit starts to settle down, I am playing with the delays.
radioactive, there is no need to make any changes in order to compile it with gcc. Probably you're using incorrect ChibiOS config
This seems to be the case. I just downloaded and it appears to build as is. I have it running in the Nano now with no changes.
-
From: ChibiOS/os/hal/templates/hal_i2s_lld.h
/**
* @brief Driver configuration structure.
* @note It could be empty on some architectures.
*/
typedef struct {
/**
* @brief Transmission buffer pointer.
* @note Can be @p NULL if TX is not required.
*/
const void *tx_buffer;
/**
* @brief Receive buffer pointer.
* @note Can be @p NULL if RX is not required.
*/
void *rx_buffer;
/**
* @brief TX and RX buffers size as number of samples.
*/
size_t size;
/**
* @brief Callback function called during streaming.
*/
i2scallback_t end_cb;
/* End of the mandatory fields.*/
} I2SConfig;
Code in the main.c in the repository:
static const I2SConfig i2sconfig = {
NULL, // TX Buffer
rx_buffer, // RX Buffer
AUDIO_BUFFER_LEN * 2,
NULL, // tx callback This appears to be wrong to me
i2s_end_callback, // rx callback
0, // i2scfgr
2 // i2spr
};
Again, it may not make any difference. My thinking is that the version of gcc I'm using might be catching an error here. What versions of gcc are you guys compiling with?
-
Lastest firmware from edy555, showing 1700 sweeps, not a single glitch. I have no idea if the software has other problems or improvements as I am only looking at this one test case. I'll play around with this version of code as time permits.
From the change log:
### v8.2.1-1.7.1 (2019-05-24)
-
The reason I reverted back to using gcc-arm-none-eabi-7-2018-q2-update:
https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile
Version 8 was painfully slow for a project I'm working on. They say it will be fixed in the next release.
-
The change I made to the struct was based on looking at the definition for that struct. I'm not saying it definitely makes a difference or fixed any issues or even that it is correct. I needed to change it to get it to compile though.
it seems that you're used SPIv1 instead of SPIv2
-
From: ChibiOS/os/hal/templates/hal_i2s_lld.h
you're needs to use ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h
-
Lastest firmware from edy555, showing 1700 sweeps, not a single glitch. I have no idea if the software has other problems or improvements as I am only looking at this one test case. I'll play around with this version of code as time permits.
Is it possible to rotate graph such a way to properly read vertical scale? Seems like it is more than 0dB at around 880MHz.. What is this? Measurement of bandpass filter or just noise floor? If noise floor then I'll pass on such VNA ;)
-
From: ChibiOS/os/hal/templates/hal_i2s_lld.h
you're needs to use ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h
Sorry, the file I posted before was not the one I was using. I am using ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h, but the problem I'm describing is still the same:
Trying to fit this from main.c :
static const I2SConfig i2sconfig = {
NULL, // TX Buffer //(1) tx pointer
rx_buffer, // RX Buffer //(2) rx pointer
AUDIO_BUFFER_LEN * 2, //(3) size_t
NULL, // tx callback //(4) tx pointer (this looks wrong)
i2s_end_callback, // i2s callback //(5) i2s_end_callback pointer
0, // i2scfgr //(6) int16
2 // i2spr //(7) int16
};
Into this: (original comments removed to make it easier to see the types)
ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h
typedef struct {
const void *tx_buffer; //(1) tx pointer
void *rx_buffer; //(2) rx pointer
size_t size; //(3) size_t
i2scallback_t end_cb; //(4) i2scallback end_cb pointer
int16_t i2scfgr; //(5) i2scfgr int16
int16_t i2spr; //(6) i2spr int16
} I2SConfig;
It might work anyway. Or it might compile, but not be what was intended being stuffed in there. I haven't tried to analyze it much more than that. This is why I got the compiler error. There are 7 elements in the initializer, but the struct definition only has 6 elements. Am I missing something here?
Anyway, I'll leave it at that. I reverted all the changes I made from previous versions of the repository (when I first got the device). Everything from the current repository state compiles (I haven't tested an image this way yet) with gcc 7.xx, but not this error.
-
How do I flash these BIN files?
It should be a DFY file...
When I compiled the sources I got the BIN myself, but was not able to flash it?
Thanks,
Vitor
-
How do I flash these BIN files?
with ST-LINK
-
Into this: (original comments removed to make it easier to see the types)
you're looking wrong file. Here is struct definition from ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h
(I removed comments):
typedef struct {
const void *tx_buffer;
void *rx_buffer;
size_t size;
i2scallback_t tx_end_cb;
i2scallback_t rx_end_cb;
int16_t i2scfgr;
int16_t i2spr;
} I2SConfig;
here is init in the main.c:
static const I2SConfig i2sconfig = {
NULL, // TX Buffer
rx_buffer, // RX Buffer
AUDIO_BUFFER_LEN * 2,
NULL, // tx callback
i2s_end_callback, // rx callback
0, // i2scfgr
2 // i2spr
};
This is original code with no changes and initialization fit with struct declaration.
-
Sorry, the file I posted before was not the one I was using. I am using ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h, but the problem I'm describing is still the same:
Trying to fit this from main.c :
...
Into this: (original comments removed to make it easier to see the types)
ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.h
typedef struct {
const void *tx_buffer; //(1) tx pointer
void *rx_buffer; //(2) rx pointer
size_t size; //(3) size_t
i2scallback_t end_cb; //(4) i2scallback end_cb pointer
int16_t i2scfgr; //(5) i2scfgr int16
int16_t i2spr; //(6) i2spr int16
} I2SConfig;
It might work anyway. Or it might compile, but not be what was intended being stuffed in there. I haven't tried to analyze it much more than that. This is why I got the compiler error. There are 7 elements in the initializer, but the struct definition only has 6 elements. Am I missing something here?
Anyway, I'll leave it at that. I reverted all the changes I made from previous versions of the repository (when I first got the device). Everything from the current repository state compiles (I haven't tested an image this way yet) with gcc 7.xx, but not this error.
Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible.
typedef struct {
/**
* @brief Transmission buffer pointer.
* @note Can be @p NULL if TX is not required.
*/
const void *tx_buffer;
/**
* @brief Receive buffer pointer.
* @note Can be @p NULL if RX is not required.
*/
void *rx_buffer;
/**
* @brief TX and RX buffers size as number of samples.
*/
size_t size;
/**
* @brief Callback function called during streaming of TX.
*/
i2scallback_t tx_end_cb;
/**
* @brief Callback function called during streaming of RX.
*/
i2scallback_t rx_end_cb;
/* End of the mandatory fields.*/
/**
* @brief Configuration of the I2SCFGR register.
* @details See the STM32 reference manual, this register is used for
* the I2S configuration, the following bits must not be
* specified because handled directly by the driver:
* - I2SMOD
* - I2SE
* - I2SCFG
* .
*/
int16_t i2scfgr;
/**
* @brief Configuration of the I2SPR register.
* @details See the STM32 reference manual, this register is used for
* the I2S clock setup.
*/
int16_t i2spr;
} I2SConfig;
Lastest firmware from edy555, showing 1700 sweeps, not a single glitch. I have no idea if the software has other problems or improvements as I am only looking at this one test case. I'll play around with this version of code as time permits.
Is it possible to rotate graph such a way to properly read vertical scale? Seems like it is more than 0dB at around 880MHz.. What is this? Measurement of bandpass filter or just noise floor? If noise floor then I'll pass on such VNA ;)
Sure I can rotate to show the scale. You are correct, this is indeed a BP filter. I'm really just looking for the Nano to send up some corrupt data. I'll try running a few other tests with it. This version does appear a little slower (I am not currently measuring the Nano's response time) which I guess would make some sense if they are slowing down the scan to make it more stable.
-
Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible.
I see what is going on. I'm using the master branch for ChibiOS sub-module.
https://github.com/edy555/ChibiOS/blob/master/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h
You are probably using this one:
https://github.com/edy555/ChibiOS/blob/669d4bbc8da1ee0e4ccdf93a472b06d183922320/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h
Thanks. That explains that. I'll try that out. When I pulled the NanoVNA --recursive for the submodules, I got an error. I just cloned the referred ChibiOS manually.
[edit]
That was it. I can compile the latest source without any issues now. I've attached a binary of that. However, after testing it for a bit, I noticed that the traces did not look near as good as the binary I created from the older ChibiOS source earlier today. I'll do some more testing, but if someone else can compare the two images, it would be appreciated.
-
Bicurico,
If you are using the DfuSeDemo program on Windows to change firmware, then you have to first convert the "BIN" file to a "DFU" file. The "BIN" format is useable on LINUX and Apple systems using a command-line utility. Both formats are released together by some Moders as a convenience. I believe the DfuFileMgr program can be used to perform the conversion but I'm not certain.
Herb
-
Your .h file and the .h file I have are not the same or I am looking at the wrong file, which is possible.
I see what is going on. I'm using the master branch for ChibiOS sub-module.
https://github.com/edy555/ChibiOS/blob/master/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h
You are probably using this one:
https://github.com/edy555/ChibiOS/blob/669d4bbc8da1ee0e4ccdf93a472b06d183922320/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.h
Thanks. That explains that. I'll try that out. When I pulled the NanoVNA --recursive for the submodules, I got an error. I just cloned the referred ChibiOS manually.
[edit]
That was it. I can compile the latest source without any issues now. I've attached a binary of that. However, after testing it for a bit, I noticed that the traces did not look near as good as the binary I created from the older ChibiOS source earlier today. I'll do some more testing, but if someone else can compare the two images, it would be appreciated.
Good to hear we are now on the same page.
If I compare the hugen firmware with the edy555, I do see a difference in the data. The edy firmware appears to be less stable overall with more noise. The transition over the 900MHz crossover point it not as smooth. However, it doesn't seem to send corrupt data like the hugen firmware.
Both firmware shown with latest build. Both are stock, just clean builds from Git. Both are shown with the same 10dB attenuator being swept from 850 - 950MHz. Note that I only ran about half as many sweeps with the hugen firmware. You can also see the hugen firmware glitching as before as the frequency is be swept to the 900MHz switch point and then recovering. You can also see that the edy firmware once again is glitch free.
-
joeqsmith,
Would you mind comparing the results from this firmware image to the plots you just posted?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596) (latest edy555 source with older ChibiOS)
If I compare the hugen firmware with the edy555, I do see a difference in the data. The edy firmware appears to be less stable overall with more noise. The transition over the 900MHz crossover point it not as smooth. However, it doesn't seem to send corrupt data like the hugen firmware.
I would describe what I've observed about the same. The image with the older ChibiOS (above link) appears to have cleared up the glitchy traces as seen in the hugen image (I assume was shipped with my device), but looks like it is better data than either the current edy555 image (latest ChibiOS) or image that shipped with the unit I'm testing as it was shipped. Unfortunately, I accidentally deleted the firmware image that it shipped with even though I had backed it up. I have no idea what version, etc it was now.
[edit]
After more testing, no doubt about it for me now. The latest edy555 firmware, but with old ChibiOS (master branch) is definitely the way to go on my device. That was a nice accident.
-
Someone shall try to contact hugen, huh?
BTW you guys are testing same range again and again, 850-950. It's deep into "out of spec" range. I wonder how glitchty firmware performs in 570-950 range. Exact numbers are important because "roll over" frequency is within specs (<=225Mhz), 570/3=190, 950/5=190.
-
Bicurico,
If you are using the DfuSeDemo program on Windows to change firmware, then you have to first convert the "BIN" file to a "DFU" file. The "BIN" format is useable on LINUX and Apple systems using a command-line utility. Both formats are released together by some Moders as a convenience. I believe the DfuFileMgr program can be used to perform the conversion but I'm not certain.
Herb
That was it!
I did not notice there was a separate DfuFileMgr. It allows to convert from BIN to DFU, which is much more convenient than using STLink.
Regards,
Vitor
-
Someone shall try to contact hugen, huh?
BTW you guys are testing same range again and again, 850-950. It's deep into "out of spec" range. I wonder how glitchty firmware performs in 570-950 range. Exact numbers are important because "roll over" frequency is within specs (<=225Mhz), 570/3=190, 950/5=190.
I thought I was clear about the reason I was using this particular range:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2703604/#msg2703604 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2703604/#msg2703604)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2708874/#msg2708874 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2708874/#msg2708874)
If not, I'll try to consolidate my findings into this single post for you.
Running older versions of firmware (I would have no idea what version as they are not clearly marked), the Nano would send up corrupt data at seemingly random times. Slowing down how fast my software requests data from the Nano improved this. The corrupt data was not correlated with any specific frequency ranges. Also, making requests too fast could cause the Nano to white screen which required a power cycle to recover. I saw the same corrupt data when using their included software.
I then installed some later version of the hugen firmware. This appeared to completely solve the corrupt data. I ran several tests over a few days and never saw a single corrupt packet, however, I limited my frequency range to 900MHz. I then started to run some tests above 900M and discovered it would once again send corrupt packets. This was independent from how fast I requested the data, or for that matter, it would happen without using any software. This area was always at the 900MHz switch point.
Current testing with the latest edy555 firmware is being ran in that same frequency range as that is the only place I have seen a problem.
Now, if others including yourself are having similar problems in other ranges, I would have no way of knowing unless you posted about it. If you are having problems at specific ranges, you should post the ranges, the version of firmware you are using and maybe screen shots of your results. I could then attempt to replicate your findings. As I said, I only have the one Nano and it's very possible that this one is unique in how it behaves.
I have not tried to contact anyone outside of this forum. The main reason is again, I only have one test point (one Nano) and as I said, if the problem in unique to this one unit, it's hardly worth going after.
-
This area was always at the 900MHz switch point.
To reiterate, 300 and 900MHz crossing points are critical. When crossing 900MHz mark, internal VCO is stepping from (899/3)*4 = 1198.66 MHz to (900/5)*4= 720MHz. Note that max specified freq of internal VCO is 900MHz. Jumping into 850MHz (of your choice) shall be considered for PLL as "tricky to lock" because it is still deep into overclock range. That's why I asked about "safe" 570-950Mhz range. It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.
Now, if others including yourself are having similar problems in other ranges
Thing is I do not have nanovna. Not yet. It is up-to you guys ::)
-
This area was always at the 900MHz switch point.
To reiterate, 300 and 900MHz crossing points are critical. When crossing 900MHz mark, internal VCO is stepping from (899/3)*4 = 1198.66 MHz to (900/5)*4= 720MHz. Note that max specified freq of internal VCO is 900MHz. Jumping into 850MHz (of your choice) shall be considered for PLL as "tricky to lock" because it is still deep into overclock range. That's why I asked about "safe" 570-950Mhz range. It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.
Now, if others including yourself are having similar problems in other ranges
Thing is I do not have nanovna. Not yet. It is up-to you guys ::)
It seems you are unable to understand that I had ran tests at 300MHz before your posting about it.
It tried to straddle 300M, 600M and 800M with a 100M span and saw no problems. It appears unique to 900M.
It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.
You don't have one to test and this is the comment you come up with. :palm:
-
joeqsmith,
Would you mind comparing the results from this firmware image to the plots you just posted?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596) (latest edy555 source with older ChibiOS)
If I compare the hugen firmware with the edy555, I do see a difference in the data. The edy firmware appears to be less stable overall with more noise. The transition over the 900MHz crossover point it not as smooth. However, it doesn't seem to send corrupt data like the hugen firmware.
I would describe what I've observed about the same. The image with the older ChibiOS (above link) appears to have cleared up the glitchy traces as seen in the hugen image (I assume was shipped with my device), but looks like it is better data than either the current edy555 image (latest ChibiOS) or image that shipped with the unit I'm testing as it was shipped. Unfortunately, I accidentally deleted the firmware image that it shipped with even though I had backed it up. I have no idea what version, etc it was now.
[edit]
After more testing, no doubt about it for me now. The latest edy555 firmware, but with old ChibiOS (master branch) is definitely the way to go on my device. That was a nice accident.
Using your build, I ran a few more sweeps than the edy555 with the same test setup. It appears very similar to the image I had just built from Git. It did not glitch, has the same harsh transition and roughly the same noise. I may have to add some metric tracking to my software.
What is really odd, is obviously this is a new day with a whole new install. Note how that same pattern immerges at roughly the same sweep. Chances of that happening by chance would be zero. I wonder if there is something happening in the firmware at these times that causes the pattern. It would be roughly synced up with the power on, or reset.
-
It seems you are unable to understand that I had ran tests at 300MHz before your posting about it.
Speaking of ability to understand: had you let VCO jump from < 900MHz frequency to >= 1100 MHz in those tests "at 300MHz"? Hint: you did not. So if you don't want to verify what I say - fine. What is not fine - passive aggressive insults.
It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.
You don't have one to test and this is the comment you come up with. :palm:
Since when owning one became criteria to post in this thread? :-DD
-
It seems you are unable to understand that I had ran tests at 300MHz before your posting about it.
Speaking of ability to understand: had you let VCO jump from < 900MHz frequency to >= 1100 MHz in those tests "at 300MHz"? Hint: you did not. So if you don't want to verify what I say - fine. What is not fine - passive aggressive insults.
It is obviously for you to decide - you want to waste your precious time checking something that comes from random d00d in the forum or not.
You don't have one to test and this is the comment you come up with. :palm:
Since when owning one became criteria to post in this thread? :-DD
What I have presented was the test case where I was able to replicate the problem. I expect it's obvious to most people that this would not include all test cases ran.
If you had a Nano, and a specific test case that was causing you problems, I would invest the time to try and replicate it. I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.
-
https://www.aliexpress.com/item/33010508546.html?spm=a2g0o.productlist.0.0.41987b1ff0XwgM (https://www.aliexpress.com/item/33010508546.html?spm=a2g0o.productlist.0.0.41987b1ff0XwgM)
Is this the new device?
Does it have a spectrum analyzer mode, too?
Regards,
Vitor
-
I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.
Right. It is so incredibly hard to set other start/stop frequencies, run test again. :blah: :blah: Oh and BTW instability of some overclocked si5351 is widely known, hold your horses naming it as my guess. Dont even bother to waste your time answering.
-
joeqsmith,
Would you mind comparing the results from this firmware image to the plots you just posted?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596) (latest edy555 source with older ChibiOS)
If I compare the hugen firmware with the edy555, I do see a difference in the data. The edy firmware appears to be less stable overall with more noise. The transition over the 900MHz crossover point it not as smooth. However, it doesn't seem to send corrupt data like the hugen firmware.
I would describe what I've observed about the same. The image with the older ChibiOS (above link) appears to have cleared up the glitchy traces as seen in the hugen image (I assume was shipped with my device), but looks like it is better data than either the current edy555 image (latest ChibiOS) or image that shipped with the unit I'm testing as it was shipped. Unfortunately, I accidentally deleted the firmware image that it shipped with even though I had backed it up. I have no idea what version, etc it was now.
[edit]
After more testing, no doubt about it for me now. The latest edy555 firmware, but with old ChibiOS (master branch) is definitely the way to go on my device. That was a nice accident.
Using your build, I ran a few more sweeps than the edy555 with the same test setup. It appears very similar to the image I had just built from Git. It did not glitch, has the same harsh transition and roughly the same noise. I may have to add some metric tracking to my software.
What is really odd, is obviously this is a new day with a whole new install. Note how that same pattern immerges at roughly the same sweep. Chances of that happening by chance would be zero. I wonder if there is something happening in the firmware at these times that causes the pattern. It would be roughly synced up with the power on, or reset.
Thanks for testing that. I may have been on the wrong track with older/newer ChibiOS. I loaded up the latest edy555 + latest ChibiOS this morning again and it looks great. I'm just visually comparing sweeps on a bandpass filter over time. Yesterday, it seemed there was a clear difference. This morning, they look the same. I may start logging sweeps as well so I can do a better comparison.
-
Vitor wrote ...
"Is this the new device?"
---------------------------------------------
Vitor,
The device you linked to is not the V2 design. V2 will come from Hugen who first retailed the nanoVNA device based on the edy555 open source project. I gleaned the following information from earlier posts in this user group regarding nanoVNA version 2.
1. The nanoVNA will eventually reach 3GHz (and at a similar price to version 1).
2. It's going to be based on the adf4350 + si5351.
3. The 3 mixers are replaced with one higher spec mixer (ad8342) that is switched between the 3 channels.
4. A variable gain amplifier is added at baseband using one opamp and switched feedback resistors for improved dynamic range.
5. The Audio codec is removed and the stm32 built in ADC is used instead.
6. The performance should be comparable or better to V1.
7. Info about the baseband VGA design: A RFIC switch is used to switch the shunt resistor in the feedback path. The switch is basically "transparent" because the off state capacitance is in the femtofarad range (it is an RF switch) which is negligible at the IF frequency. The on state resistance is small compared to the resistors being switched in. Since the amplifier gain is mainly dictated by the feedback network, and the switch is "transparent", there is nothing other than the tempco of the physical resistors that can cause a temperature dependence. The RFIC used is the same as for the receiver RF switch, and it turns out all the maxscend switches do not have the shunt diode problem (most RF switch ICs have parasitic diodes from RF input to ground which will start to conduct at lower frequencies), so it has no theoretical lower frequency limit and can be applied at the IF frequency. This is a big improvement over using normal analog switch ICs which have capacitance in the pF range.
8. Info about linearity: The code will perform a calibration of each VGA step on boot up. Since there is no temperature dependence the calibration only needs to happen once.
9. The V2 PCB is 4 layers.
10. The schematics will be posted to GitHub, at the same time as the launch on taobao,
11. Design objectives include keeping BOM cost below $100 and compatibility with current software base.
A member of this forum, located in China, indicated that the schematics are available now but only via private request. I haven't seen any leaked info regarding screen size, but Hugen has posted in the past about prototyping with a 3.5-inch LCD. I would expect something that size or larger to keep pace with the nanoVNA-F that is already being marketed. To distinguish itself from the nanoVNA-F, it will most likely be marketed as the nanoVNA-H or nanoVNA-H V2.
Herb
-
I am not interested in wasting my time investigating your wild guesses of what you feel may be a problem.
Right. It is so incredibly hard to set other start/stop frequencies, run test again. :blah: :blah: Oh and BTW instability of some overclocked si5351 is widely known, hold your horses naming it as my guess. Dont even bother to waste your time answering.
It's not hard at all to setup these tests and run them, but once they have been ran, there is no reason to waste time repeating them.
-
joeqsmith,
Would you mind comparing the results from this firmware image to the plots you just posted?
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2709596/#msg2709596) (latest edy555 source with older ChibiOS)
If I compare the hugen firmware with the edy555, I do see a difference in the data. The edy firmware appears to be less stable overall with more noise. The transition over the 900MHz crossover point it not as smooth. However, it doesn't seem to send corrupt data like the hugen firmware.
I would describe what I've observed about the same. The image with the older ChibiOS (above link) appears to have cleared up the glitchy traces as seen in the hugen image (I assume was shipped with my device), but looks like it is better data than either the current edy555 image (latest ChibiOS) or image that shipped with the unit I'm testing as it was shipped. Unfortunately, I accidentally deleted the firmware image that it shipped with even though I had backed it up. I have no idea what version, etc it was now.
[edit]
After more testing, no doubt about it for me now. The latest edy555 firmware, but with old ChibiOS (master branch) is definitely the way to go on my device. That was a nice accident.
Using your build, I ran a few more sweeps than the edy555 with the same test setup. It appears very similar to the image I had just built from Git. It did not glitch, has the same harsh transition and roughly the same noise. I may have to add some metric tracking to my software.
What is really odd, is obviously this is a new day with a whole new install. Note how that same pattern immerges at roughly the same sweep. Chances of that happening by chance would be zero. I wonder if there is something happening in the firmware at these times that causes the pattern. It would be roughly synced up with the power on, or reset.
Thanks for testing that. I may have been on the wrong track with older/newer ChibiOS. I loaded up the latest edy555 + latest ChibiOS this morning again and it looks great. I'm just visually comparing sweeps on a bandpass filter over time. Yesterday, it seemed there was a clear difference. This morning, they look the same. I may start logging sweeps as well so I can do a better comparison.
No problem. I would need to add software to try and characterize the differences as I can't tell from just visually looking at the data that there is any difference. Of course, there could be other differences if we start to run other test cases. Good to hear that you are seeing the same thing. I have wondered how temperature effects it. This time of the year, our house stays fairly stable. Maybe something like this caused your results to change.
-
joeqsmith, there is fixed bug with S21 calibration in edy555 firmware, I recommend to update.
-
Do anybody have experience with this unit ?
(http://i.ebayimg.com/images/g/~EoAAOSwCKRcucju/s-l1600.jpg)
-
joeqsmith, there is fixed bug with S21 calibration in edy555 firmware, I recommend to update.
I had seen that release and was going to download it just now but saw they had updated it again a couple of hours ago. Doing a diff on Main.c, it appears they may be trying to fix the artifact problems I was seeing with the graphics.
Looking at the hugen area, there appears to be no new changes. Depending how you use the Nano, it may be worth it to wait a few weeks and see if it becomes more stable. I wonder if they perform some sort of automated regression test before releasing the code to the public or if they rely on the users to test their code for them.
-
Been following this thread - thanks for the info. I just got a NanoVNA yesterday, so far it's pretty impressive. Matches the return loss plot of my ham bands fan dipole using a Rigol DSA815-TG.
I did use the dfu utility to update the firmware and it went well - I used this file -
NanoVNA-H__900_ch_20190924.dfu
-
I read every last message in this thread - can't claim I remember all of them :P - and promptly ordered a nanovna as a result. I'm more of a power electronics guy than RF but jeez... only $50? Why the hell not?
Actually, I do have a use in mind that I'm not sure can be done but again, only $50; I want to better characterize transformers used in resonant converters. It would be nice if the minimum frequency could be dropped to say, 10kHz (is that a hardware [unlikely] or firmware limit?) but the immediate task at hand is a converter operating at 250kHz which I suspect has an unintended parallel resonance somewhere north of 4MHz (hence why I need a VNA).
And who knows, maybe I'll learn to love the Smith chart...
-
only $50
now you can find it for 30 USD from some sellers
-
I'll see if I can narrow the problem down further so maybe the real firmware guys can correct it. Then again, if it's just this one unit, it's hardly worth going after.
It seems like hardware problem (that may be fixable in software or not). Noticeably there are many traces w/o glitch. Then suddenly one or more traces have huge noise. We see that problem occur above 800MHz only when there are huge VCO tuning jumps. Seems like PLL is struggling to lock for some reasons in overclocking freq range or software do not wait long enough for PLL to lock, continue with measurement disregarding unlocked PLL. I have not seen source code - are there any PLL lock checks at all? I say that huge VCO freq jumps shall be followed by direct PLL lock status polling and only small steps shall be done using timeouts.
I'm trying to get PLL lock check added just to see what happens, but something is not working right here. This returns fail about every other call to set_freq function. Anyone see what is wrong here? I've tried quite a few variations on this, but not sure that I'm calling the ChibiOS i2c functions correctly. Things I've already tried:
- i2cMasterTransmitTimeout() only with the receive parameters filled in
- longer timeouts
- setting bit 0 for addr on the the read function
Ideas?
Also FYI, @ogden, I took a look at the decoupling on pin 7 and pin 1 of the si5351A. On the board I have, both pins appear to be decoupled correctly.
int si5351_wait_for_pll_lock(void) {
int addr = SI5351_I2C_ADDR>>1;
#define STATUS_REG 0x00
uint8_t reg[] = { STATUS_REG};
uint8_t data[1];
int retry=6;
i2cAcquireBus(&I2CD1);
lock_retry:
retry--;
(void)i2cMasterTransmitTimeout(&I2CD1, addr, reg, 1, NULL, 0, 10);
(void)i2cMasterReceiveTimeout(&I2CD1, addr , data, 1, 10);
//A and B
//if( (data[0]&0x60) != 0x00 && --retry>0) goto lock_retry;
//A only
//if( (data[0]&0x20) != 0x00 && --retry>0) goto lock_retry;
//B only
if( (data[0]&0x40) != 0x00 && retry>0) goto lock_retry;
i2cReleaseBus(&I2CD1);
if(retry==0) return 0;
else return 1; //PLL locked
}
[edit] I should point out that I'm quite happy with the current state of the firmware in the github repository. Just experimenting with it here...
-
I'm trying to get PLL lock check added just to see what happens, but something is not working right here. This returns fail about every other call to set_freq function.
Just two cents, no pressure to do anything about what I going to say next (grin): Usually after PLL freq change there shall be some delay before continuing with PLL state check. After initial delay, PLL lock status shall be checked during defined and *limited* time. So do you know how long it takes to execute PLL lock check loop 6 times? Also such (indicator) class of instrument better not halt with "hard error" on PLL unlock, it shall continue measurements no matter what - as it does now. It may be just some "PLL unlock" warning indicator on screen which lights up for 0.5sec or so and maybe output some diagnostics info in serial output as well (w/o breaking PC s/w backwards compatibility!). As datasheet is very obscure about PLL timings, PLL minimum/maximum delay shall be determined somehow. One is clear that maximum delay do not need to be longer than 10ms which is whole chip power-up time (max). Anyway if it is not locked during significant time say 10ms, most likely it will never lock in current conditions and some change is needed to "fix" situation. BTW that also could be the case why you see errors no matter what.
Also FYI, @ogden, I took a look at the decoupling on pin 7 and pin 1 of the si5351A. On the board I have, both pins appear to be decoupled correctly.
Great. Which version do you have? Any chance of PCB close-up picture so potential buyers have better decision making chances?
-
Over on nanovna-users@groups.io, hugen gave some clarifications about his anticipated October product release.
1. It will be called NanoVNA-H per his agreement with edy555 to help differentiate clone branches.
2. He provided a pre-release photo of the anticipated October product release (see attachment).
3. The release is a repackaging of the current nanoVNA and not the STM32F303CCT6 modification currently in development.
hugen's additional comments on 9-29-2019:
"I don't have a plan to compete with NanoVNA-F. The NanoVNA-F is too big. I can't put it in my trouser pocket. I don't even think he should be called NanoVNA. If you need a larger screen, connecting your smartphone with cho45's NanoVNA-Web-Client (https://github.com/cho45/NanoVNA-Web-Client) is a great solution. Regarding the new nanoVNA-H plan, I am trying to move to STM32F303CCT6 with AA6KL. Maybe I will try 3.5-inch LCD later. If you are interested, you can follow this project https://github.com/AA6KL/NanoVNA, if You want to participate in development and you can contact me to get the hardware. Thank you!"
-
I'm trying to get PLL lock check added just to see what happens, but something is not working right here. This returns fail about every other call to set_freq function.
Just two cents, no pressure to do anything about what I going to say next (grin): Usually after PLL freq change there shall be some delay before continuing with PLL state check. After initial delay, PLL lock status shall be checked during defined and *limited* time. So do you know how long it takes to execute PLL lock check loop 6 times? Also such (indicator) class of instrument better not halt with "hard error" on PLL unlock, it shall continue measurements no matter what - as it does now. It may be just some "PLL unlock" warning indicator on screen which lights up for 0.5sec or so and maybe output some diagnostics info in serial output as well (w/o breaking PC s/w backwards compatibility!). As datasheet is very obscure about PLL timings, PLL minimum/maximum delay shall be determined somehow. One is clear that maximum delay do not need to be longer than 10ms which is whole chip power-up time (max). Anyway if it is not locked during significant time say 10ms, most likely it will never lock in current conditions and some change is needed to "fix" situation. BTW that also could be the case why you see errors no matter what.
Also FYI, @ogden, I took a look at the decoupling on pin 7 and pin 1 of the si5351A. On the board I have, both pins appear to be decoupled correctly.
Great. Which version do you have? Any chance of PCB close-up picture so potential buyers have better decision making chances?
Success!
The main problem I was having getting it to work was needing to turn off DMA for I2C communications in mcuconf.h
#define STM32_I2C_USE_DMA FALSE
beginning of sweep function in main.c looks like this now:
// main loop for measurement
bool sweep(bool break_on_operation)
{
int i;
int delay;
for (i = 0; i < sweep_points; i++) {
retry_lock:
#if 1
delay = set_frequency(frequencies[i]);
if( si5351_wait_for_pll_lock()==0) {
chprintf((BaseSequentialStream *)&SDU1, "freq: %d not locking\r\n", frequencies[i]);
frequencies[i] += 1; //see if we can lock on 1Hz greater freq
goto retry_lock;
}
tlv320aic3204_select_in3(); // CH0:REFLECT
wait_dsp(delay);
#else
tlv320aic3204_select_in3(); // CH0:REFLECT
wait_dsp(delay);
#endif
new function in si5351.c
int si5351_wait_for_pll_lock(void) {
int addr = SI5351_I2C_ADDR>>1;
#define STATUS_REG 0x00
uint8_t reg[] = { STATUS_REG};
uint8_t data[1];
int retry=99;
i2cAcquireBus(&I2CD1);
lock_retry:
retry--;
(void)i2cMasterTransmitTimeout(&I2CD1, addr, reg, 1, data, 1, 1000);
//A and B
if( (data[0]&0x60) != 0x00 && --retry>0) goto lock_retry;
i2cReleaseBus(&I2CD1);
if(retry==0) return 0;
else return 1;
}
With retry=6 in wait_for_lock function, I see errors locking like this during sweeps:
freq: 50024 not locking
freq: 108044024 not locking
freq: 153041524 not locking
freq: 306033024 not locking
freq: 450025024 not locking
freq: 50025 not locking
freq: 108044025 not locking
freq: 153041525 not locking
freq: 306033025 not locking
freq: 450025025 not locking
freq: 50026 not locking
freq: 108044026 not locking
freq: 153041526 not locking
freq: 306033026 not locking
freq: 450025026 not locking
freq: 50027 not locking
freq: 108044027 not locking
freq: 153041527 not locking
freq: 306033027 not locking
freq: 450025027 not locking
freq: 50028 not locking
freq: 108044028 not locking
freq: 153041528 not locking
freq: 306033028 not locking
freq: 450025028 not locking
With retry=99 in wait_for_lock function, I see no errors locking.
@ogden, I can post an image later, but you can just take a look at the image of pcb and schematic at hugen's sales site here: https://www.alibaba.com/product-detail/Original-2-8-Touchscreen-50KHz-900MHz_62232701280.html (https://www.alibaba.com/product-detail/Original-2-8-Touchscreen-50KHz-900MHz_62232701280.html)
-
Forgot to mention that the lock errors shown in previous post were for the standard 101 point sweep from 50kHz to 900MHz. Still no errors showing up with retry=99. I may stick the thing in freezer and oven later to see if anything different happens.
-
If anyone wants to compare their results with mine, but doesn't want to make changes to source and compile, I'm attaching a binary. This differs in one way from the results that I posted in previous 2 posts. This binary will not increment the frequency by 1 Hz if the wait_for_lock function fails to lock. If there is no lock, it will just print the frequency that did not lock in the USB serial console and continue to retry. Note that you would need to handle this in your external software application if there is actually some lock errors during the sweep. This firmware image has the retry=99 in the wait_for_lock function. I can also post an image for retry=6 (or whatever) if anyone wants to compare results for that. Aside from the changes I posted above, this firmware image is based on the latest source from here: https://github.com/ttrftech/NanoVNA , from edy555 commit 30d33571fa3929ff697bf410d3b7f25145cc6e45
[edit]
If you do try this out, it would probably be a good idea to do a re-cal just in case this might improve calibration coefficients for a few frequencies that were off from the previous cal due to unlock.
[edit]
I tested after putting it in the freezer for 10 minutes and the oven, low temp, for 10 minutes (measured 105F when I pulled it out). No pll lock errors reported with retry=99 in lock function for either temperature extreme. I did see 3-4 glitches in the display for the first 30 seconds or so after the cold temperatures. Not sure what that would be.
I would say this is something that probably should be added to the code base. Based on experience with frequency synthesizers, I have found that you *must* check for lock and have some sort of retry mechanism. It might only affect one unit out of a batch. It might only happen in temperatures extremes, but sooner or later you will find unlock happening in certain circumstances. It needs to be handled by checking lock status, retries, etc.
-
Success!
Congrats! :clap:
frequencies += 1; //see if we can lock on 1Hz greater freq
Better do not touch frequency like that unless you are absolutely sure. Even slightest shift of IF or LO freq which is unexpected for VNA math, may lead to significant errors.
With retry=99 in wait_for_lock function, I see no errors locking.
Good. You may narrow down retry number in just few test runs by using "binary search" approach.
@ogden, I can post an image later, but you can just take a look at the image of pcb and schematic at hugen's sales site here
No need. Knowing that it is hugen's original version, we just take picture from the web (attach). BTW from appearance it seems like @joeqsmith have such as well. Yes, this version have decoupling capacitor for pin7 which is kinda improvement compared to edy555 PCB, yet there's still rookie errors: both traces going to (C10) capacitor forms loop antenna close to nearby signal trace. Influence may be minimal, yet anyway... There was room for everything - few ground plane stiches along signal line *and* closer pin7 capacitor placement. It becomes clear when we look at audio codec decoupling capacitor (C34, C36, C37) placements which are strange as well: they all are at distance away from the chip. Seems like strange "minimum distance to IC" rule applied :palm: and absent ground via next to cap.
-
Better do not touch frequency like that unless you are absolutely sure. Even slightest shift of IF or LO freq which is unexpected for VNA math, may lead to significant errors.
As I already mentioned, I took that out before posting the binary image. It was just a bit of test code. I left it in the first post output, so it made it clear that the synth was locking on second call to set_freq after wait_for_lock function failed.
I agree with your assessment that the layout could be improved, but it works fine. I suspect there are some via-in-pads for some of those caps, so grounds may be closer than they look. C9 should only bypass the chip (and be moved closer) and another separate cap should be added for the ref osc. Anyway, it is close enough. Obviously, it works great.
Still no lock errors.
-
I suspect there are some via-in-pads for some of those caps, so grounds may be closer than they look.
Very unlikely, unless those vias under caps are epoxy-filled. I bet they are not because $$$. Via-in-pad is bad idea on cheap PCB, unless used for thermal pads of big components (TO-252, D-PAK). Otherwise you may get tombstone or open joint (pic below).
[edit] Briefly looked into source code. Seems like both, PLL-A and PLL-B used for VNA functions. It means that MCLK is derived from either one. Well, well, well... VCO tuning, PLL locking takes time. During that time clock output is either disabled or whatever VCO is doing at the moment - sweeping or just wandering around. It does happen to MCLK as well!! That in result can and will upset audio codec and USB operation, cause various artefacts of sample or USB data corruption. During operation you shall never re-tune VCO+PLL that feeds either audio or serial interface (USB, Ethernet). Possible fix: run si5351 and MCU from 24MHz XO and use si5351 exclusively and only for VNA frequency generation.
(https://screamingcircuits.typepad.com/photos/uncategorized/2008/02/15/led_viainpad.jpg)
-
I'm attaching an update to the firmware image I posted last night with the pll lock check. I've added a command to change the number of loops in the wait_for_lock function before it returns lock status to the main loop. If the lock fails after reading the si5351 status register n times, it will will call the set_freq() function again until lock.
usage: lock_wait n, where n=99 by default.
While running a trace from 50kHz to 1500MHz, I see no errors in the USB serial console. If I set lock_wait to a value of 25, still no errors.
ch> lock_wait 20
ch> freq: 50000 not locking
freq: 300039984 not locking
freq: 50000 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 300039984 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 900019984 not locking
freq: 50000 not locking
freq: 300039984 not locking
freq: 50000 not locking
ch> lock_wait 10
ch> freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
freq: 900000016 not locking
freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
freq: 900000016 not locking
freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
see the post above for more info on what the code looks like:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2715592/#msg2715592 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2715592/#msg2715592)
-
freq: 50000 not locking
freq: 108044000 not locking
freq: 153041504 not locking
freq: 306033008 not locking
freq: 450025008 not locking
freq: 900000016 not locking
Those frequencies makes sense because they are at the beginning of each (VCO) range:
* 1~100MHz fixed PLL 900MHz, fractional divider
* 100~150MHz fractional PLL 600-900MHz, fixed divider 6
* 150~300MHz fractional PLL 600-900MHz, fixed divider 4
Then there are two transitions of harmonics mode, 450MHz and 900MHz.
BTW 50KHz-100MHz is done using fixed PLL config, no need to test that.
BTW due to your PLL lock polling, code following comment "// Set PLL twice on changing from band ___" is superflous.
-
Those frequencies makes sense because they are at the beginning of each (VCO) range:
I noticed that. I think the reason the current firmware in the repository works good is because there is a "delay" parameter returned from the set_frequency() function. The delay is incremented by 10 on vco band changes. That delay value determines the number of adc samples to skip over. So on a band change, it skips over samples that might otherwise be glitchy due to pll unlock.
-
I tested si5351 for sweep generator. With no PLL change it allows to change frequency very fast and with no breaks. But when you change PLL and make PLL reset, the output will be disabled for a short period of time. For about 1 us or something like that (don't remember exactly). It prevents to use si5351 for continuous sweep above 150 MHz.
-
I think the reason the current firmware in the repository works good is because there is a "delay" parameter returned from the set_frequency() function. The delay is incremented by 10 on vco band changes.
yes, I think this approach is more stable than continuous check for pll lock. Because pll reset requires fixed time in average, so proper delay will works good. But continuous read of status may lead to si5351 hung up, especially if you're I2C at high speed 400 kHz.
I have such issue with si5351. If you're using overclocked I2C for communication at extreme high speed, sometimes it may leads to hung up. After that si5351 is responsive for I2C requests, but it's output is stuck and cannot be changed with any register write. After that you can fix it with power off and power on.
-
One last attachment for now. The zip has a binary image and the changes I made to the source from https://github.com/ttrftech/NanoVNA (edy555 commit 30d33571fa3929ff697bf410d3b7f25145cc6e45)
I added another command 'adc_samples' and got rid of the delay+10 in returned on vco changes because of the pll lock polling. adc_samples N, where N is a value between 3 and 255. This is the value that the set_frequency() function will return. Instead of I/Q skipping samples, it now averages them. It looks like averaging samples has a good effect on the measurement range for frequencies below 100 MHz. Of course, the higher N, the longer it takes to sweep.
Anyway, hope this gives someone else something to mess around with. I'm going to get back to work on the sdr project now.
-
I think the reason the current firmware in the repository works good is because there is a "delay" parameter returned from the set_frequency() function. The delay is incremented by 10 on vco band changes.
yes, I think this approach is more stable than continuous check for pll lock. Because pll reset requires fixed time in average, so proper delay will works good. But continuous read of status may lead to si5351 hung up, especially if you're I2C at high speed 400 kHz.
I have such issue with si5351. If you're using overclocked I2C for communication at extreme high speed, sometimes it may leads to hung up. After that si5351 is responsive for I2C requests, but it's output is stuck and cannot be changed with any register write. After that you can fix it with power off and power on.
It does seem to work fine just skipping some adc samples, so no big deal if your device looks like it is working ok. Your argument about I2C doesn't make much sense to me. The device is constantly using I2C @ 400kHz for programming the tlvxxx and si5351 part on every sweep. I know I mentioned before, but when you are dealing with PLL that has the ability to check lock (pretty much all of them), then it is a good idea to take advantage of that in general. In this case, it would be good to at least have warnings on unlock in my opinion. If you don't check, how will you know?
-
If you don't check, how will you know?
just use delay for some period of time which is needed for stable pll lock :)
You're needs to make this delay when you send PLL reset command to si5351.
-
If you don't check, how will you know?
just use delay for some period of time which is needed for stable pll lock :)
You're needs to make this delay when you send PLL reset command to si5351.
Might work almost all the time. Wonder what could be causing these issues: https://github.com/ttrftech/NanoVNA/issues/59
-
Wonder what could be causing these issues
I think he forgot to perform calibration after firmware update
-
I don't see a link to the video.
-
After having the newer firmware lockup on me a few times, I shelved the Nano. I looked a few days ago and saw there was a newer release but I have not tried it. I did see that they had uncommented the new command allowing for a variable number of samples.
-
Hi Joe, just in case it might help, the latest, 7th October 2019, version of edy555's firmware seems to have cured the "white screen" when performing segmented scanning, I am not sure if this is connected to your problem? Hope you don't hang up your nano for good as I have learnt a lot from your you-tube videos and the posts on this forum, although I admit a fair bit of your later work is above my head. Regards Mike
-
Hi Joe, just in case it might help, the latest, 7th October 2019, version of edy555's firmware seems to have cured the "white screen" when performing segmented scanning, I am not sure if this is connected to your problem? Hope you don't hang up your nano for good as I have learnt a lot from your you-tube videos and the posts on this forum, although I admit a fair bit of your later work is above my head. Regards Mike
Thanks and I'm glad you found them useful.
With the latest firmware, the screen doesn't go white like it used to but the Nano locks up. It will not accept USB commands and requires a power cycle to recover.
I had put together a longer stage for my TDR experiments and was running some fairly long tests and the Nano would lockup while running them. This was with the last stock firmware from edy555 that I downloaded. I did not reload the later hugen firmware as it was having other problems sending corrupt data.
With them cranking out what appears to be untested versions so fast, it's not worth manually checking them all looking for stable version.
-
With the latest firmware, the screen doesn't go white like it used to but the Nano locks up. It will not accept USB commands and requires a power cycle to recover.
Try this version (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2739374/#msg2739374)
-
With the latest firmware, the screen doesn't go white like it used to but the Nano locks up. It will not accept USB commands and requires a power cycle to recover.
Try this version
I would have no way of knowing what this version is. That's been part of the problem I see with the edy555 and hugen79 code, they do not document. As a user, I can waste time running a diff and try to sort of what they changed and why. A bit odd they don't keep a detailed log of the changes.
It looks like hugen79 also released something new in the last couple of days. Like the latest edy555 release, they also enabled the scan command.
It may be worth spending some time putting together some sort of automated regression tests for the Nano.
-
I had put together a longer stage for my TDR experiments and was running some fairly long tests
While doing that did you remember what you say (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2691423/#msg2691423) some time ago? Just saying.
-
I had put together a longer stage for my TDR experiments and was running some fairly long tests
While doing that did you remember what you say (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2691423/#msg2691423) some time ago? Just saying.
Sure I remember. What about it?
-
I had put together a longer stage for my TDR experiments and was running some fairly long tests
While doing that did you remember what you say (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2691423/#msg2691423) some time ago? Just saying.
Sure I remember. What about it?
Well... Rebuild of delay contraption removed most of obstacles you mentioned back then. So @rhb could get info he looked for.
-
Try this version
I would have no way of knowing what this version is. That's been part of the problem I see with the edy555 and hugen79 code
This is the most fresh version which includes edy555 changes + hugen79 improvements + improved stability + scanraw command. It also excludes these changes which didn't passed QA due to regression.
scanraw command allows to read raw S11 or S21 (with no calibration apply) and averaging. You can use it to apply your own calibration.
For example:
scanraw 0 1000000 1000000 900 10
will read 900 points from 1 MHz to 900 MHz with 1 MHz step and averaging by 10 points for CH0.
You're needs to apply your own calibration to the result.
-
Try this version
I would have no way of knowing what this version is. That's been part of the problem I see with the edy555 and hugen79 code
This is the most fresh version which includes edy555 changes + hugen79 improvements + improved stability + scanraw command. It also excludes these changes which didn't passed QA due to regression.
scanraw command allows to read raw S11 or S21 (with no calibration apply) and averaging. You can use it to apply your own calibration.
For example:
scanraw 0 1000000 1000000 900 10
will read 900 points from 1 MHz to 900 MHz with 1 MHz step and averaging by 10 points for CH0.
You're needs to apply your own calibration to the result.
Please fill me in on this regression testing you mention.
Do you have a link to where the source is being stored for the image you uploaded?
-
Do you have a link to where the source is being stored for the image you uploaded?
https://github.com/qrp73/NanoVNA
-
Do you have a link to where the source is being stored for the image you uploaded?
https://github.com/qrp73/NanoVNA
Thanks for the link.
In order to evaluate all of these various versions efficiently, I would really need to consider setting up some sort auto or semi-auto regression test. I am very interesting in knowing more about the regression testing you mentioned. Mainly, what tests you perform? Is it possible to use your test scripts on other flavors? What hardware you require? Do you create any sort of reports that could be posted?
If your regression tests could be shared with the other developers, that may be helpful.
Currently I have no way of running a decent test outside of just manually going through the paces. This takes a fair amount of time.
-
Got nanovna by shopping spree accident, black clone. Why it's not "original" - don't ask. Perhaps for greater good. Port2 mixer IC (sa612) was dead, reflection mixer seems to be "factory-repaired" as well. After quick fix it seems to perform well for a price.
Supplied cables and short are surprisingly good. Open is good by definition because it's joke at those frequencies anyway. Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator (https://www.minicircuits.com/WebStore/dashboard.html?model=ANNE-50L%2B). Those who can afford some more may get 2nd terminator and 10dB, 20dB, 40dB 6dB attenuators.
I did calibrate repaired and fully functioning nanovna using supplied accessories + mini-circuits terminator. Measured S11 of mini-circuits terminator, then supplied terminator. Files attached.
-
Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator (https://www.minicircuits.com/WebStore/dashboard.html?model=ANNE-50L%2B).
I guess results may vary. The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.
-
Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator (https://www.minicircuits.com/WebStore/dashboard.html?model=ANNE-50L%2B).
I guess results may vary. The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.
Be careful before you jump with conclusions. You can't judge about quality of your terminator unless you have one reference to calibrate & compare with. With just one terminator you don't know. You may see amazing return loss picture like attached S11 and do not even know that it is actually worst 50ohm'ish crap ever:
-
Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator (https://www.minicircuits.com/WebStore/dashboard.html?model=ANNE-50L%2B).
I guess results may vary. The 50-ohm terminator I was supplied results in S11 measurement range very close to your mini-circuits terminator measurements.
Be careful before you jump with conclusions. You can't judge about quality of your terminator unless you have one reference to calibrate & compare with. With just one terminator you don't know. You may see amazing return loss picture like attached S11 and do not even know that it is actually worst 50ohm'ish crap ever:
The supplied terminator I received with nanoVNA also looks very close to a Weinschel 50 ohm terminator of mine.
-
Terminator/load is utter piece of crap. Every owner of nanovna shall consider getting quality 50ohm terminator.
Don't rush to draw conclusions. There is big probability, that your minicircuit is much worse. At least on 1-900 MHz frequency range. I'm pretty sure about that. Because this is not cal-kit load. This is usual 50R terminator. :)
At least my NanoVNA cal-kit L load is very good. It has 49.95 Ohm and works much better than all Chinese terminators that I have.
Your minicircuit may be very good above 6 GHz but it cannot be good within entire 12 GHz range, so there is very high probability that it is not so good below 1 GHz :)
First, try to measure your minicircuit load terminator with precise DMM. And compare it with cal-kit L load.
The second issue, is that all cal-kit loads needs to have the same delay. Do you have O and S loads for your minicircuit? I guess not. And it means that you cannot use it with O and S loads from NanoVNA kit, because they have different delay. And according to picture, significantly different. I think the difference is about 20-30 picoseconds. Such delay is too high for NanoVNA.
Regarding to your request for screenshot, here it is:
CH0 and CH1 are open:
[attachimg=1]
CH0 and CH1 both connected with 50R load:
[attachimg=2]
-
Your minicircuit may be very good above 6 GHz but it cannot be good within entire 12 GHz range, so there is very high probability that it is not so good below 1 GHz
No. You are wrong. https://ww2.minicircuits.com/pages/s-params/ANNE-50+_GRAPHS.pdf (https://ww2.minicircuits.com/pages/s-params/ANNE-50+_GRAPHS.pdf)
The second issue, is that all cal-kit loads needs to have the same delay. Do you have O and S loads for your minicircuit?
Purist :D You better check presence of pin in your Open "standard" first.
And according to picture, significantly different. I think the difference is about 20-30 picoseconds.
Where did you get 20-30 picoseconds from? :-//
[edit] Thank you for screens! Speaking of insanely good return loss indication - again we see that you can't estimate precision of the ruler using same exact ruler
-
I have started working on my own regression test.
I had thought about using the SA, tied to the PC to aid with some of the tests but decided to keep the required hardware to a minimum for now and just do what I can with a thru installed.
It needs more work but can at least catch the basic problems I have been seeing with some of the firmware with the added bonus, I don't have do anything outside of pressing go. Considering it takes a few hours to run through all the tests so far, this is a big time saver.
-
With the latest firmware, the screen doesn't go white like it used to but the Nano locks up. It will not accept USB commands and requires a power cycle to recover.
Try this version
I was planning to use this version while I work through my regression tests. I have started adding a report generator and increasing some of the tests I run. I will report the problems as I find them. If you want to try to correct them as I find problems, I would be willing to work with you to run your changes through my regression tests.
Problem 1
Setting the Center frequency to 750MHz, then set the Span to 1500MHz. Request the Frequency. The firmware returns only 100 data points rather than 101. I would expect the Nano to always send 101 data points. This problem is reproducible.
Problem 2
Setting the Start frequency to 0MHz, the Stop to 1MHz. Request the Frequency. The firmware returns a starting frequency of 10KHz rather than the expected 50KHz. The number of data points is correct. I would expect the Nano to limit the lower frequency to 50KHz, or there should be a document explaining that the lower limit is now 10KHz. This problem is reproducible.
Problem 3
Screen still leaving random artifacts from previous scan when using the Smith Chart. This problem is reproducible and appeared in the firmware that was supplied with my Nano. I have yet to see firmware that does not have this problem.
Problem 4
After programming the new firmware into the Nano and running a calibration, the calibration appeared corrupt. An open was on the left side of the screen and a short was on the right. Applying any load would be unstable when looking at the display. The frequency range was set to 0.05 to 900MHz prior to calibration. A reset was ran prior to calibration. Attempting to repeat the calibration corrected the problem. I have not attempted to repeat this condition.
Problem 5
Programming a start of 50KHz and an stop frequency of 1500MHz. Request the Frequency. The firmware returns the correct frequency for the first data point. Looking at higher frequencies, there is an error between various firmware. For example, some will report 1500 for the last data point where others report 1499.99995. For a given version of firmware, it will return predictable values. This problem is easy to reproduce.
-
View at the terminators from another angle. Attached R+jX plots for minicircuits anne-50+ (18GHz) terminator, original terminator and original terminator with 40dB 18GHz hi-end attenuator attached. That atten BTW is worth more than nanovna. It is clear that supplied terminator have "parasits" inside. To be clear - that minicircuits terminator is more than good as minivna cal standard. Any claim that it's performance at minivna frequencies is poor - utter BS.
[edit] note that "original terminator" means: originally supplied with nanovna *clone*, black version
-
The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?
-
The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?
For "good terminator" - kind of. It's capacitance and inductance indication is noisy as it should be measuring return loss noise floor, yet averages around zero. Not so good terminator "averaged" around 1nH, attach.
-
Anyone else think that the need for better than 40dB for an S11 measurement might be a post for the Metrology thread? The description could be changed from "This is where the Voltnuts hang out." to "This is where the Voltnuts and S11nuts hang out".
-
The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?
That's not correct, unless something has changed recently. The 50fF is for the open. The Load and Short standards are assumed perfect.
-
I have added a few more findings to my list as I continue to expand my test scripts:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2736580/#msg2736580 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2736580/#msg2736580)
I decided to try and build the last edy555 code from 10112019 and run the regression test on it. This was right from Git.
build/ch.elf section `.data' will not fit in region `flash0'
none-eabi/bin/ld.exe: region `flash0' overflowed by 296 bytes
Odd anyone would commit something that won't even build. It's the first time I have ran into a problem like this with the Nano firmware.
I tried a version from hugen that I had downloaded on 10102019. While this version builds just fine, it will send corrupt data at other switch points, not just 900MHz like I was seeing with the older version.
It appears that most of the firmware I have looked at will send back a frequency of 1500.000000 rather than being off. I would expect if I program 1500, I would get 1500, not 1499.99995.
-
Attached R+jX plots for minicircuits anne-50+ (18GHz) terminator, original terminator and original terminator with 40dB 18GHz hi-end attenuator attached
your comparison is invalid, just because you're trying to compare different loads with different electronic delay and didn't apply correction for this electronic delay difference.
Such comparison just doesn't make sense, because you're trying to compare measurement taken with significantly different conditions.
-
The nanoVNA internal calibration assumes a 50fF C0 parasitic for the load. Would that match your measurement?
No, the NanoVNA error-adapter assumes 50 fF for open load and also it assumes zero electronic delay (like ideal loads).
Supplied cal-kit is close to that assumption. Some guys reported that supplied open load has 22 fF. That's the only complaint I've heard about cal-kit supplied with NanoVNA.
But ogen trying to compare it with terminator which has much longer visual size. I think it's delay is about 20-30 picoseconds higher than NanoVNA cal-kit load.
-
your comparison is invalid, just because you're trying to compare different loads with different electronic delay and didn't apply correction for this electronic delay difference.
Comparison was to demonstrate exactly that - "original terminator" have (longer) parasitic transmission line inside, yet you say that I shall compensate for it and basically void whole idea of demonstration :palm:
But ogen trying to compare it with terminator which has much longer visual size. I think it's delay is about 20-30 picoseconds higher than NanoVNA cal-kit load.
How many times I shall repeat that I do not compare hugens calkit because I do not have one! I just demonstrate that clones have crap calkits, especially terminators, reference planes of short and load for my supplied cal kit are kinda far from each other.
[edit] Geez, you guys seems are here only to have argument no matter what :-//
[edit1] Attached R+jX minicircuits terminator in the end of 10cm quality semirigid. As you see impedance does not wander off as in case of crap terminator. Explain that.
-
Comparison was to demonstrate exactly that - "original terminator" have (longer) parasitic transmission line inside, yet you say that I shall compensate for it and basically void whole idea of demonstration :palm:
you cannot make conclusions from your measurements, because your NanoVNA was calibrated with incompatible loads. It means that your NanoVNA calibration is invalid and you cannot believe to it's measurements.
Your cal-lit L load can be really bad, but you're needs to use proper calibration in order to check that. Proper calibration means that all your cal-kit loads - L, O and S should be exactly the same physical length. O load should have 50 fF. If you you can satisfy these conditions for calibration, then you can believe measurements results.
I can help you to determine if your load is really bad and what happens exactly.
In order to do that, please provide me with S1P files taken in the following way:
1) open CAL menu and press RESET
2) open CLIBRATE menu and perform calibration with NanoVNA cal-kit (with using NanoVNA L load). Press OPEN/SHORT/LOAD just once. If you press it twice, go to step 1 (reset cal and repeat).
3) Check if calibration success (check that O, S, L loads shows proper point on Smith chart)
4) Measure S1P file for NanoVNA cal-kit L load
5) Measure S1P file for Minicircuits terminator
6) Provide me with these two S1P files
Provide me with these two S1P files and I will check what is going on with your loads.
-
Attached R+jX
R+jX measurement is very sensitive to electronic delay. Especially on high frequency. Before R+jX measurements, you're needs to setup proper electronic delay in the menu DISPLAY => SCALE => ELECTRICAL DELAY
-
Problem 1
Setting the Center frequency to 750MHz, then set the Span to 1500MHz. Request the Frequency. The firmware returns only 100 data points rather than 101. I would expect the Nano to always send 101 data points. This problem is reproducible.
fixed
Problem 2
Setting the Start frequency to 0MHz, the Stop to 1MHz. Request the Frequency. The firmware returns a starting frequency of 10KHz rather than the expected 50KHz. The number of data points is correct. I would expect the Nano to limit the lower frequency to 50KHz, or there should be a document explaining that the lower limit is now 10KHz. This problem is reproducible.
this is not a problem. This is feature of this firmware. It allows to use 10 kHz - 1500 MHz frequency range :)
Problem 3
Screen still leaving random artifacts from previous scan when using the Smith Chart. This problem is reproducible and appeared in the firmware that was supplied with my Nano. I have yet to see firmware that does not have this problem.
this is known issue of all NanoVNA firmware versions, but there is still no fix for that.
Problem 4
After programming the new firmware into the Nano and running a calibration, the calibration appeared corrupt. An open was on the left side of the screen and a short was on the right. Applying any load would be unstable when looking at the display. The frequency range was set to 0.05 to 900MHz prior to calibration. A reset was ran prior to calibration. Attempting to repeat the calibration corrected the problem. I have not attempted to repeat this condition.
Different firmware may use incompatible calibration settings. In order to avoid such issues, it is recommended to perform clear of configuration and perform full calibration after firmware update. You can clear configuration with the following console command:
clearconfig
Problem 5
Programming a start of 50KHz and an stop frequency of 1500MHz. Request the Frequency. The firmware returns the correct frequency for the first data point. Looking at higher frequencies, there is an error between various firmware. For example, some will report 1500 for the last data point where others report 1499.99995. For a given version of firmware, it will return predictable values. This problem is easy to reproduce.
fixed
Try this version (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2739418/#msg2739418), it solves your issues, allows to enter negative electronic delay and also improves precision for data transfer from NanoVNA to PC.
-
R+jX measurement is very sensitive to electronic delay. Especially on high frequency. Before R+jX measurements, you're needs to setup proper electronic delay in the menu DISPLAY => SCALE => ELECTRICAL DELAY
Again you do not get what I am actually showing you and/or you do not understand what causes impedance increase @high frequencies in case of crap load. I just give up. Have a nice day. Meanwhile think why hi-end (Keysight, R&S, Anritsu) cal kits have length specifications only for open and shorts, never for broadband loads.
-
Try this version, it solves your issues, allows to enter negative electronic delay and also improves precision for data transfer from NanoVNA to PC.
There's no link.
-
There's no link.
Here:
-
Just downloaded from your GH area and tried to build but once again get errors that it will not fit. I assume that the image was not built from what is uploaded.
-
Just downloaded from your GH area and tried to build but once again get errors that it will not fit. I assume that the image was not built from what is uploaded.
there is needs fix for ChibiOS, and it depends on environment. The image has version stamp, it is linked to github version.
-
With the image you linked, it does appear to correct the rounding, span and range problems. Nice job. I have updated my regression tests to look for the 10KHz lower limit.
I also want to mention that I ran that last image for several hours and not once did I see the screen go white, or had the firmware lockup where it required a power cycle to reset.
I am building under Windows 10, with the same tools I previously listed. What will need to change in the ChiOS to support this tool chain?
There is one thing I notice with your code that seems unique that I find strange. I run a speed test where I make requests to the Nano and measure the response times. I start with the Frequencies command, sending it several times. I then switch to data 0. At the time I make this switch, with your code I will see the response time increase (about double) for the very first read. It then settles down. It also appears to be quicker then some of the older images I was trying to use. This delay does appear to be repeatable.
The reason I am asking about this delay is that when I was looking at the PC software they provided for the Nano, they always read the frequency and both data sets. I suspect as they scan through the commands, this delay would effect the overall speed. I have not tried to run a cycle test like this yet but may add it to my scripts.
-
There is one thing I notice with your code that seems unique that I find strange. I run a speed test where I make requests to the Nano and measure the response times. I start with the Frequencies command, sending it several times. I then switch to data 0. At the time I make this switch, with your code I will see the response time increase (about double) for the very first read.
data command needs to wait until NanoVNA will complete sweep. You can monitor sweep state by LED state on the NanoVNA board. When sweep is active, the LED is off, at this moment data command will needs to wait.
Since NanoVNA performs sweep in the loop. The delay of data command will depends on current sweep state. Because data command needs to wait when sweep will be completed.
If you don't change start/stop/center/span frequencies, there is no need to repeat "frequencies" command. You can exectute "frequencies" command just once after start/stop/center/span frequency change. After that you can execute just data command in a loop.
-
I tried installing your couple of files. I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2. It still errors out.
On the plus side, your latest version just finished running through my simple regression tests and had no errors. Of course I am not suggesting the code is bug free, just that it passed my simple test. Good job.
My software waits for each command to have a response before sending the next or it times out. I had ran some tests early on where I would stack them up, but it seems unpredictable if the Nano would keep up or not. Basically, in some cases where I would say, make a parameter change, I could send more than one command while waiting for the Nano to respond. I could not do this with the data commands. At the time, it would not crash the Nano but it appeared to just not receive the commands.
-
I tried installing your couple of files. I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2. It still errors out.
hal_i2s_lld.c needs to be replaced just in the folder ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.c
But actually, these are minor changes, and they should not affect build.
The error depends on tool chain
-
If you don't change start/stop/center/span frequencies, there is no need to repeat "frequencies" command. You can exectute "frequencies" command just once after start/stop/center/span frequency change. After that you can execute just data command in a loop.
Again, this is a regression test, not normal operation. I am collecting metrics on the firmware. One of the metrics is the response time. When I run this test, I will send the commands over and over (50 times) and then calculate my standard deviation and mean from that. I run these various odd tests to get some insight as to how the firmware behaves.
It's similar to setting the center to 750MHz and setting the span to 1500, pushing the low end to 0. A fringe case but none the less showed some unexpected behavior. Not something I would normally do if I were just using the Nano.
Some of the tests seem to cause the white screen in certain firmware versions. One of the main reasons I am creating these tests is to try and find a stable version of firmware.
I had asked you about your regression tests that you mention but you chose not to discuss for what ever reason. I am still open to discussing and plan to continue to add to the complexity of my scripts.
-
I tried installing your couple of files. I placed cstartup.s in the compilers/IAR directory and the hal_i2s_lld.c in both SPIV1&2. It still errors out.
hal_i2s_lld.c needs to be replaced just in the folder ChibiOS\os\hal\ports\STM32\LLD\SPIv2\hal_i2s_lld.c
But actually, these are minor changes, and they should not affect build.
The error depends on tool chain
/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.7.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: region `flash0' overflowed by 584 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:243: build/ch.elf] Error 1
-
I could send more than one command while waiting for the Nano to respond. I could not do this with the data commands. At the time, it would not crash the Nano but it appeared to just not receive the commands.
You can send several commands, but it depends on buffer size in the NanoVNA. If you flooding it with commands, it will be lost.
-
/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.7.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: region `flash0' overflowed by 584 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:243: build/ch.elf] Error 1
it seems that the code doesn't fit into STM32F072CB. First check that your tool chain uses 128 kB flash for this chip. The second you can play with optimization options. If it doesn't help, you can remove some commands. For example scan command duplicating sweep functionality, so you can comment it with #if 0 directive. Also remove it from the command list array.
This is known issue. The controller STM32F072CB has too small flash memory - just 128 kB. And you can find that other people also fighting with this limitation for NanoVNA.
This is why NanoVNA V2 uses more powerful controller, it has more memory, so it can handle more things :)
-
I had asked you about your regression tests that you mention but you chose not to discuss for what ever reason. I am still open to discussing and plan to continue to add to the complexity of my scripts.
I don't have automated regression tests. I do it manually. Just compare what is changed in the code and then trying to test if these changes works properly and there is no regression. That's what I mean when I told you about regression tests :)
-
You both are doing great job to improve nanovna, yet chat about build and source code specifics better be done using private messages. No offense, just saying.
-
/roaming/xpacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.7.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: region `flash0' overflowed by 584 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:243: build/ch.elf] Error 1
it seems that the code doesn't fit into STM32F072CB. First check that your tool chain uses 128 kB flash for this chip. The second you can play with optimization options. If it doesn't help, you can remove some commands. For example scan command duplicating sweep functionality, so you can comment it with #if 0 directive. Also remove it from the command list array.
This is known issue. The controller STM32F072CB has too small flash memory - just 128 kB. And you can find that other people also fighting with this limitation for NanoVNA.
This is why NanoVNA V2 uses more powerful controller, it has more memory, so it can handle more things :)
Yes, it seems to be setup for 128K. Are you building with same files you have archived? Comparing the LD file with others, any idea why flash7 is set to 32K? Do they really need this much space for calibrations?
I can disable your new commands and of course it will fit. Another option is to enable the size optimization. Setting this will easily allow it to build what you have and fit. I suspect the performance hit is too much and why they are not using it. I'll try running it built this way through the regression tests.
Assuming that you are building with all the files you have uploaded, what version of the tools are using? Hard to believe that compiler would have changed this much but maybe. It may explain why I wasn't able to build the other code I had downloaded.
As for stacking commands (sending more than one without waiting for a response), the way I have my software currently structured, if I am sending a command that will change the frequency settings, I will go ahead and send the frequencies command with it. In this case, I know all the set commands (start, stop, span....) are very fast and have virtually no payload. So far this has not caused a problem. It's the only case though where I continue to stack them.
On the regression test, this makes more sense. I've started adding an automated report generation to document the testing so I can easily compare the results later on.
-
While enabling the optimizer does allow me to build with all of the commands you have selected and fit, once loaded into the Nano, it will not run. Some text is displayed on the screen but the Smith Chart for example does not get displayed.
I'm interested in seeing what your tool chain is showing for usages.
Removing your last commands with the optimizer set to the defaults allows it to fit and also seems to pass my basic regression tests. An odd side effect is that I no longer see the delay when the commands are switched like I show in the earlier plots.
One of the test cases I added was to set the start frequency to 1500 and the stop to 0. My old analog VNA has no way to scan backwards. Looking at my old HP3589A, it behaves similar to the Nano which basically reports it will scan from 10KHz to 10KHz with 101 samples. With my Signal Hound, when trying to set the stop lower than the stop, it will coerce the it to the maximum value. Any thought on if you will change how this works?
-
An odd side effect is that I no longer see the delay when the commands are switched like I show in the earlier plots.
That's interesting. Is it better or worse compared to this hex file (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2739418/#msg2739418)?
One of the test cases I added was to set the start frequency to 1500 and the stop to 0. My old analog VNA has no way to scan backwards. Looking at my old HP3589A, it behaves similar to the Nano which basically reports it will scan from 10KHz to 10KHz with 101 samples. With my Signal Hound, when trying to set the stop lower than the stop, it will coerce the it to the maximum value. Any thought on if you will change how this works?
Do you mean something like sweep from start=100 MHz to stop=50 MHz? It is possible, but I'm not sure if it really needed.
-
What is actual bottleneck why PC (NanoVNA Saver) scan rate is much slower than on-board display? Nearly two times or so, even when PC software is running, thus primary and on-board display scans is not that important anymore? There even could be option to disable onboard display while USB software running (PC software command, screen_off/on). (NanoVNA-Q-2019-10-15-e427dbb, NanoVNA Saver 0.1.1) BTW how PC USB scan data is made? It is separate scan which is not displayed on nanovna display? If so - is it possible to just readout buffer of completed scan?
-
how PC USB scan data is made? It is separate scan which is not displayed on nanovna display? If so - is it possible to just readout buffer of completed scan?
The device performs sweep and render in a loop. The PC can request the current data of the sweep through USB and NanoVNA will send the last sweep data to PC.
-
how PC USB scan data is made? It is separate scan which is not displayed on nanovna display? If so - is it possible to just readout buffer of completed scan?
The device performs sweep and render in a loop. The PC can request the current data of the sweep through USB and NanoVNA will send the last sweep data to PC.
That means that scan is not bottleneck. Excellent. USB have enough bandwidth, MCU have bandwidth as well - because it does update it's screen fast during PC software scan. It means PC SW update speed *can* be improved. Somebody just have to look at it because it is important while using average, especially knowing that it can be *twice* as fast.
Do you release hex and/or dfu releases as well? Please.
-
That means that scan is not bottleneck. Excellent. USB have enough bandwidth
that's not the case, it uses old USB peripherals which can work in USB FS mode and the speed is limited with small amount of buffer memory and MCU speed. But it is good enough for communication. I didn't measured the maximum performance, but think it is about 50-100 kB/s.
MCU have bandwidth as well - because it does update it's screen fast during PC software scan.
It means PC SW update speed *can* be improved. Somebody just have to look at it because it is important while using average, especially knowing that it can be *twice* as fast.
Do you release hex and/or dfu releases as well? Please.
MCU cannot communicate with PC during sweep, because it will affect measurement.
Communication speed really can be improved, but I'm not sure that this is really needed.
There are several ways to improve performance:
1) optimize communication from PC side (don't send extra requests, don't do long delays, etc)
2) use binary format communications, but it will break compatibility with existing software (NanoVNASharp, Saver, etc)
As for average, it is better to perform it on MCU side. For example you can use scanraw command from NanoVNA-Q firmware. It allows to setup average from 1x to 1000x and it will be performed on MCU side. But it returns raw gamma data with no correction (with no calibration apply, the same as you see with reset calibration), so you're needs to apply your own calibration.
-
That means that scan is not bottleneck. Excellent. USB have enough bandwidth
that's not the case, it uses old USB peripherals which can work in USB FS mode
Yes, I did mean exactly that - USB FS of stm32 which is running at 72MHz(?) have enough bandwidth for this application.
MCU cannot communicate with PC during sweep, because it will affect measurement.
Well, it does not need to show scan on it's display two times faster than PC is getting scan data as well. While connected to PC, display can be off. That would also fall into "will not affect measurement", if not then "waste less time" definitely.
For example you can use scanraw command from NanoVNA-Q firmware.
No. I can do many things but what i Want to do is - *use* nanovna, not modify or develop it. What I see - PC software is slow, slower than onboard firmware and I know that hardware is more than capable.
-
Hello Ogden,
there were some changes to the official firmware which necessitated a slowdown be put in to all data reads. As of firmware 0.2.0 and newer, and NanoVNA-Saver 0.1.2 and newer (but use 0.1.3, it's just out now), the new "scan" command is used. This disables the screen, runs a single sweep of the requested range, waits for it to complete, and then the application fetches the data.
I still think it feels slow, also compared to early experiments. But it's how I'm told by the maker of the firmware that I should request data via serial, and thus it's what I make the application do. I would be very happy if someone were to try to optimize the code on the NanoVNA ;-)
-
Thanx, tried 0.1.3 and do not see any improvements in areas that IMHO are actually important. Same weird behavior - nanovna makes two scans but on PC only one is displayed. That does not makes sense because cooms interface is CDC! As soon as nano is finished scan, it can PUSH out data. Application shall jus sit and wait for next scan data to come in. Firmware and software guys shall start to talk each other. Also seems like averaging did not work in 0.1.1 and still does not in 0.1.3. Noise peak-peak amplitude does not go down . Anybody else think so?
-
Hello Ogden,
I can confirm that averaging certainly does work. Whether it gives you the results you expect, or whether it works with your particular firmware I can't promise, of course :-) What firmware revision are you running?
On the "shall start to talk to each other": I certainly have had conversations with edy555 about the device and interaction with NanoVNA-Saver, and he has specified using this particularly interface, ie. using the "scan" command in newer firmware. What speed it goes at isn't something I can affect :-)
-
I can confirm that averaging certainly does work.
Firmware mentioned in this post:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2739418/#msg2739418 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2739418/#msg2739418)
Tested using s11 noise floor which is most "noisy". Look at the picture. Those dips can't be there after 20x average. No way. Not to mention that picture does not look any different than single sweep w/o average. If you are further interested - let's go PM. I can give input as long as it does not take big chunk out of my spare time.
-
Whether those dips can be there or not depends on your calibration, I would say. If there were opposite peaks at the time of calibrating the NanoVNA itself, it would over-compensate on those particular frequencies, and consistently produce such dips.
Attached are two sweeps of 900-1500MHz (lots of noise!) - one without and one with 20x averaging. I would say it looks like it's working.
[attachimg=1]
[attachimg=2]
The levels you're looking at when looking at the noise floor are quite small. Even a tiny variation in the magnitude of S11 causes a large jump in measured return loss.
-
Even a tiny variation in the magnitude of S11 causes a large jump in measured return loss.
Agreed. Large jump will trash all the average and spike will stay. Yet I marked *dips*. Whatever. If you say it works - fine.
If there were opposite peaks at the time of calibrating the NanoVNA itself, it would over-compensate on those particular frequencies, and consistently produce such dips.
Oh, ok. It means that I did find problem with firmware/calibration, not PC software :D
-
Possibly - though to confirm, you should probably do multiple sweeps with high averaging. If the dips (or peaks) stay in place, it's a "true" error, if they move around, maybe the averaging isn't good enough to catch it, or you have indeed found a bug that I just haven't recognized ;-)
I generally run 10 segments and 25x averaging (using truncated mean, so 25 averages dropping 5 readings per average) when doing calibration. It takes a few minutes per sweep at that point, but it does give a very nice and stable in-application calibration which I can save afterwards. Then again, if I change any cables or connectors, I have to start over ... ::)
-
Possibly - though to confirm, you should probably do multiple sweeps with high averaging. If the dips (or peaks) stay in place, it's a "true" error, if they move around, maybe the averaging isn't good enough to catch it, or you have indeed found a bug that I just haven't recognized ;-)
Everything is fine, there is no bugs. Phew. Three 20x averages of 20dB reflection, they all look basically the same. Conclusion: to get meaningful averaging results, same level of averaging for calibration data is necessary. Now averaging just reveals calibration noise.
-
....
I didn't measured the maximum performance, but think it is about 50-100 kB/s.
....
Communication speed really can be improved, but I'm not sure that this is really needed.
There are several ways to improve performance:
1) optimize communication from PC side (don't send extra requests, don't do long delays, etc)
2) use binary format communications, but it will break compatibility with existing software (NanoVNASharp, Saver, etc)
Oddly, I'm seeing no where close to 50-100 kB/s (400kbs-800kbs) but then again, it could be something I am doing wrong. I don't think this is the problem with why it's so slow. Without the Nano connected to the PC and just watching it, it will scan about once a second. This is using the last image you uploaded.
On the PC I am seeing 325467 Bytes in 14.04 seconds or 185kbs. This is plenty fast to keep up with how slow the Nano scans. If I really push the data rates, basically asking for the next data set right after is finished sending a data set, without giving it some delay, the performance suffers.
Attached, I am showing the data rate portion of my regression test. I send out 50 frequencies commands which are very fast to respond as the payload is so small. This is followed by 50 data 0 and 50 data 1 packets. I will wait up to 2 seconds for the Nano to respond with a valid packet before timing out. I had tried to disable the LCD at one time but it had no effect on the speed. Maybe this has changed.
I've posted this a few times and mentioned it during my video but as long as we are on the topic of speed, unlike the software that was supplied with the Nano, I only request the frequencies when I have changed them. I also only collect data 0 for S11. Their software will collect data 0, data 1 and the frequencies for each sweep. I suspect they need a slightly longer delay for their Auto (1.2 seconds). It's a very small difference and IMO, both are very slow.
But hey, it's $50. I am just happy to see how stable this image you uploaded is! I have been running a fair number of tests on it over the last few days and not once has it white screened, locked up, or sent bad data. :-+
I have not added any support for your averaged scan or the normal scan. I did try sending the commands just to get a feel how they would work.
-
If I really push the data rates, basically asking for the next data set right after is finished sending a data set, without giving it some delay, the performance suffers.
Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small. As we see, PC manages to miss each other scan data set. Needed change is quite "simple" - leave existing "polling" approach alone and introduce new command for continuous scan and "push" for nano. In short nano while said mode is initiated: 1) performs scan 2) optionally displays it on the built-in LCD 3) sends scan data to PC unconditionally and only when USB transfer fully done, continue with next scan.
But hey, it's $50.
Yes, you can say so when you are talking about tiny screen and fonts, awkward and fragile input "thingie", lack of proper case but such excuse is not OK in case of poor software *design* that clearly can be improved.
-
Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small.
No, there is no race condition. There is just delay while NanoVNA is busy. It cannot respond immediately, because it may be busy. If PC request performed when NanoVNA is busy, it will needs to wait. NanoVNA may perform sweep or rendering. PC command cannot interrupt this operation, so it needs to wait until current operation will be completed.
NanoVNA cannot respond in parallel, because data command needs to access to measurement data, which is under update by sweep. It needs to share the same memory with measurement data, because there is not enough memory to store a copy. Measurement data for single channel requires 101*4 = 404 bytes. There is no memory even for stack margins, so you're needs just to share the same memory for different task.
Since data is modified by sweep task and modification is not complete yet, the data command needs to wait when the sweep will be completed. This is the reason for delay.
-
Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small.
No, there is no race condition. There is just delay while NanoVNA is busy. It cannot respond immediately, because it may be busy. If PC request performed when NanoVNA is busy, it will needs to wait.
You do not make any sense. Why PC does get only each 2nd scan then? I am afraid that you need to update your knowledge about "race condition". Meaning is quite broad BTW.
Since data is modified by sweep task and modification is not complete yet, the data command needs to wait when the sweep will be completed. This is the reason for delay.
Yes. It means that PC have small time window. I said it already. Yet you somehow manage to reply "no you are wrong, let me say the same just using another words" :palm: :-DD
[edit] Why don't you comment my suggestion of PC communications redesign? Two PC software guys are reading, they can potentially change software side accordingly, seems you are more than capable to make such seemingly small firmware change.
-
If I really push the data rates, basically asking for the next data set right after is finished sending a data set, without giving it some delay, the performance suffers.
Problem even have a name: multitasking race condition. PC software have to request data but time window while it is available, is very small. As we see, PC manages to miss each other scan data set. Needed change is quite "simple" - leave existing "polling" approach alone and introduce new command for continuous scan and "push" for nano. In short nano while said mode is initiated: 1) performs scan 2) optionally displays it on the built-in LCD 3) sends scan data to PC unconditionally and only when USB transfer fully done, continue with next scan.
But hey, it's $50.
Yes, you can say so when you are talking about tiny screen and fonts, awkward and fragile input "thingie", lack of proper case but such excuse is not OK in case of poor software *design* that clearly can be improved.
Sadly you seem to have ignored:
I don't think this is the problem with why it's so slow. Without the Nano connected to the PC and just watching it, it will scan about once a second. This is using the last image you uploaded. On the PC I am seeing 325467 Bytes in 14.04 seconds or 185kbs. This is plenty fast to keep up with how slow the Nano scans.
I have no race condition. My software is synchronized to the Nano by the completion of the first request.
As we see, PC manages to miss each other scan data set.
As "you" see, not "we". What I see with the software I am writing, using Radiolistern's image is that my PC easily keeps pace with how slow the Nano sweeps.
In case you would like to see what I am seeing, I made a short video showing my software plotting data. The Nano is hung next to the screen so you can watch its' LED compared with the scan indicator of my software. If you have firmware for the Nano that will sweep faster than this, post details about it and I will see if my PC can somehow manage to keep pace with it.
https://youtu.be/N77my69u_b8
-
Why PC does get only each 2nd scan then?
Because NanoVNA Saver sends two data requests. First for S11 and second for S21. Each request requires one sweep cycle. So, two request needs two sweep cycles.
That's behavior is specific for NanoVNA Saver. You can request just S11 and it will take single sweep time. But NanoVNA Saver sends two data requests and this is why it takes two sweeps.
I am afraid that you need to update your knowledge about "race condition". Meaning is quite broad BTW.
There is no race condition for data command, because operations are synchronized with mutex.
Why don't you comment my suggestion of PC communications redesign?
I don't see reason to redesign something. Yes, transfer speed can be improved, but I'm too lazy to do something with no real needs. It already works good enough :)
-
That's behavior is specific for NanoVNA Saver.
I don't know that there would be another way to do it if reading both S11 and S21?
-
Why PC does get only each 2nd scan then?
Because NanoVNA Saver sends two data requests. First for S11 and second for S21. Each request requires one sweep cycle. So, two request needs two sweep cycles.
That's behavior is specific for NanoVNA Saver. You can request just S11 and it will take single sweep time. But NanoVNA Saver sends two data requests and this is why it takes two sweeps.
When I use both data0 & data1, I plot while alternating between the two data sets. So my screen always updates once per request. I guess I could have shown that as well. It would have been just as exciting to watch.
:-DD :-DD
That's totally wrong with my current software. I plot once after both data sets have been collected.
:-DD :-DD
Wrong again.... It's actually the way I originally described. :palm: Time for some wake up juice.
-
As a totally off subject, I happened to listen to the last Amp hour podcast. Anytime they mention RF in the subject with both Dave and Chris, I'll have a listen. Oddly, they are talking about VNAs. Chris talks about getting the new Siglent one and they discuss the merits of the old 8753ES vs the new Siglent. (I almost pulled the trigger on a 6Ghz ES to replace my old 8754A). Anyway, to my surprise, even with it being as popular as it is, there wasn't a single mention of the NanoVNA.
If I were buying my first ever VNA and was just getting started with RF, I would hands down spend the $50 on the Nano to at least learn some of the basics. I wouldn't be surprised to find out that it wasn't the most sold VNA ever!
-
I don't know that I would say it's off-topic. :)
My guess is that there are two main reasons: The NanoVNA isn't being marketed, but only spreading via word of mouth, mainly among enthusiasts in the amateur radio community. And there is a preference, approaching a fetish at times, for expensive test gear from the big name brands among some parts of the electronics community ;)
The NanoVNA is my first VNA, and I have no desire to buy anything more expensive than it, given the (limited) uses I have for it.
-
If I were buying my first ever VNA and was just getting started with RF, I would hands down spend the $50 on the Nano to at least learn some of the basics. I wouldn't be at all surprised to find out that it wasn't the highest sold VNA ever!
It's selling like hotcakes in my town as far as the local hams. A few of us got them and started talking about the NanoVNA. Most people didn't have a clue what a "vector network analyzer" did. But after an explanation and some in-person demos it's caught on Big Time. Companies like MFJ who sell antenna analyzers for hams here -
MFJ Analyzers (https://www.mfjenterprises.com/Categories.php?sub=0&ref=7)
are in trouble because they will not be able to compete with something like the Nano for < $50.
-
As "you" see, not "we".
It's "you", not me/we ;) I talk about NanoVNA Saver and it was clearly said BTW.
Because NanoVNA Saver sends two data requests. First for S11 and second for S21. Each request requires one sweep cycle. So, two request needs two sweep cycles.
Well, I did not know that. It makes sense then indeed. So how does NanoVNA Saver and other PC software can get Both - S11 and S21 using single request? - If there is no command then perhaps you can make one? :-//
-
It's selling like hotcakes in my town as far as the local hams. A few of us got them and started talking about the NanoVNA. Most people didn't have a clue what a "vector network analyzer" did. But after an explanation and some in-person demos it's caught on Big Time. Companies like MFJ who sell antenna analyzers for hams here -
MFJ Analyzers (https://www.mfjenterprises.com/Categories.php?sub=0&ref=7)
are in trouble because they will not be able to compete with something like the Nano for < $50.
That doesn't surprise me at all. If anything, I would have expected him to plug his own site. I find it hard to believe Dave's not aware of this threads' popularity.
-
Companies like MFJ who sell antenna analyzers for hams here -
MFJ Analyzers (https://www.mfjenterprises.com/Categories.php?sub=0&ref=7)
are in trouble because they will not be able to compete with something like the Nano for < $50.
Right, they should be worried :) Is it even legal to use square wave signal for antenna tuning? - Harmonics violate out-of band radiation regulations for sure. It's kinda "spread spectrum" unless CW mode used, but anyway. Many of you are HAMs, right? Perhaps you can comment? - Just curious.
-
Right, they should be worried :) Is it even legal to use square wave signal for antenna tuning? - Harmonics violate out-of band radiation regulations for sure. It's kinda "spread spectrum" unless CW mode used, but anyway. Many of you are HAMs, right? Perhaps you can comment? - Just curious.
What does it output - something like -10 dBm, which is 100 uW? Maybe even less.
I just connected the NanoVNA to a 30m dipole outside, which is just under another fan dipole with the same band included (I have a lot of antennas ). I set the Nano to sweep from 10.1 to 10.150 MHz. I listened to the sweeps on an Icom IC-7300 and you can indeed hear the sweeping (and see it on the waterfall). I then connected the radio to my other main fan dipole which is about 30 feet away - the amplitude is already falling off considerably in that range.
However - I tuned through other ham bands (and other ranges in the shortwave bands) and could not hear any sweeping at all outside of the set sweep range. So, even though there may be sidebands out there, they are too low to detect with a shortwave radio
-
Well, I did not know that. It makes sense then indeed. So how does NanoVNA Saver and other PC software can get Both - S11 and S21 using single request? - If there is no command then perhaps you can make one? :-//
yes, technically there is no command which allows to read S11 and S21 simultaneously. And if you want both, you will need to send two requests and it will take two sweeps. It is possible to add such ability, but current PC software don't know about new features, so they will continue to use old command and it will still take two sweeps :)
This makes a vicious circle. Firmware don't have such command because it is not used in software. And software is unable to do that because there is no such command in firmware :)
Sending both S11 and S21 is much slower. And there is no needs for S11 and S21 simultaneously. So, I don't see the real needs for command which can send information about both channel simultaneously. If you needs S11 and S21 you can send two data commands. And if you needs just S11 or just S21, you can send single data command. It works pretty good.
-
Is it even legal to use square wave signal for antenna tuning? - Harmonics violate out-of band radiation regulations for sure. It's kinda "spread spectrum" unless CW mode used, but anyway. Many of you are HAMs, right? Perhaps you can comment? - Just curious.
NanoVNA has low power output. The maximum peak power from NanoVNA is about 10 dBm and it is even much smaller on high frequency. This is about 0.01 W power. The average NanoVNA power is about -10 dBm, it is about 0.0001 W. In most countries it is allowed to use such power with no license.
HAMs in most cases using resonant antennas, which actually works as effective bandpass filter due to it's high Q-factor. So, it radiates at ham bands and has very low efficiency outside HAM bands. If you use wideband antenna it will have low efficiency due to low Q needed for wide bandwidth.
As you can see, weak signal from NanoVNA can be radiated at HAM bands and it's power as low, so it cannot affect anything.
-
Possibly - though to confirm, you should probably do multiple sweeps with high averaging. If the dips (or peaks) stay in place, it's a "true" error, if they move around, maybe the averaging isn't good enough to catch it, or you have indeed found a bug that I just haven't recognized ;-)
Everything is fine, there is no bugs. Phew. Three 20x averages of 20dB reflection, they all look basically the same. Conclusion: to get meaningful averaging results, same level of averaging for calibration data is necessary. Now averaging just reveals calibration noise.
Yes, I was going to ask whether the calibration is using the averaging also. If not, then the averaging during actual measurement doesn't really make sense as the calibration data is noisy anyway.
Edit: Probably the calibration should be done using at least twice the averaging compared to the averaging used during the actual measurement.
-
And there is no needs for S11 and S21 simultaneously.
Nonsense. You again invent strange (to say it politely) arguments out of nowhere, just for argument sake. Not mentioning big VNA's (https://cdn.rohde-schwarz.com/pws/product/z_1/znb/ZNB_front_4.jpg), even Nanovna itself measure S11 and S21 in single scan pass and display both, yet you just decided for everybody that PC application do not need such feature, at least not as fast as nanovna *hardware* allows. :wtf: FYI it is very convenient to simultaneously see "both ends" of the filter or diplexer or whatever >=2 terminal thing you measure, especially if you tune it. Then it may be even necessity.
NanoVNA has low power output. The maximum peak power from NanoVNA is about 10 dBm and it is even much smaller on high frequency. This is about 0.01 W power. The average NanoVNA power is about -10 dBm, it is about 0.0001 W. In most countries it is allowed to use such power with no license.
Yes. When transmission is within amateur band. I was talking about out of band spurious emissions that are products of square wave. Let's check FCC 47 Radio Amateur Service regulations, §97.307.(e):
on a frequency between 30–225 MHz must be at least 60 dB below the mean power of the fundamental. For a transmitter having a mean power of 25 W or less, the mean power of any spurious emission supplied to the antenna transmission line must not exceed 25 μW and must be at least 40 dB below the mean power of the fundamental emission, but need not be reduced below the power of 10 μW.
10uW is -20dBm, 25uW is -16dBm. What is level of 3rd harmonic when fundamental of square wave is at -10dBm?
-
When NanoVNA-Saver reads a segment, it reads frequencies, S11, S21. For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:
scan 50000 900000000 101
frequencies
data 0
data 1
(Example there for 50 kHz - 900 MHz)
The timing here is as follows, examples from my own NanoVNA:
0.412s: Sending scan command
0.551s: Asked for frequencies
1.320s: Finished receiving frequencies <-- This is where the application primarily waits for the device
1.422s: Asked for S11
1.510s: Done reading S11
1.613s: Asked for S21
1.708s: Done reading S21
Total time spent 1.296 seconds plus the processing done in NanoVNA-Saver. Looks like the time between the app saving data is 1.303, so the application uses 7 milliseconds for its internal processing between segments.
I have tried moving the frequencies to be read later, but the pattern is clear that the first data requested after the "scan" command is slowed down by about 6-800ms.
After each command, the application waits 50ms before it starts emptying the buffer. I doubt that this moves the timings significantly, as emptying the buffers takes more than 50ms in all cases, and the PC speed is not the limit.
I don't know how this looks for different firmwares - I only have the one NanoVNA, and I'm not going to flash all kinds of different firmware on it, as I need it for app development ;) However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested. Prior to doing this (when the timing was 300ms), I would sometimes see values from the previous frequency span repeated. It was faster, but less reliable - and I made the decision that reliable is more important than fast. The code is there for anyone who wants to change it for their own priorities :)
-
When NanoVNA-Saver reads a segment, it reads frequencies, S11, S21. For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:
scan 50000 900000000 101
frequencies
data 0
data 1
(Example there for 50 kHz - 900 MHz)
.....
I don't know how this looks for different firmwares - I only have the one NanoVNA, and I'm not going to flash all kinds of different firmware on it, as I need it for app development ;) However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested.
...
When I first noticed the Scan command someone was posting how it worked and I was interested in looking at it but it was disabled in the Hugen code I downloaded. What was interesting to me is that it sent up the frequency, S11 and S21 data in one call. Plus it would handle more than the 101 points. I had hoped it would help speed things up. While I archived the details how it worked, when I tried to use it with the last image from Radiolistener, it was nothing like what had been presented. It seems like there were different people creating the same commands.
Once again, the lack of documentation for the firmware makes it less appealing at least for me at least to try it out. In the case of the Scan command that's implemented in this particular load, I suspect it is similar to what you have shown. The original documentation I have shows the command not applying the calibration. You don't mention this detail, and I would be guessing and using trial and error. Certainly one way to develop code.
Their Scanraw may be of more interest to me as it supports some sort of averaging which I don't currently support because of how slow the Nano is. Currently I will run a smoothing filter across each sweep. I can easily do this and keep up with that ultra fast 1Hz rate. :-DD I showed a plot and a link to an article about it here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2703604/#msg2703604 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2703604/#msg2703604)
Comment I had archived about the Scan command:
I added one command to the eddy firmware to enable on demand scans of
arbitrary length (yes, you can scan with one million steps or much more if you want)
Usage:
First pause the continuous scanning with "pause" and the use the "scan" command
to scan [from frequency in Hz] [increment frequency in Hz] [number of steps]
The frequency increment step is for now an integer
The scan command outputs
start
frequency s11_real s11_imag s21_real s21_imag
done
during the scan the calibration is NOT used so the output are uncalibrated numbers
allowing alternative calibration strategies
Example:
ch> pause
ch> scan 5000000 20 5
ch> start
5000000 0.001503840 0.000420701 -0.306770563 0.018568072
5000020 0.000695601 0.000503197 -0.306792527 0.018579231
5000040 0.000532656 0.000520238 -0.306793421 0.018573865
5000060 0.000495833 0.000512704 -0.306819111 0.018593480
5000080 0.000520689 0.000523833 -0.306812644 0.018576323
-
Good. Seems like least effort solution to PC software "individual data request for each port which results in 2x slower scanning" problem is - just make new data request command ("data01" ?) that returns data for both ports. As we see format is already there, at least on Nano side. Obviously scan shall include NanoVNA calibration corrections.
5000000 0.001503840 0.000420701 -0.306770563 0.018568072
5000020 0.000695601 0.000503197 -0.306792527 0.018579231
5000040 0.000532656 0.000520238 -0.306793421 0.018573865
-
I'm currently working on porting the firmware to the V2 and I can tell you it's a cesspool of bad design, very typical of embedded code. Implicit function calls everywhere (calling a function without including a header file that contains the declaration, and usually there is no declaration at all), everything communicates through globals, no clear dependency relationship between files, hardcoded callbacks everywhere, compiler warnings seem to be all ignored (because I found a handful of bugs just by looking at the warnings), functions just call each other with no regard to which module it is in (e.g. the si5351 driver accesses global variables declared in main.c), forward declarations in the *caller*'s file, and of course I found one that had the wrong signature. The UI code directly manipulates the ADC FFS.
So far I've decided to simply refractor and integrate the UI code into my own firmware that implements all the VNA functionality from scratch. Of course, the command interface is completely replaced so compatibility is broken and you can get far higher sweep rates. Here is the firmware being worked on: https://github.com/nanovna/NanoVNA-V2-firmware-new
-
For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:
scan 50000 900000000 101
frequencies
data 0
data 1
you can do it in the following way:
scan 50000 900000000 101
frequencies
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
...
I don't know how this looks for different firmwares - I only have the one NanoVNA, and I'm not going to flash all kinds of different firmware on it, as I need it for app development ;)
that's your mistake and the source of bugs. There is no risk for firmware update, except that you may loss your configuration settings and calibration and will needs to calibrate it from scratch after firmware update. But it takes not so long time.
Probably you're using very old firmware, it has race condition issues, high noise floor, high spikes, frequency step rounding error, frequency range rounding error, data transfer error, floating point precision loss and a bunch of other bugs. I highly recommend to use more new firmware.
However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested. Prior to doing this (when the timing was 300ms), I would sometimes see values from the previous frequency span repeated.
such behavior was possible in the old firmware which has race conditions issues and very unstable.
Now I understand the reason why edy555 added scan command. The difference between sweep and scan commands is just that scan command is synchronized with sweep and waits for scan end before executing next command. The sweep command is not synchronized and don't wait's. That's the difference.
That's why you have long delay on frequencies command executed immediately after scan command. You will needs to wait while scan command execution will be completed (it needs to wait for sweep end).
Now I see that using sweep command very often is not thread safe and may leads to data transfer errors. I will think about it and how to fix it.
By the way, NanoVNA-Q has scan command from edy555 version. So you can use it if you needs scan command. Technically all fixes from edy555 branch are included in the NanoVNA-Q firmware, include these which still not released and will be released in the future release of firmware. In addition it also has some fixes from hugen79 branch. Also NanoVNA-Q has a lot of bug fixes.
-
it's a cesspool of bad design, very typical of embedded code
Right. It is usually in case of hobby projects that are started by hobbyists who do not foresee that their creation will ever become widely popular. We shall just live with that.
-
I'm currently working on porting the firmware to the V2 and I can tell you it's a cesspool of bad design, very typical of embedded code. Implicit function calls everywhere (calling a function without including a header file that contains the declaration, and usually there is no declaration at all), everything communicates through globals, no clear dependency relationship between files, hardcoded callbacks everywhere, compiler warnings seem to be all ignored (because I found a handful of bugs just by looking at the warnings), functions just call each other with no regard to which module it is in (e.g. the si5351 driver accesses global variables declared in main.c), forward declarations in the *caller*'s file, and of course I found one that had the wrong signature. The UI code directly manipulates the ADC FFS.
уeah, it has poor design. There is also variable which actually #define for struct member access. It very confusing when you debugging the code :)
The most of warnings, except these about goto statement and floating point conversion, they are fixed in NanoVNA-Q branch.
I also thought about refactoring, but it will take a lot of time. So, I just fixed critical issues in the code and that's it :)
-
Comment I had archived about the Scan command:
this scan command was invented by @erikkaashoek, but it is was rejected by @edy555. He implemented scan command as a thread safe version of sweep command.
So, now scan command is just a thread safe replacement for sweep command. And it cannot sweep more than 101 point.
This is why scanraw command was introduced in the NanoVNA-Q. It has the same principle as @erikkaashoek, but a little optimized and improved.
scanraw don't returns frequency, because frequency can be easily calculated by adding step frequency on each step. And it allows to perform average measurement.
But scanraw don't apply calibration to the measurement results, it just returns raw uncalibrated measurements.
If you're planning to add the same command with calibration apply, I suggest to use name scancal for such command. :)
-
you can do it in the following way:
That would just give me the same data over and over. The NanoVNA stops sweeping after sending the scan command.
Even if it did not, my most common use case is to sweep one segment, then the next, then the next, etc.
that's your mistake and the source of bugs.
Good, we got that squared away then.
Probably you're using very old firmware
I think my post makes it quite clear that I have coded the particular sequence for firmwares newer than 0.2.0. I'm running 0.2.3.
However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested. Prior to doing this (when the timing was 300ms), I would sometimes see values from the previous frequency span repeated.
such behavior was possible in the old firmware which has race conditions issues and very unstable.
Yes, that's where the delay is used.
By the way, NanoVNA-Q has scan command from edy555 version. So you can use it if you needs scan command. Technically all fixes from edy555 branch are included in the NanoVNA-Q firmware, include these which still not released and will be released in the future release of firmware. In addition it also has some fixes from hugen79 branch. Also NanoVNA-Q has a lot of bug fixes.
How would I programmatically recognize a NanoVNA-Q firmware? Which versions have the scan command? Is it from a specific version number and up? Is it fully compatible with the original firmware, or would I have to make special handling for it?
-
......
By the way, NanoVNA-Q has scan command from edy555 version. So you can use it if you needs scan command. Technically all fixes from edy555 branch are included in the NanoVNA-Q firmware, include these which still not released and will be released in the future release of firmware. In addition it also has some fixes from hugen79 branch. Also NanoVNA-Q has a lot of bug fixes.
How would I programmatically recognize a NanoVNA-Q firmware? Which versions have the scan command? Is it from a specific version number and up? Is it fully compatible with the original firmware, or would I have to make special handling for it?
I use the Help command and check the list of supported commands before trying to test them. I would imagine the Info command could be used to narrow it down further.
While my software will work with the six or so images I have tried (at least to the degree that the firmware works), because I don't use the Scan command, I can't comment on if that will hinder you or not.
-
For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:
scan 50000 900000000 101
frequencies
data 0
data 1
you can do it in the following way:
scan 50000 900000000 101
frequencies
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
...
I assume that the data0&1 will cause the Nano to sweep and update the display then.
I wonder what drove the change. If it really takes 1.3 seconds to pull both data sets plus the frequency list, it seems like from your post that the data0 for example could be repeated with an update rate of half that. Still, not great but it seems be this may be an advantage.
-
For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:
scan 50000 900000000 101
frequencies
data 0
data 1
you can do it in the following way:
scan 50000 900000000 101
frequencies
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
...
I assume that the data0&1 will cause the Nano to sweep and update the display then.
I wonder what drove the change. If it really takes 1.3 seconds to pull both data sets plus the frequency list, it seems like from your post that the data0 for example could be repeated with an update rate of half that. Still, not great but it seems be this may be an advantage.
It appears that the scan must be sent prior to each data set being read, or the same data is read. The LCD does not appear to update. So the ordering listed makes sense. Ignoring the floating point errors, you may be able to ignore the frequencies command and just call say data 0. The more I look at it, I am missing the point. The way I structured my code appears very stable and again keeps pace with the slow Nano. So Scan is out unless I really missed the point of it.
scan 50000 900000000 101
frequencies
data 0
data 1
Sending the Scanraw, followed by Frequencies, the displayed frequency list will not match the requested range. The software could calculate the frequencies, ignoring the floating point errors. It's blind faith...
Normally when running a sweep, setting the start frequency to 0Hz will cause the actual start to be whatever the lowest supported frequency is. With Scanraw, it will report out of range. I'm not sure why the commands don't work the same in this respect. As is, without the frequency tracking and lower limit not being coerced, without support for the original command set it would be difficult to find the lower limit.
When using the Scanraw to average the data, there appears to be no user feedback that the Nano is doing anything. The LED stops flashing and the unit appears hung. Again, blind faith, pry it comes back in some amount of time..
When using the Scanraw and setting the upper frequency to 900MHz and a lower to 100KHz, will cause an out of range error. I started with 10KHz to 1G which also errors out. 100KHz to 100MHz seems to work. Same with a 10MHz upper limit.
This was a mistake on my part, using improper syntax.
scanraw
usage: scanraw {channel(0|1)} {start(Hz)} {stEp(Hz)} {count} [average]
ch>
Setting the average parameter to 0 causes an error. I would have expected that to disable the average. Again, trail and error. It's possible that not including the average parameter disables it. Just a guess.
Again, problems could be on my side. I have no documentation on how it should be used and what the fringe cases are. It's a pure design be trial and error, using blind faith. Oh mighty Nano, please except my offering.....
I would expect a new command like scanraw to use the start and stop frequencies along with span and such. I would also expect to be able to use the standard commands like frequencies with it. Having a command to enable average and set what ever parameters it needs, then use the other existing commands to support it.
Using the Scanraw and sending up 101 data points when compared with the original method appears to be very slow. I suspect the only gains are when using the average feature.
***
Added a plot showing the result with the Average parameter set to 100. Without documentation, I am not sure how the average is performed but assume the system performs 100 sweeps to do it. What is interesting is it takes roughly 11 seconds per command or a sweep every tenth of a second. If that's true and the Nano can actually scan this fast, not loose lock and send corrupt data, forget all this scan stuff and speed it up. I would much rather see a 10Hz sweep rate.
-
Dear joeqsmith
i would like to thank you for all this knowledge you are offering.
May I ask you please, what is the program you use and present in your images?
Can you share it with me or let me know about it?
Thanks.
-
Dear joeqsmith
i would like to thank you for all this knowledge you are offering.
May I ask you please, what is the program you use and present in your images?
Can you share it with me or let me know about it?
Thanks.
If you look at the first few posts in this thread, you will find it's custom and written in LabView. There is a member here creating a fully open source interface. I don't know much about it and only tried it out when they first posted about it. I would imagine by now it's fairly mature. Being supplied to the public, I would expect it is much more user friendly and well documented. I would also imagine the support would be there from people using it as well as the author. Personally, I suggest you have a look.
My software by contrast is really being developed to conduct my own personal experiments with the Nano. It's an engineering tool at best. While I have thought about releasing it a few times, reality steps in, bitch slaps me and snaps me out of it. Lack of time to support it is still the biggest concern I have. I suspect the majority of uses of the Nano are amateurs and to be frank, I suspect the software in it's current state would not be well suited for this group. So have a look at the open source and enjoy your Nano. It's a pretty slick device IMO.
-
thank you again for your response
-
The NanoVNA stops sweeping after sending the scan command.
You can use sweep command instead of scan. It works great and allows to update S11 and S21 in a single sweep. At least with NanoVNA-Q it works in such way :)
How would I programmatically recognize a NanoVNA-Q firmware? Which versions have the scan command? Is it from a specific version number and up? Is it fully compatible with the original firmware, or would I have to make special handling for it?
it has board name: NanoVNA-Q
Yes, it is fully compatible with the latest original edy555 firmware. The only difference is that the data command returns more precise values and frequency range has no rounding error. These bugs are fixed.
-
The NanoVNA stops sweeping after sending the scan command.
You can use sweep command instead of scan. It works great and allows to update S11 and S21 in a single sweep. At least with NanoVNA-Q it works in such way :)
Yes, but that doesn't work on the original firmware, at least not after 0.2.0. That's why I changed it; I talked to edy555, and he told me that software should use the "scan" command for future firmware versions. Whether he makes it faster is up to him.
it has board name: NanoVNA-Q
Yes, it is fully compatible with the latest original edy555 firmware. The only difference is that the data command returns more precise values and frequency range has no rounding error. These bugs are fixed.
Sounds good wrt the board name. I'm a little confused that you say it's fully compatible, though, if the scan command behaves differently. What rounding error are you saying the edy555 firmware has?
-
Sending the Scanraw, followed by Frequencies, the displayed frequency list will not match the requested range. The software could calculate the frequencies, ignoring the floating point errors. It's blind faith...
scanraw use integer frequency arithmetic, there is no floating point error for integer arithmetic. It always calculate exactly the same value.
For example, if start frequency is 1000000 and frequency step is 1000. It is guaranteed that frequency list will be exactly the following:
1000000
1001000
1002000
1003000
1004000
...
The result is always predictable. This is why scanraw don't needs frequencies command.
Normally when running a sweep, setting the start frequency to 0Hz will cause the actual start to be whatever the lowest supported frequency is. With Scanraw, it will report out of range. I'm not sure why the commands don't work the same in this respect. As is, without the frequency tracking and lower limit not being coerced, without support for the original command set it would be difficult to find the lower limit.
scanraw returns requested frequency range only. It doesn't shift frequencies. If you requested start frequency 12345 Hz and frequency step 100 Hz, then scanraw guarantee that the first frequency will be always exactly 12345 Hz, the second frequency will be exactly 12345 + 100 = 12445 Hz, the third frequency will be exactly 12345 + 100 + 100 = 12545 Hz etc. Scanraw command guarantees that frequencies will be exactly the same as requested, with no shift, with no rounding error.
This is why scanraw returns error if requested range is out of device frequency range (10 kHz - 1500 MHz).
You can find supported frequencies by send sweep commands and then execute frequencies command:
sweep start 0
sweep stop 4000000000
frequencies
Just look for the first and last record and you will know device limit :)
When using the Scanraw to average the data, there appears to be no user feedback that the Nano is doing anything. The LED stops flashing and the unit appears hung. Again, blind faith, pry it comes back in some amount of time..
it didn't hung. It just capture device for exclusive use during command execution time. When the command will be completed, the normal sweep operation will be restored and you will be able to continue use touch screen as usual.
Setting the average parameter to 0 causes an error. I would have expected that to disable the average. Again, trail and error. It's possible that not including the average parameter disables it. Just a guess.
average = 1 means no average, just single measurement.
average = 0 means zero measurement count and no data. This is why it returns error for zero average.
I would expect a new command like scanraw to use the start and stop frequencies along with span and such.
If you specify start/stop or center/span it leads to uncertainty. The frequency step will be calculated on NanoVNA side and it may have rounding error and you will need to request frequency list. As it used with usual sweep and data commands.
It leads to redundant transfer for frequency data and more long measurement time. And PC cannot control frequency step value, because it will be calculated on NanoVNA side with it's rounding precision. This is why using start/stop center/span is a bad idea.
scanraw uses start/step parameters in order to guarantee that the frequency list will be exactly as requested with no rounding and no shifting. It allows to exclude frequency data from data transfer, because frequency can be easily calculated on PC side and it will be exactly the same. Because it uses integer arithmetic and fixed frequency step. It allows to significantly improve data transfer and measurement speed. And excludes frequency step uncertainty.
Using the Scanraw and sending up 101 data points when compared with the original method appears to be very slow. I suspect the only gains are when using the average feature.
scanraw is introduced for a large datasets. For example if you request 1000 points, scanraw will be done in 6 seconds. If you use data command it will require about 15 seconds for 10 sweeps.
For 3000 points scanraw takes 17 seconds.
With 10x average, 1000 points measurement takes 15 seconds.
This is how it works :)
-
I'm a little confused that you say it's fully compatible, though, if the scan command behaves differently.
"scanraw" and "scan" are different commands.
"scan" command works exactly the same as "scan" command in original edy555 firmware.
What rounding error are you saying the edy555 firmware has?
original firmware has frequency rounding error. For example, if you selected 50000 to 900000000 range, you will find that there is no 50000 and 900000000 frequency. All frequency are shifted with random value, about 16 Hz or something like that.
The worse thing is that the real frequency also may be different from that value which you will get with frequencies command. And there is no reliable way to know that it uses proper frequency.
It will be even more confusing, because NanoVNA shows different frequency range than you get with frequencies command.
These bugs are fixed in NanoVNA-Q.
-
"scan" command works exactly the same as "scan" command in original edy555 firmware.
Right, okay. I was just confused by your earlier post where you suggested I could do scan/data 0/data 1/data 0/data 1/... and get new data. Which isn't possible with the stock firmware. So I thought your version was different. :-)
If it's fully compatible, I think I'll just let it use the same interface as the stock firmware for now.
-
Yes, but that doesn't work on the original firmware, at least not after 0.2.0. That's why I changed it; I talked to edy555, and he told me that software should use the "scan" command for future firmware versions. Whether he makes it faster is up to him.
it works with any firmware version :)
-
Right, okay. I was just confused by your earlier post where you suggested I could do scan/data 0/data 1/data 0/data 1/... and get new data. Which isn't possible with the stock firmware. So I thought your version was different. :-)
yes, you're right, I just forgot, that "scan" command disable sweep. So, such method won't works with "scan" command. But it works good with usual "sweep" command.
-
Yes, but that doesn't work on the original firmware, at least not after 0.2.0. That's why I changed it; I talked to edy555, and he told me that software should use the "scan" command for future firmware versions. Whether he makes it faster is up to him.
it works with any firmware version :)
Firmware version 0.2.0-0.2.2 at least had problems with it - it would return data from the previous span if polled too fast after a sweep command. I think earlier firmwares showed this problem as well. That's why I talked to edy555 about it in the first place.
So no, it doesn't work with "any" firmware version: Sadly, the various firmwares are not generally compatible. :)
-
Firmware version 0.2.0-0.2.2 at least had problems with it - it would return data from the previous span if polled too fast after a sweep command. I think earlier firmwares showed this problem as well. That's why I talked to edy555 about it in the first place.
yes it is possible to read the same sweep two times in a row. But I don't see a big problem with that. Just wait for the next sweep :)
There is no need for delay. Just execute data command again and you will get next sweep.
-
There are serious problems with that approach: When reading multiple segments in a row, reading the wrong data for a given frequency span gives completely wrong readings.
The frequencies command would return the requested span of frequencies, but the data commands would sometimes return the old data. So it wouldn't even be sufficient to check if the frequencies were right.
Your approach of executing the data command again only seems to work for the limited use case of doing continuous single-span sweeping.
-
okay, now I understand the problem. I will try to fix it.
-
try this one. If all works as expected, this version should guarantee that the "data" command will read correct data after "sweep" command. But needs to test.
-
scanraw use integer frequency arithmetic, there is no floating point error for integer arithmetic. It always calculate exactly the same value.
....
The result is always predictable. This is why scanraw don't needs frequencies command.
Understood.
scanraw returns requested frequency range only. It doesn't shift frequencies. If you requested start frequency 12345 Hz and frequency step 100 Hz, then scanraw guarantee that the first frequency will be always exactly 12345 Hz, the second frequency will be exactly 12345 + 100 = 12445 Hz, the third frequency will be exactly 12345 + 100 + 100 = 12545 Hz etc. Scanraw command guarantees that frequencies will be exactly the same as requested, with no shift, with no rounding error.
This is why scanraw returns error if requested range is out of device frequency range (10 kHz - 1500 MHz).
You can find supported frequencies by send sweep commands and then execute frequencies command:
sweep start 0
sweep stop 4000000000
frequencies
Just look for the first and last record and you will know device limit :)
Understood. Of course, it requires the older Frequencies command, which is how I had been determining the limits.
When using the Scanraw to average the data, there appears to be no user feedback that the Nano is doing anything. The LED stops flashing and the unit appears hung. Again, blind faith, pry it comes back in some amount of time..
it didn't hung. It just capture device for exclusive use during command execution time. When the command will be completed, the normal sweep operation will be restored and you will be able to continue use touch screen as usual.
My point is from a user perspective. Depending on the parameters passed down to the command, it may require minutes to run. During that time, nothing is happening on the Nano. The PC can't detect if it's doing anything. The LED that normally would show that it is scanning, doesn't appear to be used. For all practical purposes, it appears dead.
If you specify start/stop or center/span it leads to uncertainty. The frequency step will be calculated on NanoVNA side and it may have rounding error and you will need to request frequency list. As it used with usual sweep and data commands.
It leads to redundant transfer for frequency data and more long measurement time. And PC cannot control frequency step value, because it will be calculated on NanoVNA side with it's rounding precision. This is why using start/stop center/span is a bad idea.
scanraw uses start/step parameters in order to guarantee that the frequency list will be exactly as requested with no rounding and no shifting. It allows to exclude frequency data from data transfer, because frequency can be easily calculated on PC side and it will be exactly the same. Because it uses integer arithmetic and fixed frequency step. It allows to significantly improve data transfer and measurement speed. And excludes frequency step uncertainty.
Understood. I doubt the rounding would make any difference to me as a user. I only request the frequency when I change it so that really doesn't come into play when looking at the measurement times. From my experience, start, stop, center and span are all fairly common commands for NA and SAs. The analyzer normally calculates the step size. It's been ingrained into me by the industry.
Overall speed wise, from what I can tell, the scanraw is very slow for doing 101 samples without average. Hands down, if I needed to run a longer average, it would be faster but the smoothing has been good enough and I get the updates live. I've thought about using a running average but haven't had a need for it yet.
Using the Scanraw and sending up 101 data points when compared with the original method appears to be very slow. I suspect the only gains are when using the average feature.
scanraw is introduced for a large datasets. For example if you request 1000 points, scanraw will be done in 6 seconds. If you use data command it will require about 15 seconds for 10 sweeps.
For 3000 points scanraw takes 17 seconds.
With 10x average, 1000 points measurement takes 15 seconds.
This is how it works :)
Understood. If it were possible to get the system to collect data on the PC faster, that's what I would want. Fast enough that as I make adjustments that there is no perceptive delay. Then again, that $50 number forgives a lot....
It's odd as I started using segmented sweeping shortly after getting the Nano and having it miss or be out of sync hasn't been a problem. I tried several tests with your previous image and it seems to work fine.
I have downloaded your latest version and plan to let it run the latest regression tests overnight. It's about a quarter of the way through now and I'm not seeing any problems with it.
I tried downloading a really early version and running it. I couldn't make it past one loop without getting bad data from the Nano. Even if I don't end up using any of these new commands, these updates you have made appear to be a substantial improvement in making the Nano more robust.
************************************
Your latest version passed the regression test without any errors. There are commands that I don't currently support as I havn't found a use for them. Also, the order the commands are sent is pretty much the same as I would use when normally talking with the Nano. The fact it doesn't detect a change in the this new version and your previous one should give you some idea how primitive the tests are.
I made a couple of custom transfer relays for the Nano, both with poor performance. One uses GaAs. I've thought about using this relay (which would not wear out) to allow me to enhance my tests. Currently I just install a thru and do what I can with it.
-
My point is from a user perspective. Depending on the parameters passed down to the command, it may require minutes to run. During that time, nothing is happening on the Nano. The PC can't detect if it's doing anything. The LED that normally would show that it is scanning, doesn't appear to be used. For all practical purposes, it appears dead.
This is done intentionally. LED blinking leads to a small power supply voltage fluctuations due to Ohm's law, which leads to a little voltage jumps for SA602 mixers and ADC REF power supply. Also it leads to noise from rise and fall pulses.
Power supply purity is critical when you deal with 80-90 dB range signals. This is why LED is off during measurement, to eliminate redundant noise source.
You can check that device still alive by monitoring data transfer through USB port. If device sends you a lot of data, it cannot be dead :)
-
My point is from a user perspective. Depending on the parameters passed down to the command, it may require minutes to run. During that time, nothing is happening on the Nano. The PC can't detect if it's doing anything. The LED that normally would show that it is scanning, doesn't appear to be used. For all practical purposes, it appears dead.
This is done intentionally. LED blinking leads to a small power supply voltage fluctuations due to Ohm's law, which leads to a little voltage jumps for SA602 mixers and ADC REF power supply. Also it leads to noise from rise and fall pulses.
Power supply purity is critical when you deal with 80-90 dB range signals. This is why LED is off during measurement, to eliminate redundant noise source.
You can check that device still alive by monitoring data transfer through USB port. If device sends you a lot of data, it cannot be dead :)
It may take minutes for it to start to send data. I didn't try to see how far I could push it out but I tried it at around 1 minute, 45 seconds and it did eventually respond with data.
scanraw 0 10000 10000 101 1000
Plug in the wrong parameters and there is no way I know of to abort it. Still, if what I am seeing is actually correct, that's 1000 sweeps in 105 seconds or around 10X faster than what we have today.
-
It may take minutes for it to start to send data.
no, scanraw command starts to send data immediately. There is no memory to store all points, so it needs to send each measured frequency to PC.
-
It may take minutes for it to start to send data.
no, scanraw command starts to send data immediately. There is no memory to store all points, so it needs to send each measured frequency to PC.
Odd. That's not what I see with a dumb terminal.
Using scanraw 0 10000 10000 1000 1000 requires about 17 minutes before the Nano responds. 1Hz with 10X the data.
I sent something like scanraw 0 10000 1 1000000 10. I assume it's been crunching on it for over 45 minutes now. During this time, I have tried sending various commands to see if it would respond to anything but it appears not to. The touchscreen has no effect.
While you may not perceive these as valid use cases for your command, if that's true you need to limit the parameters that can be sent to it and document these limits.
***
I had assumed you accumulated the data for the average then did a simple divide before sending. It sounds like this may not be the case and it may be something other than an average.
-
Odd. That's not what I see with a dumb terminal.
Using scanraw 0 10000 10000 1000 1000 requires about 17 minutes before the Nano responds.
just tried. It responds in 1 second and sends each frequency step with about 1 second interval. Probably your terminal has some kind of buffering or cache. Try PuTTY
-
That's really odd. The scanraw 0 10000 1 1000000 1 required well over an hour before it responded. Again Nano is locked up from a user perspective this entire time.
How should it work then? For the case of scanraw 0 10000 10000 1000 1000, does it do 1000 sweeps at each discrete frequency, do the division then send that one frequency?
I just tried Tera Term and sure enough, it is sending something. I still see no way to abort it. It doesn't appear to respond to any commands until it is finished.
-
That's really odd. The scanraw 0 10000 1 1000000 1 required well over an hour before it responded. Again Nano is locked up from a user perspective this entire time.
This is problem with your terminal application. There is no delay. The first response takes about 0.5 second.
-
How should it work then?
scanraw 0 10000 1 1000000 1 works in the following way:
- measure frequency 10000 Hz
- send measured data to PC
- measure frequency 10001 Hz
- send measured data to PC
- measure frequency 10002 Hz
- send measured data to PC
...
if you requested 1000000 points it can take long time :)
-
How should it work then?
scanraw 0 10000 1 1000000 1 works in the following way:
- measure frequency 10000 Hz
- send measured data to PC
- measure frequency 10001 Hz
- send measured data to PC
- measure frequency 10002 Hz
- send measured data to PC
...
if you requested 1000000 points it can take long time :)
Is there a reason you don't want to discuss the average? Or am I not being clear when I am asking how the average works?
And, is there a way to abort it?
-
Is there a reason you don't want to discuss the average?
Average works in usual way. For example average 3x is specified.
Then it performs 3 measurements: a1, a2, a3.
each measurement is complex, it includes real and imag part.
the result will be calculated in the following way:
real part = ( real(a1) + real(a2) + real(a3) ) / 3
imag part = ( imag(a1) + imag(a2) + imag(a3) ) / 3
And, is there a way to abort it?
yes, you can abort it with power off NanoVNA ;D
-
Is there a reason you don't want to discuss the average?
Average works in usual way. For example average 3x is specified.
Then it performs 3 measurements: a1, a2, a3.
each measurement is complex, it includes real and imag part.
the result will be calculated in the following way:
real part = ( real(a1) + real(a2) + real(a3) ) / 3
imag part = ( imag(a1) + imag(a2) + imag(a3) ) / 3
And, is there a way to abort it?
yes, you can abort it with power off NanoVNA ;D
Hang in there. It's slowly sinking in.
After some trial and error, it seems you limit the number of accumulations to 1000. 1001 errors out. For a single sample with averages set to 1000, scanraw 0 10000 1 1 1000, it seems as though you can read at about 1KHz. So, for 100 samples, can it sweep at 10Hz without averaging? At least running it with the Tera Term and sending scanraw 0 10000 1 101 1, it doesn't appear so. I wonder is the poor update rate really the time it takes to sweep (perhaps limited by the loss of lock) or is it the data rate.
-
sweep requires change frequency. Change frequency needs for wait PLL lock, etc.
Average don't needs to change frequency. It just needs to get more samples. This is why it works much more faster than usual sweep.
scanraw works pretty fast for usual measurements. If you want realtime fast sweep several times per second, I think NanoVNA cannot do that, because there is needs some time for pll lock, for channel switch, for gain stabilization, etc.
Average don't needs to switch channel, don't needs to change gain, don't needs to change frequency and don't needs to wait for PLL lock. This is why it can measure several samples more fast.
-
Thank you for all the information.
Does your new firmware wait for the lock status?
Have you looked into the purpose of the other two commands (threshold & transform) you added? If so, could you provide a brief description?
-
Does your new firmware wait for the lock status?
yes, it check hardware status of PLL lock. In, comparison original edy555 firmware just use some delay with no actual check for hardware PLL status. The idea to check PLL status was introduced on this thread by user radioactive (https://www.eevblog.com/forum/profile/?u=250409).
Have you looked into the purpose of the other two commands (threshold & transform) you added? If so, could you provide a brief description?
These commands were added by edy555 in original firmware it will be available in the next edy555 firmware release. It just merged to NanoVNA-Q.
"threshold" command allows to change frequency threshold for 1-st harmonic. By default it uses 300 MHz threshold. Bad quality si5351 chips cannot work at 300 MHz. In such case you can decrease threshold.
"transform" command just a console command for DISPLAY => TRANSFORM menu. It enables TDR mode on NanoVNA.
-
Your lock check routine appears to only be used when changing ranges. Others appear to use a fixed delay time.
I tried to download your latest files and now see this error:
./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
extern uint32_t dfu_reset_to_bootloader_magic;
^~~~~~~~
Looks like you have been busy. Lot's of changes.....
-
I tried to download your latest files and now see this error:
./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
extern uint32_t dfu_reset_to_bootloader_magic;
^~~~~~~~
interesting. I don't have such error, some compiler dependent issue.
You can solve it by adding this line at the top of board.h file:
#include <stdint.h>
-
I tried to download your latest files and now see this error:
./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
extern uint32_t dfu_reset_to_bootloader_magic;
^~~~~~~~
interesting. I don't have such error, some compiler dependent issue.
You can solve it by adding this line at the top of board.h file:
#include <stdint.h>
Thanks. After adding, it builds without any other changes. It's running the regression now.
*****
Passes.
-
I connected my home made GaAs transfer relay to the nano with two different loads. I then toggle between the two, collecting and plotting the data while in each state. The firmware I am using is the one I mentioned in the previous post, so I assume it will have whatever fix was specifically added to try and address the out of sync problem.
You can see there are two discrete lines for the two states. If the firmware or my software were to fall out of sync, these two lines are going to swap positions.
This is using my normal method of start, stop, data0, toggle and repeat. Again, I have never had this be a problem when I use my segmented sweep and am not expecting to find anything. I'll let it run overnight.
It's possible that something else was wrong but because of how I talk with the nano, I never run into it.
****
I had the wrong data being plotted, but caught it before calling it a day. It ran all night and never fell out of sync.
-
Showing test setup and data from the toggle test. I am not sure what was going on with the 500 ohm being bimodal towards the end. It gets a bit of an offset and higher noise. Maybe something being coupled in from the PC.
-
Showing test setup and data from the toggle test. I am not sure what was going on with the 500 ohm being bimodal towards the end. It gets a bit of an offset and higher noise. Maybe something being coupled in from the PC.
probably this is charge controller from NanoVNA. It is a little noisy and you can notice significant offset when usb charger is connected to NanoVNA.
-
I would expect with it plugged into the USB while running it, if it was low we would have seen it charge early on in the data set, not towards the end. Still, it's certainly possible.
What is the thread safe display about?
-
it allows to use display from different threads of NanoVNA firmware. Technically it allows to get screenshot from almost any device state, for example now you can get screenshot with numpad, or version screen. Old firmware doesn't allow that. :)
In addition, these issues related with data modification from different threads are fixed. Now it will not get you garbage if two threads trying to modify the same memory simultaneously. Unfortunately, not all issues are fixed. Actually, original firmware was overcrowded with these thread collision issues. Fix of some issues may leads to slow down PC data transfer due to poor data transfer protocol. I cannot change it, because it will break backward compatibility. So, I leave some issues unfixed in order to support backward compatibility and fast data transfer.
In overall, I feel the whole code needs to be rewritten. Because there are whole black holes full of bugs. For example, try to press joystick for long time on START/STOP menu in the STIMULUS. It will open numerical editor, which currently don't works properly. I have fix, but it pulls a buch of another changes. So, I just shelved these fixes. It will take a lot of time and I'm not sure that I want to spend time on that :)
I feel that I want just to fix major issues and the rest of issues leave as is. Because it already works good enough :)
PS: forgot to say, numpad frequency rounding error is fixed. Now you can enter 123456789 Hz on NanoVNA numpad and it will be exactly 123456789. In old versions it was rounded to 123456792. Annoying bug. But now it works as expected :)
-
Thanks for the description. I'm not understanding what you mean by a screen shot. Are you suggesting there is a way to do screen captures of the Nano from the PC?
Personally, I think you've done a great job getting it as stable as it is. My software is fairly simple and doesn't take advantage of most of the new features. Combined with seldom running it standalone, this may be why I'm not finding problems with your later versions.
I would still like to see the Nano scan faster but I don't see it as a major issue. If you decided to go after it, I would attempt to support it.
It's funny to hear your concerned with few Hz error. Having used my old HP VNA, I can't control it anywhere near that. There's no way to control the start, stop, center or span from the software. Even from the panel, it's not accurate. The only thing I can do with the PC is download the data from it. The Nano being 40 years newer, is far more advanced.
"transform" command just a console command for DISPLAY => TRANSFORM menu. It enables TDR mode on NanoVNA.
Could you please walk though the steps on how to use it?
I was missing that real needs to be selected.
-
Hello 'radiolistener':
A little over a month ago I installed newer firmware in my NanoVLA per your instructions here -> https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2701026/#msg2701026 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2701026/#msg2701026)
First of all I would like to thank you again for all the assistance you provided, and I was able to successfully install version 0.1.1.9 firmware, also others below this level. Although this is where it has stopped for me, as I'm not able to fully install any 0.2.x or 0.3.x versions. It seems to install, and it reports that it was installed, although when I select the menu, and them select a individual menu item, the whole menu just disappears. Gonski! So I'm unable to Cal. the unit, see version info, or do anything else with it. Although earlier versions, and 0.1.1.9 does works Ok (with a few miner bugs) and of course up to 1.5 GHz. By the way I had some other issues here that has taken all my time until now, and I have been re-visiting this with no results to date. I'm still able to go back and reinstall ver. 0.1.1.9 after several failed attempts with newer firmware.
Do you (or anyone else please) have any thoughts on what could cause this inability to install more recent firmware? Any suggestions to try wold be appreciated. Thank you in advance, Ted
Edit - PS: I have been using your method '2) ST-LINK update', and have also tried '1) DFO update'. Neither works for me with the newer FW.
-
Try the attached file which clears all memory, then try the latest firmware. Hope it helps.
-
Hello xrunner:
Wow! That did it for me. Thank you so very much. I had supposedly previously cleared the firmware area a couple of times thinking that would have possibly helped. Any way your file did the job. Thanks, Ted
-
Cool!
[attachimg=1]
-
Do you (or anyone else please) have any thoughts on what could cause this inability to install more recent firmware? Any suggestions to try wold be appreciated. Thank you in advance, Ted
it looks like you're forgot to clean up settings after update. You can do it with console command
clearconfig 1234
Just run PuTTY, select Serial connection and enter COM port name with NanoVNA. Connect and execute this command. It will clean all settings. After that do power off and power on. That's it.
Some peoples doing clean memory with CLEAR.DFU file. But this way is not reliable. Execute clearconfig is more reliable way.
After cleanup, you're needs to do touch calibration, enter to CONFIG menu and select TOUCH CAL. Then check your touch calibration with TOUCH TEST menu. If it works ok, then save this touch calibration with menu SAVE.
After that, just setup frequency range in STIMULUS menu and do usual calibration.
-
it looks like you're forgot to clean up settings after update. You can do it with console command
clearconfig 1234
*Manual* reset of data which is made invalid by data-related changes in firmware can be easily avoided. Usually it is done by saving firmware data format version along with data (settings/calibration), comparing it upon startup. When no match - reset automagically, just notify user, or maybe not.
-
*Manual* reset of data which is made invalid by data-related changes in firmware can be easily avoided. Usually it is done by saving firmware data format version along with data
it's already present. But it seems that some old firmware had different data structure, but the same version code. I think you're right it will be better to change version for different firmware, even if it uses the same data structure.
-
it seems that some old firmware had different data structure, but the same version code
You may avoid that mistake by simply introducing new version code disregarding fact that structure is not changed. [edit] Data contents (compatibility) change also shall be versioned, not only structure change.
-
Thanks radiolistener! I've been following this thread for a while, waiting for my nanoVNA to arrive.
I finally got mine a couple of weeks ago, and thanks to all the information you've shared here I was able to update my nanoVNA to a more recent firmware version!
I was also able to fix the battery indicator by soldering D2 on the board. I have to admit I didn't have the diode specified in the schematics, so I used a thru-hole 5817 that I managed to solder on the pads by clipping and bending the diode legs against its body, similar to a DO-214 package. I figured the only important spec was low Vf, and that's the diode with the lowest forward voltage I had. I'm not 100% sure if it's a good choice for that application, but for the time being it seems to work.
-
Hi battlecoder,
You should subscribe to this board ASAP:
https://groups.io/g/nanovna-users (https://groups.io/g/nanovna-users)
It's really the main place of info, help & devel works for this marvelous unit :)
-
The NanoVNA menu can be like working in the dark searching for where to go next. That is until you get used to it, and appreciate it’s features and very easy operation. So for a kick start and a reminder, I made this PDF Table of the Menu Options in the NanoVNA with Firmware (edy555) 0.3.1 (the latest). Please let me know if you find any errors or missing info.
-
... So for a kick start and a reminder, I made this PDF Table of the Menu Options in the NanoVNA with Firmware (edy555) 0.3.1 (the latest). Please let me know if you find any errors or missing info.
This, IMHO, is the most actual, accurate & convenient Menu info page:
https://oristopo.github.io/nVhelp/html/Menu.htm (https://oristopo.github.io/nVhelp/html/Menu.htm)
Oristo prepared quite comprehensive docu page also:
https://oristopo.github.io/nVhelp/html/nVhelp.htm#U0 (https://oristopo.github.io/nVhelp/html/nVhelp.htm#U0)
-
Hello Joe, I'm new to the nanovna but delighted with the product. I'm trying to find your Nano Custom Software (for a pc) as shown in your video .... is it available for download anywhere?
-
Hello Joe, I'm new to the nanovna but delighted with the product. I'm trying to find your Nano Custom Software (for a pc) as shown in your video .... is it available for download anywhere?
Bradley, while I have not released my software there are a few open source projects being worked on that may work well for you. I can't say I have personally tried any of them but I suspect they are much closer to what you would want from a software interface than what I put together for doing my own evaluation of the Nano.
As I have stated a few times, mine is really more of an engineering research tool than anything. It supports some hardware to run specific tests that the average user is not going to have access to. It's also become a lot more complex over time and I have yet to put any sort of manual together for it.
I was going to make one last video showing some of the latest features and maybe provide some additional ideas to those creating the open source code but I lost interest in the project. If you find that the open source projects are lacking in some way, I suggest you politely ask the authors and see if they will support you.
Enjoy your Nano. It is a pretty nice device, especially at the $50 price.
-
I installed VNASaver on my iMac. Installation was succesful. But when I connect my unit by USB and click connect to NANOVNA I get this failure:
MacMini-I:.config mathieuverhorst$ cd nanovnasaver
MacMini-I:nanovnasaver mathieuverhorst$ nanovnasaver
NanoVNASaver 0.2.0
Copyright (C) 2019 Rune B. Broberg
This program comes with ABSOLUTELY NO WARRANTY
This program is licensed under the GNU General Public License version 3
See https://github.com/mihtjel/nanovna-saver for further details
Settings: /Users/mathieuverhorst/.config/NanoVNASaver/NanoVNASaver.ini
2019-11-28 11:40:42,308 - NanoVNASaver.NanoVNASaver - ERROR - Tried to open and failed: [Errno 2] could not open port : [Errno 2] No such file or directory: ''
What can be wrong?
If I cannot connect to my Mac, I even cannot update my VNA-f in the future...
Thanks in advance again!!
-
pa3hfu, I'm not sure if NanoVNA-F is compatible with NanoVNA-SAVER, but your error looks like you have issue with port name. It may be related with missing driver or bad USB connection.
-
Thanks RadioListener, It was a bad USB connection. Another cable ==> succes!! :D
-
RF Demo Kit - NanoVNA Test Networks Data
The following PDF provides information on the RF Demo Kit manufactured by SYSJOINT.CON, EEPELEC.COM, etc. This document describes the required VNA settings (of course not just the NanoVNA) to duplicate the response cures depicted on the unit's PCB for each RF circuit.
Edit: Without this type of information the RF Demon Kit is of very little value, if any for a novice. Although with it you can verify that your VNA (any type/model) is working properly, and the RF Demo Kit then can also assist with learning how to use a VNA for measuring low value LC (i.e. uH, pF) components, use of a Smith Chart, etc, in addition to simply Antenna SWR.
Note: I’m not affiliated with any eBay seller of the RF Demo Kit, and in fact I held off posting this for a month or so because I didn’t want them to use this info to sell their product. But I caved and decided to share it with other users that may be interested. Although this is not rocket science, and anyone with a VNA could have done this very easily.
-
Just an update.
I've had a few people ask me about how the Nano compares with other VNAs. I will ask for specifics but it seems to be a more general question in general. I think the last person asked about reliability and I responded that I had the Nano for a few months but my old 8754A has spanned five decades now and still running. (with the original capacitors BTW lol)
I see where there continues to be an effort to produce a 3GHz pocket VNA that doesn't use harmonics. If they come up with a product, I plan to have a look.
Playing with the Nano may end up costing me a chunk of change as it's rekindled my interest in replacing my old VNA. I am reading up on the more common instruments available today.
I was thinking that I may do some sort of video that compares these four systems. Obviously reliability can't be a metric but if you have something you would like to see, feel free to chime in.
A few things off the top of my head are noise, cost, features, noise, stability, accuracy, noise, dynamic range, ease of interfacing it with a PC, noise and sweep rates. I may do something with noise while I am at it.
-
Main difference between two: 8754A is instrument with certain and defined accuracy, NanoVNA is "low cost tool". Latter is more like pocket DMM which BTW is sold w/o proper enclosure, another - benchtop multimeter with (possibly valid) calibration sticker on it. Both have their use.
-
While it wouldn't take much to improve on my old HP, I would like to find something that will support lower frequencies (<1MHz) and faster data rates to the PC. I dare say without the Labview interface, the old HP would be worthless as I no longer have a grease pen to write on the screen. With Windows 10, I now need to run it under a virtual XP box and I can't see investing the time to do this. I want to get something new enough to at least support Ethernet. Thinking something along the lines of the old Agilent PNAs like this one:
https://www.ebay.com/itm/Agilent-PNA-E8358A-300kHz-9GHz-2-Port-4-Receiver-RF-Vector-Network-Analyzer-015/223568031067?hash=item340db16d5b:g:rw4AAOSwK0ldFTxx (https://www.ebay.com/itm/Agilent-PNA-E8358A-300kHz-9GHz-2-Port-4-Receiver-RF-Vector-Network-Analyzer-015/223568031067?hash=item340db16d5b:g:rw4AAOSwK0ldFTxx)
I've been reading the manuals and like the system but they do seem to have some high asking prices for them.
-
Please look here:
https://groups.io/g/nanovna-users/wiki/shellcommands (https://groups.io/g/nanovna-users/wiki/shellcommands)
-
Please look here:
https://groups.io/g/nanovna-users/wiki/shellcommands (https://groups.io/g/nanovna-users/wiki/shellcommands)
If there is something specific you would like me to have a look at, just upload it here or to Google docs.
I have to be registered to gain access to this area. I was a member for a very short time. The majority of posts were about how to print a case for it. There were very few technical discussions and so I left.
That ebay listing advertises "Fully Functional, aligned with test data", but we can clearly see one of the source attenuators is damaged.
https://www.ebay.com/itm/Agilent-PNA-E8358A-300kHz-9GHz-2-Port-4-Reciever-RF-Vector-Network-Analyzer/273440234503?_trkparms=aid%3D1110001%26algo%3DSPLICE.SIM%26ao%3D2%26asc%3D20160323102634%26meid%3Df1cbcf5bc5c74606920468d8c5276bd9%26pid%3D100623%26rk%3D2%26rkt%3D6%26sd%3D223568031067%26itm%3D273440234503%26pmt%3D0%26noa%3D1%26pg%3D2047675&_trksid=p2047675.c100623.m-1 (https://www.ebay.com/itm/Agilent-PNA-E8358A-300kHz-9GHz-2-Port-4-Reciever-RF-Vector-Network-Analyzer/273440234503?_trkparms=aid%3D1110001%26algo%3DSPLICE.SIM%26ao%3D2%26asc%3D20160323102634%26meid%3Df1cbcf5bc5c74606920468d8c5276bd9%26pid%3D100623%26rk%3D2%26rkt%3D6%26sd%3D223568031067%26itm%3D273440234503%26pmt%3D0%26noa%3D1%26pg%3D2047675&_trksid=p2047675.c100623.m-1)
I was thinking, pay a little more and you could get a working one. We can see "Seller refurbished: An item that has been restored to working order by the eBay seller or a third party not approved by the manufacturer. This means the item has been inspected, cleaned, and repaired to full working order and is in excellent condition." Again, slide down to the diagnostics page and we can see the unit fails the diagnostics.
Most listings don't offer any details so it's a pretty high risk for such an old system that is no longer serviced and parts may be difficult to locate.
I haven't looked at what they are actually selling for yet but for a 20 years old, damaged unit, the prices see way off. Maybe time for some very low offers.
-
I have to be registered to gain access to this area. I was a member for a very short time. The majority of posts were about how to print a case for it. There were very few technical discussions and so I left.
Joe,
The groups.io nanaovna users group has changed a lot since you first saw it. High SNR now...
There a now a lot of people with extensive VNA experience posting good technical stuff at a high level. Some are VNA calibration commercial vendors and one is developing a new low cost VNA's that go up to 3.5 GHz for $100 USD (just went into production) . Hugen who made the nanovna so popular by creating an assembled product posts from time to time as well as several authors who have created forked firmware and software for the device. There is also an extensive wiki on all facets of software, hardware and documentation plus many informative user manuals.
Roger
-
I have to be registered to gain access to this area. I was a member for a very short time. The majority of posts were about how to print a case for it. There were very few technical discussions and so I left.
Joe,
The groups.io nanaovna users group has changed a lot since you first saw it. High SNR now...
There a now a lot of people with extensive VNA experience posting good technical stuff at a high level. Some are VNA calibration commercial vendors and one is developing a new low cost VNA's that go up to 3.5 GHz for $100 USD (just went into production) . Hugen who made the nanovna so popular by creating an assembled product posts from time to time as well as several authors who have created forked firmware and software for the device. There is also an extensive wiki on all facets of software, hardware and documentation plus many informative user manuals.
Roger
Good to hear that the group has evolved.
In my first post, I had mentioned the plan was to compare the 3GHz unit with a few others once it becomes available. As I mention, their Wiki appears locked for member's only. So if there is anything specific people would want me to look at, they would need to make it publicly available.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2887094/#msg2887094 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2887094/#msg2887094)
There was a member here that was doing a fair amount of work on the firmware. I haven't looked at their progress in a few months but the later versions I was testing were a lot more stable that anything else I had seen at the time.
-
You are basing this on ADC bits. ADC bits is not the limiting factor on dynamic range. It is the synthesizer, followed by harmonic mixing that is limiting dynamic range.
Also the lower maximum sampling rate of the TLV320 limits the frequency of the I.F. which in turn results in more sideband noise from the synthesizer which limits dynamic range.
-
You are basing this on ADC bits. ADC bits is not the limiting factor on dynamic range. It is the synthesizer, followed by harmonic mixing that is limiting dynamic range.
Also the lower maximum sampling rate of the TLV320 limits the frequency of the I.F. which in turn results in more sideband noise from the synthesizer which limits dynamic range.
I would have no way of knowing what this is in regards to. Who is "you" and what was based on ADC bits?
-
Yes, so V2 uses the built in ADC on the GD32. The input noise floor is still far above the ADC's own noise floor so it was "free" cost savings. The bottleneck on S21 noise floor is the PSRR of the receive mixer and the fact that LF noise can't easily be filtered (and there is no power budget available for a linear regulator instead of a switching one).
The bottleneck on S11 trace noise is synthesizer phase noise, both the close-in noise (slow wobbling of the center frequency/phase) and the noise at the image frequency (f_RF + f_IF * 2). The close-in noise can be cancelled by the reference receiver, but the image noise can't. At 12kHz IF the two noise contributions are about the same, which means the noise improvement due to the reference receiver is only 3dB, which is why we went with a switched reference channel in V2.
-
May I make a suggestion? Synchronize the data acquisition to the IF cycles, rather than free acquiring the IF because the microcontroller and the frequency synthesizer are on different clocks. This also helps with phase noise. The VNA I designed acquired four samples per cycle, so that one can do simple addition and subtract to get in-phase and quadrature components. This is not presently done in the NanoVNA. This will help reduce the sensitivity to phase noise and allow much longer integrations (smaller IF bandwidth) to achieve a lower noise floor if needed.
Also, I don't think the NanoVNA as built presently stays within the linear region of the mixer. It overdrives the inputs of the SA612 severely. The datasheet indicates the proper level of drive. The RF pins should be much less than kT/q or 26 mV, usually 10 mV is the maximum desired drive. The oscillator pins should be no more than 200 mV. I stick with 100 mV to stay in the linear region.
Gilbert cells are good for RF receivers but their dynamic range is not that great because they only accept small signals. The dynamic range in practice is determined by the noise voltage on the low-end (a few microvolts) up to the limit where the intermod products start to distort the mixing signal (about 10 mV). EU1KY did a good job in his design because he maximized the signal available to the SA612 given these constraints. The tests being done on the NanoVNA on open, short, load don't test this at all. Try measuring 10000 ohms S11 in the HF or 1000 ohms at UHF and see what happens. Don't make these mistakes again with a new design.
Also, it wouldn't hurt to have a proper fixture so that you can do these tests properly. I designed one for my VNA. Perhaps you could use that or make one of your own. I very much tried to wring every bit of accuracy out of the VNA design even if it meant the data acquisition would be slow.
Anyways if any of this interests you, take a look at
http://github.com/profdc9/VNA (http://github.com/profdc9/VNA)
-
microcontroller and the frequency synthesizer are on different clocks
No they are not. In NanoVNA and NanoVNA.v2 everything related to signal path (mixers & ADC) is clocked from single source, si5351.
-
https://www.rtl-sdr.com/a-nanovna-2-0-is-in-the-works-same-price-frequency-range-up-to-3-5-ghz-higher-dynamic-range/ (https://www.rtl-sdr.com/a-nanovna-2-0-is-in-the-works-same-price-frequency-range-up-to-3-5-ghz-higher-dynamic-range/)
In the above article, dated Oct 4th 2019, they mention initial sales in roughly 3 months. I assume then that things are pretty much wrapped up with research/development and it is now in the production phase . Is this correct, or is the project still in the design phase?
-
That doesn't mean that the acquisitions are synchronized so that the same part of each IF cycle is sampled. How many clocks of the crystal on the SI5351A correspond to the RF and LO signals and the MCLK driving the codec and the microcontroller? They are all on separate fractional dividers. Being clocked from the same crystal is a necessary, but not sufficient, condition for the IF acquisition to be synchronized. It doesn't take much error in the phase to limit your dynamic range, and the microcontroller needs to know the phase fairly precisely to demodulate the IF signal, especially if there no other signal indicating the relative phase relationship between the microcontroller's clock and the IF.
Anyways, do it or don't do it, it doesn't matter to me. The NanoVNA is a result of groupthink. There's not much verification of performance against real loads. All of the emphasis is on precision, not accuracy.
https://groups.io/g/nanovna-users/topic/nanovna_real_resistance/33508471
You might want to understand the sources of error in the present NanoVNA before moving on to the next one. The SI5351A is used out of spec up to 300 MHz and the SA612 is heavily overdriven. What do you expect? But since it seems its mostly used for testing whether antennas are matched or not, it's probably good enough for most of its users who have never used a VNA before and don't know what to expect. I can't even get a straight answer to how to calibration works on the NanoVNA. Is there anyone besides edy555 that knows how that works? I sat down and derived the equations myself and tried to figure out how the NanoVNA firmware implements calibration.
Anyways no matter how it turns out that NanoVNA v2 will be a success, so there's no point in criticizing it.
-
Yes I know what you are talking about. People on that list "verify" their calibration by remeasuring their short, open, and load. I suggested the coaxial stub test to check for linearity and so far only one person has done a proper test.
V2 is a separate effort and doesn't reuse anything from the original design. The IF signal's period is exactly 25 ADC clock cycles. The mixer is a high linearity one (over 20dBm IIP3) and is driven at least 20dB below P1dB. I posted some linearity and error magnitude calculations on the list where I concluded you must stay 20dB below IP3 and 10dB below P1dB to get reasonable EVM.
-
Well it's good, if you're going to make a fresh start, it's better of course to not repeat mistakes. I think some kind of fixture would be helpful, however, to go with the new VNA to verify its operation. That way someone who receives it can verify it is working properly to spec.
I have used a zif socket, and if used carefully, can actually work up to about 500 MHz! But that's not going to cut it for the V2, so think about a good set of standards and a fixture to go with it. That will both help to create it and put to rest questions about its performance. Even a simple PCB with a coplanar waveguide on it, something like this:
https://www.edn.com/pcb-fixtures-improve-component-measurements/ (https://www.edn.com/pcb-fixtures-improve-component-measurements/)
could be a big help.
-
That doesn't mean that the acquisitions are synchronized so that the same part of each IF cycle is sampled. How many clocks of the crystal on the SI5351A correspond to the RF and LO signals and the MCLK driving the codec and the microcontroller? They are all on separate fractional dividers.
Many commercial VNA's have multiple Fractional-N synthesizers as well. For example N5222 have three independent synths (RF LO, source1, source2). Only difference to NanoVNA - ADC clock of "commercial VNA" usually is not PLL-synthesized. BTW MCU&ADC of NanoVNA also can be clocked from "jitter-less clock", directly from XTAL (thru mode of SI5351A). Just knowing that any PLL have phase errors is not enough. Did you actually analyze impact of SI5351A phase noise on measurements?
-
If you put the IF on a scope, you can clearly see the jitter. I don't have a spectrum analyzer to measure the phase noise in dBc/Hz but a zero-crossing detector clearly shows the edge of the pulse moving around. If you have two high frequencies with very close fractional divider settings, as you would have when the difference between the RF and LO is a IF frequency a thousand times smaller or more, their mixing product will not repeat until the counters for both fractional dividers both run through their counts and realign. A fractional divider guarantees that a fixed number of pulses of approximately the same length are produced per time interval, but some are pulses stretched a VCO cycle and others are not depending on the state of the fractional divider counter. This means it might take many milliseconds with a 20-bit fractional divider for the output clock signal to repeat. There will be beats between the two signals that will reoccur over the millisecond repeat intervals of the fractional divider counter of the two signals, which means the edge of the mixing product of the two clocks can move around on a time scale over milliseconds. Depending on the state of the fractional divider counters when you start and end sampling, the phase of the signal may or not may not be what the microcontroller expects the signal to be and uses to demodulate the signal. Some way for the microcontroller to know the phase of the IF signal, such as a zero-crossing detector or other trigger signal, could be helpful in ensuring repeatable measurements. A fast XOR gate would be ideal for this purpose, or a zero-crossing comparator triggering off of the reference.
-
No need to seek for instruments or build them because you already got one - VNA itself. Just run thru calibration at single frequency for some time to gather "statistically enough" phase/magnitude readings. Phase spread bell curve (if any) will indicate phase measurement accuracy.
-
Please imagine, how this VNA works:
There are three mixers, all driven with the same frequencies f1 and f2.
IF = f2-f1 is constant.
All phase jitters in the IF are the same.
In addition, low-pass filters and especially the FFT include calculations and give further average values. Your considerations of phase jitter do not lead to a meaningful result.
And keep in mind: This is a product for ham radio enthusiasts, not intended for professional use.
For antenna matching/measurement it is fully sufficient, also for tuning a filter or amplifier.
-
Please imagine, how this VNA works:
There are three mixers, all driven with the same frequencies f1 and f2.
IF = f2-f1 is constant.
All phase jitters in the IF are the same.
Incorrect. f1 and f2 are coming each from separate Fractional-N synthesizer (PLL-A & PLL-B), their jitter definitely are not the same.
-
a product for ham radio enthusiasts, not intended for professional use.
For antenna matching/measurement it is fully sufficient, also for tuning a filter or amplifier.
My friend who gave me one wouldn't have any idea what amateur radio is, and I have no interest in it. That certainly doesn't mean that we have no use for the Nano. I would imagine any hobbyist experimenting with high speed designs that has never used a VNA could benefit from it. As a minimum, it may help cement some concepts. IMO, it's a great product for anyone wanting to learn the basics.
-
>> Incorrect. f1 and f2 are coming each from separate Fractional-N synthesizer (PLL-A & PLL-B), their jitter definitely are not the same.<<
Hello, Ogden, you misunderstood me.
My statement refers to the difference f1 - f2.
And to the averaging of the FFT.
-
>> Incorrect. f1 and f2 are coming each from separate Fractional-N synthesizer (PLL-A & PLL-B), their jitter definitely are not the same.<<
Hello, Ogden, you misunderstood me.
My statement refers to the difference f1 - f2.
And to the averaging of the FFT.
:-//
Please explain what you mean by saying "All phase jitters in the IF are the same", how there can be more than one jitter in the f1 - f2 difference. Are you sure you fully understand PLL synths?
-
Ok, it looks like I opened up the can of worms in Pandora's box, or whatever mixed metaphor you like.
I am going to try to put an example forward. Say the PLL VCO is 600 MHz, and we want the RF signal to be 10.25 MHz and the LO to be 10.26 MHz. The integer divider for both the RF and LO signal is 58. The fractional part for RF=10.25 MHz is 0.53658 and for the LO=10.26 MHz it is 0.47953. The divided by 58 frequency is 10.34482 MHz and the divided by 59 frequency is 10.16949 MHz. So we expect the RF signal to actually be at a frequency of 10.34482 MHz for 0.46342 of the time and 10.16949 for 0.53658 of the time. Likewise, the LO frequency is at 10.34482 MHz for 0.52047 of the time and 10.16949 MHz for 0.47953 of the time. While some of the pulses have a period of 96.7 ns, and others 98.3 ns, they must be interleaved so that the instantaneous IF beat frequency between RF and LO does not deviate too much. I am not sure how the SI5351A actually interleaves the two sets of divided pulses, perhaps it uses a sigma-delta modulator? Nevertheless, one can clearly see the period of the IF vary on the scope. For a 3.333 kHz IF frequency (3rd harmonic) I see about 2-4 microseconds of jitter. For a 300 microsecond period, that corresponds to 3 microseconds = 3.6 degrees or 0.0628 radians, which suggests an instantaneous frequency variation between 3.300 and 3.367 kHz, but it averages to 3.333 kHz. Because the SNR of a single measurement is approximately 1/(radians) that would be a SNR of about 16 or 12 dB. But if we integrate over many cycles, we can improve this by assuming the phase errors are independent. Of course they aren't, and if you integrate assuming the correct third harmonic mean frequency (10 kHz) when you demodulate the phase errors ought to cancel out and the signal improvement should be better than assuming independent phase errors. But if the instantaneous frequency of the IF is varying a little bit due to the fractional divider, say 1% or so, that does contribute some phase error to the demodulated signal.
I tried to deal with this problem by actually clocking the ADC using a zero-crossing detector. However, there are probably better ways, or maybe the integration time is long enough in practice that this error source is negligible. But it is not true that the period of the IF is constant but it does average out over a long interval.
-
I posted some linearity and error magnitude calculations on the list where I concluded you must stay 20dB below IP3 and 10dB below P1dB to get reasonable EVM.
So much trouble to investigate something that has been known for ages, seriously ...? ;) :)
-
Apparently not by the original developers of the Nano which drives the mixers close to P1dB.
-
Above 140MHz on the V2 the si5351 is unused and there are no fractional dividers on the RF path or ADC clock path. The MCU and ADC are NOT clocked by the si5351. They are driven by a clock buffer that is sourced directly from the TCXO. The si5351 has lots of spurs on its output but the phase error only becomes noticeable above 200MHz, so we switch to the ADF4350 as low as possible.
-
I am going to try to put an example forward. Say the PLL VCO is 600 MHz, and we want the RF signal to be 10.25 MHz and the LO to be 10.26 MHz. The integer divider for both the RF and LO signal is 58. The fractional part for RF=10.25 MHz is 0.53658 and for the LO=10.26 MHz it is 0.47953. The divided by 58 frequency is 10.34482 MHz and the divided by 59 frequency is 10.16949 MHz. So we expect the RF signal to actually be at a frequency of 10.34482 MHz for 0.46342 of the time and 10.16949 for 0.53658 of the time. Likewise, the LO frequency is at 10.34482 MHz for 0.52047 of the time and 10.16949 MHz for 0.47953 of the time. While some of the pulses have a period of 96.7 ns, and others 98.3 ns, they must be interleaved so that the instantaneous IF beat frequency between RF and LO does not deviate too much. I am not sure how the SI5351A actually interleaves the two sets of divided pulses, perhaps it uses a sigma-delta modulator?
Your whole "explanation" is fundamentally wrong from very beginning where you assume that both VCO's are tuned to exact same frequency out of specified 600..900MHz range. Granularity of Fractional-N synth frequency steps is good enough to avoid fractional ratios of output divider meaning everything you just explained do not apply. Hopefully OwO can elaborate here.
-
The MCU and ADC are NOT clocked by the si5351. They are driven by a clock buffer that is sourced directly from the TCXO.
Don't you use internal PLL of MCU? - STM32 have inherent clocking architecture flaw - when ARM/bus clock source is PLL (which indeed have phase noise), you can't clock ADC directly from XTAL. Dunno about GD.
-
Yes, the ADC is clocked from the internal PLL. It's integer N, and probably has no good phase noise, but in our tests it was still found that the ADF435x phase noise dominated (you can see an almost linear increase of phase noise floor as RF frequency is increased; ADC sampling jitter would be independent of RF and LO frequency changes).
Above 100MHz the si5351 operates with a fixed output divider of 6. Below 100MHz the fractional divider is indeed used and it's done this way to get more frequency precision. My original code actually tried to use the same output divider for RF and LO, while mainly using the multiplier (feedback divider) to set frequency, but this resulted in slower lock times and slow sweep rates.
However, there is speculation that the si5351 fractional dividers aren't just dumb ones that switch between N and N+1, but also has a programmable delay network to correct the output edge timing. I'm not sure if this is true (and the datasheet doesn't talk about it), but I'm inclined to believe it based on the observed spur floor. I've used chips with a dumb fractional divider before and they produced far higher spurs.
See: https://groups.io/g/BITX20/message/29001
-
There are a lot of differences in the RF and DSP design between the V2 (S-A-A) and the original Nano, because S-A-A is not actually based on the Nano. S-A-A was designed before the Nano hit the market, and we already had all the basic VNA infrastructure. The timeline is like this:
- Early 2019 - S-A-A-1 was designed as a 1-200MHz antenna analyzer using a si5351, no LCD and only USB interface, to retail for $20.
- May 2019 - NanoVNA began selling on taobao, but the news hasn't yet gotten to us
- Aug 2019 - NanoVNA becomes popular outside of China, and I first hear about it. I immediately inform our client and hold a meeting about direction.
- Sept 2019 - It is decided that S-A-A must go up to 3GHz to compete. The design rework starts and we make a decision to integrate the NanoVNA's UI.
- Dec 25 2019 - Design work meets spec at iteration 2 (the third iteration). Firmware and software are also in usable shape.
- Jan 2020 - We submit final designs to client and give the green light to manufacturing. Software and firmware work continues.
The S-A-A-2 started off as a separate project unrelated to the Nano, but we have integrated the UI from the Nano (and fixed a shitload of bugs). Unfortunately I can't upstream these bugfixes because the refractoring included a port to C++17, switching all code to use std::complex, and quite a bit of rework of the UI event handling and drawing code. Of the bugfixes there were stack corruptions, drawing bugs, basic math (geometry) errors (which caused the persistent old traces on screen) etc.
-
Above 100MHz the si5351 operates with a fixed output divider of 6. Below 100MHz the fractional divider is indeed used and it's done this way to get more frequency precision.
I see. That's because you match IF frequency precisely. IMHO performance of MCU is good enough to calculate sincos coefficients on the fly (using cordic), thus relaxing IF frequency precision requirements so you can use integer dividers for < 100MHz as well. Just saying.
-
Regardless of the source of the jitter of the SI5351A, and unless an engineer from Silicon Labs is going to chime in here, you might want to do the measurement I did and see how much the IF period varies before you decide it's not a problem. By triggering the acquisition off the zero-crossing and sampling at four times IF, I can get away with four Fourier coefficients: 1, j, -1, -j and so all of the quadrature demodulation can be performed using additions and subtractions. No guessing at the phase relationship of various PLLs both internal or external to the microcontroller. And by synchronizing, I can integrate a smaller signal with a small IF bandwidth so I don't have to greatly overdrive the SA612 to obtain enough signal, even though the acquisition takes longer. It's the same principle used for a lock-in amplifier which is able to accumulate signals with a very low SNR.
I am not sure any of the people who use the NanoVNA care about this, or care about the accuracy of their instrument, because for $50 they will like whatever they get. I wanted to put together something that used as many commodity parts as possible so that it does not become obsoleted like so many other antenna analyzers or VNAs in the past, be easily built without excessively small SMD parts so that hobbyists with limited skills could reproduce it if it can not be obtained commercially, and be completely and unquestionably open source hardware and software so that others could continue to change and improve it even if I can not. Unlike the Chinese vendors, I have to worry about legal repercussions if I don't respect the copyrights of others, and edy555 seems to not be too happy about where the NanoVNA is going. I am not going to make money off of the VNA I designed, I just want to point out a problem I found that could be a concern for others designs that could be improved, as in the end I think the main interest is getting good equipment into the hands of hams.
-
Regardless of the source of the jitter of the SI5351A, and unless an engineer from Silicon Labs is going to chime in here, you might want to do the measurement I did and see how much the IF period varies before you decide it's not a problem. By triggering the acquisition off the zero-crossing and sampling at four times IF, I can get away with four Fourier coefficients: 1, j, -1, -j and so all of the quadrature demodulation can be performed using additions and subtractions.
Are you sure about your measurement? I am asking because specified jitter of SI5351 is <100 ps (picoseconds). What scope did you use? BTW phase noise measurements of SI5351 are looking surprisingly good: https://nt7s.com/2014/11/si5351a-investigations-part-7/ (https://nt7s.com/2014/11/si5351a-investigations-part-7/)
-
Regardless of the source of the jitter of the SI5351A, and unless an engineer from Silicon Labs is going to chime in here, you might want to do the measurement I did and see how much the IF period varies before you decide it's not a problem. By triggering the acquisition off the zero-crossing and sampling at four times IF, I can get away with four Fourier coefficients: 1, j, -1, -j and so all of the quadrature demodulation can be performed using additions and subtractions. No guessing at the phase relationship of various PLLs both internal or external to the microcontroller. And by synchronizing, I can integrate a smaller signal with a small IF bandwidth so I don't have to greatly overdrive the SA612 to obtain enough signal, even though the acquisition takes longer. It's the same principle used for a lock-in amplifier which is able to accumulate signals with a very low SNR.
I get the use of 4*IF sample rate, but I don't get what you are talking about with the phase relationship. As I said, the VNA detects phase difference between the reflected and a reference signal, so no guessing at phase relationships anywhere.
Adding a zero crossing detector and aligning the ADC sample clock edges with the IF period boundaries will do nothing, because the IF signal is the product of two high frequency carriers and its phase is completely arbitrary; for example just the microstrip trace between the coupler output and mixer input will alter the IF phase, and this phase shift is based on the phase change of the RF carrier so is highly sensitive to distance.
Also IF bandwidth is inversely proportional to the integration time. This is a fundamental fact of physics regardless of how you do the IF detection. The optimal detection is simply multiplying with the complex sinusoid (as you are doing), plus integrate and dump. As I'm aware the Nano also does this.
-
I've also verified that the measurement noise floor when using the si5351 is not noticeably higher than the ADF4350, and see no change in noise floor below 100MHz when the fractional dividers are active. I'm not sure if you can even measure jitter with an ordinary scope, but I've looked at the raw baseband signal from the ADC using GNU radio and didn't see higher noise floor with the si5351 fractional divider. Plus at these low frequencies other noise sources dominate anyway, which is likely why I don't see a change when switching from si5351 to ADF4350. Once you get to 1GHz however, the phase noise floor is clearly visible in spectrum view and it's on-par with what the ADF4350 datasheet says (plus a few dB due to noise folding).
-
Put the IF signal on a scope and see for yourself. Even a modest oscilloscope can do this. That is what your codec/microcontroller ADC sees. You don't have to take my word for it.
-
Apparently not by the original developers of the Nano which drives the mixers close to P1dB.
What you guys think - is there any chance to improve performance of original Nano as it is? Lowering input levels of ref & reflected mixers is kinda easy (1 & 2 resistors), reducing OSC level for all mixers piece of cake, but then what? Most likely IF level will decrease and codec gain (or rather lack of it) will be problem, right? Basically we trade linearity for dynamic range, right? Or not?
Put the IF signal on a scope and see for yourself. Even a modest oscilloscope can do this. That is what your codec/microcontroller ADC sees. You don't have to take my word for it.
Nah. Multiple sources - jitter specs, phase noise figures, use of si5351a in many HAM DIY HF receivers do not agree with what you say.
-
Member enut11 posted about making their own attenuators. I decided to show a few examples using the Nano compared with my other old network analyzers. At the lower frequencies, the numbers the Nano throws up is pretty decent. For these tests, things start falling apart once we get beyond 0.3GHz or so. Still, it's impressive for $50.
https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/ (https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/)
For the fun of it, I soldered an unknown 51.6MHz crystal to a test board as a shunt to look at the reflection coefficient. This was the highest part I had on hand and I would suspect is a 3rd overtone. It was swept from 10MHz to 55MHz with a 0.1MHz step (45,000 data points) to see if there were any other areas where the device would react.
One of the problems with my old 8754A VNA is without using an external generator, looking at narrow band signals like this can be a problem. The frequency is low enough that my 3589A can display it.
-
I had shown an attempt to make a low cost transfer relay for the nano. One of the things I had did to show how poor its performance was along with the nano was to run a T check on it. On the left is a screen shot from that video showing +/-20% up to 500MHz. On the right, using these same home made "standards" on a better system, sweeping to 900MHz.
I had made a really cheep power supply made from a 4000 CMOS part to drive my old transfer relay from the USB adapter. The transfer relay is latching, so the power supply just charges a large cap that I then dump to the relay.
Working on putting together some better standards for my hobby use.
https://www.eevblog.com/forum/rf-microwave/get-ideal-networks-from-cal-kit-parameters/msg2921098/#msg2921098 (https://www.eevblog.com/forum/rf-microwave/get-ideal-networks-from-cal-kit-parameters/msg2921098/#msg2921098)
-
There is an easy way to build a decent transfer switch, which is to use many stages of cheap MMIC RF switches. In fact that's how the V2 hardware switches one receiver between the two ports, and still is able to get ~70dB isolation across the frequency range. Relays are not fast enough when you want to see the sweep in realtime with all traces visible.
-
I think its about a second with the Nano for a single read of 101 points. Comparing the time to offload all four, even zero time to switch would help very little. My old HP uses a similar mechanical transfer relay to the one shown. The system uses GPIB to interface with the PC and like the Nano, it's very slow.
How much time does the V2 take to sweep and then pull the data from it? In that time, how many data points does it collect?
-
I think its about a second with the Nano for a single read of 101 points. Comparing the time to offload all four, even zero time to switch would help very little. My old HP uses a similar mechanical transfer relay to the one shown. The system uses GPIB to interface with the PC and like the Nano, it's very slow.
How much time does the V2 take to sweep and then pull the data from it? In that time, how many data points does it collect?
It's 100 points/s just like the original Nano, but the screen is updated as the sweep progresses rather than updating once per sweep. The USB data interface also streams data points out rather than send a full scan at a time. It has to operate the switch multiple times for each frequency point (duration 10ms).
-
I think its about a second with the Nano for a single read of 101 points. Comparing the time to offload all four, even zero time to switch would help very little. My old HP uses a similar mechanical transfer relay to the one shown. The system uses GPIB to interface with the PC and like the Nano, it's very slow.
How much time does the V2 take to sweep and then pull the data from it? In that time, how many data points does it collect?
It's 100 points/s just like the original Nano, but the screen is updated as the sweep progresses rather than updating once per sweep. The USB data interface also streams data points out rather than send a full scan at a time. It has to operate the switch multiple times for each frequency point (duration 10ms).
Thanks for the information. I'm still a little unclear. For a single sweep it takes then 10ms X 100 samples, then X 2 for both channels? So 2 seconds to read S11 & S21? Or does it read and send both channels at the 10ms rate?
The Nano requires about 2.1 seconds to download both channels or 4.2 seconds for all four S parameters.
-
It sends all channels at once, so 1 second for a full sweep (S11 and S21). Toggling the switches is far faster than changing synthesizer frequency, so it makes sense to do this rather than do two sweeps.
-
It sends all channels at once, so 1 second for a full sweep (S11 and S21). Toggling the switches is far faster than changing synthesizer frequency, so it makes sense to do this rather than do two sweeps.
Thanks for clearing this up. Have you published any specs yet, or is it still in limbo? I wasn't able to find a supplier for it. Can you provide one?
-
https://github.com/nanovna/NanoVNA-QT/raw/master/ug1101.pdf
Designs are also released. There is originally one manufacturer who will be selling these, but they are on vacation until the flu is over.
-
https://github.com/nanovna/NanoVNA-QT/raw/master/ug1101.pdf
Designs are also released. There is originally one manufacturer who will be selling these, but they are on vacation until the flu is over.
Nice job with the manual.
For the sweep points when using USB, is the 1024max basically still the 10ms, so 10 seconds to get the two S parameters?
What is the input power level before going nonlinear? I don't believe they ever did publish this for the nano.
What is the output power level? How flat is it over the frequency range?
With the Nano and my software, there is no support to enter the impedance values for the calibration standards. The frequencies I normally work with are so low, I wasn't concerned with it. It appears that you now support S-parameter calibrations. Nice.
Nice job with the TDR as well. Just from the manual, it looks like a really nice setup. I look forward to trying one out.
-
Yes the sweep rate is constant, so 1000 points ~= 10 seconds.
The output power isn't specified, but it's around -20dBm to -10dBm by design. The flatness is dictated by the baluns so probably not very good. The ADF4350 has 10dB of adjustment range, although it's currently hardcoded to max power in the firmware.
The receiver IP3 should be around 30dBm, but it's only tested to not saturate the ADC up to the maximum signal generator output power (using a thru cable), so to measure an amplifier with 20dB gain use at least a 20dB attenuator.
-
[slightly on topic?] NanoVNA features in a short article in the April 2020 edition of Silicon Chip magazine and Joe Smith's video is referenced for handy tips on physical handling, calibration and connecting to USB software.
-
That's cool. Congrats, Joe.
-
Thanks for the posts.
With help from member rf-messkopf I finished my Open and Short SMA and N standards. I had borrowed various standards that I used to characterize mine using Mario's Octave scripts. In my last few posts, you can see where I do a comparison between my NanoVNA and my latest boat anchor, using these metrology grade standards.
https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg2986524/#msg2986524 (https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg2986524/#msg2986524)
Someone had asked me about doing a review for the V2. I still plan to buy one at some point but most likely would make some sort of comparison video. When I made the videos for the Nano, I was trying to focus on what it can be used for, rather than it's shortcomings. I would like to stay with that theme with the V2, but compare it with the Nano and my old HP network analyzers. Again, just showing some practical measurements. After many years of pondering buying another VNA, my flock has grown with the addition of a third relic (the catalyst for making improved standards).
****
Using the Nano to characterize quartz crystals for home made filters:
https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3036196/#msg3036196 (https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3036196/#msg3036196)
-
*******************
Chapter II
*******************
I picked up the new NanaVNA V2Plus & Plus4. I was hoping they would have followed the same command set as the original firmware but they used a whole new command set. Posts moving forward will be in referencing the new models unless I state otherwise.
At first glance the new command set seemed to be fine but now as I start to dive in, it looks less inviting.
If you look at the manual, you will notice commands like READ, READ2, READ4. For example, if you wanted to read four 1-byte sequential registers, you would use READ4 sending it the starting address. If you wanted to read 5 registers, well I guess you could send READ 5 times or one of the many other combinations. Why wouldn't you use have a ReadSeq where you send it the start address and the number of registers to read. IMO, really odd.
They have registers for example say the start frequency. It's 8-bytes long. Of course, we don't see a READ8 command.
Normally, for every instrument I can run them from the instruments GUI as well as my software. When I start my software, I will commonly query the instrument to learn how it is configured and display that on my own GUI. But we see there is a note:
You can not observe user entered sweep parameters (from the device UI) by reading these registers.
Really! So, you must configure the unit to know how it is set. That's all fine except you will not find any error checking. If for example, you set the instrument to start a 1MHz and something caused a fault (I know, USB is the perfect bus) you have no way of knowing this.
I assume they did some things to try and improve the communications performance. The Nano will switch from the normal GUI to displaying a text message NanoVNA V2Plus... USB MODE. All fine except, I am wanting to create new software to talk with it. So say I program the start frequency. The display only shows USB mode. I can't read the value back....
It's a system ran by Blind Faith.
-
The configured parameters can be read back using READ* commands, just it's a separate set of sweep parameters that are unaffected by what the user configured on screen. That is because when you enter USB mode the VNA basically resets and is entirely under USB control. That there is no READ8 command was a mistake in the protocol design because command 0x13 used to be something else, but since all software have now been updated I can introduce READ8 in the next firmware update. For now just use two READ4 commands to read back the frequency values.
The reason the protocol is designed the way it is is to allow easy implementation in hardware on an FPGA. That's why there are a small number of fixed-length commands and a continuous FIFO, rather than on-demand sweeps. The same reason there is no variable length READN command (or worse, WRITEN), since variable length complicate the state machine for not much gain. READ2/READ4/READ8 should only really be used to read short/long integers, not a sequence of any 2/4/8 registers.
-
Thanks.
So if I am only using the commands to read the S-parameter data from the Nano (never using the start,step and sweeppoints), the Nano's UI remains active and I can continue to control it with the touch screen and display the data on the PC?
When using the RawSamplesMode, does the format of the data remain the same? So no difference other than no calibration being applied?
What are the ValuespPerFrequency? I would assume you set the sweep points to 100, you get 100 values total. In the case of the V2P, 401. The manual does not provide boundaries.
It appears it must resend the same frequency over and over or something like that. I am having to use a SA to write the code to see what it is doing and it seems to just sweep the same frequency over and over before moving to the next location. Really odd.
If I set the start at say 100MHz, 10KHz step, 400 sweep points and 1 value per frequency, the sweep rate is VERY slow. Maybe 2-3 seconds. Maybe 4-6 for the V2P. I don't see anything about a sweep time or a way to set the IF filter.... I was expecting it to sweep well below a second based on the new specs. I'm not understanding something.
I have been playing with the V2P4. I had a quick look at the V2P. It appears the only way to tell them apart is by looking at the hardware revision. My V2P reports 3 and V2P4 reports 4. I assume there could be a rev 4 of the V2P and so on. What is the proper method to detect the device type. I was guessing the Variant but it appears fixed.
-
Before it enters "USB mode" you can't read any S parameter data from the FIFO. There is no way to get data out while the UI is active, and this is by design because either the UI is "attached" to the VNA or the host is, never both at the same time. Data points over USB are always uncalibrated. Basically you need to think of it as a USB-only VNA when programming for it, nothing the user does on the device UI ever affects or is visible over USB.
valuesPerFrequency is what it says, values to obtain per frequency. If you set it to 2 the data points will be f0, f0, f1, f1, etc. This is what nanovna-qt uses to implement averaging. Each returned data point has the frequency embedded in it, and this is what you need to use to determine where you are in the sweep. The sweep is always ongoing and can not be paused, so there is no such thing as an on-demand "single sweep". To get a close approximation of a single sweep, simply read sweepPoints*valuesPerFrequency points from the FIFO in total, but before you do that you have to make sure the FIFO is drained (the FIFO will overflow and be filled with stale data if you don't keep reading it).
If I set the start at say 100MHz, 10KHz step, 400 sweep points and 1 value per frequency, the sweep rate is VERY slow. Maybe 2-3 seconds. Maybe 4-6 for the V2P. I don't see anything about a sweep time or a way to set the IF filter.... I was expecting it to sweep well below a second based on the new specs. I'm not understanding something.
That is about right, look at the specifications here:
https://nanorfe.com/nanovna-v2.html#specifications
The sweep speed below 140MHz is 200 points/s because the si5351 can not be controlled very fast.
400 points @ 200 points/s = 2 seconds.
Averaging over many points is equivalent to reducing IF filter bandwidth, and you can use valuesPerFrequency to do that.
rawSamplesMode gives you raw ADC samples, and this was for debugging only. In newer devices this is broken because USB can't keep up with the higher sample rate.
Hardware revision is what you use to tell between V2_2, v2plus, and v2plus4. That is the revision, so there is no such thing as newer revisions of the v2plus, if there was it should be invisible to the software anyway.
-
Thanks for taking the time to answer my questions. This was very helpful. Your one comment
Data points over USB are always uncalibrated.
was going to be my next question.
I am curious why the need for a valuesperfrequency. Was the thought that holding steady at each frequency yields a higher throughput because you don't need to wait for the system to settle? I was thinking I would just read the whole data set multiple times if I wanted to average.
The whole idea of a free running system is fine. Had you thought about using some sort of index (starting frame) followed by the data without sending up the frequency for each sample? It would seem like you could improve on the throughput removing this data but then again, it may help the software keep in sync when using the valuesperfrequency.
Hope to really put in some effort in a few weeks. For now, I'm just trying to understand enough to give me an idea how to code it. If you do decide to change the firmware (add a READ8 or just a generic READn commands, other), if you are posting this somewhere, it would be good to know ahead of time.
You should have your company make up some decals for them to bling them out a bit. I keep thinking to letter mine but if you are planning to come out with something I would wait.
***
Trying it at 500MHz, 100 points, 1 sample per point, it does seem to sweep in about a half second. Is the slow sweep rates due to settling time or other hardware or a limitation of the USB bus?
When using the valuesperfrequency >1, if you collect all the sweeps and perform the average for each discrete point and download it once rather than having the PC perform the average, would this be faster?
It looks like mine is about a -10 dBm at 100MHz and -20 at 4GHz. Any idea what the compression is at the two extremes? Any way to adjust the level?
It appears I can program the frequency up to about 4.6GHz I assume I could run it up this high with a very reduced performance as long at I use this as the stop frequency, or is there something that would prevent it?
Is there any sort of diagnostic information that can be queried over USB?
****
You have a ReadFIFO command that accepts an address and one byte for the number of values. However SweepPoints is a uint16. So, to pull down the entire sweep could require several reads which are all out of sync? So after some chance, we have the full amount of data for a sweep but really don't know which sweep which segments went with?
I just tried the ReadFIFO command telling it to read a single sample. Each time I do this, the index increments. I would assume doing this slower than the sweep time would cause each value to be from a different sweep. From your last post, this would seem to be the case but I just want to make sure I understand it.
Looking at the FIFO data format you define Bytes 1a..1f as reserved. However, it seems that the last byte may be a checksum for the packet. If this is a checksum, could you please provide how you calculate it?
Sadly, the official support group was locked for viewing messages so I joined hoping that others have already asked you similar questions. After joining, I didn't find a lot of details. If there is a better group where you have already covered these questions, just let me know.
Thanks again for your help.
-
I joined nanovnav2@groups.io and picked up a few pointers from a member OneOfEleven. They explained the undocumented checksum and the data format. I have a pretty good idea now how to structure the software. So I thought I would run a quick test to make sure I understood.
Frame ms is the time to read a single data point. Sweep ms is the time to read the full sweep. So 1.95 seconds when starting at 1MHz and sending 400 data points. There are currently two FIFOs. There is a receiver thread that constantly reads in single data points and places them into the first FIFO (assuming we have a good checksum). A second thread, stitches the data together and to form a competed sweep data set that then gets placed into a second FIFO. A third thread then processes the data. It seems very stable and robust.
I need to add support for the average and I need to arrange where some of the processing is done to make better use of the memory.
-
Spent the day working on the software. The new average feature doesn't appear to offer any performance gains. For example running a sweep that required 1.62 seconds with valuesperfrequency set to 1, required 16.2 seconds with it set to 10.
Because the V2+ is so different, I will just use a different program to support it rather than trying to support both VNAs with one program. I already had ported the code to support my old HP boat anchors anyway.
Here's the first real test. The V2+ was calibrated then a 100 ohm resistor installed an ran for several minutes to check how stable the readings were. For now, I am just using my PCB standards.
Seems very stable (firmware, hardware and my new code). A good start anyway.
-
I have been testing the V2+, not the 4. Now trying to run some narrow band tests. The data is very poor compared with my original Nano. Both units set to 5MHz.
Also shown attempting to look at a 3.68 crystal using the same jigs and cables I have shown in the past with the Nano. It is stable enough to track the drift from touching the crystal's case but there's far too much error to make use of it. Wasn't expecting this. Maybe there is some setting to tame the phase noise.
-
I don't have a battery for the V2P and was running it from the PC's USB port. The data for the original Nano was with it running standalone.
Curious to see if the poor phase noise was just a bad unit. This is the V2 Plus 4, running standalone.
-
The Si5351 covers frequencies up to 140MHz, and the rest are covered by the ADF4350s.
Curious to see if the phase noise was improved above 140, shown is my original Nano compared with the V2+4. Both running from battery, no connections to the PC. CW mode set to 150MHz.
I also repeated the test, looking at the 3.68MHz crystal. Note the difference of the Span setting, due to the lower phase noise. Crazy.
I would have assumed, if you were going to come out with a new product to compete with something as popular as the original Nano, you would start by use it as the baseline for your requirements. You may improve, or have the same performance but I'm surprised it would ever be worse.
-
"CW" mode is really CW output with the V2 now? Not in the original software IIRC, there was a patch from a forum member implementing actual CW output, but I don't know if it has been pulled. If not, even in CW mode there's some (a lot) AM on the signal.
PS: I checked on my V2+4 unit, it's not actually CW, it's pulsed. This explains the spectrum you see.
-
Yes, it's pulsed. I haven't thought much about how this will play into testing active devices. Right now I am just trying to perform some basic narrow band measurements and can't pull it off. It may be possible that they don't allow it to settle long enough on each state. As it stands now, it's useless for making these measurements. That or I am missing something, which is also very possible.
I personally don't have much of a need for a CW mode but the modulation may be a problem, even if the system could settle enough to get some decent data off it.
-
I had made up a few microwave experiments to show off the V2 and had planned on doing a sort of shootout video where I was going to compare it against the other old vintage VNAs I have, including the new boat anchor. Sadly, I wasn't able to find a work around for the poor phase noise and I doubt anyone is interested in seeing another low frequency video of the old Nano. Writing software to support the V2 wasn't a huge investment in time and I wasn't expecting a whole lot from the V2 to begin with, so lesson learned.
That original Gen 1 Nano flipper sent me is still the clear winner for me. I'll take less slow data over fast poor data any day of the week. Too bad, but it was only $120 bucks.
-
V2 can not resolve frequencies beyond 10kHz accuracy because the frequency step of the ADF4350 is 10kHz, not because there is significant phase noise (you can't look at the output on a spectrum analyzer because the signal is pulsed and the pulse period is not fixed). The quick switching of the ports does affect ability to measure very narrowband devices (less than 1kHz bandwidth), but this wasn't considered an issue because you only have 10kHz resolution at the upper frequencies anyway. If it can even track the drift of a crystal it's beyond my expectations, since it was not designed for this use case at all.
-
V2 can not resolve frequencies beyond 10kHz accuracy because the frequency step of the ADF4350 is 10kHz, not because there is significant phase noise (you can't look at the output on a spectrum analyzer because the signal is pulsed and the pulse period is not fixed). The quick switching of the ports does affect ability to measure very narrowband devices (less than 1kHz bandwidth), but this wasn't considered an issue because you only have 10kHz resolution at the upper frequencies anyway. If it can even track the drift of a crystal it's beyond my expectations, since it was not designed for this use case at all.
While being able to detect some drift may exceed your expectations and you may not consider your designs inability to be used for narrow band work an issue but I do. It makes the product far less useful. I assumed you would have understood the market well enough to know what requirements would be important. Had you used the original Nano for your design criteria and met or exceeded every aspect of it, I think you would have a great product. It's also possible that I am not part of the targeting market.
After being so impressed with the original Nano, I bought yours to have a little fun with and maybe do a little promotional video for it. It's a low cost analyzer and in this case performs like one. I'm out a bit of cash and a couple of days work is all. Could be worse.
-
How bad is the V2P, following showing my old boat anchors, the original NanoVNA and the V2P. Same fixture and 3.686MHz crystal.
The two vintage analyzers are fairly close. The original Nano is off by around 0.2dB. I may have messed up the cal. Then we have the new V2P. The span of the V2P is set to 2KHz rather than 1KHz like the other three VNAs so at least you could see something.
-
Your span is 2kHz. That means the step size is 20Hz. This is not supported, as the ADF4350 step is 10kHz, and even in the si5351 region stepsizes < 1kHz are not supported (because of the high measurement bandwidth). It looks like I will have to include a check in the firmware preventing setting the span this narrow, to prevent people from accidentally setting the parameters to give meaningless readings.
-
Anyway this is the first time I've heard of building a filter with ordinary crystals (more common is using an off-the-shelf SAW filter). 1kHz passband @ 150MHz is 0.0007% fractional bandwidth. Basically no physical filter can achieve that except for electroacoustic filters, and even those are generally built to give a wider, flat passband instead. So far no one else has talked about this issue so I think it's an extremely niche use case that happens to be better suited to the V1 Nano. Personally I think it's a matter of using the right tool for the job, just as a cheap LCR meter will beat any VNA measuring impedances > 10k ohms. I could design a VNA that will work for very narrowband measurements, but to do that and *also* measure up to 3GHz, have high dynamic range, and still be able to adjust the sweep speed up would mean it would cost at least 10x what it costs now.
-
It looks like I will have to include a check in the firmware preventing setting the span this narrow, to prevent people from accidentally setting the parameters to give meaningless readings.
I'm not aware of any error checking in the firmware outside of the undocumented checksum. You should add that information BTW. Adding range checks is fine but I would suggest you send a return message when each command is set so the software knows that something went wrong. I created a simple regression test for the original Nano when the firmware was in such turmoil. With the V2+ not supporting any boundary checks, I decided against implementing any sort of automated tests.
Anyway this is the first time I've heard of building a filter with ordinary crystals (more common is using an off-the-shelf SAW filter). 1kHz passband @ 150MHz is 0.0007% fractional bandwidth. Basically no physical filter can achieve that except for electroacoustic filters, and even those are generally built to give a wider, flat passband instead. So far no one else has talked about this issue so I think it's an extremely niche use case that happens to be better suited to the V1 Nano. Personally I think it's a matter of using the right tool for the job, just as a cheap LCR meter will beat any VNA measuring impedances > 10k ohms. I could design a VNA that will work for very narrowband measurements, but to do that and *also* measure up to 3GHz, have high dynamic range, and still be able to adjust the sweep speed up would mean it would cost at least 10x what it costs now.
I really don't know what the communications hobbyists, like the amateur radio operators, are up to. I had received comments that the Nano was designed for tuning antennas and that was really it's only intended use. That seems to represent the majority of the amateur group.
Someone asked me about home made crystal filters and it's common enough that there have been several articles published about them over the years. I created a thread to talk about them and to your point, it wasn't very popular.
https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3036196/#msg3036196 (https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3036196/#msg3036196)
Right tool for the job in my case was helping my friend flipper learn a little about VNAs before they leaped into buying one. The original Nano works well for that. As I have shown in several test cases, as long as I stay below 300MHz, it throws up some very impressive data for $50. For 3GHz, I haven't done anything outside of measuring the included loads.
-
Let's have a a little fun with some higher frequency bandpass filters. While the original Nano can actually make some measurements in excess of a GHz, it does a poor job at best so I'll leave it out of the mix.
For starts, this is a TOKO dielectric 915MHz band pass filter, PN# 4DFA-915E-10. Both my old boat anchor and the NanoV2+ were swept from 700MHz to 1.1GHz. Looking good.
-
Sweeping both VNAs from 890MHz to 940MHz. Again, looks decent.
Let's have a look at something with a bit sharper skirt. In the last attachment, Yellow is the TOKO part we just looked at. Red is a 9 element interdigital filter.
-
Let's start by sweeping from 800MHz to 1.4GHz. Ignore the floor, really it doesn't look too bad. This filter has a fairly flat pass band. Maybe a tenth.
-
Odd, not sure what the security issue is.
Sweeping from 1.01GHz to 1.135GHz. I had ran the Nano a few times.
***
Just for fun, I have attached the data using the original NanoVNA.
-
I recently finished repairs of a "working" 100W JFW attenuator. I changed it to use a 20dB, 150W network. While the original attenuator was rated for 1GHz, the new network was spec'ed to a dB up to 3GHz. I tried it and even with the poor launch (new part is not a perfect fit), it's basically a dB out.
So hows the Nano V2+ compare? Not too bad.
Data was collected using the supplied cables. I replaced the supplied thru with a higher grade part that can be torqued. The load was replaced with the second best Mini-Circuits ANNE I had sorted.
https://www.eevblog.com/forum/rf-microwave/fixed-attenuator-repair-mods/ (https://www.eevblog.com/forum/rf-microwave/fixed-attenuator-repair-mods/)
One thing I have ran into twice now with the V2+, if I set the samples to 400 and less, the unit appears VERY stable. I've never seen it crash after several hours of operation. Setting it to higher values, for example 800 was used for this test, seems to cause problems where the unit will no longer communicate. I have to power cycle the V2+ in order to recover. Outside of that, I haven't seen anything else I would consider a bug when using the USB.
****
Make that three times now. The unit basically stops sending all data. Looking at capture.png, I was sweeping from 300KHz to 4.58GHz (unit becomes unstable above the frequency). Sending 800 data points per sweep, it hung after 22 sweeps. I would guess I have ran it at least 3 hours solid at 400 points. It does not appear to be tied to the frequency range. This graph BTW, is looking at the thru. The unit has a but of noise at the low end it increases as we move beyond 3GHz.
-
I dialed back the sample points to try and get a better look at the noise.
Noise1: 1200 sweeps 300K to 4.58GHz.
Noise3: To zoom into the area of the low band, changed the start and stop to 99.847MHz to 99.852MHz
Note the spur is close to 99.85MHz.
Noise4/5: Even with 100 samples and such a narrow sweep, the spur isn't always captured. It looks like one particular frequency. It's amplitude varies a fair amount.
-
Narrowing the span much further, reducing the number of points to 4, turning off the color mesh, we can clearly see this is a single data point. Oddly of the 3800 sweeps, there appears to only be three states.
-
Running similar tests with the V2+4. First thing I noticed is that using the same 800 data points has yet to cause it to hang. I also found that this particular unit would go unstable at a much lower frequency. 4.4GHz seems to be stable.
Noise7: Sweep 300K to 4.4GHz, 800 points per sweep. Notice the very low frequency noise is gone. We can also see the unit drifting a bit as it warms up. Something is happening around 900MHz.
Noise8: Looking below 1GHz. Pretty decent.
Noise9: Sweeping from 850 to 950, looking at raw data, we can see some short of shift happening at 910MHz. Shouldn't cause any problems.
I like the speed of the V2+4 and having the ability to pull more samples without crashing. I was sweeping in small segments with the original Nano to increase the resolution in order to look at narrow band parts. Now I have all these samples and can't put them to use. I want my cake and to be able to eat it too!!
-
I wanted to try running something a bit closer to the 4GHz limit of the V2plus4. Shown are the S21 plots for the V2+4 compared with one of my old VNAs.
Cal: Showing both units after calibration. The Nano is using the cables supplied with the unit. The cal kit was changed as mentioned previously. The Nano looks pretty good. Consider in the previous plots the amount of noise above 3GHz.
Notch: Showing a 3.8GHz notch filter (stub). The two VNAs track fairly close except for the notch where we see a 4dB difference.
MidWest: Let's have a look at Midwest Microwave DC-18GHz 40dB attenuator.
See Posts below for corrections:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3341186/#msg3341186 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3341186/#msg3341186)
-
Using the V2+4 to look at a small preamplifer.
-
No real point to this exorcise other than just playing with the Nano and testing my software. I'm sure a few of you wonder if I have a CB radio. :-DD I don't.
Looking at a small power amplifer. The total attenuation between the amplifier and Nano is 60dB. The step attenuator was then set to 0dB and a amplifier was bypassed to get a relative measurement from the Nano. The step attenuator was then set to 30dB (90dB total) and the amplifier installed. The total gain is about 80dB which is close to the limit of the Nano. Note the 1dB steps. Starts to compress above 7dB.
-
Note the spur is close to 99.85MHz.
Not a local broadcast station is it?
-
Note the spur is close to 99.85MHz.
Not a local broadcast station is it?
It's possible it's an external source. 0.3dBm is up there pretty high. Seeing the three states is also really odd. I would expect it to be random. A thru was installed to collect this data. The v2+4 does have a metal case, vs the v2+'s plastic. I could install the V2+ into a shielded case and see if anything changes. If I had the battery pack, I could also try it stand alone. Maybe something from the PC getting in through the USB cable.
-
Case is made from PCB, soldered together. Lined with Teflon. Ferrite added internal and external on the USB cable. Case grounded by large braid. Section of semi-ridged used for through. No calibration performed. Showing the raw data.
Swept the V2+ from 90 to 110MHz. Started test with cover open to get a baseline. At roughly half way through the test (750 sweeps), the enclosure was sealed off. There appears to be no difference.
-
I used a small USB battery to power the v2+, then used the menus to program the start/stop. Turned off all other traces. Couldn't sort out how to get a good scale and reference. So cal'ed it with a thru only and set it to 0.1dB/div. Sure enough, I can see the spike randomly show up. Tossed it all into the shielded box and watched it through the screen. Still does it. Should be easy enough to reproduce.
You may have seen they claim the v2+ is rated for 3GHz, where the v2+4 is rated for 4GHz. I have been meaning to go back and repeat the 40dB attenuator test with the v2+ and see what difference there is. It actually looks like my v2+ is slightly better with this test than the v2+4. I doubt anyone is expecting them to perform as well as my vintage Agilent.
Seeing a claimed 4GHz system off by 20dB below that, well... Pretty much what I have been saying about keeping the original Nano below 300MHz, goes for the Plus. Stay below 3GHz, don't expect to do anything narrow and if you use the V2+, stay with a smaller number of points (maybe these lockup problems can be corrected with firmware). It's pretty good for only $120.
-
The 3GHz upper limit of the v2+ and v2+4 improves the TDR. 512 steps per unit length or 0.025. After 200 samples, the standard deviation is 0.0018". The histogram and unit length per sample are much more stable now. It would be interesting to see how it would perform with a commercial airline rather than my homemade one. Still, a big improvement over the original Nano.
-
Looking through some older data for the original Nano, it appears I had ran a test using increments of 0.010". I replicated this test with the V2P and the results were nearly identical. I repeated the test with the V2+ set to 900MHz and 101 data points like the original Nano.
It's very possible that the mechanical hardware is the limiting factor.
-
Tried a few tests with the +4. Added a digit to the standard deviation which is a bit lower. We can see the p-p is also slightly better. Could just be a matter of running the slide.
-
Continuing to play with the software and slide.
Sweeping the V2+4 100K to 3GHz and incrementing the slide by 0.100". Looking at the return loss, we can see how the travel effects the reflections. As the number of sweeps increases, so does the distance from the V2+4 to the end of our airline.
-
They claim the lower limit of the V2+/+4 is 50KHz.
Looking at a 5.6pf between port1&2. The V2+ was swept from 50KHz to 5MHz. No calibration was performed. The USB has proven to be unreliable with this unit and I am using 101 data points (like the Nano). Strange as the V2+4 has never hung. Maybe a bad unit?
Notice how bad the noise is as we go below 500KHz.
The second plot is looking at the same capacitor but I have now calibrated the unit and am sweeping from 2MHz to 10MHz. The jig adds a bit of error but no matter. Notice it really doesn't settle until 6MHz or so. Below 500KHz or so there's a lot of error. Difficult to calibrate noise out.
-
The attenuator measurement doesn't look right; here is what I'm getting with a 40dB attenuator 3-4GHz, calibrated with the cal kit supplied with the V2 plus4, and no averaging:
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1116746;image)
Please check your measurements with NanoVNA-QT, right now even nanovna-saver does not implement the isolation calibration correctly. If you are not sure how to implement it, check the code here: https://github.com/nanovna/NanoVNA-QT/blob/master/libxavna/calibration.C#L63 (https://github.com/nanovna/NanoVNA-QT/blob/master/libxavna/calibration.C#L63)
-
I tried to run the software again and it basically seems to hang. When I select various menus nothing happens. After several seconds it will flash up the menu, then it goes away.
The software doesn't show a version number anywhere on it. There appears to be no text files included with it that provide any details about the software. I am running Windows 10. LabView talks just fine to the device (when it doesn't hang). So it doesn't seem hardware related. If you have better software or know of a way to get this version working, let me know and I will try it.
*****
Playing around a bit more, I finally was able to get it to select the communications port. It started sweeping but came up with this error.
-
have you updated the driver to the one given/suggested by the SW documentation? CH340 iirc. that message appeared to me when i disconnected Nano while the SW is sweeping.
-
have you updated the driver to the one given/suggested by the SW documentation? CH340 iirc. that message appeared to me when i disconnected Nano while the SW is sweeping.
As I have mentioned a few times, the V2P appears to hang when using the USB. Again, maybe firmware or a defective unit. It's possible this could have caused the error but it happened pretty fast and normally when it see it I am using large data sets.
I have attached a screenshot of the driver. Is this what you are using? It's what they had when I downloaded the software. When I first plugged in the device, Windows recognized it but their software was hanging. When I changed to this diver, I saw no difference.
Again, their software hangs with both the V2+ and +4.
I tried to follow the undocumented code and it does appear that the could be the problem. I ignore the leakage terms with my software. It may be faster to add this to my software than spend time trying to get their software working. I didn't have any luck with the original Nano's software as well. I have not tried this new software on a different PC.
-
yes thats the same driver but i'm on Win7.. havent played much with large dataset but i just tried 5000 points, it took a while before the sweep starts, but i dont wait until completion. communication interruption (esp USB) is likely due to the driver or the USB IC or the how your PC is setup. too many USB devices and data transfer may affect that channel too? is there such thing as dropped USB packets? :-//. it could be out of the HW designer's hand as well or the NanoVNA-QT. you may ask the original programmer (xaxaxa) maybe? lets hope OwO frequently reply to Q&A.
-
I still have a Windows 7 PC that I could try.
I am seeing the V2+ crash with even 400 points. But again, I am running it non-stop for hours on end. It does appear to have something to do with the number of points. The average time between crashes seems to increase with the number of points selected. The V2+4 has yet to crash with my software. I've been unsuccessful in finding a way to cause the V2+ to crash at will.
That VNA's communications is very slow. It's hard to believe it's a driver or hardware problem as LabView talks to it V2+4 just fine even with 800 points selected. LabView isn't known for it's ultra fast speeds.
Adding support to my software to include the crosstalk error terms isn't a big deal. It would still be nice to be able to compare the data from my software with the included software.
The one thing I noticed in their software was the ability to change the power level. I didn't see anything in their documentation about how to change this setting. Like the checksum, it may just be another undocumented feature. I would like to add support for it.
-
I added support for the leakage and repeated the test with the 40dB attenuator sweeping 3 to 4GHz. I then repeated the test sweeping up to 4.4GHz as before.
Looks MUCH better! Thank you very much for that little hint OWO!
-
I loaded the software onto my Windows 7 PC and it seems to work fine. This PC has an old i7 2630QM processor where the Window 10 PC uses a Xeon E5-1650 v4.
Attempting to sweep down in the 50KHz range where the worse noise is but their software appears to limit it to 100KHz.
Before digging into their source code, I tried adjusting the Ouput Power but it appears to have no effect. My guess is that it's not supported and that's why there is nothing in the documentation about how to set it.
****************
Talking with a friend today about the USB problems with this V2P hanging. Apparently they ran into a similar problem with Windows 10 USB selective suspend causing them problems. They suggesting disabling all of the USB power saving features. I tried it and the V2P has been collecting 400 point datasets for a bit over an hour and a half now without a fault (using my software). This is the longest I have seen it run with this amount of data but I'll let it continue to run just to make sure.
****************
It made it to two hours and I aborted the test. I restarted collecting with 800 data points. It finally hung at 2200 cycles. It collects at roughly 17 sweeps per minute with 800 points. So roughly 129 minutes until it failed.
*****************
The next attempt to run am 800 point test, the unit crashed after 210 sweeps. I tried it one last time and it made it to 4500 sweeps or around 4 hours before it crashed.
When the Nano crashed, it still shows the USB menu but doesn't respond to any USB commands. The PC still see's the port. The only way I have found to recover from it is by power cycling the Nano V2+.
After several attempts to get the VNA View (VNA QT) software to run on this PC, I did eventually get it to sweep. There isn't any way to tell how many sweeps it has ran. I'll check on it over the day and see if it has hung or not.
*****************
I ran their software for roughly seven hours and the V2P never crashed using the same PC, driver, cables, Nano. I started my software and the Nano crashed within a half hour. So it's not the USB power savings features in 10.
My software is pretty simple. When it causes the Nano to crash, it's just asking for a single data point and reading it.
-
Hi,
I checked few pages of this long forum thread, but I could not find any application attachment or link. Is this application going to be released or is it just for internal use? Or maybe I missed link/attachment?
I would gladly try it on my new SAA2 v4 which I got yesterday :)
Regards, Darko
-
Hi,
I checked few pages of this long forum thread, but I could not find any application attachment or link. Is this application going to be released or is it just for internal use? Or maybe I missed link/attachment?
I would gladly try it on my new SAA2 v4 which I got yesterday :)
Regards, Darko
Reading has become a lost art.
I have no plans of making my software available. However, I understand there are a few open source packages that are well supported and excellent to use. You should join one of the many groups for the Nano as I am sure many people would provide you with any help you need getting it setup. There was one person that dropped me a couple of bread crumbs on the V2+ interface. It sounded like they were working on their own program for it as well. Check them out.
-
I ran a few more tests trying to sort out why my software can get only the V2+ to hang. First, I would never expect firmware to get into a state where it would require a power cycle to recover. I have no desire to have to unplug my appliances or countless other embedded devices. But it seems like there is something that I am doing that causes it, at least with this PC.
If you have a V2+ (not the +4), and know a bit about Labview, I have attached a simple program that sets the Nano to sweep from 1-900MHz, 800 points, 1 sample per point. It then just reads data from it until you press Stop. It may need to run for several hours as I've seen the V2+ run anywhere from 15 minutes to 5 hours before it locks up. Once it locks up, there is nothing I can do to recover outside of power cycling the Nano.
I have also built the program as an EXE. These are created with 2011 so if you wanted to run the EXE you would need the 2011 runtime. If you use something other than COM4, just stop the app, select the port and run it. You should see roughly 3.8 seconds per frame.
-
I had ran it one last time for over three hours with my software and the V2+ did not hang. |O
It makes no sense that their software wouldn't cause the problem but maybe it has something to do with them plotting the data real time and it just slows it down enough.
I changed that test code to try to force the fault. You can play around with more data, and throttle it. The Nano will stop sending data but it seems I can always get it to recover. Maybe it has to sit in this mode for a long time before it hangs.
Back to testing with their software. Note the 98MHz glitch I saw with my software. Totally random.
-
I think I may have stumbled onto a way to recover from the lockup. If you run that last program, bump the elements to 2, it should lock. Most likely it will recover just by starting and stopping the Labview software. When I see the V2+ lock, resetting Labview has no effect. I have have had this program cause it to lock this way as well by doing what I describe.
I mentioned earlier that the port appears to still be open. Requesting a read from the FIFO with the number of elements set to zero will recover from a soft lockup. Seems very easy to replicate.
Imagine telling someone driving down the highway that they need to pull off to the side of the road and disconnect their battery terminal to reset the ECM fault.
I've added this simple change to the main program and will let it run overnight. With any luck it may be a work around.
-
That was a bust. The V2+ still locked up as before and the 0 element trick didn't help. The last thing I thought to try was removing the Cypress drivers and going back to the original Microsoft driver. This is version 10.0.18362.1.
***************
The MS driver made no difference. Another possible clue, when looking at the sweep time plot, it never misses a beat. Also, looking at the data over these long runs, it appears stable. There are no signs of a problem until the V2+ locks up.
-
Trying a 25 point sweep overnight to see if the V2+ will lock. It's always hung with larger sets but I just want to make sure. I basically let the Nano throttle the speed, so Labview is asking for data as fast as what the Nano can supply it. I've tried slowing down the requests before but it didn't seem to make a difference. The +4 continues to be a rock star and has never locked and it can stream the data about 2X faster.
Video clip showing it running.
https://www.youtube.com/watch?v=pbK4xXuyins (https://www.youtube.com/watch?v=pbK4xXuyins)
-
After 4.6 hours, it also locked up with the smaller data sets and required the V2+ be power cycled.
At least we now know it has nothing to do with the number of data points. Interesting is that I have been using the V2+ for the last few days and didn't have a single lockup. The difference is I was making short tests. Maybe 10 minutes long at the most.
-
After a full day of extended testing on the V2+4, it didn't lockup like the V2+. I think the longest I have seen the V2+ run was maybe 6 hours.
Looking in the area of 80 to 140MHz on the V2+4, there are two spurs rather than the one seen with the V2+. The frequency is a little off between the two VNAs. More interesting is the V2+ spur would show up at random times, the spurs seen with the V2+4 are always present. As with the V2+, it doesn't appear to be a local source.
*****
The V2+4 has now been running for almost 35 hours non stop. My software treats both VNAs the same.
Looks like a few people downloaded the test program but with no responses, I assume no one else was able to replicate the lockup. It could be that I received a bad unit. This came right from the main supplier which I understood was the only way to make sure you were getting a quality product. I'll take it apart and see if there looks like any problems with their soldering.
****
The soldering seems fine so while it was apart, I connected only the control board to the PC (no LCD). It's been running about 4 hours now. I'll let it run overnight and see if this tells us anything.
-
Running it without the display made no difference.
One difference is that I am still running the V2+4 with a battery installed. So I installed this LG battery from an old cell phone. A bit of Kapton tape and some memory foam to hold things in place. Doubt this would have anything to do with it locking up but if the designers decide to try and correct it, may as well provide as much data as possible.
-
Not surprising, adding the battery pack had no effect on my V2+ lockup problem.
-
Made some progress on a manual. I know it's a total shit show but feel free to suggest additions, changes and what not.
https://github.com/joeqsmith
****
New draft, needs a lot of work..
****
Added TDR section plus a few others.
****
Added Interpolation
-
I have gone ahead and wrote some test software to support the offset loss.
-
Working on my review of the new 4GHz NanoVNA V2 Plus 4.
https://www.youtube.com/watch?v=JgMVYEoA1Zc (https://www.youtube.com/watch?v=JgMVYEoA1Zc)
-
Oh, how often that has happened to me!
-
If I needed a set of cables, at $60 I would most likely just purchase a second V2+. I could then check if the lockup problem is unique to mine. Plus I don't mind supporting their efforts.
-
For the review, I plan to focus on the V2+4 due to the problems with the V2+. I'll run the same circuits used with the original Nano plus a few others. I then plan to run a few experiments with it.
If you have any suggestions on what you would like to see, feel free to ask.
-
Updates to the manual reflect the revision of software used for my upcoming review.
https://github.com/joeqsmith/NanoVNA_V2Plus
-
Review of the new NanoVNA V2 Plus 4
https://www.youtube.com/watch?v=XaYBpPCo1qk (https://www.youtube.com/watch?v=XaYBpPCo1qk)
-
Looks like a great contribution, Joe -- especially nice to see the automated crystal measurement functionality. Shame about the artifacts you were seeing in narrow spans. I wonder if slowing down the sweep would help with those?
How exactly is the software installed? Looks like there are 18 files with .zip.xx suffixes...?
-
Hi Joe,
Thanks very much for the exhaustive review, nice to hear about real world measurements.
I just downloaded and installed your software. I will play with it in the next days.
I use a V2+4, I bought a couple weeks ago to play with. About the narrow band measurement, I was having problems for the past week trying to draw a crystal filter using the vna_qt software.
Using the NanoVNAv2+4 in stand alone mode brought some light when used with the averaging (cf. attached pictures). Indeed measurements have been made with fresh SOLT calibration. The filter is a Yaesu 455k 500Hz.
Could this behaviour be caused by clock jittering within the nano ? If so, the various software might benefit to implement the averaging parameter.
Best Regards, 73's
François / F4HTX
update 1 : Added the same measurement with joeqsmith software (450 to 460kHz / 1024pts)
-
Someone had pointed out that VISA was missing from the installer. I have rebuilt the installer to include it. No changes were made to the NanoVNA software.
-
A few people have asked me about the software missing. It was moved to released.
-
A few people have asked me about the software missing. It was moved to released.
Gotta say, I still have no idea what to do with 21 .zip files. How about a standardized installation procedure? :)
-
It's just a spanned zip file to get around Github's file size limitation.
https://sourceforge.net/p/sevenzip/discussion/45798/thread/9cefe2c2/
-
The program seems to be a great tool for NanoVNA :) and I am able to run V2+ with the LabVIEW code without any hardware issue as of now.
I want to perform S11 sweeps continuously and store the files therefore I want to know the following:
1. How can I change the frequency sweep?
2. How can I can get the real and imaginary parts of the data? I use the USB sniffer software (device monitoring studio) to monitor the port (COM 3 in my case) but still unable to decrypt from the long strings of data (up and down)
3. In the program there are some hex numbers passed to the serial port like 2300 4042 0F00 0000 0000, what is the reason of this arrangement? is there any command list documentation available?
A reply would be really appreciated.
Best Regards
Adiy
-
The program seems to be a great tool for NanoVNA :) and I am able to run V2+ with the LabVIEW code without any hardware issue as of now.
I want to perform S11 sweeps continuously and store the files therefore I want to know the following:
1. How can I change the frequency sweep?
2. How can I can get the real and imaginary parts of the data? I use the USB sniffer software (device monitoring studio) to monitor the port (COM 3 in my case) but still unable to decrypt from the long strings of data (up and down)
3. In the program there are some hex numbers passed to the serial port like 2300 4042 0F00 0000 0000, what is the reason of this arrangement? is there any command list documentation available?
A reply would be really appreciated.
Best Regards
Adiy
I wouldn't be at all surprised to hear about problems with that software. It's really an engineering tool that I put together to evaluate the Nano.
It sounds like you haven't actually taken the time to read the manual or even watch the video as both certainly cover your first question. I suggest you start there.
I don't understand what you are asking with your second question. Combined with your third question, it sounds like you would like to write your own software. The best thing to do may be do download the open source code and start there. There are also several groups for the various versions of the Nano that you may want to consider joining. If that's your end goal, I would not waste your time with the manual or video as I don't go into any details about the protocol or any of the math behind it.
Yes, the designer's of the V2+ made a command document available that everyone may freely download from their site.
-
Looking in the area of 80 to 140MHz on the V2+4, there are two spurs rather than the one seen with the V2+. The frequency is a little off between the two VNAs. More interesting is the V2+ spur would show up at random times, the spurs seen with the V2+4 are always present. As with the V2+, it doesn't appear to be a local source.
@joesmith,
I can't duplicate the spurs that you see on my V2+4. The first time I tried, there was a clear single spur around 136MHz, but after a power cycle, it was gone. After each power cycle I get (or not) different spurs in different places. See below.
-
I wonder if you were to increase the number of sample points like I show if you would see two of them.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3352770/#msg3352770 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3352770/#msg3352770)
-
Wouldn’t reducing the span achieve the same thing? Unless these spurs are dependent on frequency and span settings and the moon phase, which I’ve seen on an HP SA at work (there’s an internal spur that shows up only at a narrow range of center frequency and span settings), reducing the span around the frequencies of interest would give me more resolution.
Edit: The forum does whatever it wants when posting from mobile. I couldn't get it to attach two different pictures. Now should be correct.
-
I have no idea but if you wanted to try and replicate what I have, I would start with the same settings. If you like, I could also try running mine in other configurations as well.
I haven't seen the V2+4 available for some time. We are now waiting to see one of these 6GHz units on the market.
-
How do I do that, I thought you don’t share your SW.
-
Here are some screen shot using the crappy "VNA View" with 401 and 600 points.
-
Ever wonder how much torque it takes to rip an end launch connector off a circuit board?
https://www.youtube.com/watch?v=HiJVeQvqtsM (https://www.youtube.com/watch?v=HiJVeQvqtsM)
-
Great work! Thank you very much. I successfully installed the NanoVNA V2 Plus ver 0.10 and ran the setup.
I know that the manual says that the software supports both the NanoVNA V2+ and V2+4, however I see from some of the posts (i.e. reply # 716, 3p68xtal_originalNano.PNG ) that the original NanoVNA seemed to have some support. I have the original and not the V2+ or V2+4 yet. I would like to add a transfer relay to be able to get 4-port S-Parms, so I tried to run with v0.10 and don't get the green light on the "Link" command button. It does seem able to communicate with it as in the status window I see "NanoVNA V240+,Protocol 241, FW 243.244". Note that I had upgraded the FW a couple of times and have been using it with NanoVNA-Saver.
My question: is there any way to get this to work with your software or is support for the original not planned? - Maybe with different firmware?
-
Dr Nefario,
Great work! Thank you very much. I successfully installed the NanoVNA V2 Plus ver 0.10 and ran the setup.
I know that the manual says that the software supports both the NanoVNA V2+ and V2+4, however I see from some of the posts (i.e. reply # 716, 3p68xtal_originalNano.PNG ) that the original NanoVNA seemed to have some support.
You are correct that the manual mentions and this thread certainly covers that I did write some software to support the original Nano. You are also correct that my manual states:
• Supports both the NanoVNA V2+ and V2+4
It also states in the scope:
This software can be viewed as an engineering tool at best. Its primary use was to extend the author's understanding of V2+. It was never intended to be used as a general tool for radio hobbyist to tune their antennas. The software is fairly buggy and not very robust. Even under normal conditions, expect to run into several problems if attempting to use this software. It’s a very poor choice for the beginner.
I will assume that paragraph doesn't pertain to you personally.
I have the original and not the V2+ or V2+4 yet. I would like to add a transfer relay to be able to get 4-port S-Parms, so I tried to run with v0.10 and don't get the green light on the "Link" command button.
Seems normal. I didn't try to run this software with anything except what the manual calls out. Were you expecting something else to happen?
It does seem able to communicate with it as in the status window I see "NanoVNA V240+,Protocol 241, FW 243.244". Note that I had upgraded the FW a couple of times and have been using it with NanoVNA-Saver.
Both the original and the V2 Plus/4 do use USB and both simulate the old RS-232 comm ports. So assuming that's what you mean by the software being able to communicate with it, then it sure can. We are both humans. I speak English. If you spoke another language, there may be some crossover where I may understand you once in a while. I guess we could call that communicating as well. We humans go beyond what simple software can do. We can actually learn in some cases. Over time our communications may improve. I doubt you will see this with the software. Were you expecting otherwise?
My question: is there any way to get this to work with your software or is support for the original not planned? - Maybe with different firmware?
Because the word "works" has lost much of its meaning lets say that it is certainly possible that if firmware were written for the original NanoVNA to support the same protocol as the V2+, it would indeed work, at least to the degree of how well the firmware was written. That would be true for ANY device, not just the original NanoVNA.
From what I understand, the open source software for the nano is very good. It has a large support group and is actually something put together for the amateur/CB radio group. The whole idea with it being open source is YOU can change it. If software isn't your thing, I suggest you start by politely asking the developers to add what ever features you want. This way everyone benefits.
If you really want to evaluate my software, the obvious thing to do would be to procure one of the supported products. I have no plans to support the older hardware at this time.
I have been following some of the development of the newer low cost VNAs. One in particular seems very interesting. If something like this becomes available, I would most likely procure one to review and make and software I write for it available for free as well.
-
I have been following some of the development of the newer low cost VNAs. One in particular seems very interesting.
Which VNA might that be? :)
-
I have been following some of the development of the newer low cost VNAs. One in particular seems very interesting.
Which VNA might that be? :)
https://github.com/jankae/VNA
https://github.com/jankae/VNA2
-
I had a look at this one but there is very little documentation. I'm not sure if it would interface with the PC. The other was designed to run headless. This is more what I am after.
http://www.arinst.net/files/2114-ARINST-VNA-PR1/User-manual-ARINST-VNA-PR1-1-6200_ENG.pdf?spm=a2g0o.detail.1000023.2.38956f630VOcBJ&file=User-manual-ARINST-VNA-PR1-1-6200_ENG.pdf (http://www.arinst.net/files/2114-ARINST-VNA-PR1/User-manual-ARINST-VNA-PR1-1-6200_ENG.pdf?spm=a2g0o.detail.1000023.2.38956f630VOcBJ&file=User-manual-ARINST-VNA-PR1-1-6200_ENG.pdf)
https://www.aliexpress.com/item/1005001683791887.html?spm=a2g0o.productlist.0.0.4037645ecHafMg&algo_pvid=36f641a7-2fa6-4475-b6c7-b7c1d206eca4&algo_expid=36f641a7-2fa6-4475-b6c7-b7c1d206eca4-0&btsid=0b0a556b16153985764111357e19c0&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_ (https://www.aliexpress.com/item/1005001683791887.html?spm=a2g0o.productlist.0.0.4037645ecHafMg&algo_pvid=36f641a7-2fa6-4475-b6c7-b7c1d206eca4&algo_expid=36f641a7-2fa6-4475-b6c7-b7c1d206eca4-0&btsid=0b0a556b16153985764111357e19c0&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_)
-
I'm looking for most stable (bug free, robust) firmware for the original NanoVNA hardware. The firmware I am using today is something one of the local members was working on several months back.
What's the hot ticket?
-
An updated draft of the manual is available that provides additional details when using the original Nano to characterize crystals.
-
Mr. Smith... I present your/my crystal fixture.
Have to make some calibration jobbies, but seems to be about right.
(https://i.postimg.cc/vm5XLr5t/IMG-0196.jpg)
(https://i.postimg.cc/DZZJyFf4/saver.jpg)
-
Looking good. If you perform a normal SOLT. then insert the fixture with the crystal socket shorted, what does the response look like from say 500KHz to 50MHz?
-
Not sure which charts you wanted.
(https://i.postimg.cc/HWXwZqs0/jr.jpg)
-
S21 log mag. Your 6-7dBish from 500K to 25MHz is close to my jig. What frequency range do you require?
-
Morning,
Right now I'm not looking to go beyond 10MHz.
(https://i.postimg.cc/jdCTF8m9/jr3.jpg)
-
For your particular range, I assume that's your lower limit as well, which shouldn't be a problem. You just want to play with your 10MHz crystals is all.
If you want to sort out the question on if your Nano supports the original command set, I would just fire up a dumb terminal program. I use TeraTermPro but it's not important. Select 8,N,1. BAUD rate isn't important. Connect to your Nano and type "help" without the quotes. Mine will return the following: (see attached)
-
Cheers.
Mine returns something different.
(https://i.postimg.cc/h410kWfG/term-2.jpg)
But dropping back to the previous firmware gives me this.
(https://i.postimg.cc/QMSfc21C/term3.jpg)
-
What was the reason you loaded the newer firmware?
For the original NanoVNA, my software uses the following commands:
freq
info
data
sweep (start, stop, center, span)
reset
frequencies
recall
As long as they were smart enough to keep the format the same for all of these, it may just work.
-
Mr. Smith,
What was the reason you loaded the newer firmware?
Just to see what it was all about and to see if I could do it without bricking it.
As long as they were smart enough to keep the format the same for all of these, it may just work.
Here's hoping, but if not, I could maybe flash the same firmware that you're running.
My pcb is rev 3.4
Peter
-
We can cross that bridge when we come to it. The firmware you are running may be more stable than what I have.
Once I have a little time, I will go through and functional test the new versions of software. Hopefully, I can upload them over the weekend and make a quick video walking you through how it's done.
-
Marvellous... Thank you.
Peter
-
I've been playing around with the new 1.0 software that I plan to release shortly. While searching the forums for some decent firmware that supports the original hardware, I kept coming across posts where people have damaged their Nanos. One person had bought 5 of them and 3 were damaged. This video gives some of my thoughts on how to protect the front end. It also shows off the new software.
https://www.youtube.com/watch?v=totwu4IbavE (https://www.youtube.com/watch?v=totwu4IbavE)
I finally received some much needed feedback on the manual and need to address that. I am also seeing a small problem with the software or maybe it's firmware, that needs to be corrected. Things are starting to come together.
-
I have been using my Original NanoVNA since December 2019 now and have gone through several FW loads. I am now on edy555's v 0.8.0 and am quite happy with it and mostly use it on the bench with NanoVNA-Saver. This is the latest FW version from edy555 and I don't know about others, but here are the features it has:[attachimg=1]
-
Any known problems with it?
-
In general I have not had any problems. The github is at https://github.com/ttrftech/NanoVNA and there is an issues list but some things seem more like a 'wish list'.
I have taken lots of data with the Nanovna-saver program including downloading S parameters and saving the cal sets.
I downloaded the binary that is listed as the latest: https://github.com/ttrftech/NanoVNA/releases/tag/0.8.0
Also, I am not a software type, but I did compile the master as listed and it did work OK, but not with the saver program.
The saver program gave me this error list when I tried to run it with my compilation: ( it seems to not have a valid version )
Traceback (most recent call last):
File "NanoVNASaver\NanoVNASaver.py", line 516, in serialButtonClick
File "NanoVNASaver\NanoVNASaver.py", line 538, in connect_device
File "NanoVNASaver\Hardware\Hardware.py", line 111, in get_VNA
File "NanoVNASaver\Hardware\NanoVNA.py", line 40, in __init__
File "NanoVNASaver\Hardware\VNA.py", line 61, in __init__
File "NanoVNASaver\Hardware\VNA.py", line 186, in readVersion
IndexError: list index out of range
So, I went back to the binary v 0.8.0 which does not give any errors.
-
Thanks for the input. Not being able to rebuild it doesn't give me a lot of confidence but I went ahead and downloaded the image you suggested. The first thing I notice is they did not adopt the 10KHz feature. More useful for me than a battery indicator but oh well. It looks like they went the other way and allow it to operate a bit over 2.1GHz. It was pretty poor above 300MHz. I played with the hardware above a GHz and even used it in that last review I made for the V2+4.
Its running the regression test.
*****
What do you use the NanoVNA for? What frequency ranges do you use?
I may have you try and run a test for me in the near future.
-
I use it for various things including sweeping filters, measuring and designing impedance matching networks, component measuring and some antenna matching. I would like to build the crystal test fixture for occasional use. Most of this has been below 300 MHz, but I have used it for some stuff up to 1 GHz. I have an HP3577 and an HP8753C but it is so convenient to grab the Nano and get the data into my PC that I have been mostly using the Nano. I plan to buy one of the newer designs that would cover 4 - 6 GHz but am waiting for the designs and the shipping situation to gel.
I rarely use the built in display and would be just fine with a headless unit. I notice that the NanoVNA-Saver application just freezes the display on the Nano, which is OK but I wonder if there would be anything to gain by blanking it when using it headless. I realize that would require different firmware for the Nano, but this mode might be something to consider adding for the folks that are designing these new VNA's.
I would be happy to run a test for you. deflatermaus at outlook dot com.
-
The 8753C is a workhorse. There may be better software for your PC that supports it. Your 3577 seems like it would be the unit of choice for the amateur and CB radio group. Have you ran into cases where the 3577 provides any use to you compared with the original Nano?
I have created a new repository on Github for the old hardware and have uploaded test reports for the two versions of firmware. One is the last version that member RadioListener posted that I had rebuilt, the other the TTRFTech binary you linked.
When you run the TTRFTech firmware, does the software you use have any sort of metrics that it provides? Have you noticed any differences in the performance when running it with the PC?
-
It seems like the new firmware may have a smaller message buffer or is just using up more CPU time showing the low battery indicator. I stack commands (send more than one) and parse the responses in a separate thread to speed things up. This seems to cause the new firmware problems and it chokes. You can see the effects in the two reports. It's funny with it being as slow as it is that it has any problems.
With the firmware still being developed, supporting it seems like a problem. Looking at the software repository is seems the original author is no longer listed as a developer. Looks like 15 people working on it now. Would enjoy hearing from Rune B. Broberg on why he stopped working on it.
Marvellous... Thank you.
Peter
To make the software somewhat usable for you, I would cripple my software to work with the new firmware. This will allow you to continue to play with the latest releases of firmware up to the point where they brake it. At that time you would just need to archive the firmware that works the best for you.
From a software point of view, the main difference between the old and new VNAs is how the new VNA will just send the raw data and it's fairly fast. The old required you to request both channels seperatly. If you are only looking at S11, there's no reason to ask for the second channel. I would leverage this to get faster updates. Still very slow but hey, it's $50. When using S21, I always collect both channels which doubles the time it takes to update the screen. The advantage is the software behaves more like the V2+. For measuring crystals, I don't see it being a problem. If you plan to try an use it for other measurements, you may run into snags.
-
Several months ago, my 3577 POST indicated an over current event by the LED's status. There was nothing on the screen. I traced it down to a problem with the display module and when this module is unplugged it appears to boot OK as for as the front panel indicators tell me. I am debating weather to buy the LCD display replacement or sell as is. So, unfortunately I can't do any comparisons with this. I am slowly moving into a condo and really don't have room for it.
I see that you have been to:
https://github.com/NanoVNA-Saver/nanovna-saver. I have been following the forums on groups.io for the Nano and wiki at https://groups.io/g/nanovna-users/wiki/12336.
I guess Rune thought it was useful as is and left it for posterity at github. I'm think if you posted there he would reply as he has been quite active on the forum.
I really have not compared the stand alone performance of the Nano to it working with the Saver program, but from what I read in the forums I trust most of what it tells me.
I'll look at your reports later to see what you found. Thank you for your work and informative videos!
-
To make the software somewhat usable for you, I would cripple my software to work with the new firmware. This will allow you to continue to play with the latest releases of firmware up to the point where they brake it. At that time you would just need to archive the firmware that works the best for you.
From a software point of view, the main difference between the old and new VNAs is how the new VNA will just send the raw data and it's fairly fast. The old required you to request both channels seperatly. If you are only looking at S11, there's no reason to ask for the second channel. I would leverage this to get faster updates. Still very slow but hey, it's $50. When using S21, I always collect both channels which doubles the time it takes to update the screen. The advantage is the software behaves more like the V2+. For measuring crystals, I don't see it being a problem. If you plan to try an use it for other measurements, you may run into snags.
Mr. Smith,
Updating, or down dating the firmware takes seconds, so should you release your software I would still be game.
On another note... I've just ordered a NanoVNA H4 (bigger screen version), because apparently there is a firmware available that gives you 401 data points. We can't have angular Smith charts.
(https://i.postimg.cc/Df14hRwK/dislord.jpg)
Peter
-
Updating, or down dating the firmware takes seconds, so should you release your software I would still be game.
Peter, If you haven't already, you can check out the version he released in late January - but as Joe mentions above it is intended for the V2 Plus
https://github.com/joeqsmith/NanoVNA_V2Plus/releases/
-
The V2+4 supports 401 data points running standalone and 1024 when using the PC (which is really all I care about). It can download it at 400 data points per second. That's everything. When I demonstrated how to sweep in small segments, it was to overcome problems when looking at narrow band parts for SPICE. The V2+ removes the need for it but I still have it included in the software.
Yes, I checked out their Github account today to see if I could learn anything. I was surprised the original developer not being listed. With 15 developers, I expect that software is very polished by now. They adopted segmented sweeps early on and I would have expected them to roll in any other features I had shown they felt would be useful. From reading the groups, I didn't see a lot of people actually experimenting with RF. So spending resources adding support for mixers, transfer relays, automated crystal characterizing may not make a lot of sense if only a few people are asking for it. That's really IMO what people should be doing as they have a much larger support group.
I just finished editing the manual after getting some very good feedback on it and I still plan to release the software. Running that regression test gives me some idea what needs to be done but it will require a lot more testing. I changed my software to ease up on demands from the firmware. It's slow but at least the data rates are stable now.
-
Peter, If you haven't already, you can check out the version he released in late January - but as Joe mentions above it is intended for the V2 Plus
https://github.com/joeqsmith/NanoVNA_V2Plus/releases/
Have checked it already, Mr. Kean.
Thanks
Peter
-
The V2+4 supports 401 data points running standalone and 1024 when using the PC (which is really all I care about). It can download it at 400 data points per second. That's everything. When I demonstrated how to sweep in small segments, it was to overcome problems when looking at narrow band parts for SPICE. The V2+ removes the need for it but I still have it included in the software.
Ace.
Yes, I checked out their Github account today to see if I could learn anything. I was surprised the original developer not being listed.
Dislord is credited in the firmware I currently run. I tried his 1.0.38 in the hope of maybe upping the data point count, but it's limited to the H4 version.
With 15 developers, I expect that software is very polished by now. They adopted segmented sweeps early on and I would have expected them to roll in any other features I had shown they felt would be useful. From reading the groups, I didn't see a lot of people actually experimenting with RF. So spending resources adding support for mixers, transfer relays, automated crystal characterizing may not make a lot of sense if only a few people are asking for it. That's really IMO what people should be doing as they have a much larger support group.
If only they could be more like you, cough.
I just finished editing the manual after getting some very good feedback on it and I still plan to release the software.
Marvellous.
Running that regression test gives me some idea what needs to be done but it will require a lot more testing.
When you're good and ready, sir.
I changed my software to ease up on demands from the firmware. It's slow but at least the data rates are stable now.
I doubt you not.
Many thanks
Peter
-
I tried out the basic functions and checked my test loads using the new firmware. Seems alright. Looking in my pile of junk crystals, I had a 10MHz NYMPH that I thought I could run to give you some sort of a reference what you should see.
Beyond suggesting you not waste too much time with the EXE, my only other advice is read the manual. Good luck.
-
The old RTFM, eh?
Well, it'll have to wait for the morning.
Many thanks, Mr. Smith.
-
Not really. When I see read the fucking manual, I normally end the conversation which is not my intent. That manual is there for a reason. Make good use of it. If you have questions not covered by the manual, let me know and I can add more detail. That way others benefit. Now that the manual has been updated, I doubt I will make a clip showing how to measure crystals.
-
Morning Mr. Smith,
Well I did read the manual... well the crystal pertinent bits, just so I could give it a try before I went to bed.
Fired straight in and am currently characterising away. I also forgot to go to bed.
I'll certainly delve deeper into your writings and give any feedback I note.
Very interesting to see the very different responses of these Chinese made jobbies. No wonder they're dirt cheap.
When they're all done, I can't wait to press sort.
(https://i.postimg.cc/kgFVVy6j/Clip-14.jpg)
Once again
Very many thanks
Peter
-
If the goal is only to press sort and see what comes up, just select save 10-50 times for the same crystal and try it. If the goal is to actually measure crystals, the plot you show doesn't look right. You can waste a lot of time taking bad data. I suggest your time is better spent making sure things are correct before going further.
First thing are those spikes in the frequency. There is no way the crystal should shift frequency like that. It wouldn't recover that fast. Something else is going on, maybe noise. Assuming the cables are tight and you're not touching anything, maybe it's your Nano. Some versions of firmware would show bad readings at random. That's part of the reason for the regression testing. I haven't seen this problem for some time. It should be obvious that running the same firmware removes a lot of questions and may save you a lot of time.
Start by selecting the Xmsn Rectangular from the Main menu. With your short installed in place of the crystal, it should read well within 0.1dB after proper calibration (Capture1.PNG). Make sure you understand the difference between the Nano's internal calibration and the software's. Post a screen shot.
Assuming that the gain and noise look good, I would select Record and let it run for 10 minutes or more. Press Record again to turn off the recording. Select Advanced, Surface, Add Waveform and then load the file you saved the data to. Next select Narrow Band Zoom and select S21 Mag. You should have << 0.1dB noise P-P. Notice mine after touching the setup takes a dive but is still within 0.045dB P-P (Capture2.PNG). Post a screen shot.
Assuming you are not seeing a problem up to this point, select the Main menu (you should still be seeing << 0.1dB) and swap out the short for one of your 10MHz crystals. You should see a VERY smooth curve (Capture3.PNG). The peak is the Attenuation. You show 20dB which seems very low. Post a screen shot.
Select Record and save the data to a new file. Let it run for another 10 minutes or more. Don't touch anything and stay away from the fixture. If you have a lot of air flow in the room, my standard practice it the beach towel. It's too bad that the Nano doesn't have an ambient temperature sensor. People would rather have a worthless battery indicator. I would make a note of the temperature if you plan to try and reproduce the test or are collecting the data over long periods of time. 100ppm/degC with even a 2 degree shift and a 10MHz is easily detected.
Select Record again to stop the recording. Select Surface and select Flush. Now select Add Waveform. Looking at both S21 Mag/Phase, it better be very clean. (Capture4 & 5)
If all of that seems good, I have no idea what those spikes are. If a second crystals shows the same problem and you are running identical firmware, it seems there is a problem with the Nano, cables, not tightening things, external noise source.... You need to figure it out before wasting time measuring parts.
If you find the problem and get similar data, I would next validate that the C0 measurement is working. If you don't have a good RLC meter, I suggest installing a known capacitor. Maybe a few values from 10pF to 100pF. Depending what you have for parts, their tolerances can be pretty wide. Just make sure that the numbers are in the ballpark and you should be fine. If you insert a 100pF capacitor and it reads 50pF, something is obviously wrong. Try another capacitor. This shouldn't be a problem based on the data you posted for your jig. Again, that assumes you have properly calibrated the setup.
***
Very poor grammar for even me.
-
Evening Mr. Smith,
If the goal is only to press sort and see what comes up, just select save 10-50 times for the same crystal and try it.
OK. Sometimes I act like a schoolboy.
You can waste a lot of time taking bad data.
A good job I actually went to bed.
Start by selecting the Xmsn Rectangular from the Main menu. With your short installed in place of the crystal, it should read well within 0.1dB after proper calibration (Capture1.PNG). Make sure you understand the difference between the Nano's internal calibration and the software's. Post a screen shot.
(https://i.postimg.cc/FzGMKpW1/Clip.jpg)
Next select Narrow Band Zoom and select S21 Mag. You should have << 0.1dB noise P-P. Notice mine after touching the setup takes a dive but is still within 0.045dB P-P (Capture2.PNG). Post a screen shot.
(https://i.postimg.cc/Bbhz36bK/Clip-2.jpg)
Quite possibly not narrow band zoom.
Assuming you are not seeing a problem up to this point, select the Main menu (you should still be seeing << 0.1dB) and swap out the short for one of your 10MHz crystals. You should see a VERY smooth curve (Capture3.PNG). The peak is the Attenuation. You show 20dB which seems very low. Post a screen shot.
(https://i.postimg.cc/JzRQxmhw/Clip-3.jpg)
I would make a note of the temperature
23 new degrees.
(https://i.postimg.cc/bN9xsM9m/Clip-4.jpg)
(https://i.postimg.cc/Dz8LpzkN/Clip-5.jpg)
If all of that seems good, I have no idea what those spikes are.
Probably operator error. I'm really not that bright.
Many thanks
Peter
-
A few spikelets and a hump when I went to get some water.
(https://i.postimg.cc/wjwgTh41/Clip-6.jpg)
-
Start by selecting the Xmsn Rectangular from the Main menu. With your short installed in place of the crystal, it should read well within 0.1dB after proper calibration (Capture1.PNG). Make sure you understand the difference between the Nano's internal calibration and the software's. Post a screen shot.
Notice how you have ran a complete calibration where in every graph I show the data is normalized. Do yourself a favor, stop randomly pressing buttons, go to page 71 and carefully read section 14.4. It looks like this may have been the cause of that -19dB you first showed as you are now at -3.6dB. I am guessing that is still not right. I am not even sure how you would use that full calibration with the fixture. Maybe you felt you should run a full SOLT then installed the fixture. No matter. It you want to get it working, you must follow the directions in the manual. If something is not clear, let me know so I can address it.
Notice in the data I have presented, the span is set to 500Hz. You have clearly not selected zoom and are looking at a very wide frequency range. In the manual where it says Select Zoom, you have to actually select Zoom. You can't just skip steps. :-DD
Once you have it correctly calibrated and the span set, then run your 10 minute collection. There is no reason to collect 10 minutes of bad data. Your setup should be the same as what I show or something is wrong. Once you have that, don't go any further. Just post a screen shot of the 3D plot. I suspect with such a wide span, you may not see the noise problem.
-
Do yourself a favor, stop randomly pressing buttons
I identify as a toddler... it's my job.
Still, I'm glad my first joeqsmith admonishment was a wrist slap. instead of a punch in the mouth.
I'm going to have to have the night off and read the manual a few times, because following instructions and replicating your charts
are beyond me right now.
This is the latest...
(https://i.postimg.cc/LXBf09VK/Clip-7.jpg)
(https://i.postimg.cc/jdkf1ky5/Clip-8.jpg)
-
Good Job. This is what I was expecting. Now what is causing those spikes? Are you using the exact same firmware downloaded from the image mentioned in the earlier posts? If not, I would start there. Again, I had seen something like this with the earlier versions of firmware.
If you are running the same firmware, you could try to move the cables and your jig to see if it has an effect but assuming you are not anywhere near it while it it running, I doubt this is the problem. If it's not the firmware, I would guess the Nano itself. You need to get this resolved before moving to the next step.
-
Just put in the edy555 firm 0.8.0.
Waveform update seems about half as quick.
(https://i.postimg.cc/7YTBm7Tp/Clip-9.jpg)
(https://i.postimg.cc/HLTBYhPg/Clip-10.jpg)
-
Just grabbing some data.
Here's the attenuation..
(https://i.postimg.cc/L4fq68dz/Clip-12.jpg)
-
Hit that record and let's see if the firmware had any effect.
If it does, what version was previously loaded?
-
You want me to do the exact same as my previous? With the 0.8.0 firmware, or with the old?
-
Oh wait, that was the 3D with the span set correctly!! Let's see the C0 with 100pF installed in that fixture of yours. A few caps wouldn't hurt if you have them.
If you have an RLC meter, you could measure one of your crystals with it and plug it in and try it. I would expect something below 10pF.
****
Looking at some of the data I collected for various brands and frequencies, the HC49 package seems to give me between 4 and 6pF. It looked like that was what you were using so if you don't have any caps, just plug one in and lets see what it comes up with.
Then clear the graph, and let it collect until the part is stable.
-
When you tried the 100 and 33 in the de-5000, what does it show?
I wonder are we pushing your RLC meter. Another thing you could do is remove the capacitor from your jig and just run it with nothing and see what you get for C0. I would expect it to read around 600fF to 900fF. If you keep selecting C0, I would expect roughly 100fF of variance.
My old BK meters compare very close to the Nano and the old HP3589A. I have some tighter tolerance parts from ATC that are very stable which also come out. But you're getting close now to where I ended up. I could get all my instruments to basically agree but I was wanting to try and procure a reference crystal that had baby papers to get a handle on the absolute accuracy.
-
100pF in the de is 105.7pF, in fixture was 106.181pF
5pf in the de is 5.14pF, in the fixture was 5.59pF
33pf in the de is 32.54pF, in the fixture was 33.356
remove the capacitor from your jig and just run it with nothing and see what you get for C0.
Varies between 500 and 850f.
procure a reference crystal
Best of luck with that, Mr. Smith. Should I ever spot one in the wild, I'll let you know.
-
In the future, I may change the test frequency to 500KHz (seems like it was a bit more stable).
Try it with a crystal and let's see what numbers it comes up with.
Also, I am still curious what firmware you had loaded that caused the glitches.
-
Glitchy firmware was hugen79 1.0.45 NanoVNA-H_20210130.dfu.
Try it with a crystal and let's see what numbers it comes up with.
The DE? 2.93pF @100kHz
-
:-DD Yeah, I meant run it for real with the Nano and lets see what numbers you get. Don't run a bunch of them just yet. I want to have a look as see if I can improve this measurement first.
Just an FYI. The following mentions some of the problems with the firmware in the past. It's simple enough to test the firmware for headless operation. Odd after a year it's still a problem. Hopefully it helps you start to understand why I chose not to release the code to the public. On one side we have people not smart enough to not plug them into their transmitters and the other unstable firmware. Icing on the cake was people demanding it. What a shit show. You should feel privileged :-DD.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2710524/#msg2710524 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2710524/#msg2710524)
Saunder's standard crystal. They never responded to any of my attempts to contact them.
https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3060008/#msg306000 (https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3060008/#msg306000)
-
I meant run it for real with the Nano and lets see what numbers you get.
Slight wobble to it, but no glitches.
(https://i.postimg.cc/C5mR3YxR/Clip-17.jpg)
What a shit show.
I'm a delicate soul. Do I have to?
Saunder's standard crystal.
I shall have a word in their shell like.
peter
-
Shit show refers to the whole nanoism of it all, nothing to do with you specifically. Again, had you not been trying to use it to measure filters, I doubt I would have uploaded it. Good to see someone doing something besides trying to measure SWR.
TrC units "(pF)" were removed from the UI. The TrC test frequency was changed from 1MHz to 300KHz to allow for lower values crystals to be characterized. TrC measurement now uses an average of 4X sweeps (404 data points). This improves the calculations variance. To speed this measurement up, channel 0 is no longer collected during this time. Overall, it may actually be a little faster. You may also notice the open circuit capacitance being slightly lower (approx 100-200fF) as well due to the lower test frequency.
I tested it with a few different crystals as well as running through my test capacitors. It seems fine. No other changes were made.
-
Mr. Smith,
I read all of that stuff a few days ago. The gimme generation are a constant source of disappointment.
Just downloaded the latest and about to give her a go.
Anything specific you'd like me to do?
Peter
-
Mr. Smith,
open circuit capacitance
Much the same @ 500fF-1pF.
The fixture is on a really thick (3.5mm) double sided pcb (with no vias). I'm thinking I need to address the pcb's capacitance.
5pF measures 4.5pF in new software, 5.59pF in old.
33pF measures 32.26 in new, 33.356pF in old.
100pF measures 106.25pF in new, 106.181pF in old.
I'll get back to it.
Many thanks
Peter
-
If you remeasure the same part several times in a row it should be more stable now. Attached shows my open circuited jig running at 400KHz. I ran 130 C0 measurements and the peak to peak variance was 5fF. I compared it with my two BK RLC meters and also tried a few 5% tolerance caps and it seems to be in the ballpark. I'm pretty much at the limit of what I have available to to validate it.
Assuming you are getting stable readings, based on the numbers you're seeing I would just go ahead and try it.
You may consider building a pull test oscillator and compare the results with it vs your VNA. I tried a few different methods and the errors were fairly small.
Let me know how it works out.
-
Let me know how it works out.
Will do.
Many thanks
Peter
-
In order to speed up Zoom, it now works similar to the C0 measurement where Port1 data is not collected. Also to handle more error in the peak location when Zooming, I now center the peak before changing the span the first time. No other changes were made.
-
Mr. Smith,
You're going to tell me I'm doing it wrong, but I've been shorting the fixture, punching 10kHz into the span and ref/chn ref, loading the crystal, then centering the peak. Span to 500 Hz and centering again. Then off to advanced for the fun stuff. Pressing zoom a dozen times wasn't working for me.
BTW, I was playing with the bandwidth in the glitchy firmware and discovered that it defaults to 4000Hz. Tried it at the more standard 1000Hz and far less glitchy in the xtal data gathering. going down to 330Hz pretty much eradicated it.
Either way, the glitches didn't seem to show up in the 3D graphs.
Nevertheless, I'm back to eddy 0.8.0.
Peter
-
OK... It's now a single click... very nicely done sir.
Ooops... it always was. Cough.
Mr. Smith,
Re. manual proof read...
I've made a few suggestions.
I couldn't find much at fault.
Doesn't look like I can attach the pdf.
OK if i email it to you?
peter
-
You're going to tell me I'm doing it wrong, but I've been shorting the fixture, punching 10kHz into the span and ref/chn ref, loading the crystal, then centering the peak. Span to 500 Hz and centering again. Then off to advanced for the fun stuff. Pressing zoom a dozen times wasn't working for me.
That method should work fine, maybe even a little better than the method I describe in the manual. It comes down to how flat the Nano's response is in the range we are working over a small span. Again, we are normalizing the data (subtracting off the error). I show using a 1MHz span which is much different than a 500Hz span. Zooming into 500Hz, then taking the baseline with the short, then reinstalling the DUT gains us very little (from my testing) as the Nano is fairly flat. Still, 100K is going to be much better than 1MHz. I will change the manual to reflect this.
Using the term "ported" VERY loosely, because of how this software has evolved, starting with the old HP8754A, ported to Nano, ported to my other VNAs, then ported to the Plus, restructured to a common code base, then ported back to the Nano.... :-DD .... it's not a well thought out, polished bit of software by any means. To make things easier to maintain and keep more code common, some features work better on different products. The old Nano is very slow compared to the V2+4. Treating the old system like the new, then doing something simple like Zoom took a lot of time. I am starting to diverge from the common code for some functions to improve their performance. Really, that new V2+4 would have been the best solution for all of this had they considered the measurements you are trying to make. Seeing spikes in the lastest Hugen firmware tells me that the old Nano will continue to be a problem.
The button that starts the Zoom process is released when it completes. You could push it 1000 times and if you don't wait for it to finish, you won't get there.
BTW, I was playing with the bandwidth in the glitchy firmware and discovered that it defaults to 4000Hz. Tried it at the more standard 1000Hz and far less glitchy in the xtal data gathering. going down to 330Hz pretty much eradicated it.
Either way, the glitches didn't seem to show up in the 3D graphs.
I don't know what you mean by defaults to 4KHz. The span?. No doubt we saw in your first data that with a wide span, you may not see these glitches. They may appear at random. If you like collecting random data, I would run the Hugen's. If you want something more stable and slow use eddy 0.8.0. If you want something faster, glitch free and old, I would hunt down that last version RadioListener posted (keeping in mind that my software is now crippled to support the slower eddy firmware).
Our host sells a hand held meter that while not open source, does have user updateible firmware. Like the Nano, the firmware was in constant limbo. Like the Nano, I gave up trying to track it. Some people like to play with new releases of OSs, firmware.... I just want the thing to work well enough that I can use it (I've given up on modern software/firmware not having problems).
-
That method should work fine.
Marvellous.
Using the term "ported" VERY loosely
The only porting with which I am familiar is taking a grinder to a cylinder head. You're well ahead of my game.
Treating the old system like the new, then doing something simple like Zoom took a lot of time
I doubt you not, but anything to get away from the wife.
Really, that new V2+4 would have been the best solution
Still has its uses, I'm sure.
The button that starts the Zoom process is released when it completes. You could push it 1000 times and if you don't wait for it to finish, you won't get there.
I discovered this yesterday. I'm an impatient child sometimes.
I don't know what you mean by defaults to 4KHz. The span?
In display settings, down at the bottom.
If you like collecting random data, I would run the Hugen's
I'm fine with the eddy. The hugen just has a few extra bells and whistles.
I would hunt down that last version RadioListener posted
I'll certainly try, but your wares are running fine with the eddy.
I just want the thing to work well enough that I can use it
I hear that.
Many thanks
Peter
-
In this context, porting is moving the software to a different platform. I have a bit of an addiction myself. The ports on my motorcycle have been opened up a bit along with larger valves......
https://www.youtube.com/watch?v=sYUw1S9SESU (https://www.youtube.com/watch?v=sYUw1S9SESU)
The manual has been updated to include the troubleshooting from this thread and comments about the firmware I used during testing. The comment about the Span was also changed.
The software was also updated. The quick tips were updated to reflect the V2+4 (which also needed some corrections). The C0 test frequency was moved up to 500K from 300K. The Zoom was changed from 25% to 20% of previous range.
Page 90&91 includes some data I collected with my original NanoVNA compared with my Fluke 189 and two of my RLC meters.
-
Very nice motorcycle. 7.85 @ 164.... That is not hanging around.
I was never much into drag racing, but with the advent of youtube I seem to have developed a mild addiction.
Squeezing a thousand horsepower out of a 4 cylinder Honda is bonkers.
Off to download the latest.
Many thanks
Peter
-
If you want to make a list of your corrections and post them here, that would be great. Otherwise, I would need to enable the private message feature. Also make a note of any changes you would like to see in the software as you go through it.
-
Hi joeqsmith !
Question - Is it possible to use your Nanovna program with NanoVna-H4 hardware version?
STM32F303C processor.
-
Question - Is it possible to use your Nanovna program with NanoVna-H4 hardware version?
Hello. As I have mentioned, I only have the original NanoVNA and the two versions of the V2 Plus. I don't know anything about any other flavors of the NanoVNA but if you read the recent posts, you know that the firmware even a year after I first looked at it is still a problem. So even if your H4 uses one of these two protocols, there is a good chance that the firmware would cause random problems. You may be able to find some combination that is stable.
My advice would be to stay with the open source software. While they started that project after I did, it looks like there are 15 people now working on it. I would expect with that effort, it would be far more advanced and well supported. It should also be better suited for the radio group.
If you do decide to look at the software I have made available, I suggest you read the manual first. You may also want to watch that video I made where I reviewed the V2 Plus 4 as that demonstrates the basics on how to use it.
-
If you want to make a list of your corrections and post them here, that would be great. Otherwise, I would need to enable the private message feature. Also make a note of any changes you would like to see in the software as you go through it.
It was done within the (r11) pdf, with highlighted text and pop-up notes.
Let me run through the r12 changes and I'll report back.
Peter
-
Mr. Smith,
Firstly, the improvements made work well.
The quick tips correspond nicely with the buttons.
The zoom function had a glitch one time, where it got stuck on (I think) 300Hz, but a quick hit on the centering button unstuck it. Hasn't happened since and doesn't bother me in the slightest.
I left it running for several hours gathering data and was still doing so when checked.
So far I've only characterised crystals and the few filters that I have. Not one hiccup.
Other functions will have to wait until I understand the instrument better.
The manual could certainly use the addition of link/s to your youtube videos on the nano.
I've read the manual a few times now, yet when I then watch your vids, a great deal more sinks in.
That's about as much as I can say at the moment, but I'm not going to post the grammar and punctuation errors on here... far too many... cough.
Send me an email with a throwaway address, that way I can send you the pdf and you can still be incognito.
Peter
-
The zoom function had a glitch one time, where it got stuck on (I think) 300Hz, but a quick hit on the centering button unstuck it. Hasn't happened since and doesn't bother me in the slightest.
I assume you were running at 10MHz as usual, the software had set the span to 300Hz. The peak was still visible and centered once it completed but the span was set to 300Hz rather than 500Hz.
If it happens again, try and supply as much detail as possible and then I'll see if I can address it. Center frequency, span, is it continuing to hunt or the Zoom completed.
****
When we did that last round of review on the manual, the had tried to send the file be email but it was too large. They had set up some MicroSoft shared area but sadly, after changing to Windows 10, I have every IP for MS blocked at the router to prevent them from doing anything to my system while I am trying to work. This is why I was suggesting if there are a limited number of update, can you just paste them in ASCII from here? If that would be a lot of work, could you maybe setup a Github or GoogleDocs account and load it there. Github would be the better solution as the file could be stored without any formatting changes. If you really want to use email, I think you will need to use the span option to limit the file size. What a pain....
-
I assume you were running at 10MHz as usual, the software had set the span to 300Hz. The peak was still visible and centered once it completed but the span was set to 300Hz rather than 500Hz.
If it happens again, try and supply as much detail as possible and then I'll see if I can address it. Center frequency, span, is it continuing to hunt or the Zoom completed.
The usual 10MHz, yep. What seems to happen (every zoom press) is that it overshoots the 500Hz to an arbitrary number 160Hz/300Hz/400Hz, then back up to 500.
Peter
-
I'll sort something.
I gave up my website last week, because the greedy bastards wanted 4 times as much as last year.
Beginning to think I should have paid them.
-
The usual 10MHz, yep. What seems to happen (every zoom press) is that it overshoots the 500Hz to an arbitrary number 160Hz/300Hz/400Hz, then back up to 500.
It makes sense to change the check so it doesn't overshoot the span but regardless it shouldn't get stuck. You can try that new version if you like. I am attempting to get the it to hang right now but not having any luck. I wonder if I am still just asking too much from the firmware and overran its message buffer.
***
I should mention that assuming the crystals are the same, you shouldn't have to zoom in but once for the very first part you characterize. Of course, I never numbered the steps in section 14.4 so you may not know that.
-
It makes sense to change the check so it doesn't overshoot the span but regardless it shouldn't get stuck. You can try that new version if you like. I am attempting to get the it to hang right now but not having any luck. I wonder if I am still just asking too much from the firmware and overran its message buffer.
***
I should mention that assuming the crystals are the same, you shouldn't have to zoom in but once for the very first part you characterize. Of course, I never numbered the steps in section 14.4 so you may not know that.
There's another new version? So there is. Didn't overshoot.
Same crystals and I'm not zooming like a madman.
Numbering is for people that can't count.
-
Thanks for the feedback. I'll go over it for the next revision. At some point, I will also release an update to the V2+ software that rolls all of these changes in as well.
I wasn't able to get it to hang and would hate to further cripple the software if we don't have to. Let me know if it continues to be a problem.
-
Let me know if it continues to be a problem.
It was never a problem. One click and it was gone.
At some point, I will also release an update to the V2+ software that rolls all of these changes in as well.
If they ever re-release the V2 Plus 4 (doesn't look hopeful) I could see that being rather handy.
Cheers
Peter
-
One thing that I forgot to mention was that upon start-up and in Xmsn Rect, the phase waveform is displayed without the tick box activated. Ticking and unticking sees the wave gone.
While I'm at it... SetupDiag page, change Responce to Response.
Peter
Feel free to take some time off.
-
Done.
LabView is a very powerful tool when it comes to putting together simple test software like this. It has a feature that allows you to take whatever you have shown as the defaults. I will often use this feature rather then initialize everything to a known state manually. In the case of the phase being active, this is what happened. I had it active and saved it as a default. You select the checkbox the first time and it does nothing because it is already active. You press it again and now it turns off. This is a case where I have added it to the initialize sequence as I can see myself turning it back on and saving it again as the default. Spelling was also corrected.
Let me know if it continues to be a problem.
It was never a problem. One click and it was gone.
At some point, I will also release an update to the V2+ software that rolls all of these changes in as well.
If they ever re-release the V2 Plus 4 (doesn't look hopeful) I could see that being rather handy.
If the software is not behaving as expected, I consider it a problem. In this case you found a workaround that you were happy with but it still should be addressed.
I have not seen anything more on the V2 Plus 4. I noticed they had ran out of stock of the V2 Plus as well. I'm glad they sold out and I hope they met their goals. If they make another batch, I think they should screen some graphics onto the case, at least advertise their company and mark the buttons. Outside of the lack of narrow band support, that +4 is a really nice unit. I'm looking forward to seeing them introduce a 6GHz version with narrow band, more data points, faster update rates and wider dynamic range.
-
Sorted.
If the software is not behaving as expected, I consider it a problem.
I fully understand.
Outside of the lack of narrow band support, that +4 is a really nice unit. I'm looking forward to seeing them introduce a 6GHz version with narrow band, more data points, faster update rates and wider dynamic range.
As you say in your videos, the original is best for narrow band stuff. It's still more than I envisage ever needing, but should I learn how to get the best out of it and find it lacking, then I shall see what you find a worthwhile upgrade.
Many thanks
Peter
-
Peter,
First I just want to thank you for taking the time to go over the document and provide feedback for it. As I go over your comments, the following paragraph sums up my thoughts about the software:
This software can be viewed as an engineering tool at best. Its primary use was to extend the author's understanding of V2+. It was never intended to be used as a general tool for radio hobbyist to tune their antennas. The software is fairly buggy and not very robust. Even under normal conditions, expect to run into several problems if attempting to use this software. It’s a very poor choice for the beginner.
[/i]
Adam Savage showed us that indeed it is possible to polish a turd. :-DD
A few comments on your feedback
Pg8) Current: The author is not an amateur radio or citizens band hobbyist.
Proposed: The author is not an amateur radio enthusiast, or citizens band hobbyist.
In general, I don't place one group above the other and consider both to be hobbyists.
Pg8) Current: Because the software was written for my own personal use, there are many features that may be lacking or have not been completed.
Proposed: Because the software was written for my own personal use, there are many features that may be lacking or have not been implemented.
I want to make a distinction between features that someone may feel should be included but are not and features that have been included but may not be fully functional. Changing completed to implemented vs lacking does not make that clear.
Pg 10) Current: If we are sweeping from 1.0 to 1MHz, the first sample has an index of 0.
Proposed: Add units to left.
When using the same units, it is common to leave off the left side.
Pg 26) Current: Performing a full calibration or selecting standards is not necessary.
Proposed: Performing a full calibration, or selecting standards is not necessary.
I'm not sure about as they are both talking about how the software converts raw data into something usable. With a comma added, MSW will flag it as a grammar warning.
Pg 71) Current: The software will try and zoom into the peak and set the span to 500Hz
Proposed: remove try, no trying about it
From what I understand the software has a bug and it does not always zoom in. :-DD I have removed the word try as suggested but this means the problem needs to be resolved. Of course, I have covered it in that one paragraph in the Scope where I state: " The software is fairly buggy and not very robust." :-DD It can't get much clearer than that!
Pg 71) Current: Notice without the calibration, the original NanoVNA will display roughly 17dB.
Proposed: Change the sign.
Interesting. You know, I don't normally think about such things as I am considering the context. I would expect and amplifier to have a positive gain (although, it may not) and most everything else to have a loss. In this particular case because the document is stating what the display should be showing, I think it needs to change as well. I wouldn't be surprised at all if you found other sections of the document that need this clarification.
I added links to the Github and YouTube accounts to section 1.
-
Mr. Smith,
Adam Savage showed us that indeed it is possible to polish a turd.
There's video...Now I'm going to have to watch it.
Pg8) Current: The author is not an amateur radio
Neither am I. This is what I had a minor problem with.
Changing completed to implemented vs lacking does not make that clear.
I shall consult the Thesaurus.
When using the same units, it is common to leave off the left side.
Should it then not be 0.1 to 1Mhz? As 1.0 is the same as 1 and sweeping was mentioned.
With a comma added, MSW will flag it as a grammar warning.
I took the day off to avoid the English exam.
I wouldn't be surprised at all if you found other sections of the document that need this clarification.
I'll certainly run through the next iteration. I seem to learn a little something every time. How odd.
I added links to the Github and YouTube accounts to section 1.
Top job.
Peter
-
Pg8) Current: The author is not an amateur radio or citizens band hobbyist.
Proposed: The author is not an amateur radio enthusiast, or citizens band hobbyist.
Pg8) Current: The author is not an amateur radio
Neither am I. This is what I had a minor problem with.
I would understand it to mean "The author is not an amateur radio hobbyist or citizens band hobbyist." I consider both groups to be hobbyists but do not want to use the same word twice in a sentence. Are there documents known to have been authored by any electronic equipment? Even if we consider an electric typewriter, we still need the monkeys to write War and Peace.
Proposing one group being enthusiasts and the other hobbyists, I don't think is valid. Not to say that if someone obtained their license that they may feel that put them a cut above. I would consider an enthusiasts as someone from one of these groups who went on to further their education, perhaps becoming degreed engineering professionals.
Maybe there is a better way to convey it.
When using the same units, it is common to leave off the left side.
Should it then not be 0.1 to 1Mhz? As 1.0 is the same as 1 and sweeping was mentioned.
:palm: Now I see the problem. Yes, 0.1. We are not sweeping from 1MHz to 1MHz as the document suggests. :-DD Strike this one off the list.
-
From Google, I get the following hit:
https://theeditorsblog.net/2015/08/08/one-adjective-paired-with-multiple-nouns-a-readers-question/
-
Might I suggest The author is not an amateur radio/citizens band hobbyist. That might cover it.
Now I see the problem.
I knew there was one lurking.
From Google, I get the following hit:
I've just woken up from a lucid dreamy nap. It'll have to wait until processed.
-
Might I suggest The author is not an amateur radio/citizens band hobbyist. That might cover it.
Often, when a slash is used in a formal or informal text, it is meant to indicate the word or. The examples below illustrate this meaning of the forward slash:
When leaving the classroom, the teacher noticed that a student had left his/her backpack.
https://www.grammarly.com/blog/slash/ (https://www.grammarly.com/blog/slash/)
Personally, I like using or over slash.
-
Then or it is.
Last punt... The author is neither an amateur radio nor citizens band hobbyist.
-
The author is neither a citizens band or amateur radio operator.
Did you attempt to construct a pull tester yet? I am interested in hearing what results you come up with if you compare the two methods.
-
The author is neither a citizens band nor amateur radio operator.
Alternatively.. The author cares not for rubber ducks, phonetic alphabets nor talking to those stranded in Antarctica.
No offence, boys.
Did you attempt to construct a pull tester yet?
I did not. One pull test oscillator on the way.
Is this the type of thing?
https://www.electronics-notes.com/articles/electronic_components/quartz-crystal-xtal/crystal-resonator-frequency-pulling-trimming.php (https://www.electronics-notes.com/articles/electronic_components/quartz-crystal-xtal/crystal-resonator-frequency-pulling-trimming.php)
Peter
-
While I thought I had provided the link, here it is:
https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3036196/#msg3036196 (https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3036196/#msg3036196)
You can also see pictures of the one I constructed from these papers and some of the data I collected. I would expect the data from your NanoVNA will match up with what I have shown.
-
this is a very usable software. The only real problem for me is now, since I have big computer monitors with high resolution, that the charts are very small. I can't make them bigger.
Any plans to make it resizable?
-
this is a very usable software. The only real problem for me is now, since I have big computer monitors with high resolution, that the charts are very small. I can't make them bigger.
Any plans to make it resizable?
No.
-
Discovered that the software for the original Nano has a major bug where it doesn't load the defaults file. By pure luck maybe the comm port settings were the same or you would have to change it every time. It's been like this since the first release. The Plus software was correct. Strange it never came up.
-
Mr. Smith,
I was going to mention it, but entering a baud rate (0 wasn't working) and selecting a com port took seconds.
Waiting on a few parts for tester.
Peter
-
Hello Mr. Smith!
Thanks for sharing your software. Great job! :-+
Yesterday I installed both versions, although I don't have the NanoVNA V2+, but needed the Labview runtime for the original NanoVNA.
I'm living in Germany, so Windows is (stupidly) using ","(comma) as decimal separator. I'm not familiar with Labview, but it seems that the conversion from strings to numbers you are using is dependent on the windows regional settings for numbers.
So I had to change these settings to explicitly use "." as decimal separator to run the program. Thats not a big problem, but I thought that maybe you can change the conversion you are using, making it independent.
Many thanks,
Cyprian
-
Hello Mr. Smith!
Thanks for sharing your software. Great job! :-+
Yesterday I installed both versions, although I don't have the NanoVNA V2+, but needed the Labview runtime for the original NanoVNA.
I'm living in Germany, so Windows is (stupidly) using ","(comma) as decimal separator. I'm not familiar with Labview, but it seems that the conversion from strings to numbers you are using is dependent on the windows regional settings for numbers.
So I had to change these settings to explicitly use "." as decimal separator to run the program. Thats not a big problem, but I thought that maybe you can change the conversion you are using, making it independent.
Many thanks,
Cyprian
LabView uses Window's regional settings. Yes, the software could be changed to perform conversions on all of the numerical data.
-
I was going to mention it, but entering a baud rate (0 wasn't working) and selecting a com port took seconds.
Per the manual and videos, the BAUD rate has no effect but it sounds like entering 0 causes a problem. I am guessing the call to open the port doesn't like that.
Not mentioning problems you find will certainly make it easier for me to ignore them. :-DD While I have no plans to add additional features (unless there is some experiment I want to run), I would consider addressing problems.
-
Re baud rate... Sometimes on start up the baud rate would show as zero. Selecting the correct com port would not enable the link. Entering 115200 would then link nicely.
No problem when start up gives me 115000. Seems random.
Not mentioning problems you find will certainly make it easier for me to ignore them.
I didn't want to bug you.
I would consider addressing problems.
Author, prepare thyself.
Peter
-
Re baud rate... Sometimes on start up the baud rate would show as zero. Selecting the correct com port would not enable the link. Entering 115200 would then link nicely.
No problem when start up gives me 115000. Seems random.
Not mentioning problems you find will certainly make it easier for me to ignore them.
I didn't want to bug you.
I would consider addressing problems.
Author, prepare thyself.
Peter
I doubt the code is changing the BAUD rate at random. I suspect it's the human who does take note of what they are doing and changing their process.
The program initialized the settings (including the BAUD) when the default settings file was invalid. If the file was valid, it would not initialize. So if you created a defaults files with a valid BAUD rate of say 9600, the next time you run the program it loads this file, sees it is valid and doesn't update the BAUD, so it remains at the default of 115K. If however you selected a non-existing default file or there was a problem with the file, it would initialize the BAUD to 0. I suspect VISA sends out an error when you try to open a comm port with a BAUD rate of 0. I tried it and indeed it does flag an error. If you find that the display settings are indeed random, then there is a major problem with LabView.
Asking about legitimate problems is fine. Just make sure you document the steps to replicate the problem.
I have no plans to add additional features. Functions that are still not completed most likely will not be worked on anytime in the near future. With it being an engineering tool for my own use, features are added if there is some test I want to run that requires a software change.
-
LabView uses Window's regional settings. Yes, the software could be changed to perform conversions on all of the numerical data.
But please don't get me wrong, you don't have to change it, I just thought it's maybe worth mentioning and because it's not specified in the manual. The workaround is very simple. :)
I'm also writing software for the NanoVNA for my own (specific) applications and had similar problems, but I'm using C#
I was just curious testing your software for comparative measurements.
There is only one more little thing I have noticed, probably also LabView specific :
Disconnecting the COM Port (by pushing the Link button) does not really work. It's shown disconnected, but the COM port is not accessible for other application as long as the program is still running.
Keep the great and inpiring work going!
-
LabView uses Window's regional settings. Yes, the software could be changed to perform conversions on all of the numerical data.
But please don't get me wrong, you don't have to change it, I just thought it's maybe worth mentioning and because it's not specified in the manual. The workaround is very simple. :)
I'm also writing software for the NanoVNA for my own (specific) applications and had similar problems, but I'm using C#
I was just curious testing your software for comparative measurements.
There is only one more little thing I have noticed, probably also LabView specific :
Disconnecting the COM Port (by pushing the Link button) does not really work. It's shown disconnected, but the COM port is not accessible for other application as long as the program is still running.
Keep the great and inpiring work going!
Believe me when I say, I know I don't have to change it.
I would assume that most Windows PC users know if they select a region that uses commas rather than than a decimal that this is how it will work. If you like the decimal, don't select regions that don't use it. No matter what you select for your region, it has no effect on the data the software produces. It's just how you choose to enter and have it presented. You're right, it is very simple. It was never in the scope of the manual to help educate people on the basics of how to use a computer.
From the manual:
This manual assumes the reader is PC literate and has some basic understanding of how a VNA works. It is not a learner’s guide on using a VNA and offers no assistance into solving basic computer related problems.
and of course
This software can be viewed as an engineering tool at best. Its primary use was to extend the author's understanding of V2+. It was never intended to be used as a general tool for radio hobbyist’s to tune their antennas. The software is fairly buggy and not very robust. Even under normal conditions, expect to run into several problems if attempting to use this software. It’s a very poor choice for the beginner.
Yes, LabView does have a problem closing the comm ports. If you start LabView, then run a program that uses a comm port, then close that program down. As long as LabView remains running, that port is locked. They may have addressed it on newer versions. I never looked into it. Funny that you mention C# as from what I remember, they had rewrote the comm port, guessing because some software person thought it would make things so much better. It broke pretty much every serial port I had. Even if Windows supported the hardware, LabView would not work with it. I changed to FTDI, tossed all the other hardware and moved on. This problem you mention may have cropped up at that time.
If you wonder why I use LV 2011 when it's so old and the latest is free (for home use), it's because I know about most of the problems with it and the new versions don't really offer anything that would be of benefit to me.
-
I doubt the code is changing the BAUD rate at random. I suspect it's the human who does take note of what they are doing and changing their process.
Yes. I'm sure it's me. Fresh out of the zip file it defaults to 0, but saving 115k sees it there on next reboot.
Is it supposed to save the com port? If yes, then mine doesn't. Still not a problem.
If you find that the display settings are indeed random, then there is a major problem with LabView.
Maybe I'm just being a bellend.
Asking about legitimate problems is fine. Just make sure you document the steps to replicate the problem.
There is nothing at all that irks me.The workarounds are intuitive and simple. There will be no frivolous requests.
I have no plans to add additional features.
Should I find anything lacking, I'll keep it to myself.
Peter
-
No matter what you select for your region, it has no effect on the data the software produces. It's just how you choose to enter and have it presented. You're right, it is very simple. It was never in the scope of the manual to help educate people on the basics of how to use a computer.
The software produces no data at all when it is used with regional settings that don't use "." as decimal separator.
Maybe I wasn't able to described the problem very clear. Parsing/converting the data from the NanaVNA (and generally from any instrument and peripherial device using ASCII) should be culture insensitive, otherwise (in this case) the software reads 0-0i. Using the binary protocol for the NanoVNA V2 was a good choice.
So I was not refering to the way I'm entering decimal numbers, with "." or ",". That works fine.
Funny that you mention C# as from what I remember, they had rewrote the comm port, guessing because some software person thought it would make things so much better. It broke pretty much every serial port I had.
I can't complain about serial ports in C#, but it took some time get it working stable.
-
The software produces no data at all when it is used with regional settings that don't use "." as decimal separator.
Maybe I wasn't able to described the problem very clear.
I didn't get that from your first post. That's very interesting. I will try it out as it seems very unexpected. Sounds like you believe the problem is due to the Nano pushing ASCII that uses the decimal point rather than the comma. This could very well be the case and would be an easy fix if this is what is going on. Now that I understand let me get back with you on it.
I doubt the code is changing the BAUD rate at random. I suspect it's the human who does take note of what they are doing and changing their process.
Yes. I'm sure it's me. Fresh out of the zip file it defaults to 0, but saving 115k sees it there on next reboot.
Is it supposed to save the com port? If yes, then mine doesn't. Still not a problem.
Until I release a new update, rest assured is not intelligent and will not fix itself. You can save but it will not load the file.
Fresh out of the ZIP there is no default settings file. As I previously explained, it will see this as valid file even though you don't have one and initialize the BAUD to 0. Once you create a valid file, the software thinks it is not valid and runs with the factory settings. For the BAUD rate, that's 115k. Try it. Repeat the steps you describe but instead of saving 115k, save some other value. Try 300. I assume reboot does not mean an actual system reboot. If you are actually rebooting, then why? Restart the program, does it show 300 or 115k?
-
Yeah... re-starting the software.
Saved 300 baud to defaults, re started and came back with 115k.
-
The software produces no data at all when it is used with regional settings that don't use "." as decimal separator.
I tried it and sure enough. No problem though. Open the .INI file and add the line:
useLocaleDecimalPt=False
Rerun the application. It will then use a decimal as it should regardless of the regional settings.
Yeah... re-starting the software.
Saved 300 baud to defaults, re started and came back with 115k.
So the bug does not have a bug and the software is not as random as was first suggested.
-
Both the manual and software have been updated. The software corrects the bug when loading the defaults. The manual has a few minor updates which now includes a comment about the regional settings and how to modify the INI file. I have also released 1.0 of the software for the V2+4 which is based on the same common code and corrects a few problems discovered during the port.
-
I tried it and sure enough. No problem though. Open the .INI file and add the line:
useLocaleDecimalPt=False
Rerun the application. It will then use a decimal as it should regardless of the regional settings.
It works, thank you! :)
-
So the bug does not have a bug and the software is not as random as was first suggested.
In my defence, there is very little between my ears.
Cheers
Peter
-
r13 manual proof read.
I missed 'summery' the first time around. It should of course be summary.
Also a couple of very minor niggles.
Let me know if you want it uploaded.
peter
-
Github has an issue tracking feature if you would like to start using it.
-
While porting my other VNA software to use the new common code, I noticed a few major problems with both the original and V2+ programs. These have now been corrected.
Note that I combined both into a single repository. The repository for the original hardware has been removed.
-
Just a quick note.
My NanoVNA H4 arrived, I then loaded the latest Dislord firmware (1.0.53 with 401 data points) into it.
Lo and behold it behaves itself very nicely with Mr. Smith's software, which eats up the extra data with ease.
3D charts take a little longer to display, but that would be expected.
Toodle pip.
Peter
-
Just a quick note.
My NanoVNA H4 arrived, I then loaded the latest Dislord firmware (1.0.53 with 401 data points) into it.
Lo and behold it behaves itself very nicely with Mr. Smith's software, which eats up the extra data with ease.
3D charts take a little longer to display, but that would be expected.
Good to know. Also smart idea to document the firmware.
Jankae's unit appears to be available but I'm a bit uncomfortable with some of their description. Software seems lacking and I'm not sure if they have it open to where I could port mine over to run with it. I wonder how it would compare with my old Agilent.
https://www.aliexpress.com/item/1005002428364525.html (https://www.aliexpress.com/item/1005002428364525.html)
Speaking of the Agilent, I finished up the port which lead to a few more changes to the software. I've added a few new features, finished up some of the other features and made a few enhancements. The changes have now been wrapped back into the Nano software. I need to update the manual and plan to make a short video showing the differences.
-
Morning,
Jankae's unit appears to be available but I'm a bit uncomfortable with some of their description.
A £350 punt is a little more spicy than £50.
100dB dynamic range is attractive (up to 3GHz), as is the 3 in 1 VNA, sig gen and spectrum analyser choice.
It might be the answer, but might also be a donkey.
I wonder how it would compare with my old Agilent.
Only one way to find out. I'll chip in if you fancy a gamble.
Speaking of the Agilent, I finished up the port which lead to a few more changes to the software. I've added a few new features, finished up some of the other features and made a few enhancements. The changes have now been wrapped back into the Nano software. I need to update the manual and plan to make a short video showing the differences.
Marvellous
Peter
-
If the software is like the first two I looked at and the interface is not well documented, it could be a waste of time. Odd they didn't provide a link to the designer's Github project. If you read my early posts on the V2+, OWO pointed out the need to add the cross coupling to the calibration model. I wonder how many of the problems (port mismatch between ports, poor performance above 3GHz....) are a result of the software.
I haven't spent enough time looking into if it can be used for narrow band parts. IMO, that was a big miss with the V2Plus design.
It may be worth waiting to see if the designer comes out with a third generation that improves some of the performance problems. We may also find that the open source software starts to support it. At $500, I doubt you will see much hype from the radio group about the next antenna analyzer. If they were smart, they would drop some of these off to the main RF channels to do a review on. I'm sure that would clear up a lot of the unknowns.
-
Just a quick note.
My NanoVNA H4 arrived, I then loaded the latest Dislord firmware (1.0.53 with 401 data points) into it.
Lo and behold it behaves itself very nicely with Mr. Smith's software, which eats up the extra data with ease.
3D charts take a little longer to display, but that would be expected.
Hi Peter!
I have the same H4 as yours and I also downloaded Dislord Firmware 1.0.53. Does not work for me Mr. SMITH's Software! Can you give me advice? Now I get this status when connecting Nanovna
-
It may be worth waiting to see if the designer comes out with a third generation that improves some of the performance problems.
Makes perfect sense. I'm in no rush whatsoever.
If they were smart, they would drop some of these off to the main RF channels to do a review on. I'm sure that would clear up a lot of the unknowns.
Quite. Anyone know the designer?
-
Mr. indman,
Correct COM port?
Cable plugged in to the hilt?
Double tap on link button?
Config/Connection set to usb?
No other ideas I'm afraid.
Peter
-
Mr. indman,
Correct COM port?
Cable plugged in to the hilt?
Double tap on link button?
Config/Connection set to usb?
No other ideas I'm afraid.
Peter
1. COM port correct - COM9.
2. Cable plugged.
3. Double tap on link button -yes!
4. Where should I watch these USB settings? Is it possible in more detail? :)
-
Where should I watch these USB settings?
VNA Config menu... connection... select usb.
Which version of Mr. Smith's software are you using?
I'm on 1.06.
peter
-
I showed you a screenshot of the program- NanoVNA V2+4 rev.0.10
-
Wrong version.
You need the type for original Nano.
https://github.com/joeqsmith/NanoVNA_Software/blob/NanoVNA/NanoVNA_original_1p07.zip
seems to be the latest
Peter
-
Wrong version.
You need the type for original Nano.
https://github.com/joeqsmith/NanoVNA_Software/blob/NanoVNA/NanoVNA_original_1p07.zip
seems to be the latest
Peter
Many thanks, Peter! :)
Now I see a connection.
-
You're welcome.
-
Video showing some of the changes to the new software.
https://www.youtube.com/watch?v=scZ3kZ4Q2sQ (https://www.youtube.com/watch?v=scZ3kZ4Q2sQ)
-
The new documentation and software for both the original NanoVNA and the V2 Plus have been uploaded. There were no changes from what was shown during the video. There are other changes that were not mentioned. The main one you may have guessed from the video's thumbnail is when making full 2-port measurements, the menu was changed to make it more generic. Having SWR was more a test case and really was just taking up space. The Smith charts sizes were increased and polar transmission graphs were added. You will also notice that I have added addition readouts for the cursors. Most of this stemmed after porting the software to my old Agilent which is a 2-port system.
-
Looking through the comments on Jan Käberich's VNA, it seems like there are a lot of basic problems being worked on. They made the group public for viewing.
https://groups.io/g/LibreVNA/topics (https://groups.io/g/LibreVNA/topics)
This post from the designer on the 9th pretty much sums it up where they are with the project:
"jankae Apr 9
Hi Herb,
so far, only a few beta testers had the hardware so I didn't bother with creating proper releases. Since the project is now officially up for sale, I will create a new release this weekend (the github actions are really useful but not exactly easy to find for new users)."
Paying for the pleasure of of helping with the development may sound fun but I'll continue to keep a watch out for it in the future.
https://www.aliexpress.com/item/1005002428364525.html (https://www.aliexpress.com/item/1005002428364525.html)
-
Paying for the pleasure of of helping with the development may sound fun but I'll continue to keep a watch out for it in the future.
Get the credit card out, fix it, then send them an invoice and charge like a wounded Rhino.
-
Did you ever get a pull tester made? If so, how did the results compare with my software and your Nano?
-
I am a bit stumped on "labview runtime 2011 or compatible". I have the original NanoVNA software, version 1p08 (NanoVNA_original_1p08.zip) and I have the LabVIEW runtime 2020SP1. But the NanoVNA software says I need labview runtime 2011 or compatible. Can you clarify what does "compatible" mean? Is 2020SP1 alright? It is entirely possible I have done something wrong not actually related to the LabVIEW part.
Assuming that exactly 2011 is needed, is there a way of getting that proper version of LabVIEW runtime without registering for an NI account? The manual suggests that some versions of the NanoVNA software might have it. I see a large multipart zip in here: https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10 Is that what I am looking for?
Thanks.
-
The manual suggests that some versions of the NanoVNA software might have it. I see a large multipart zip in here: https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10 Is that what I am looking for?
Yes, download all 21 files, unzip and install.
-
Do me a favor and don't uninstall the wrong files. Someone else had posted an issue about LabView not working on their system and I wondered if they had installed the newer release as well.
Of course, I suggest reading the README file and the manual BEFORE you start trying to install and use it.
-
Okay, I am up and running and getting useful results it seems. Thanks for your assistance.
I am a little puzzled by segmented sweeps. With so few points in the built in frequency sweeps on the original NanoVNA, it seems that it would be useful to allow segmentation of sweeps for the "Main" tab -- SWR. Smith chart and so forth. But when I tried that, it looks like I get a sequence of charts, updating once for each segment, rather than a single chart with all the segments on it. I will experiment a bit more.
Thanks again. This is a really great project and I very much appreciate your efforts on it.
-
Did you ever get a pull tester made? If so, how did the results compare with my software and your Nano?
I did not, but will.
-
Okay, I am up and running and getting useful results it seems. Thanks for your assistance.
I am a little puzzled by segmented sweeps. With so few points in the built in frequency sweeps on the original NanoVNA, it seems that it would be useful to allow segmentation of sweeps for the "Main" tab -- SWR. Smith chart and so forth. But when I tried that, it looks like I get a sequence of charts, updating once for each segment, rather than a single chart with all the segments on it. I will experiment a bit more.
Thanks again. This is a really great project and I very much appreciate your efforts on it.
Did you uninstall the wrong runtime first, or is it still install like I asked?
There is a section on segmented sweeps which I assume you read and it is not behaving how the manual shows. I came up with that mode for looking at narrow band parts to create models for SPICE and normally don't have a use it. It's very possible I broke it when I combined all the software. Then again, you may enjoy randomly selecting keys without reading the manual and then ask why things don't work. Let me just give it a quick test....
***
To give us something to look at, here's a 12MHz crystal filter I put together using 101 data points. Sure looks like we could use more data....
***
So far it seems what I would expect. With basically steps of 1Hz, it's collecting VERY slowly. No reason to bitch as it's only $50. Running a segmented sweep like this with my old HP8754A would require a lot of manual setup. The Nano is far more advanced.
I must have put a limit on the number of data points. So I dialed it back and changed the range. Its no problem to increase the buffer size but I suspect people wouldn't want to wait.
It seems like it works as I would expect it to but that may not be how you expect it to work. One thing I am seeing is how the data seems to jump. It's possible this it a result of running newer firmware than what I had originally used. I would need to roll back.
-
Did you uninstall the wrong runtime first, or is it still install like I asked?
I didn't mess with the LabVIEW runtime at all. I assume I now have both 2020SP1 and 2011. When I look in the NI package manager I see NI-VISA 5.40.491.52 which wasn't there before. I am guessing that this is the runtime I actually needed.
One issue I probably have is that my NanoVNA firmware is very old and crappy. I will update it, likely with ttrftech/NanoVNA/releases/tag/0.8.0, once I have the update tools set up. Is this a reasonable firmware to choose? Is there a recommended firmware for an old original NanoVNA?
Thanks again.
-
The manual talks about my testing with one version and how other versions may cause random problems and a lot of wasted time. That firmware seems to be anything but stable. I'll reload the old image and see if it corrects this little snag. I tested the segmented mode with the V2+ and it wasn't a problem. Still, it could be my software.
-
I rolled back to the old firmware and tried running it without the PC. The problem remains. So it's been there at least a year. Not a big deal for me. Doing a quick search, I don't see anyone reporting it as a problem as well.
It appears that the segmented sweep times could be improved by a factor of about 2X (much in how the Zoom was improved). It would still be very slow. There also is a compare problem which should be corrected. I'm not seeing any other problems with it.
-
One issue I probably have is that my NanoVNA firmware is very old and crappy. I will update it, likely with ttrftech/NanoVNA/releases/tag/0.8.0
I now have edy555's 0.8.0 firmware on my NanoVNA. This is the version mentioned in the r15 manual.
I've gone through the segmented sweep again and I think it still is wonky. I am wanting to do a SWR across 420 to 480 Mhz in 5 Mhz segments and when I set that up and initiate a sweep, I can see the SWR graph display each segment in succession. This is not what I expected, but appears to be the design. Within each segment, the portion of the SWR curve looks reasonable. When all the segments are complete, the SWR chart finally shows the X axis covering the whole range, but the SWR curve is completely wrong, not resembling the individual segment curves at all.
I'll put some screen shots.
-
I noticed that I had forgot to enable port2 for polar transmission with the old Nano. So there's a few things that need attention. I've also had that firmware crash to where I had to power cycle the Nano to get it to recover. This is happened twice since I started testing with it.
Pictures would help.
****
I suggest you also provide as much detail as possible about the setup and procedure you are using.
Did you cal it first?
If so, what standards did you use?
What range did you cal over?
...
Every detail you provide will help me reproduce it.
-
I did calibrate it via the two port cal procedure. The calibration standards are total rubbish -- my objective is to characterise twisted pair and bits of bent wire for use with those cheesy 434MHz OOK radios. The setup is a female dupont connector soldered onto an SMA and the reference standards are a short and 50R metal film resistor soldered on a bit of 2.5mm header.
[attach=1]
The procedure for segmented sweeps is not perfectly laid out in the manual. Steps 2,3,4 below are set out, but not the rest. Here is what I did.
(1) toggle sweeps off
(2) enter span 10Mhz, press enter
(3) enter start 420Mhz, press enter
(4) enter top, 470Mhz, press enter
(5) press Segment. At this point the start and stop values begin to change, cycling through the required segments. I wait for them to stop changing.
(6) I press sweep and the start and stop values once again change, cycling through the required segments.
The displayed SWR/return loss chart updates for each segment and within the segment appear plausible. When the segment sweep is complete, the graph is drawn with the complete (or almost complete) X range specified. Most times the final graph is a total mess.
[attach=3]
Once I got the whole thing, sometimes I get all but the last segment like here.
[attach=2]
-
(1) toggle sweeps off
(2) enter span 10Mhz, press enter
(3) enter start 420Mhz, press enter
(4) enter top, 470Mhz, press enter
(5) press Segment. At this point the start and stop values begin to change, cycling through the required segments. I wait for them to stop changing.
(6) I press sweep and the start and stop values once again change, cycling through the required segments.
1) Why do you turn the sweeps off? Shouldn't matter, just curious.
6) Why are you running a normal sweep after the segmented sweep? I doubt the software will set things up right but you should notice that. Still that first segmented sweep should have been fine.
I did calibrate it via the two port cal procedure. The calibration standards are total rubbish -- my objective is to characterise twisted pair and bits of bent wire for use with those cheesy 434MHz OOK radios.
Did you calibrate it for the 420-470 range, 420-480 range, some other range? Want me to guess?
****
The partial is most likely the compare bug I mentioned. The scrambled may be a problem with the communications.
Showing my antenna simulator.
-
What I find interesting is the feel for needing higher resolution when looking at SWR. As I mentioned, I came up with the idea of sweeping in segments after trying to collect S-parameters for a crystal to make a model for SPICE. There you are working with a very narrow band. An antenna, not so much. Seems like it's just going to take longer to collect the data with little or any gains. That said, the V2Plus4 I bought can scan over a 1000 points without segmentation and the performance in this frequency range is much better than the old hardware. You may want to consider getting one.
Here's my antenna simulator at the standard 101 data points, using a 2MHz Span for 3001 data points and a Span of 500KHz for 12002 data points. I've heard that it's important to get that 3 places beyond the decimal as well... :-DD
If you really feel you need this feature, let me correct the problems I noted and try to improve the sweep times.
-
Did you calibrate it for the 420-470 range, 420-480 range, some other range? Want me to guess?
The calibration was over 384MHz-484MHz -- 434+/-50MHz
I did the sweep (6) because after the (5) segment, the graph never seemed to update. I stopped the sweep at the start because it seemed like the right thing to do. The manual doesn't say it should be sweeping or not prior to steps (2) (3) (4). I took a guess. Since the sweep seems to turn off after the segmented sweep and the graph gets updated/displays the final results, it seemed reasonable to guess that it should be off to start.
For grins I set up https://github.com/NanoVNA-Saver/nanovna-saver. Their approach to segmented sweeps seems more what I would have assumed. It is easy to configure and works alright with my unit. It can't do as much as your LabVIEW software, but what it does do, I find easier to figure out and more stable with an old original NanoVNA.
-
It's now available if you want to try getting your 12000 points of antenna data. You should find it to be a bit faster. Running from 1 to 300MHz with a 50MHz span required 1min 40 seconds with 1.08. This new version requires about 17 seconds. Other communications are faster as well and you may notice some commands are processed much faster.
I have corrected the polar transmission mode. Not sure how I missed that. When using segments, the software always sweeps to or past the stop frequency. It then truncates the data. Greater than or equal bug....
Because it seems you want to run multiple segmented sweeps back to back, the software now shows you a popup telling you to press the Sweep to reset the VNAs ranges and enable sweeps. It just saves you having to do this manually. For me, it was no big deal as I was only collecting a single sweep.
Not being able to replicate your problem with the firmware/hardware I have, I am not sure if this new version will have any effect on what you are seeing.
-
What I find interesting is the feel for needing higher resolution when looking at SWR.
Well I don't, really. Where I want more points is when I want to sweep from 100MHz to 500MHz and have the smith chart or the return loss chart look like something. With too few points, the curve shapes wind up with large aliasing artefacts and aren't useful. Once the bent wire, make-shift balun or section of twisted pair is in the ball park and I'm looking for tuning around the last 5MHz, the small number of points is fine.
With the nanovna-saver calibrations may be performed with a segmented sweep and have 1000 or more points to cover a large range of frequencies with enough points to keep artefacts somewhat at bay. It also lets me do single port calibration, which is what I want at this stage of the game.
-
What I find interesting is the feel for needing higher resolution when looking at SWR.
Well I don't, really. Where I want more points is when I want to sweep from 100MHz to 500MHz and have the smith chart or the return loss chart look like something. With too few points, the curve shapes wind up with large aliasing artefacts and aren't useful. Once the bent wire, make-shift balun or section of twisted pair is in the ball park and I'm looking for tuning around the last 5MHz, the small number of points is fine.
With the nanovna-saver calibrations may be performed with a segmented sweep and have 1000 or more points to cover a large range of frequencies with enough points to keep artefacts somewhat at bay. It also lets me do single port calibration, which is what I want at this stage of the game.
Not having ever tried it, I still have little doubt that the open source software would be much better suited for the radio hobbyist and general user. It was written for the public which is why I continue to suggest people use it.
I can understand the time required to measure the thru causes a loss in productivity over just performing the SOL. Of course, one could always press the OK button without the thru inserted to save those few seconds.
Here we have the simulated antenna being swept from 200MHz to 900MHz with 101 data points. The one thing to notice that there isn't enough data to see the range crossover noise but the area I would expect we are interested in is clearly visible.
******
Oh now I see the need. Those extra 34900 points made a huge difference. :-DD
-
Had to power cycle the old Nano again after the new firmware hung again. The noise at the transition was much worse than the old firmware. There have been some random glitches as well. Not to mention, I can speed things back up with it. The plan is to go back to the old firmware from RadioListener. It's archived somewhere in this thread if anyone is interested.
-
I am a little puzzled by segmented sweeps. With so few points in the built in frequency sweeps on the original NanoVNA, it seems that it would be useful to allow segmentation of sweeps for the "Main" tab -- SWR. Smith chart and so forth. But when I tried that, it looks like I get a sequence of charts, updating once for each segment, rather than a single chart with all the segments on it.
After reading this comment a second time, I wonder if there was an expectation that when using segmented sweeps that you get a concatenated view of the data while it is being captured. So the software would display all of the data captured up to the point of each segment. Easy enough to add but a pure guess on my part if adding it would be useful to anyone.
***
I tried it and personally like it, so it's in there.
-
I wonder if there was an expectation that when using segmented sweeps that you get a concatenated view of the data while it is being captured.
Yes, that was how I imagined it would work, before I first tried it. As I mentioned before, the appearance of the subcharts for different segments was not really how I pictured it working, but seemed to be according to design.
As it happens, NanoVNA-saver shows the same chart continuously during the sweep. You can see the effect directly on the chart as additional sweeps are made and averaged, and as additional segments are swept in succession. It's pretty well how I imagined it would work.
-
Mr. Smith,
Quick note to say that v1.10 will not work at 401 data points. v1.08 worked well and displayed the correct points value.
Switching the vna to 101 resolved the issue.
Peter
-
That new version my be more to your liking then if you wanted to try it. Still, I wouldn't spend too more time with it.
I had not given much thought how the segmented sweep should work when I wrote it over a year ago. I just knew I needed more data to run that particular demo.
https://youtu.be/v01lSgWo904?list=PLZSS2ajxhiQD2gftdurGQoyGpUM_HobNI&t=989
It's not a big deal to change the code. The problem is defining what it should do. For this particular software, that hasn't been a problem as I wrote it for my own use. Now that it is in the wild, I am open to making changes that would make it more useful to the general user.
Recently someone posted that Labview is crap and the serial ports don't work. Now that's some top notch feedback.
-
Mr. Smith,
Quick note to say that v1.10 will not work at 401 data points. v1.08 worked well and displayed the correct points value.
Switching the vna to 101 resolved the issue.
Peter
:-DD :-DD Yeah, this is what happens when I do a quick and simple change.
It's like my previous post. What are the exact settings you are using? Span, Start, Stop, Function?
When you say it does not work, what does it do?
Should be simple enough to fix if you can explain how to replicate it. If you can't, then I am left to guess..
-
Yeah.... I like shiny things.
Standard defaults..
10M centre
2M span
Start 1M
Stop 300M
Crystal fixture as usual. Bridge, ref, chn ref and throw in the crystal.
Waveform not visible, just noise.
Points box showing 101, but with v1.08 it would show 401.
The auto sensing of data points seems kaput.
Peter
-
What I see
(https://i.postimg.cc/0y4fTmWR/Clip-51.jpg)
What I expected to see
(https://i.postimg.cc/zfCvSFKJ/Clip-52.jpg)
-
Yeah.... I like shiny things.
Standard defaults..
10M centre
2M span
Start 1M
Stop 300M
Crystal fixture as usual. Bridge, ref, chn ref and throw in the crystal.
Waveform not visible, just noise.
Points box showing 101, but with v1.08 it would show 401.
The auto sensing of data points seems kaput.
Peter
Because you did not say, I am going to guess you are using the transmission function then.
I am sure I am missing something.
Are you using segmented mode? What steps did you perform with the old versus new software? You would need to made sure you detail this as the manual suggests, the order is important.
****
Ok transmission then.
Forget the new software for now. In 1.08, what exact steps did you take to get the 401 displayed?
-
Forget the new software for now. In 1.08, what exact steps did you take to get the 401 displayed?
Not a single thing. It auto detected it and worked flawlessly from the start.
-
Forget the new software for now. In 1.08, what exact steps did you take to get the 401 displayed?
Not a single thing. It auto detected it and worked flawlessly from the start.
Not a single thing? Really? Its not magic and certainly requires the human to do things. Guessing your steps will make it much more difficult.
You turned on the Nano with the fixture inserted and a crystal install. You started the software, selected your defaults file. You then selected link. Next you selected sweep. You are using normalize which I doubt magically was enabled so, you may have removed the crystal, installed the short, stored the reference then selected the CHn-Ref. Next you reinserted the crystal.
Of course I don't see what you have included because I am only guessing at what you have done.
-
Let me guess, you are playing with some new version of firmware which supports 401 data points and I was supposed to just know this.
-
Not a single thing? Really?
Really.
Same exact procedure with the different versions of software gives me different results.
No fixture, turn on the vna, then start the software and select defaults. Hit link and 1.08 will automatically update the data points to 401. Even if I use the 1.10 defaults. 1.10 just remains at 101.
And I am not pulling your plonker.
Peter
Same firmware that I informed you of a week ago. You even gave me an attaboy for documenting the firmware version.
-
Just a quick note.
My NanoVNA H4 arrived, I then loaded the latest Dislord firmware (1.0.53 with 401 data points) into it.
Lo and behold it behaves itself very nicely with Mr. Smith's software, which eats up the extra data with ease.
3D charts take a little longer to display, but that would be expected.
Good to know. Also smart idea to document the firmware.
-
Just saying that something has changed between 1.08 and 1.10.
-
Not a single thing? Really?
Really.
Same exact procedure with the different versions of software gives me different results.
No fixture, turn on the vna, then start the software and select defaults. Hit link and 1.08 will automatically update the data points to 401. Even if I use the 1.10 defaults. 1.10 just remains at 101.
And I am not pulling your plonker.
Peter
Same firmware that I informed you of a week ago. You even gave me an attaboy for documenting the firmware version.
So you have gone back to the problematic firmware that I gave you an attaboy for telling us what not to use? Last I knew:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3525476/#msg3525476 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3525476/#msg3525476)
Which is why all your earlier screen shots show 101 data points up until now. At least we now know what has happened.
Just saying that something has changed between 1.08 and 1.10.
Of course it did. Did you think I roll the version for the fun of it?
The way the Nano works, there is a command to request the frequencies that it uses. In my early versions of the software, I would request the frequency, then the two data sets. To speed things up, I would request only the first data set if I was using S11. Later I only requested the frequencies when I changed one of the setting that would effect it. Again, to increase the speed.
When the V2+ came out, they were smart enough to do away with all that. It's up to the software to calculate the table. When I went to a common code base, I had left the frequency request in there. The number of elements the Nano returns is the number of data points I used.
Now we want to sweep / zoom faster. Simple solution, ditch that frequency command. The Nano has always used 101 data points, so lock it down and calculate the tables like how the V2+ works. This is much faster as we don't have to wait for the Nano to send us that data.
This works fine with the 1.08 firmware which at least defaults to 101 data points. Of course, if you use firmware that has a different number of data points, its not going to magically use them. It's not just the number of data points that are a problem, the frequencies the software calculates would be wrong as well.
They may have added similar commands as the V2+ that allows you to program in the data points. You can imagine the nightmare this firmware mess can cause. This is why the manual provides a link to the version I tested with.
The software was tested with the following firmware.
https://github.com/ttrftech/NanoVNA/releases/tag/0.8.0 (https://github.com/ttrftech/NanoVNA/releases/tag/0.8.0)
An attempt was made to test hugen79 1.0.45 NanoVNA-H_20210130.dfu which caused random errors in the data. This was something that was found early on when I first started to look at the NanoVNA. Sadly, a year has passed and the firmware is still unstable.
The fact you have gone back to that version tells me there is some feature it has that is worth having bad data.
-
So you have gone back to the problematic firmware that I gave you an attaboy for telling us what not to use?
No, this is my new Nanovna H4 with firmware that gives up to 401 data points.
It worked fine with 1.08. It was nice to have a well rounded Smith Chart.
Of course it did. Did you think I roll the version for the fun of it?
OK... I left myself open to that one.
Of course, if you use firmware that has a different number of data points, its not going to magically use them. It's not just the number of data points that are a problem, the frequencies the software calculates would be wrong as well.
I've certainly seen a few Hz difference from 101 to 401 testing crystals, but v1.08 does appear to be crunching the greater numbers. Whether accurate ... only you would know.
The fact you have gone back to that version tells me there is some feature it has that is worth having bad data.
Different beastie altogether.
(https://i.postimg.cc/vH8mN7Y0/vnas.jpg)
-
There are a few things that could be done.
1) Obviously, do nothing requires the least effort. Just stay with the old software.
2) Add the frequency command so the table is scanned upon connecting. It would need to be done before the Span and Center are set. It would work for a while but someone would have the bright idea to remove the command and break the software again.
3)The software for the V2+ is user settable. I have no idea if your new firmware supports a command like that or not. The problem with this approach is people are not going to be smart enough to know how many points they need to set it to.
4)It's easy enough to stay with the old method, but it's too slow if you want to use the segments and like the first approach, may brake in the future.
5)Another option would be to lock the software to a version of firmware.
Maybe there are other options. I get the feeling that the firmware will continue to cause problems. I'm thinking option 3. If they remove the command in the future, I don't care as I no longer use it. It is just that closer to the V2+ software. It could be saved in the defaults file for both flavors of software. And again, lets not forget the reason I ditched that frequency command was for the speed.
The other problem with option 3, people will think they can set the Points to what ever number they want. They may think it has something to do with segmented sweeps. Option 2 is looking better....
-
There are a few things that could be done.
1) Obviously, do nothing requires the least effort. Just stay with the old software.
That sounds right up my street.
2) Add the frequency command so the table is scanned upon connecting. It would need to be done before the Span and Center are set. It would work for a while but someone would have the bright idea to remove the command and break the software again.
I wouldn't have a clue where to begin.
3)The software for the V2+ is user settable. I have no idea if your new firmware supports a command like that or not. The problem with this approach is people are not going to be smart enough to know how many points they need to set it to.
I would have to include myself in the not smart enough group.
4)It's easy enough to stay with the old method, but it's too slow if you want to use the segments and like the first approach, may brake in the future.
I spent the best part of the day re-reading this thread in search of radiolistener's elusive firmware. I think he has deleted most of his links, but think I found his github (https://github.com/qrp73/NanoVNA-Q), as the dates seem to be about right.
I'm willing try it out in my first little nano, in the hope of replicating your setup.
5)Another option would be to lock the software to a version of firmware.
Firmware takes moments to change. I wouldn't mind that in the slightest.
Maybe there are other options. I get the feeling that the firmware will continue to cause problems. I'm thinking option 3. If they remove the command in the future, I don't care as I no longer use it. It is just that closer to the V2+ software. It could be saved in the defaults file for both flavors of software. And again, lets not forget the reason I ditched that frequency command was for the speed.
Speed is nice, accuracy even better, but I wouldn't know what to do with either.
Peter
-
If we go with option 3 and save it to the defaults, it certainly makes the code cleaner. It could be a pull down menu to force 101 or 401. Then again, the firmware will then break it in the future. So keeping it flexible would make more sense. Use the default of 101, but just allow you you change it.
Of course, in cases where people have a Nano fetish, they may want one default file for their entire collection. :-DD There was a person who had bought five of them and I think they wrote they had damaged three.
Yes, that looks like their code. A shame that the people doing the large releases didn't follow suit. That code has problems as well but I am not having to power cycle the Nano with it, no random jumps in the data, it's faster and the range change transitions are cleaner.
If you want to try it with a programmable points setting like the V2+, let me know. A few minutes and we could have it in there.
****
Because the V2+ has a programmable number of data points, I store this with each calibration. When you load a calibration, it sets up the VNA's defaults.
I do the same thing with the original Nano. I don't think this would be a problem as I doubt you would try and use the same calibration files from one version of the firmware to the next.
-
The manual and both programs have been updated. You will need to manually set the number of data points and save your defaults for it to stick.
-
Morning Mr. Smith,
In v1.11 I adjusted the points box to 401 (highlighting and inputting from the keyboard) and saved to defaults. Restarting shows 401, but as soon as I link, it jumps back to 101. Again putting 401 in the box while linked, as soon as I click on a parameter it again jumps back to 101.
I tried changing the numbers with the up/down icons and it made no difference.
I tried calibrating and saving, no joy.
101 points works exactly as advertised.
Am I missing something other than grey matter?
Peter
-
Remember how I posted about hard coding the number of data points to 101? Well, I never removed that initialization. Of course, this causes no problems with the old firmware as I am expecting it to be 101. :-DD Testing the software will continue to be a problem as people diverge from the original hardware / firmware.
-
Remember how I posted about hard coding the number of data points to 101?
No. I must have been drunk.
Well, I never removed that initialization.
V1.08 would beg to differ.
Of course, this causes no problems with the old firmware as I am expecting it to be 101.
Of course.
Testing the software will continue to be a problem as people diverge from the original hardware / firmware.
I can live with 101. Less data to crunch, but I know it's there if I need it.
Peter
-
Remember how I posted about hard coding the number of data points to 101?
No. I must have been drunk.
Well, I never removed that initialization.
V1.08 would beg to differ.
Of course, this causes no problems with the old firmware as I am expecting it to be 101.
Of course.
Testing the software will continue to be a problem as people diverge from the original hardware / firmware.
I can live with 101. Less data to crunch, but I know it's there if I need it.
Peter
Life didn't start or end at software v1.08. I thought I had made it clear in this post the steps I had taken AFTER 1.08 to improve the speed but you didn't seem to follow.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3552000/#msg3552000 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3552000/#msg3552000)
Simple solution, ditch that frequency command. The Nano has always used 101 data points, so lock it down and calculate the tables like how the V2+ works.
In other words, 1.09 hard codes the initialization. I thought it would be understood that this hard coded initialization is what my comment referred to. Version 1.11 allows the user to change the points setting but the software would still initial it to 101 data points. Again, because it may not be clear, version 1.11 is after 1.08. Version 1.12, which is also after 1.08, removes this initialization. Because you seemed to miss it, prior to 1.09 which includes 1.08, the software would initialize the number of point by sending the frequency command. This command is no longer in use.
If the firmware being used with software 1.09-1.11 has anything other than 101 data points, it's going to cause a problem.
-
I thought I had made it clear in this post the steps I had taken AFTER 1.08 to improve the speed but you didn't seem to follow.
I'm just miffed that you would take my precious points away. The naughty step is a lonely place.
because it may not be clear, version 1.11 is after 1.08
I'm not buying that. Surely some mistake on your part. Hic.
Version 1.12, which is also after 1.08
Now you're just being ridiculous and it's mean of you to confuse someone with dyscalculea.
Sniff
-
Well would you believe it. The one that comes after 1.11, you know the one, now works.
Mr. Smith... may you live for a thousand years.
Cheers
Peter
Spoke a little prematurely.
101 points behaves correctly, but 401 throws a minor wobbly.
Zoom goes though its motions with angular waveforms and shifts right at the 500Hz step.
Hitting peak center does not set it back.
What comes after 12?
-
Sadly, once again I am given little data. Maybe it's to the right 100Hz. Maybe 10Hz. Maybe 1. Wit the technology available to us today where we can easily do screen captures, its still a problem.
Oh well, I don't have the hardware to test it anyway and with firmware that places random errors in the data sets, it may not be useful to even try and sort it out. Your call. You want me to look at it, provide some actual data.
Don't tell me the car pulls to the right. Show me a picture so I can see the front wheel is missing....
Also, it would have been helpful to know if you could replicate the problem with the old hardware and the version of firmware I tested with.
*****************
Also, it would have been helpful to know if it 1.08 zooms correctly when using the new 401 data point Nano.
*****************
Also, you may want to make sure that it's not some sort of resolution problem with your new firmware/hardware. You know the original firmware firmware was 101 data points. You know the software zooms into a span of 500Hz. So you can calculate the step size. You can also calculate the step size for your new configuration. You could then test the step size to see if its acceptable.
*****************
101 points behaves correctly, but 401 throws a minor wobbly.
I am not even sure what this comment means. Are you running the new configuration with the 401 points but then setting the software to 101 and suggesting that behaves correctly? Or are you running the original hardware with the firmware I tested with and that behaves correctly?
-
Good Morning Mr. Smith,
Sadly, once again I am given little data.
You scientists and your bloody data.
Here we go then.
Kindly assume that these experiments are all carried out by a monkey under duress.
All will be with your software version 1.12 and are with the standard procedure for crystal measurement, up to and including zooming the waveform.
Start up defaults 10M centre, 2M span, 1M start-300M stop.
The first slide please, Mrs. Coldheart.
Old hardware with eddy 0.8.0 firmware.
No problems whatsoever, Exactly as I expect it to perform.
(https://i.postimg.cc/Kv5RqLQp/1.jpg)
Old hardware with radiolistener's 0.4.4 firmware.
First zoom attempt missed the mark by 500k and did not recover.
Yes the crystal was plugged in and no I wasn't distracted by something shiny.
(https://i.postimg.cc/3wCHFC3n/2.jpg)
Second zoom attempt grabbed it nicely.
(https://i.postimg.cc/QMpWgPBw/3.jpg)
Now on to the fun stuff.
New H4 hardware with Dislord's 1.0.53 firmware, with 51-101-201-301-401 data point choices.
101 data points set.
First attempt was much the same as the first with radiolistener's. I forgot to take a screenshot (because I was distracted by something shiny) and the second attempt behaved as would be expected.
(https://i.postimg.cc/3rpSzrsD/4.jpg)
401 data points set.
The waveform 'throwing a wobbly'. It's not consistent, but disforms half a dozen times throughout the zoom process.
(https://i.postimg.cc/4NnCKHnH/5.jpg)
This is where we end up after it kicks to the right at the 500Hz step.
Cursor centre set. Cur B-Cur A shows -29.
(https://i.postimg.cc/639WF6cV/6.jpg)
Also, it would have been helpful to know if it 1.08 zooms correctly when using the new 401 data point Nano.
Indeed it does.
Also, you may want to make sure that it's not some sort of resolution problem with your new firmware/hardware. You know the original firmware firmware was 101 data points. You know the software zooms into a span of 500Hz. So you can calculate the step size. You can also calculate the step size for your new configuration. You could then test the step size to see if its acceptable.
I'm sorry, but anything containing the word 'calculate' frightens the life out of me. Simple arithmetic is within my ability, but I'm still in the dark. Could you rephrase your last paragraph for a child.
Are you running the new configuration with the 401 points but then setting the software to 101
No. I set the vna to whatever points I'm using, then change the software to match before linking.
1.08 would detect whatever the vna was set to and change automatically.
Or are you running the original hardware with the firmware I tested with and that behaves correctly?
I refer you to my previous answers.
Peter
-
Just to add to the last screenshot.
Pressing peak centre has no effect at pulling the waveform back.
On this test CurB-CurA is showing -50.
(https://i.postimg.cc/fTHmfKmC/7.jpg)
-
Old hardware with radiolistener's 0.4.4 firmware.
First zoom attempt missed the mark by 500k and did not recover.
I've ran into this as well, even with the newer firmware. I suspect its a result of my trying to speed the zoom process up.
401 data points set.
The waveform 'throwing a wobbly'. It's not consistent, but disforms half a dozen times throughout the zoom process.
If you manually zoom in using the software (setting the span and center), do you get the same effect? Can you replicate it without the PC attached? (I am guessing you could)
No. I set the vna to whatever points I'm using, then change the software to match before linking.
1.08 would detect whatever the vna was set to and change automatically.
There's a new bit of info I did not have before. I had assumed it was fixed at 401. Of course I've covered the difference of how 1.08 worked compared with the newer versions and the reasons for the change and won't repeat it a third time. Yes, it's different. If your too old for a trophy, would you like a gold star?
Also, it would have been helpful to know if it 1.08 zooms correctly when using the new 401 data point Nano.
Sadly I am left to guess if this actually zooms in correctly or not. All I know from your previous statement is that it picks up the number of points automatically.
The fact the software can't tell your Nano to move the peak to the center, seems to point to something with the firmware. Again, you should be able replicate this without the PC.
-
If you manually zoom in using the software (setting the span and center), do you get the same effect?
Exactly the same. Warped waveform shapes and stuck 50Hz right. Unable to centre.
(https://i.postimg.cc/mDX2DMVr/8.jpg)
Can you replicate it without the PC attached? (I am guessing you could)
I can't.
If I turn off the software and re start the vna, then use the span to zoom in increments, the final 500Hz step is solid.
If you're too old for a trophy, would you like a gold star?
Yes please, Sir.
-
Sadly I am left to guess if 1.08 actually zooms in correctly or not.
Answered, but yes it does.
-
If you manually zoom in using the software (setting the span and center), do you get the same effect?
Exactly the same. Warped waveform shapes and stuck 50Hz right. Unable to centre.
Can you replicate it without the PC attached? (I am guessing you could)
I can't.
If I turn off the software and re start the vna, then use the span to zoom in increments, the final 500Hz step is solid.
If you're too old for a trophy, would you like a gold star?
Yes please, Sir.
You mention the centering problem and you read that I asked you to try and replicate it without the PC. I am not sure if you actually started the Nano with no PC, set the span to 500Hz, set the center for 9.9974MHz as your graph shows, saw the same peak location, and assuming you did, entered a center of 9.997446MHz and saw the peak center. Maybe it moved. Maybe it didn't. Maybe you didn't try it. I don't have a crystal ball. If you want a gold star, you're going to have to step up your game. Don't try and out guess what I am asking by entering 9.9974 and thinking that is good enough. You need to use the same settings that the software is using.
Jot down the center and spans where you have noted the odd shapes and enter them in manually as well.
Sadly I am left to guess if 1.08 actually zooms in correctly or not.
Answered, but yes it does.
So we are clear, 1.08 will zoom in correctly with 401 data points? Or are you saying that 1.08 will zoom correctly with the old firmware and 101 data points?
-
You mention the centering problem and you read that I asked you to try and replicate it without the PC.
And because you asked so nicely, I did just that.
I am not sure if you actually started the Nano with no PC
I did and also shut down the nano and restarted.
set the span to 500Hz, set the center for 9.9974MHz as your graph shows, saw the same peak location, and assuming you did, entered a center of 9.997446MHz and saw the peak center.
(nano only)As the software was off and I wasn't looking at any pictures, I would have to put on a peak marker and centre to that frequency.
If you want a gold star, you're going to have to step up your game.
I'm thinking of settling for the bronze.
You need to use the same settings that the software is using.
400k-60k-16k-3.2k-640-500. Done.
Jot down the center and spans where you have noted the odd shapes and enter them in manually as well.
Software 1.12
400k-hit peak centre, no worries
60k-hit peak centre, no worries
16k-waveform deformation-hit peak centre fine
3.2k-hit peak centre-not moving, but could be because it really is centered
640- mild deformation, hit peak centre jumped 50Hz left of centre
500-stays at 50Hz left of centre-hit peak centre jumped to 30Hz right of centre
I need a Whisky... Oh look, there's a bottle of Grant's.
-
So we are clear, 1.08 will zoom in correctly with 401 data points?
YES
Or are you saying that 1.08 will zoom correctly with the old firmware and 101 data points?
Probably also yes.
-
set the span to 500Hz, set the center for 9.9974MHz as your graph shows, saw the same peak location, and assuming you did, entered a center of 9.997446MHz and saw the peak center.
(nano only)As the software was off and I wasn't looking at any pictures, I would have to put on a peak marker and centre to that frequency.
You can't type in the center frequency from the menu?
Jot down the center and spans where you have noted the odd shapes and enter them in manually as well.
Software 1.12
400k-hit peak centre, no worries
60k-hit peak centre, no worries
16k-waveform deformation-hit peak centre fine
3.2k-hit peak centre-not moving, but could be because it really is centered
640- mild deformation, hit peak centre jumped 50Hz left of centre
500-stays at 50Hz left of centre-hit peak centre jumped to 30Hz right of centre
So you're plugging these numbers in without the PC using just the Nano and seeing deformation? Or are you using my software to manually enter them?
The fact it seems to work with 1.08 and how you are seeing these odd spaced jumps when zooming, I am leaning towards some sort of rounding problem with the Nano's firmware. Again, 1.08 is asking for the table and working from that rather than telling the Nano what to do. If there is a problem with the resolution 1.08 would mask it.
Sort out how to enter the set points from the menu, then maybe you can help answer this.
-
You can't type in the center frequency from the menu?
I could, but just centered the marker frequency. I'm slow.
So you're plugging these numbers in without the PC using just the Nano and seeing deformation?
Two different tests
Just the nano (no pc) when manually inputting the frequencies, no deformation.
In software when manually inputting the frequencies, the odd deformation.
The fact it seems to work with 1.08 and how you are seeing these odd spaced jumps when zooming, I am leaning towards some sort of rounding problem with the Nano's firmware. Again, 1.08 is asking for the table and working from that rather than telling the Nano what to do. If there is a problem with the resolution 1.08 would mask it.
I don't know if this is of any help, but the frequency jumps while zooming are the same in 1.08 and 1.12.
Sort out how to enter the set points from the menu, then maybe you can help answer this.
Are you talking about setting centre frequency on the nano? Or set the data points in software?
I might be having a stroke.
-
" but the frequency jumps while zooming "
Are you referring to the center and span being the same between the two versions? If so, that would make sense.
Sort out how to enter the set points from the menu, then maybe you can help answer this.
Are you talking about setting centre frequency on the nano? Or set the data points in software?
Nothing to do with software. I am interested in seeing what problems you run into when using the Nanos firmware.
I might be having a stroke.
I'm not sure why. You read the manual enough to provide some feedback on it.
Those wanting to use this software with the original NanoVNA need to be aware that the poor quality of firmware and cloned hardware may cause a lot of wasted time. You’re on your own.
This software can be viewed as an engineering tool at best. Its primary use was to extend the author's understanding of V2+. It was never intended to be used as a general tool for radio hobbyist’s to tune their antennas. The software is fairly buggy and not very robust. Even under normal conditions, expect to run into several problems if attempting to use this software. It’s a very poor choice for the beginner.
You made a choice to run unsupported hardware and firmware and then bring it up. I made the choice not to ignore you. And so, here we are... Having some fun... lol.
So you're plugging these numbers in without the PC using just the Nano and seeing deformation?
Two different tests
Just the nano (no pc) when manually inputting the frequencies, no deformation.
In software when manually inputting the frequencies, the odd deformation.
I wonder if the firmware will round when data is entered with the keypad but fails when you send it the command.
Sadly, I think the only way to sort it out would be to try and replicate your setup. You like playing with firmware. Can you take that firmware and run it in old hardware? Do you even have the old hardware to try it? If that works, point me to where the hex or binary image can be found and I will try and load it into mine.
-
Are you referring to the center and span being the same between the two versions? If so, that would make sense.
I merely observed the frequency stops when zoomng. Those six frqs are the same between versions. So, yes.
Nothing to do with software. I am interested in seeing what problems you run into when using the Nanos firmware.
OK...
You made a choice to run unsupported hardware and firmware and then bring it up. I made the choice not to ignore you. And so, here we are... Having some fun... lol.
I'm having a blast... is that what the kids are saying today? I've never written so much, I might write a book.
-
Sadly, I think the only way to sort it out would be to try and replicate your setup. You like playing with firmware. Can you take that firmware and run it in old hardware? Do you even have the old hardware to try it? If that works, point me to where the hex or binary image can be found and I will try and load it into mine.
-
I tried an earlier version of Dislord's firmware in my first nano in the hope of upping the points count, but no joy.
My newer nano H4 has a slightly different processor that allows the 401 points.
As for sorting out my problems... I don't have any with 1.08. It's only the later versions giving me grief. I'm more than happy to stick with it.
https://groups.io/g/nanovna-users/files/Dislord%27s%20Nanovna%20-H%20Firmware for all of Dislord's firmware.
-
My newer nano H4 has a slightly different processor that allows the 401 points.
That makes sense.
It's odd the frequencies would be identical but 1.08 works and 1.12 does not. It's possible that it has nothing to do with the added number of points. I wonder with 1.12 being faster if that is causing the problem with your new hardware. Hard to believe a new processor and the latest firmware can't keep up over a slow serial connection but maybe. When you select 400 data points, it pushes the timing over the edge. 1.08 was much slower.
We could try 1.13 - 1.21 (figure it would take at least that many attempts) of trial and error. Another option that may actually be faster would be replicate your setup. Of course, that do nothing option is always there as well. If you want to try some random guessing, I can upload a new version in a few minutes.
***
Go ahead and provide me with the purchasing info for your exact hardware as well. If you have modified yours in any way, I want that information as well.
***
1.13 is live if you want to try it. Step one, turn off the data while changing the frequency.
-
You make em... I'll test em.
My H4 was bought from these chaps...
https://www.aliexpress.com/item/1005001548276258.html?spm=a2g0s.9042311.0.0.3cef4c4dXTxMXT (https://www.aliexpress.com/item/1005001548276258.html?spm=a2g0s.9042311.0.0.3cef4c4dXTxMXT)
No modifications by me, but the photos I've seen online show my display is slightly different with its connection.
The only thing I have done is put it on a stand.
(https://i.postimg.cc/pV50YRQy/h4s.jpg)
-
Step one, turn off the data while changing the frequency.
Not entirely sure what you mean by this.
Just tried it as normal. More deformed waves and ending up 30Hz to the right of centre.
Need some sleep, but expect you'll have 14 by the time I wake up.
Toodle pip.
-
Step one, turn off the data while changing the frequency.
Not entirely sure what you mean by this.
Just tried it as normal. More deformed waves and ending up 30Hz to the right of centre.
Need some sleep, but expect you'll have 14 by the time I wake up.
Toodle pip.
Explain what is meant by "normal"?
Did you try both 101 and 401? Does 101 still work?
Change the Refresh time from 200 to 600 and the PgmTimeout from 1200 to 1800 and let me know if it has any effect. There may be more than one problem. That centering sure sounds like a resolution problem but if you say it works fine with the menus, maybe not. No point in wasting too much more time with it.
You should plan on staying with 1.08 for now. It will take some time for the VNA to show up. I will still need the Github link for the exact same firmware image you are using.
-
Morning,
Explain what is meant by "normal"?
Because you didn't explain what "Step one, turn off the data while changing the frequency", I didn't do it, so ran the normal test.
Did you try both 101 and 401? Does 101 still work?
Last night only 401, but this morning tried 101 and 101 works well.
Change the Refresh time from 200 to 600 and the PgmTimeout from 1200 to 1800 and let me know if it has any effect.
None, or at least none that I noticed. Waveform still ends up to the right of centre.
No point in wasting too much more time with it.
Agreed.
One other thing that I forgot to mention is that all versions after 1.08 (in the SetupDiagnostics page info box), only displays 'the quick brown fox', whereas previous versions have all the nano info.
Might be something.
Peter
-
Morning,
Morning.
Explain what is meant by "normal"?
Because you didn't explain what "Step one, turn off the data while changing the frequency", I didn't do it, so ran the normal test.
You may have noticed that this was the same comment in the readme file for that release. It's not instructions for you to follow, its documenting what has been changed. More so for my own benefit. The manual now contains a Software version section that I will maintain, at least internally, to help keep track of the development.
>>>Just tried it as normal.
>>Explain what is meant by "normal"?
>Because you didn't explain what "Step one, turn off the data while changing the frequency", I didn't do it, so ran the normal test.
:-DD :-DD :-DD
Ok, it's clear with your circular explanation of what normal is, you're not sure, which is normal.
Did you try both 101 and 401? Does 101 still work?
Last night only 401, but this morning tried 101 and 101 works well.
Good info.
Change the Refresh time from 200 to 600 and the PgmTimeout from 1200 to 1800 and let me know if it has any effect.
None, or at least none that I noticed. Waveform still ends up to the right of centre.
More good info.
No point in wasting too much more time with it.
Agreed.
One other thing that I forgot to mention is that all versions after 1.08 (in the SetupDiagnostics page info box), only displays 'the quick brown fox', whereas previous versions have all the nano info.
Might be something.
Certainly a possible clue. Some firmware does not report any info. If you run the terminal menu and select the info command does it send anything back?
No matter. Once the hardware arrives and you provide a link for the exact firmware you are using, I can take it from there.
In the mean time, I suggest you get a pull test jig finished so we can start to validate some of your results.
-
Ok, it's clear with your circular explanation of what normal is, you're not sure, which is normal.
Nothing is as it seems.
If you run the terminal menu and select the info command does it send anything back?
It does. Fills the info box with what I would expect to see.
Tried running another crystal test, but same right of centre result.
In the mean time, I suggest you get a pull test jig finished so we can start to validate some of your results.
I'll get on it. Cough.
Peter
-
Afternoon,
I think I may have inadvertently made this...
(https://i.postimg.cc/2jXRdq0r/arrl.jpg)
(https://i.postimg.cc/KzvwBFL1/xtest.jpg)
You're going to tell me to start reading some lengthy paper now, aren't you.
-
Looks good. Do you know how to use it? If not....
Because the person who first asked me about making this measurement had brought up the Dishal software, this is what I used. I used version 2.0.5.2. This has support built-in for that pull test. There is a decent help file for it.
In my case, I used my old HP5328A counter. I have a GPS that runs 24/7 for the time reference.
Running the 1.08 software and working firmware (if you can find one) you should be able to compare Lm, Cm and Fs. For Cp, I just used my RLC meters to compare results.
Make sure the parts are stable before you measure them. I noticed that the 0.8.0 firmware would still glitch which is why I went back to what I know works.
-
Evening,
Do you know how to use it?
Of course not, but finally got some numbers out of it. Missed a couple of connections.
I don't have a counter with a reference in, so will have to make do with what I have.
Browsing the 'crystal test set' pdf you linked mentions this in regard to the G3UUR circuit...
Although this circuit is useful for general
purposes, it is terribly inaccurate for those
performing demanding design tasks such as
narrow-band crystal filters.
That, plus a probably inaccurate counter might just be a waste of your time and mine.
Talk me out of it.
Peter
-
Evening,
Do you know how to use it?
Of course not, but finally got some numbers out of it. Missed a couple of connections.
I don't have a counter with a reference in, so will have to make do with what I have.
Browsing the 'crystal test set' pdf you linked mentions this in regard to the G3UUR circuit...
Although this circuit is useful for general
purposes, it is terribly inaccurate for those
performing demanding design tasks such as
narrow-band crystal filters.
That, plus a probably inaccurate counter might just be a waste of your time and mine.
Talk me out of it.
Peter
Not sure why you feel that's my job. If you have things you would rather be doing, I am perfectly fine with that.
-
Not sure why you feel that's my job.
You threw me into this quagmire, at least throw me a rope.
-
Not sure why you feel that's my job.
You threw me into this quagmire, at least throw me a rope.
No, you make your own choices. While I have some of my own time invested in your project (my choice) I have no problem stopping the efforts if that is what you would like to do.
-
Good grief, Mr. Smith, ... I merely suggested that my setup was possibly inadequate.
I'm not going to let you abandon the last few weeks of interaction because of a misunderstanding.
Have a smoke if you've got em... pour yourself a whisky and I'll pop back in after I've committed my mother to the flames.
Peter
-
Good grief, Mr. Smith, ... I merely suggested that my setup was possibly inadequate.
I'm not going to let you abandon the last few weeks of interaction because of a misunderstanding.
Have a smoke if you've got em... pour yourself a whisky and I'll pop back in after I've committed my mother to the flames.
Hopefully you understand that this is my choice to make.
I didn't think it was going to be such a big deal for you to run the test and post your findings.
-
Hopefully you understand that this is my choice to make
Sure, but leaving a destitute orphan to navigate the wilderness is cruel.
Besides, you've just ordered a new gizmo and you have to at least tell me I'm a bellend for even ordering it.
Peter
-
Well, accuracy aside, I did some mathematics and came up with...
Cm 9.0616fF. Software 1.08 came up with 9.6216fF.
Lm 27.98mH. Software 1.08 came up with 26.33mH.
Would this be considered a validation?
-
Hopefully you understand that this is my choice to make
Sure, but leaving a destitute orphan to navigate the wilderness is cruel.
Besides, you've just ordered a new gizmo and you have to at least tell me I'm a bellend for even ordering it.
I see people buy all sorts of things for various reasons. What you spend your money on is really your choice. I have no use for this VNA outside of seeing why my software isn't working with what ever flavor of the day firmware you are trying to use. I had no plans to support anything beyond the original hardware and firmware called out in the manual.
Well, accuracy aside, I did some mathematics and came up with...
Cm 9.0616fF. Software 1.08 came up with 9.6216fF.
Lm 27.98mH. Software 1.08 came up with 26.33mH.
Would this be considered a validation?
I have no way to know what you did unless you provide the details? What did you use for CSW? How did you derive it? Guess? Saw something on the internet? Don't think it matters? Guessing gets old.
It does seem like what ever you are doing is causing a fair amount of error.
-
I have no way to know what you did unless you provide the details?
Here we go...
I measured the crystal with S1 and S2 closed (crystal to ground) and got a number.
I then measured with S1 open (through Cs) and got another number.
Punched these numbers into some formulas and got some other numbers.
Mathematics is not my thing, so could easily have made a mistake.
The formulas were this lot and are not my numbers...
(https://i.postimg.cc/MTkRZzDT/Clip-57.jpg)
My numbers were...
fgnd 9997742
fopen 9998439
Cs 62pF
Co 2.99pF
Delta f 697
What did you use for CSW? How did you derive it?
Cs was 62pF. W? Not a clue. Measured at 10M on the vna.
It does seem like what ever you are doing is causing a fair amount of error.
Again, mathematics is not my thing.
-
I thought the software made all the calculations for you. You just had to plug in the values you read from your equipment.
There was a pretty good help file for it and I would have assumed you read it.
What did you use for CSW? How did you derive it?
Cs was 62pF. W? Not a clue. Measured at 10M on the vna.
How did you connect it? If you use your RLC meter and replicate my steps, then what do you get?
-
I thought the software made all the calculations for you.
Now that you mention it... cough.
(https://i.postimg.cc/Pfp4szGX/dish.jpg)
Pretty much bang on to what the vna reports.
Software 1.08 came up with 9.6216fF
Software 1.08 came up with 26.33mH
-
I could believe those numbers. My problem was I never had a way to prove the absolute accuracy, which is where that standard crystal would have been nice to have.
-
Same crystal, different day.
1.08 software, 401 data points, 650 sample crystal sweep.
(https://i.postimg.cc/PqyrnDLj/401650.jpg)
Input software reported Co of 2.49pF into dishal calc.
(https://i.postimg.cc/d0VD1nc1/dish249.jpg)
-
Looks like the VNA will arrive sometime next month. In the mean time, I have removed the newer versions of the software and have left 1.08 based on your claims of it being more compatible with other hardware/firmware. You may not be the only person trying to run unsupported combinations of firmware and hardware. While the newer software is much faster running segmented sweeps, I have only seen one person ask about it. With them now using the open source software, I consider it a very low priority. Reading the groups, you get a feel for how unstable the software/firmware/hardware combos are.
I would imagine if you ran some sort of repeatability study, you may get a better feel for how stable the readings are. That seems like a deep rabbit hole. Much more effort than just collecting some data off your new fixture which was already a stretch. You could just play with that software to try and see how these errors would effect the filter you are trying to design.
-
I would imagine if you ran some sort of repeatability study, you may get a better feel for how stable the readings are.
OK. Exact same everything, say 10 times and jot down any differences. I can do that.
Probably prudent to restart software and hardware between each pass.
Peter
-
Achieving the exact same conditions will be impossible.
I doubt restarting the PC, software, or VNA would do much beyond adding the time required to run it. The VNA will drift and would rather be just turned on and running.
Depending what you want to learn, you could try different firmware. Glitch free stable versus the current versions. Leave the cables attached and the crystal plugged in, not touching anything. Maybe even put a towel over it to minimize the effects of air currents. Or maybe you want to try swapping the same crystal in for each test. Or maybe even reinsert the cables for every test. You could try with them torqued vs hand tightened. At the frequencies you are running, finger tight should be fine and I doubt you would see a difference unless you were being very sloppy.
You could play with the software to determine what sort of sample size you need. Time to blow the dust off that stats book.
-
Time to blow the dust off that stats book.
A bit short of breath these days, but I'll get as much done as I can.
-
Another option, now that the data is within reason between your pull fixture, RLC meter and Nano, is try to measure your bag of parts and build up the filter you are after.
-
Another option, now that the data is within reason between your pull fixture, RLC meter and Nano, is try to measure your bag of parts and build up the filter you are after.
I could do that. I got most of the way through the 50 using the old hardware, so I might just finish them off with the same. The fixture is new, but using the components from the old. I'll compare some results to see if I have to rebuild the old.
-
First attempt at a 5 pole jobbie. Needs some fyne choo ning (correct capacitors) , but joeqsmith's software, coupled with the Dishal software certainly gets you right in the ballpark.
(https://i.postimg.cc/k49X6nTn/5p.jpg)
-
Sounds like you have made some good progress with your filter.
After trying to measure an RF capacitors ESR, I was attempting to use the shunt through method to read a 100uOhm resistor. After designing a custom common mode transformer, I was able to get something sort of close.
https://www.eevblog.com/forum/rf-microwave/impedance-measurement-with-vna-using-series-shuntseries-through-methods/msg3546156/#msg3546156 (https://www.eevblog.com/forum/rf-microwave/impedance-measurement-with-vna-using-series-shuntseries-through-methods/msg3546156/#msg3546156)
The transformer led me down another path... The last time I played around with a breadboard, we were making an oscillator for the fun of it. This one is simulating a very bad power plane and bypass capacitors. :-DD
-
That lot is above my pay grade, but here is a pic of my shunt/series component fixture.
Flick a switch between the two.
(https://i.postimg.cc/Xvq8cMxd/shuser.jpg)
-
The log sweep mode is getting a workout. Shown is a 1nF silver mica in series with a 10 ohm on the breadboard so simulate a fairly high ESR. All the spurs above 80MHz are present with nothing plugged into the breadboard.
-
Using the default 101 data point, linear sweep but viewed as a log. Shown with a 100uH in series with the 10 ohm. The inductor's DCR is about 5 ohms. Seems like a poor choice for a decoupling network, even for a breadboard. :-DD
-
Sweeping 20KHz to 100M, still no transformer and unit is not calibrated. Plot A, starting with a tant for the bulk. B, adding a 0.1. C adding a 0.001uF.
-
Tried bunching up the caps onto one small section of the breadboard then trimmed the leads and jammed them on a bit of FR4. Tames some of the peaks, sort of.
-
Still way above my pay grade, yet appears useful to those earning a goodly chunk.
-
I'm not sure how useful this particular setup actually is. Obviously you can measure components this way. From my software, you can guess that normally I will use the shunt method. You need to use the setup that best fits what you are trying to measure. I had thought about changing my software to have a way to change the measurement type for the readouts. It may help clean up some of the front panel. For the low frequency work, that common mode transformer will be important but I doubt the people buying the Nano would have the $800 or so to buy one. I want to roll on for about the same price as the Nano that the RF/digital hobbyist can build. If you read through that other thread, the one I built has really good performance at the lower frequencies but it falls apart before you get to a GHz.
There are posts about repairing GPUs and wanting to look at the power planes. Basically, how to look at a PDN with such a low impedance. Something like Nano may aid in the troubleshooting.
When I first reviewed the original Nano, I mentioned that a friend had bought these and given me one. That video starts out with me reading a paragraph about high speed digital design. My friends whole interest in the Nano was to strengthen their understanding of PDNs. When I first introduced them to the VNA, we were looking at part of their PDN design as an example.
-
Parts are taking longer to get than I expected. The new cores are due next week. The H4 is still a few weeks out.
The software was diverging a fair amount from what was last released. My plan is to release the software without all the PDN functions and just try and address the the incompatibility with the H4 and what ever flavor or the week firmware is out there. Also I uncovered another bug that happened during the port that will be corrected.
Later, if I get anything that seems useful working on the Nano, I will roll the major revision and release new software for both the old hardware and the V2 Plus. The main menu was getting too tight. I want to keep the size small enough to fit on my laptop. In the attached picture, upper left, you can select the type of measurement and the cursors will change. It makes the readouts more generic. All those Transmission readouts are gone, freeing up a bunch of space. Most likely I will add more buttons to automate some of the measurements I tend to make. This would also require a major update to the manual.
-
All sounds good to me.
-
Checked the status and it's still on the boat.
I have been giving some thought to your being able to change the number of data points independent from the software. With the software you are using, it will detect the number of data points during the connect and anytime you change the frequency settings. You could however fool it easy enough. The problem with that is you could potentially waste a bunch of time collecting bad data.
The performance hit comes when you want to change the frequency a lot (segmented sweeps, zooms). Assuming that your H4/firmware combo allows you to save the number of points such that on power up it is automatically set, another option would be to have the software detect it during connection only.
One problem is that I store the number of data points that were used when creating a calibration file. When you load a calibration, it will properly setup the VNA. The V2Plus has provisions allowing the software to change the number of points remotely. The original Nano was always hard coded to 101 so it posed no problem. Now we have a case where the cal file could be set to 401 and the Nano is set to 101. It doesn't seem like this was a well thought out idea. You could contact the firmware group and see if they support remotely changing the number of data points.
***
It seems Dislord has posted in the V2 group. I have reached out to them to see if we can sort some of this out.
-
Talking with Dislord and a few others, its possible to select the number of points remotely. They also have a few other features that may help improve the performance (update rate). I will just need to play around with it. The first question I have is if it will give us reliable data or does it send random garbage like the other new releases. After seeing the problem first hand in your early posts, I assume you have ran some long term tests with it and if it was a problem you would have brought it to my attention. After all, that would be a show stopper.
-
When you say 'long term', are we talking something like overnight data gathering?
I've taken 2000 sample sweeps that appear to be glitch free, which of course I can't find now.
-
How long does it take to sort a bag of crystals? I would expect it to run over night with no trouble at all.
-
How long does it take to sort a bag of crystals?
I would do 300ish sample sweeps, so not an aeon.
I would expect it to run over night with no trouble at all.
Of course you would. Pretty sure you won't be disappointed.
-
what are people doing with crystals that makes them so interesting?
Is it crystal filters?
-
It should be here this week so hopefully we can start looking at the code again next weekend.
-
what are people doing with crystals that makes them so interesting?
Is it crystal filters?
In my case, yes.
-
It should be here this week so hopefully we can start looking at the code again next weekend.
Marvellous.
-
There are countless posts talking about what people have bought. It's rare to see people like the two of you who are actually experimenting and building something. Good to see it.
-
well at least the gear will end up on ebay eventually (partially) restored, even if people are just collecting you still get some saves because people don't turn on ancient capacitors, replace swiss filter technology, catch corrosion, save it from the landfill and sometimes offer pictures and information much more useful then old catalogs and manuals
if no one is buying it then its very possible to get it thrown into a e-waste dumpster and reclaimed for scrap
theoretically, even not looking at specifications, there is usually a chinese PCB you can get on ebay that theoretically does the work. practically, its unlikely to make it into even a plastic box with connectors on it to turn it into a usable tool (half of the stuff people claim makes things obsolete is kind of like attaching a saw to a motor body without a gearbox and calling it a useful carpenters tool (it does not even have a handle). but on paper both spin?
also, I expect there is at least some suppression from hardware developers.. those guys selling DC/DC converter minipcbs on ebay.. they don't want you to make your own thing, they wanna take over because its more sales. when they have cheap parts and a big inventory of course the trend will be to discourage people from doing otherwise.
effort required to use it as a test system in acquired state: obscene (who the hell actually can stand using a bunch of circuit boards strewn over a table connected by screw terminals and solder as a 'useful' laboratory. ?)
specification: facilitates blinking of light if you manage to connect it all without breaking something
so that gear has alot of use. its a step up above a shoe box with a bunch of cards. some people can get places with that though. imo its nuts to work like that. I think thats why people are going for it, but then nothing is developed because it 'feels' like you can just buy every simple thing on ebay, so I think people get stuck. feels like a bit of a youtube popularity contest (how many people are getting stuff to try to get followers? how many percent of followers actually know anything?). if you get started like that and then realize your projects are all seemingly out there, the equipment gets frozen. then in that case, just playing antiques road house will get more popularity then doing something with the equipment, because 'i can just buy that board and hook it up look it has these connections on it', the equipment body is kind of like art.. very few people actually understand the utility of the specification
try showing someone a thought out project, the end many times is a graph or number on something, often written on a note pad. then show someone glowy tubes.. whats going to get you props? the social media / marketing aspect that is common in this hobby completely drives some people crazy, but it reduces costs and increases availability. so frustration is inevitable?
plus it helps younger people in electronics careers because sometimes you can get through a non technical hiring manager because they saw something silly about what you are doing. any large company is going to have that problem. if there is some boss somewhere in the building that just happens to collect cool looking standard resistors to put into a display case near the model cars, you are kind of in luck. I once saw a gigantic radio transmitter tube in a hardware store, for no reason. i bet if you knew what it was you can get hired easier if you need money.
but it does clog the forum.. and sometimes stuff you need gets locked up in art prison..
and the electronics industry is just completely nuts because of things like Chinas mail/shipping subsidies (which some say is a part of some kind of economic war). for small and cheap things, the effects of shipping on purchasing can be described as chaotic. i have a feeling small changes in postage price, can already make things weird, and large ones are just ludicrous (not sure if its good or bad). and things like amazon and counterfeits, they reported 2 million listings that were removed just right now..
-
It should be here this week so hopefully we can start looking at the code again next weekend.
Marvellous.
They missed their long range projected date and have added another week.
-
How nice of them. >:(
-
The H4 never arrived and the tracking status hasn't changed.
-
We'll just have to wait then.
I just lost my hard drive and everything on it, with no back up. :--
Not having a good day either.
-
I would think that once it made it into the country, there would be an update. Suspect the ship is stuck at the docks or something.
-
Infuriating as it is, it'll show up.
-
I have 3 folders in my email client.
Waiting
Bought
Write-off
When I buy stuff, the acknowledgement email goes into waiting.
As stuff arrive, they go into bought.
When they don't arrive in expected days, I either file a complaint or put it in write-off and forget about it.
The last folder and complaining has amazing hidden feature. The very next day, the item shows up!
Seriously though, shipping process from China is quite mysterious. After an email that item is sent, nothing is updated for quite some time. Then it shows up in shores of US. Then another nothing for quite a while. The next step is in my mail box. I waited for 3 month total once.
-
The last folder and complaining has amazing hidden feature. The very next day, the item shows up!
If only.
-
Looks like the order was cancelled. I tried to find one on Amazon that was at one of their distribution sites but no luck. So the H4 is off the table.
-
No worries.
-
It seems like this is an opportunity for you to buy yet another low cost VNA to add to your collection.
-
Have you buckled and dipped your toes in the libre pond?
-
Have you buckled and dipped your toes in the libre pond?
Based on reading the forum, I have no plans at this time to buy one. I just can't see spending that sort of cash for the privilege of helping to develop it. I wouldn't be surprised to see a new revision of the hardware. While searching Amazon for your H4, I saw they have a listing for it. Are you planning to get one?
https://www.amazon.com/Analyzer-100KHz-6GHz-Measuring-Parameters-Reference/dp/B092Q6W2Z6/ref=sr_1_1?dchild=1&keywords=librevna&qid=1621780836&sr=8-1 (https://www.amazon.com/Analyzer-100KHz-6GHz-Measuring-Parameters-Reference/dp/B092Q6W2Z6/ref=sr_1_1?dchild=1&keywords=librevna&qid=1621780836&sr=8-1)
-
Are you planning to get one?
No, but should everything get ironed out, maybe.
-
While looking to replace my old 8754A, I came across the PicoVNA. I didn't like their software but the specs looked decent. If you are looking for something low cost, you may want to check them out.
https://www.picotech.com/vector-network-analyzer/picovna/picovna-series (https://www.picotech.com/vector-network-analyzer/picovna/picovna-series)
-
If you are looking for something low cost, you may want to check them out.
As someone who poorly emulates a hobbyist of electronics on the internet, I can barely justify spending $50 on toys, so there's no way I'm splashing out four grand on something that'll get minimal use, whereas the libre could tidy things nicely at the right price.
-
I would wait then. Even if the price stayed the same, if they roll out a third revision of the hardware, your into it for over a $1000.
OWO had mentioned they were working on a 6GHz version as well (if that's what you are after). Based on the V2+4, even if they close source the hardware and firmware, as long as they document the interface, I would give it a try.
-
I would wait then.
I could handle that.
-
A few people pointed out this version but the pictures appear different that what you show. I can't see buying something that may not be identical and we end up wasting even more time trying to hunt down some other incompatibility problem. If you want to try and chase down if this one is indeed the same as yours, I would be up for trying to order another one.
https://www.amazon.com/gp/product/B08FD35LRW/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B08FD35LRW/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)
-
Whilst mine was the cheapest H4 on aliexpress, it came in the presentation box that I would expect a real H4 to come in.
Clone or not, it works well, so I don't think you could go wrong with anything claiming to be an H4, as there's so little to them.
Nooelec appear to be the official N. American H4 distributor....
https://www.nooelec.com/store/test-equipment/analyzers/nanovna-h4.html (https://www.nooelec.com/store/test-equipment/analyzers/nanovna-h4.html)
A few bucks more expensive than China, but you get the real deal for sure.
Chasing the identical jobbie might be futile.
Peter
-
I suggest you post pictures of your PCB to the group and ask there. Maybe someone there can confirm if they are the same.
If I am going to attempt to solve these problems your having when attempting to use unsupported firmware and hardware, I need an identical setup. The real deal could cause a huge time waste.
One option if you don't want to take the time to dig into it, you could buy the same product from the same supplier.
****
Looking at the manual in the link you provided, it's basically a rib off from the original. No big deal but when I compare the schematic in the manual against the original hardware I have, there are very few changes. The same micro is is used. I thought the H4 had a different micro to support that 401 data points your wanting to play with? Maybe I missed something.
-
If I am going to attempt to solve these problems you're having
I'm not having any problems. Everything appears to be fully functional.
Possibly a few questions about your software post v1.08, but other than that, nothing.
-
If I am going to attempt to solve these problems you're having
I'm not having any problems. Everything appears to be fully functional.
Possibly a few questions about your software post v1.08, but other than that, nothing.
Odd, maybe your short term memory is starting to fail you. I didn't order that hardware because everything was all fine in the world of Purpose!
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3552390/#msg3552390 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3552390/#msg3552390)
Or, maybe you're suggesting you will not attempt to use the newer software with unsupported hardware/firmware or at least not question it when it doesn't work.
-
Odd, maybe your short term memory is starting to fail you.
Could easily be amnesia, or early onset Alzheimers.
I didn't order that hardware because everything was all fine in the world of Purpose!
I hear that and thought it very nice of you to offer to buy an identical gizmo in order to see why your software was not working as expected with my gizmo, but v1.08 worked nicely and it was only the later stuff that didn't. If memory serves me (cough), we agreed to stick with 1.08.
Or, maybe you're suggesting you will not attempt to use the newer software
I've said, or thought no such thing. You make em... I'll try em... was something I did say.
with unsupported hardware/firmware or at least not question it when it doesn't work.
I was reporting, not questioning. I'll try any version of your software you want me to.
If I have to buy something to add to your collection, then so be it, but if you ordered from the link I sent and you didn't receive it, then we might have a problem getting the identical piece.
-
I was reporting, not questioning. I'll try any version of your software you want me to.
Morning Mr. Smith,
In v1.11 I adjusted the points box to 401 (highlighting and inputting from the keyboard) and saved to defaults. Restarting shows 401, but as soon as I link, it jumps
back to 101.
...
Am I missing something other than grey matter?
Peter
That looks like a question to me, not reporting. The manual is clear about what the software supports. Reporting on unsupported combinations isn't helpful. In the future I will handle it differently.
... but v1.08 worked nicely and it was only the later stuff that didn't. If memory serves me (cough), we agreed to stick with 1.08.
You may certainly use any version I have made available but I have no intent on sticking with it.
If I have to buy something to add to your collection, then so be it, but if you ordered from the link I sent and you didn't receive it, then we might have a problem getting the identical piece.
Maybe but my track record with Amazon has been good. With them stocking the product, I doubt it would have been a problem.
-
That looks like a question to me, not reporting.
That was quite obviously a report, followed by a question which was nothing to do with the software.
You're not getting away with that.
You may certainly use any version I have made available but I have no intent on sticking with it.
Fair enough.
I doubt it would have been a problem.
Jeff Bezos to the rescue.
Personally, I prefer to give my dosh to the little guy.
-
I have a whole bunch of fair-rite very tiny balun cores, beads, etc. I have several materials.
I am assuming you want to try the effect of a small decoupling transformer vis-a-vis smoothing out the peakiness shown in the images?
Now I have an original nanona2 and a bunch of TH components, probably the ones you used (including the coil) as well as the toroids, probably. As well as the breadboards. I also have some gold plated DIP plugs with solderable pins ideal to carry the xformer. From experience this works great up to a few hundred MHz.
Can I attempt to replicate what you are trying to do which I am guessing likely involves either a 1:1 or fixed ratio transformer (1:4?) to match the nanoVNA to the "transmission line" on the breadboard?
I'd be happy to bang it together, scan the DUT at the proper range and then show you what the results are via screenshot here. I would be using the software that I have which is the QT software (which works fine for me)
I dont have a windows box so cant run windows apps. My wine install is broken now too. :(
This is not an inconvenience because I have been meaning to try exactly this, to check this out for a while.
I also have the nanovna test board and a bunch of stripboard (good for series and shunt testing fTH components but ...
And SMA connectors. and my x-acto knife and soldering iron. would be good for HF, too much capacitance to work well much above that. But okay for banging out filters for HF.
Sweeping 20KHz to 100M, still no transformer and unit is not calibrated. Plot A, starting with a tant for the bulk. B, adding a 0.1. C adding a 0.001uF.
Should be fine at 100 MHz.
-
I have a whole bunch of fair-rite very tiny balun cores, beads, etc. I have several materials.
..
Can I attempt to replicate what you are trying to do which I am guessing likely involves either a 1:1 or fixed ratio transformer (1:4?) to match the nanoVNA to the "transmission line" on the breadboard?
..
I am guessing that you are talking about making that crystal test jig on a breadboard which seems like it could work. You may get better results building it up on perfboard. I have never looked at any of the other software for the NanoVNA but assume what ever you are using supports the measurement.
Sweeping 20KHz to 100M, still no transformer and unit is not calibrated. Plot A, starting with a tant for the bulk. B, adding a 0.1. C adding a 0.001uF.
Should be fine at 100 MHz.
The quote you mention from the following post is testing out some new routines to look at the impedance of the power rails. The mentioned transformer is not the impedance matching bifilar transformer used for the crystal test fixture. Instead its a coaxial transformer used to break the ground loop when making shunt through measurements at low frequencies. The breadboard allows me to build up simple networks used to test the software.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3559860/#msg3559860 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3559860/#msg3559860)
-
I doubt it would have been a problem.
Jeff Bezos to the rescue.
Personally, I prefer to give my dosh to the little guy.
No worries. I have no plans to pursue it further.
-
That'll do me.
-
Hello joeqsmith,
I read earlier (in 2019) in the forum group, a lot of changes have happened since then. Yesterday I downloaded the program and tested NanoVNA v1.08. I attach the difference between the current firmware 1.0.62 (not yet released by DiSlord) and the shell commands in version 0.8.0. I hope you find it useful. I find the program interesting, but I have a lot to learn about using it. A small spelling: there is an unnecessary 'i' in the text in the info window: 'Th (i) e quick brown fox jumps over the lazy dog' telex test text in which all letters are included.
Gyula
-
I wouldn't be surprised if you found other spelling errors in the software or documentation. Please feel free to post them as you find them and I will correct them on the next release.
Radiolistener's firmware running on the original hardware from a more than a year ago seems to be the only stable combination I have found.
I think I am up to four software problems with 1.08 so far. I have no plans to fix any of them. If I get something I feel is useful working with the PDN measurements, I will release 2.0 for both the original hardware and the V2Plus4. If you have read the last few pages, this new software will most likely be even less compatible with the newer versions of firmware and various hardware that pops up.
-
My latest version of software for the original NanoVNA only uses three commands. One of those is obviously Freq where I only use two of the sub commands. After working with the V2Plus, I settled on a much simpler approach.
-
For NanoVNA version greater 0.7 you can use one command
scan start stop points 7
start - start frequency in Hz
stop - stop frequency in Hz
points - points count (up to 101 for H version, up to 201 or 401 (on my fw) for H4)
It return all measured data after
Example see screenshot
Command return list of measured data
freq s11_re s11_im s21_re s21_im
PS you can use faster exchange mode im my fw (in binary format as vs V2)
scan start stop points 15
In this case returned binary
uint16_t mask;
uint16_t points;
struct {
uint32_t freq;
float s11_re;
float s11_im;
float s21_re;
float s21_im;
}data[points]
-
Mr. DiSlord,
Спасибо for the great firmware. :-+
-
DiSlord,
Hopefully my last response solves your regional settings problem. Make sure you read it carefully.
Without having the H4 hardware, there is little reason for me to try and run your firmware at this time. The goal would have been to replicate Purpose's setup in an attempt to help them out. They have some flavor of an H4 which I was unable to obtain. Not a big deal as the original hardware will do what they need and it seems that my software at least somewhat works with his H4 setup.
Again, thanks for providing me with help on the command set.
-
Shown with a 7805 regulator, 1.84MHz oscillator, meter and various caps. The DC blocks and transformer are installed.
-
Shown with a 7805 regulator, 1.84MHz oscillator, meter and various caps. The DC blocks and transformer are installed.
good job!, where can I download VI?
Thanks
-
Shown with a 7805 regulator, 1.84MHz oscillator, meter and various caps. The DC blocks and transformer are installed.
good job!, where can I download VI?
Thanks
I have never released the source code (VIs), only the EXEs. You will find the link to my Github account in my signature.
Make sure you read the README BEFORE you try and download and install it. One of the most common problems people ask me is they will download the EXE and then they try and find the runtime for it, then if they manage to find the right version, the software won't find the device because they still haven't installed VISA. :palm: The next problem is people will try and use the wrong software for their device. They have the V2Plus and are trying to use the software for the original hardware. I suspect DisLords problem with their regional settings is they didn't change their .INI file covered in the manual.
There are also cases of trying to use the software with unsupported firmware/hardware. Most likely 2.x is be be even less compatible. I suggest archiving the current versions. If you manage to get it running, the next hurdle will be reading the manual.
The PDN measurement features are still being developed. The changes will need to be added to the V2Plus and the manual needs to be updated. So it's a ways off.
-
Using the same setup, the original NanoVNA was swept from 10kHz to 1.5GHz using a thru. The data was then normalized. Next both ports were terminated using a common shield.
-
Looking at the calculated resistance with both ports terminated, it's a bit under 3mOhms from 20kHz to 70MHz.
The V2Plus4 is limited to 50kHz which we saw from looking at the 100uOhm resistor is already on the high side.
-
Using the same setup but removing the homemade common mode transformer. We wouldn't expect there to be any difference as we are after all testing with the two ports terminated and there should be no ground loop. More a sanity check than anything.
-
Using the completed setup to sweep the 100mOhm, 25mOhm and 1mOhm resistors from 20kHz to 70MHz. Still a few more things to work out but for a $50 VNA, I'm impressed. The V2Plus4 is limited to 50Khz which is better then my new boat anchor.
When I was looking for a new VNA I was interested in finding something that would be usable at these lower frequencies. Asking about what was available in the HPAK group, some of the feedback suggests not many people have a use for it. I'm keeping my fingers crossed that the new low cost VNAs are able to measure narrow band devices as well as make some of these low impedance measurements.
True, but wanting your Microwave VNA to go down to DC is like
wanting your Ferrari to have tank tracks.
It just isn't right. Better would be to have a Ferrari and
a tank. They serve different functions.
-Chuck Harris
-
25, 1 and 0.1 mOhms. The 0.1 mOhm appears less inductive but we can see its beyond what the original NanoVNA can measure.
-
Purple, original setup on the breadboard. Pink showing the 7805, oscillator and the single alum elec cap. Green, removing all the caps and cutting the leads of the two tants and adding three ceramics. Less caps and the impedance is much more stable.
I came across this video from Keysight talking about the breadboard's claimed 10MHz limit. I like the little FieldFox but while he says it's 25GHz is overkill for breadboard work, I would imagine it's possible to use a breadboard at frequencies in excess of this ;)
https://www.youtube.com/watch?v=SI8DGyl0K8E (https://www.youtube.com/watch?v=SI8DGyl0K8E)
-
I tried it and sure enough. No problem though. Open the .INI file and add the line:
useLocaleDecimalPt=False
Rerun the application. It will then use a decimal as it should regardless of the regional settings.
It works, thank you! :)
I am curious when you installed the software, did you have the .INI file or if you had to create it? Member DisLoard appears to be having the same problem but from their latest response it seems they may not have the .INI. I suspect they may have not installed it from the original installer (which should have had the .INI file). I tried a clean install for the V2+4 and it shows up in the same directory as the .EXE. Maybe something else is going on.
The manual includes the contents of the .INI (auto created by LabVIEW during the build) and a copy paste is fine but assuming the install was done in the proper order, you shouldn't have to do this. I may add more details in the manual.
-
I am curious when you installed the software, did you have the .INI file or if you had to create it?
I created the NanoVNA.ini file, it was not automatically created after first running the exe.
I thought it's maybe because I did not reinstalled the runtime engine (although it doesn't make much sense). But I haven't done futher tests.
-
I am curious when you installed the software, did you have the .INI file or if you had to create it?
I created the NanoVNA.ini file, it was not automatically created after first running the exe.
I thought it's maybe because I did not reinstalled the runtime engine (although it doesn't make much sense). But I haven't done futher tests.
Thank you very much. When you created the file, did you only include the one line "useLocaleDecimalPt=False"?
-
Thank you very much. When you created the file, did you only include the one line "useLocaleDecimalPt=False"?
I copy/pasted all the lines from the manual, but i just tested again and it's also working with only the on line in the ini:
[NanoVNA]
useLocaleDecimalPt=False
-
This is good to know. Thanks for trying that last test. I will add more details to the manual about the regional settings. I have linked these to DiLord's open issue on Gitub.
-
No problem, you're welcome, anytime.
Thank you!
-
I also create nanovna.ini file in NanoVNA.exe directory, after all work
PS in my fw i also add expert option for change dot or comma as digit separator (sended to console)
-
PS in my fw i also add expert option for change dot or comma as digit separator (sended to console)
Good to know, thanks!
-
I also create nanovna.ini file in NanoVNA.exe directory, after all work
PS in my fw i also add expert option for change dot or comma as digit separator (sended to console)
Sounds like that solved your problem then.
As you can see, with LabVIEW being designed to control test equipment, they anticipated the need to handle the regional settings. So there is no need to have the firmware handle this case. A plus for me as I am pretty lazy and the whole reason I use LabVIEW is because of the time it saves me.
-
Moving away from the breadboard and trying it on a PCB required a couple of very short cables with an SMA on one side. These are soldered directly to the PCB. I wrapped the braid with a single strand wire and used a bit of Kapton tape to cover it up.
Data taken with transformer #8 and DC blocks. Shown looking diagonally across the FPGA's core supply. Both a bare and populated boards were tested. The populated board was tested off and powered up. Starting to make a little headway...
-
This issue possible vs others software, so better have it as option
PS You write about not stable exchange. I think it come from old 'data' command, in some rare cases possible receive not calibrated point.
In all cases better use
'scan start stop points 7'
console command it supported by all fw (i add it to eddy v0.7)
PSS also you can select less bandwidth on device and get more better noise floor on measure (in < 100MHz range noise floor for S21 can be less -100dB)
PSSS i made release v1.0.63 for H/H4 https://github.com/DiSlord/NanoVNA-D/releases/tag/v1.0.63
-
Looking at R for the powered core supply.
-
This issue possible vs others software, so better have it as option
PS You write about not stable exchange. I think it come from old 'data' command, in some rare cases possible receive not calibrated point.
In all cases better use
'scan start stop points 7'
console command it supported by all fw (i add it to eddy v0.7)
PSS also you can select less bandwidth on device and get more better noise floor on measure (in < 100MHz range noise floor for S21 can be less -100dB)
PSSS i made release v1.0.63 for H/H4 https://github.com/DiSlord/NanoVNA-D/releases/tag/v1.0.63
This threads pretty massive and may take some time for you to track it down if you decide to dig into it. You may want to post a question to member Radiolistener. The problem I ran into was random errors in the data. I believe the problem was how they were doing the sweep. From what I remember they had a fixed delay, then changed the delay based on frequency to try and speed it up. I think Radiolistener changed over to using some of the hardware status bits to determine when to move to the next point. After they made this change, the problem was solved. When I decided to release the software, I tried some of the latest firmware but had the same problems I saw from over a year ago. So I am back to using very old firmware that I know will give me clean results.
If you have been reading my more recent posts, you will see me collecting data down to 10KHz. Another change Radiolistener had made that the new firmware never adopted.
Back then I wrote a regression test that I can run against the firmware. So many versions were popping up, it was like trying to follow Dave's 121GW meter. That regression test requires several hours to run but does a decent job weeding out basic problems.
I haven't ran into to many problems with the actual serial data. Some experiments I have ran for hours at a time. The only problem I can think of is with the V2Plus (not the 4). This VNA will hang and require a power cycle to recover. I tried several tests to narrow down the problem but in the end, it was tossed into its box and I have not looked at it since. Too bad really as it seemed like a decent product otherwise.
-
Looking at the design and removing one component (green trace, power applied). Second picture, showing only the two powered up traces. Really knocked down the 200KHz and 15MHz peaks. Not sure why the impedance starts to rise after 20MHz. Maybe you could actually use a $50 VNA to tune your power supply network.
-
Dave's video on by-pass capacitors using a RedPitaya. Looks like it was limited to 100kHz on the low end. Seems a bit too high for what he was trying to show. Too bad that the NanoVNA wasn't common place back then.
https://www.youtube.com/watch?v=BcJ6UdDx1vg (https://www.youtube.com/watch?v=BcJ6UdDx1vg)
-
I had posted a few links to videos on this subject in another thread. The last one sponsored by Keysight explains the basics.
https://www.eevblog.com/forum/rf-microwave/impedance-measurement-with-vna-using-series-shuntseries-through-methods/msg3556953/#msg3556953 (https://www.eevblog.com/forum/rf-microwave/impedance-measurement-with-vna-using-series-shuntseries-through-methods/msg3556953/#msg3556953)
This simple example should provide you with some idea how the software will work. We will be using the breadboard and start out with a 100uH inductor (PIC1). The DC blocks were left in series even though this will be an unpowered test. Transformer #8 was again used to break the ground loop (PIC2). The inductor was placed across the power bus on the breadboard (PIC3) and NanoVNA was sweept from 10kHz to 1MHz (Comp_100uH_1).
No surprise, the plot shows we have an inductor. The NanoVNA measures roughly 100uH. We don't really have a load and you can see I have set the target impedance to 50ohms. Normally this would be set based on your load requirements. The software calculate that we need a bypass capacitor of 40nF (C = L/Z^2).
-
The closest thing I found to 40nF was this 47nF polyester film (PIC4). The capacitor was placed in parallel with the 100uH inductor (PIC5) and the Nano was again swept.
-
Doesn't look very good but keep in mind that we are targeting 50 ohms. The capacitors ESR needs to be the same as the desired impedance. To increase the ESR, a 50ohm resistor was then placed in series with the capacitor and then the Nano was swept one last time. Notice now how stable the impedance is. This is really what we are after.
-
We can change the target impedance from 50 to 10 ohms. The compensation can be calculated in our head now, C = 100uH/10ohms^2 = 1uF.
Using a couple of 2uF capacitors in series. Note their ESR is < 0.1 ohms, so we add a 10 ohm resistor in series.
Again we show the inductor by itself, then with the paralleled capacitors and finally adding the series resistance. The inductor waveform was deselected for the last image to allow a more zoomed in view.
-
Using two 100uH in series and compensating it with the 2uF film in series with a 10ohm. I had a 2.2uF aluminum electrolytic that measures an ESR of 42 ohms at 120Hz. At 10KHz, it's closer to 3 ohms. The film capacitor and resistor were then swapped for the alum elec with a 6.7 ohm to compensate for the difference in ESR.
The 1nF (picture showing 100nF which is not correct) helps smooth the impedance above 7MHz but seems a bit much. The long leads and breadboard don't help but it's just for demonstration.
-
Of course, if the only goal was to get it flat it's hard to beat a resistor. Note the purple and pink trace were prior to cutting off the long leads.
Time to start working on the new manual.
-
Some of the changes with 2.0 are:
Readouts are now more generic and correspond to the measurement type selected
Auto center the waveform at the minimum and maximum
Auto move the cursors to the min and max
Add delta dB for cursors
Correct bug with 2 port Touchstone
Correct bug when saving segmented data to Touchstone (AppCAD does not handle the odd spacing when using quasi log sweeps)
Display the number data points when using segmented sweeps to the status box
Reduce commands used to interface with the firmware (now similar to V2Plus4)
Add Bode plot for PDN analysis
For the Bode plot, the following are supported:
Auto detect peaks and vallies and provide readouts for each
Calculate compensation values
Performs conversions to ohms and dB ohms
Improve the trigger and data collection (faster and easier to setup and use)
Plot gain, phase, ohms and db ohms
-
Tried running the regression test with the firmware supplied with the H4 (0.5.0) but it wasn't stable. I wasn't expecting it to pass as I had tested newer firmware with the original hardware and it fails as well. I then tried loading in the latest firmware from DisLord but after having it hang several times and requiring a power cycle to recover, I went back to what was supplied. My guess is the standard firmware has the same problem as the original Nano firmware.
****
I then tried installing DisLord's 1.0.38. This version appears to behave slightly better. Running the regression test on it it shows some some basic problems which would need to be addressed before more detailed regression tests could be performed.
When trying to characterize crystals it exhibits the described frequency offset in the peak while using zoom. This was a rounding error I caused after removing support for the frequency command, which was corrected with 2.0. It's no problem using the 401 data points and the basics seem to work but I suspect with it failing the regression test that it will cause some pretty strange behaviors if used with my software.
****
As far as the zoom display odd looking waveforms, it appears this is a result of the buffer only being partially updated. The old software was slow enough that we never see this condition (or rarely). While it's a cosmetic problem and does not effect the crystal measurements, it's an easy change to just not show the data when changing the Nano's settings and it does not cost any more time to during the collection process. I have gone ahead and made this change to 2.0.
I plan to stay with manually setting the number of data points rather than auto detecting them as I was before.
-
Using the H4 with DisLord's 1.0.38 firmware to look at the 100uH // 1uF+10ohm. I'm not sure why the performance is so poor compared with the original hardware, but it does appear to somewhat work. Hopefully others get better performance with theirs and this is just a lemon.
Finished with the updates to the V2+ software and one of my vintage VNAs. I have started working on the manual. Originally I had planned to start over but I have now decided instead to just add a section to cover the main differences. There will also be a separate section for the PDN.
-
on 12k you see IF (On original fw used 6k IF), also my fw allow work from 800Hz (but yes you get some errors near IF harmonic), for less 15k better use less then 1000 Hz bandwidth
Also try use less bw settings (you can change it in device (DISPLAY->BANDWIDTH) or use console command 'bandwidth 100 Hz' there can be any up to 4000)
Calibration also better done in 100 Hz or less bandwidth settings (allow get more clean result), less bandwidth - need more time for measure
-
on 12k you see IF (On original fw used 6k IF), also my fw allow work from 800Hz (but yes you get some errors near IF harmonic), for less 15k better use less then 1000 Hz bandwidth
Also try use less bw settings (you can change it in device (DISPLAY->BANDWIDTH) or use console command 'bandwidth 100 Hz' there can be any up to 4000)
Calibration also better done in 100 Hz or less bandwidth settings (allow get more clean result), less bandwidth - need more time for measure
I would have expected the firmware to default to being backward compatible and at least provide similar performance. Normally, I would never use the display or touch pad. It's certainly possible to support commands that are added to the firmware. So far, I have not found any advantage to them and the lack of detailed documentation is always a good deterrent. I would rather that the firmware just send up reliable raw data. The PC has slight advantage in computational horse power.
1.0.38 seems to default at 1000Hz. Per your suggestion, I repeated the same test using lower values.
1) shows both 30Hz and 100Hz datasets.
2) same as 1 but with the 1KHz dataset added.
I have also included the old hardware with the year old firmware. The purple trace is the one we are interested in which is just the LC circuit.
-
How you receive data from device? (command usage)
sweep start stop points
data 0
data 1
or
scan start stop points mask
mask - data receive mask:
0x01 - need frequency
0x02 - need data 0 (S11)
0x04 - need data 1 (S21)
0x08 - disable calibration for data
example usage - need receive 101 uncalibrated points (freq + S11 + S21) from 1MHz to 10MHz:
scan 1000000 10000000 101 15
or
scan 1000000 10000000 101 0b1111
In this case get list of data
freq s11_real s11_imag s21_real s21_imag
Example of answer:
09.143 tx: scan 1000000 10000000 101 15
09.146 rx: scan 1000000 10000000 101 15
09.460 rx: 1000000 0.093020952 -0.000852031 -0.000012151 0.000000849
09.464 rx: 1090000 0.092999120 -0.000905091 -0.000010828 0.000009627
.........
PS soon i allow get unlimited points count for this command
PSS 12k IF better for higher frequency, i try usage dynamic IF select for low freq range (800Hz to 15kHz), for reduce IF error
-
During setup I use the following:
sweep start i32 CRLF
sweep stop i32 CRLF
For data collection I use a combination of:
data 0 CRLF
data 1 CRLF
depending what I am measuring. In the above example, only the data 1 CRLF is used.
The number of points was always fixed at 101. My software (for the original NanoVNA) has no provisions to change it.
I also issue the info command on connection but I believe that's the only other command I currently use. As long as the firmware supports these and functionally they are kept backwards compatible, my software should work.
If the protocol is drastically different, I create a new top level and interface layer. Normally the hardware is different enough that it makes sense to just start over with a clean slate.
For my normal uses, the 101 data points is fine. The only reason I came up with that segmented sweep was to demonstrate making a blackbox model of a crystal for SPICE.
-
sweep command not made real swep, it used for set start stop range on device
data command return current data (so you receive wrong results)
You not correct receive data from device.
In all cases need use scan command - old format for receive data (all firmwares support it), remove 'sweep start' and 'sweep stop'
scan start stop CRLF
data 0 CRLF
data 1 CRLF
All fw from v0.7 support 'scan start stop point mask' in all cases better use it, more faster and more correct
-
sweep command not made real swep, it used for set start stop range on device
data command return current data (so you receive wrong results)
I suspect this is a language problem. I use the sweep to set the start and stop, which I referred to as setup. I use the data command to return current data, which I refer to as data collection.
I wouldn't call it wrong results but certainly when I use your firmware the results are poor. It's easy enough to look at the VNAs screen and see that the sweep commands have taken effect.
You not correct receive data from device.
In all cases need use scan command - old format for receive data (all firmwares support it), remove 'sweep start' and 'sweep stop'
scan start stop CRLF
data 0 CRLF
data 1 CRLF
All fw from v0.7 support 'scan start stop point mask' in all cases better use it, more faster and more correct
There is no advantage for me to change the command set. There is already firmware that works fine with the old hardware using the old protocol. I say that but then you claim more faster. Currently the update rate seems limited by how fast the Nano can sweep. It could send ASCII or binary and it would not matter. The PC has no problems keeping up. So I am curious what this more faster really means. I assume you have ran collected metrics on this. Could you please post these results here? If indeed it really is more faster than what I achieve with the old commands, I will have a look.
-
I tried to explain what you are doing wrong. Even on the old firmware, this is incorrect.
Yes, it works if you pause between command and data retrieval.
Even on the old firmware, it is necessary to use the sequence of commands that I gave.
Again, the sweep command will only set the start and end frequencies on the device. Then the device must make at least one pass (if there is no pause). The date command returns the current data value. If you set the interval, and immediately request the data, then you will get the old dataset.
On this I will no longer recommend anything, do as you want
-
No need to be sensitive about it. I'm looking for what more faster means and trying to understand what advantage if any there would be to changing software that has been working fine for over a year. From your comments is seems that you really feel this is the cause of the poor performance I am seeing with the H4 running your firmware. I would have assumed you're testing your software before releasing it and would have caught something this obvious.
Normally I am only sending the Data 0 or Data 0, Data 1, Data 0.... That is the sequence. Changing the frequency is infrequent compared with collecting the actual data. The software does change the frequency asynchronous with the data collection and I expect to throw out a sweep. If I didn't have to, there would be some gains but hardly worth mentioning. Now if we could go 4X or 8X faster, that would indeed be more faster.
I will reinstall the original firmware that was shipped with the H4 and run my software as is. If the performance is on par with the original NanoVNA, it rules out the hardware as the cause. I will then change from the sweep to the scan and repeat the test. I will then reinstall your firmware and run it with the software change. And finally, I will try the old hardware/firmware with the software change and see if it has any effect.
-
Send scan command
scan start freq_start
scan stop freq_stop
After device only change strart and stop points, not made sweep (just start it if no paused)
if after you send
data 0
Device return current data set (and if at this moment not complete scan - data not fully correct)
You must wait sweep complete (need add delay)
So if used segment scan and call
scan start 1000000
scan stop 2000000
data 0 - at this moment device in most cases not complete current sweep measure (last part of data contain prev scan measure, yes all good if you not change sweep range and so on)
scan start 2000000
scan stop 3000000
data 0 - in this case first part data contain new measured result, last part - contain any data from prev scans)
You get not correct result if not add delays (yes you can calculate it, but .. not good)
If use sweep command
sweep start stop points
points - optional, if not set - used max possible for device points
Device set start stop frequency (and points count if set), after made sweep and pause
So next received command
data 0
or
data 1
Always return correct result
This old format for receive data from device, work on any firmware (not related to my)
After v0.7 i extend this command by add mask, if set possible get result after scan, not need call 'frequencies' or 'data 0' and so on, this allow save some time
In my last fw to mask also added uncalibrated data ask (this allow in all cases get uncalibrated data, not depend from options selected on device)
Also added binary command scan_bin (it return data in binary format as v2, not need additional data convert), but this command supported only by my firmware.
-
I use a handshake with the data collection thread. The old firmware may have cleared the buffer and resampled but I always toss out the first data set. While I display the data, I don't use it for any measurements. This caused the person trying to use your firmware to ask about the odd waveshapes. Again, cosmetic. It sounds like making these changes still requires the first data to be tossed out, so I still don't understand what more faster means.
If the sweep command is causing the problem, are you suggesting that making two separate sweep calls rather than one is causing the poor performance? If so, I can try that combination as well but it seems if you are testing your firmware with:
scan start stop CRLF
data 0 CRLF
data 1 CRLF
This is how I should test it. Again, tossing out the first sweep after the scan is sent.
-
scan start stop CRLF
data 0 CRLF
data 1 CRLF
In this case not need drop first scan, you should always get correct result after this commands.
Faster - not need wait additional thread sync in device for receive and exec shell commands (save some ms)
scan_bin more faster - not need made lot of float calculations for convert data in text format, less data send.
In most cases need get only s11 or s21 data, if use 'scan start stop' device always made 2 channel measure, if ask get only one channel data - sweep made 1.5x faster
example how receive only s11 data
scan start stop points 0b011
result list of
freq s11_re s11_im
-
Again maybe a language problem but if I am only looking at S11, I send data 0, data 0, data 0 .... I've always done this to speed it up. When I first sniffed their software, I believe they sent data 0, data 1, frequency (repeat) which seemed stupid. I know the frequencies, so that was dropped. I then stopped asking for both data sets. Again, it's been like that over a year. With the new software, it's even further simplified. Not having to drop that first data would help somewhat. I suspect what you are suggesting is that the time to calculate the floating point values in firmware is taking a lot of time and ditching it would somehow speed up the over all data rates to the PC.
It sounds like you are now suggesting that scan start stop will somehow cause it to collect both S11 and S21 but not send them. This would be a detriment unless it actually improves on the poor performance from using the sweep command.
I think now that I understand what is meant by more faster and the gains are small over what I have today, the real question is back to the poor performance. Above all else, the data needs to be good. If we can't get past that, the rest is useless. It will be very interesting to see if how the ranges are set has anything to do with the actual data being sent back. I wouldn't think it would have any effect on it but it's an easy test so we will see.
-
It's going to be a real pisser if I find out the hardware has a problem... Still the box is pretty fancy and nice to look at. :-DD
-
>Again maybe a language problem but if I am only looking at S11, I send data 0, data 0, data 0 .... I've always done this to speed it up.
when a scan command is received, the device does not know what data will be requested later (you send in future 'data 0' or 'data 1'), therefore it always measures two channels.
If you explicitly indicate in the mask that only one channel will be needed, then only it will be measured (which is faster).
But since you are not using a mask, it doesn't matter
-
H4 with the stock firmware (0.5.0) looking at the 100uF//1uF. Very similar to what we see with the old hardware and year old firmware.
Running the regression test with this combination will not pass but outside of what appears to be the same old problem from a year ago, it seems alright. It does not appear that the poor performance is related to the H4's hardware.
-
Just using a dumb terminal, if I send "scan 100000 1000000" it returns without an error but the screen does not reflect the changes. Sending "sweep start 100000" does change the start frequency on the screen.
I then tried "scan 100000 1000000 101", no change.
So the command that is wrong to use works but the one that fixes everything doesn't work, at least with 0.5.0. Nice. There's not much else I can do with that.
****
Next I reloaded your firmware 1.0.38 and again using the terminal program I send the same commands. Again, the H4s LCD does not reflect the changes. So, I sent the frequencies command and it seems to report correct range. I sent the data 0 command but the screen still shows the wrong range.
I then made the change to my software to use the scan rather than the sweep. I left your 1.0.38 firmware installed in the H4. It appears to have no effect (which I would expect) and the performance is again very poor.
-
Next I reinstalled the original 0.5.0. The firmware behaves a bit different but it does appear to update the range. Once again, we can see it had no effect on the data and the performance is decent.
-
Next I attached the original NanoVNA with my year old firmware to see what effects the scan command has with it.
help
Commands: help exit info threads version reset freq offset dac saveconfig clearconfig data frequencies port stat gain power sample sweep touchcal touchtest pause resume cal save recall trace marker edelay capture
ch>
Notice, there is no scan command. So while the sweep command may be wrong, it certainly works and it much more compatible. I think we have our answer to what the cause of the poor performance is. Sadly, the standard firmware for the H4 isn't good enough to use. I have packed away the H4 and won't bother with it. On the plus side, it does appear that talking with it the wrong way works and it does put out good enough data to measure crystals. I think that was all they were after.
Back to writing manuals....
-
Hmm i check again Hugen v0.5.0 (from 21/02/2020)
https://github.com/hugen79/NanoVNA-H/releases/tag/0.5.0
scan command present in code (it added in 24/09/2019)
scan command does not change the device settings, and is intended only for receiving data from the computer
PS About perfomance - used 12k IF (possible see it on measure in 12k and 24k?) better in work on higher frequency > 50k. Old fw use 5k IF
Need made research better IF for < 50k work
Thanks
-
Hmm i check again Hugen v0.5.0 (from 21/02/2020)
...
scan command present in code (it added in 24/09/2019)
You would need to search this thread to find when the members here had started to fix the bugs in the firmware. Looks like I made that first demo video in August 2019. This gives you some idea of the timeline. Once the major problems had been corrected, there was no need for me to try other firmware.
scan command does not change the device settings, and is intended only for receiving data from the computer
Thanks
The language makes it difficult for me to understand what you are trying to convey. Of course the scan command changes the device settings.
It's odd how they decided to change how the H4's screen functions once you control it remotely. I had not really paid attention to it until I ran these tests for you.
PS About perfomance - used 12k IF (possible see it on measure in 12k and 24k?) better in work on higher frequency > 50k. Old fw use 5k IF
Need made research better IF for < 50k work
Thanks
You claim one of the features of your firmware is supporting 800Hz but the old firmware will far outperform what you have at lower frequencies. At higher frequencies, your firmware can really mess up the data. I suspect your filters have done more harm than good. BTW, while I did not show it, using the scan versus the sweep had no effect when changing the bandwidth filters. The data still exhibits the same poor behavior.
As you said: I tried to explain what you are doing wrong. Even on the old firmware, this is incorrect. ... On this I will no longer recommend anything, do as you want
I now tend to agree with you. We have done about all we can. You're happy with what you wrote and I am happy to continue to incorrectly use the old firmware and get good results. We both come out winners.
-
A draft manual for 2.0 is now available. Of course the TOC was updated along with the what's new. The main changes are at the end where it describes the difference in the new version and the new PDN measurement feature.
-
If the "native protocol" of all these VNA variants is getting to be a tower of babylon, what may be desirable is a rosetta stone.
Program client software based on an abstraction of WHAT the VNA hardware is supposed to be able to do (e.g. measure parameters discretely vs. frequency points), not HOW the VNA hardware may be asked to get that data and how it does the data acquisition.
Then all that is needed for clients is a fairly generic stable interface for "data requests" that pretty much any VNA can somehow or other satisfy (given range limits, et. al.).
For the wrapper that supports that generic interface for a particular model of VNA then that would be reduced to something simple / stable and easily tested / regression tested since the API of the VNA exercised by its interface wrapper implementation would be simple, consistent, and possible to optimize (or work-around) completely arbitrarily without modifying either the SW client code or the VNA protocol implementation / VNA firmware.
One could transparently talk to GPIB, Ethernet, USB, serial port, whatever VNAs with the same client side API.
Obviously if there are certain "access patterns" which are important to be able to represent to optimize the VNA's throughput / latency in responding to them then defining the API interfaces so they can express asking for a batch / vector of data or whatever could be interesting to consider. The client could ask for anything as fancy as it wants as a "batch transaction" / request vector within the limits of the defined API but the API implementation could freely simplify or optimize that as much as it can for a particular back-end device protocol.
At first I thought you were referring to these low cost VNAs that this thread is about, until I saw your mentioning of Ethernet and GPIB. It seems like you are interested in writing a generic VNA program. This sounds like an interesting project but I am not sure how you would pull it off. Normally, when it comes to test equipment, if I see generic software, it will have very limited capabilities.
I have a few VNAs and each is very unique. It's not just the physical layer, or the protocols used. The systems are totally different. One has a mechanical interface that can't be controlled remotely. In this case, I prompt the user what they need to do. The features they support can also be very different. For example, I have one that can do spectrum analysis. If you want to measure S11, you have to manually insert a directional coupler. My less crappy VNAs support log or linear sweeps. They also have basic features, like attenuators. The attenuators may require manual setting or they can be remotely set. Then there are countless options you are not going to find in every VNA. To top it off, you would somehow need to rent or procure all these VNAs, learn how to use them, maintain them.
Some flavor of my software runs on all of my VNAs. There is a common library which for the most part contains all the number crunching stuff. For each VNA, there is a top level program that supports their unique feature sets. Finally, there is an interface layer.
For the low cost VNAs, the problems I have ran into are poor documentation and unstable firmware.
It will be interesting to see what you come up with and what instruments you support. Maybe start up a new thread for your generic VNA software.
-
Thanks for the post. It was a good read.
I own a modest amount of test equipment and most of it is controlled remotely. Most is from major brands. The documentation is well written and the systems are fairly bug free. For me, putting together software for them has never been easier. Its rare I need software that would say, record data from a meter. It's more common that I want to read the meter as part of a much larger setup involving other equipment all tied together.
The VNA is no different. If you look at my software, you will find it has the ability to control a linear stage. This isn't something you will normally find in any VNA software. Having the ability quickly and effortlessly change the software to run more complex experiments is really powerful.
It is certainly possible to make external calls from LabView. I would frequently use MSVC to write code that needed to execute faster or more efficiently. However, I have not had to resort to that in several years. The modern PCs are so fast I now just use LabView for anything PC related.
From my experience with that first Nano, it became apparent that with it being opened source, a lot of people were interested in making their own changes to try and improve the firmware. It seemed like it would be a never ending battle to find something that worked well enough to use. It was bad enough that I put together a simple regression test to automatically check the firmware of the week. Much of the changes were focused on features I really had no use for rather than addressing the problems.
Not surprising, none of my vintage VNAs are open source. I'm not against it but when you have people making changes who really don't understand the problems they can cause, it's doing more harm than good. In the case of the original NanoVNA, having the source allowed a few people to address the basic problems and get it working. So there can be an advantage depending on the skills of the people working on it.
At least for these low cost VNAs, my demands for the firmware and hardware are simple. Document your code, allow the software to control what ever peripherals are attached and send down good data. Getting good data off the Nano was always a problem. Not because the protocol was complex or the PC lacks performance. It was just bad firmware. Oddly, more commands were added rather than correcting the root problems which had nothing to do with the protocol. Once the locals sorted out the basic problems, there was no need to do any more with it. I am surprised that much of what I saw with the early firmware is still a problem with the latest releases.
If people want to try and run my software with the original NanoVNA, the manual is pretty clear about different firmware/hardware combos being a problem. All the software in the world isn't going to make bad firmware/hardware good. We need a solid foundation to build on.
Looking at the LibreVNA, it seems like they are having problems with their software and firmware. While the moderators of some of the groups (for example https://groups.io/g/NanoVNAV2) have chosen to make them private (which I see it as a dick move), the LibreVNA group seems to want to sensor the posts. That was enough to turn me off of it. Hopefully OWOs team will roll something out that can measure lower frequencies, with a higher resolution (at least at lower frequencies) and an increased upper frequency range beyond the capabilities of the V2Plus4. Even if they kept it closed source, as long at the interface is documented, I would get one based on my experience with the V2Plus4. Even if they just improved the V2Plus4 to allow it to fully replace the original NanoVNA, I would get one.
I was mostly referring to the low cost ones here, I was just extending the example how the same basic "I want to measure X at frequency Y" approach is vendor / model / VNA / interface neutral and could apply to high end units or low cost ones.
I gather that the tower of babylon of both interface hardware as well as interface apis & protocols is a fairly major annoyance with respect to cross platform applications that control and access test equipment in general. It seems like it doesn't need to be so bad these days one could have a simple HTTP/REST or JSON or XML or database or something based neutral exchange layer and then the instrument driver can go off and get the data however it wants, and the client applications can fetch/use the data however they want.
So far I've just got one nanovna model and no "boat anchor" devices. But even just with that it's getting hard to keep track of what nanovna variants there
are and what the differences in their hardware capabilities are not to mention what differences exist in their protocols and firmwares with respect to how to talk to them from a client application and what works / doesn't.
Eventually I'd like to upgrade to measure to 6GHz, low frequency / narrow bandwidth crystal parameter measurement, and PDNs but given what I see in this thread and the mailing lists being full of "but X doesn't work on model Y, and Z doesn't work on firmware Q" it's seeming out of hand.
I get that they're trying to build it down to a cost level but it seems so penny wise pound foolish to have all the variants of these tiny little MCUs running mutually incompatible firmware as the interface. They could just have made it so the processor board was pluggable e.g. arduino interface or something and then one could at least upgrade the CPU and the host interface (e.g. ethernet) so one wouldn't be quite so limited in terms of MCU and interface quirks / limitations by spending a few more optional dollars on a better controller.
Anyway I'd be willing to write a wrapper and API layer for these things in spare time but I don't have nearly enough hardware variants to make it very useful in the sense I couldn't port / test things to different devices without those protocols / devices available.
And in the client end since in your code's case you run labview I take it that'd mean it'd be more oriented to a C-API + DLL or better yet something over IP/UDP/TCP/HTTP or something that'd be much more portable cross client sw / platform.
I suppose if there was a simple suite of unit / system tests and a half decent client API / protocol in a few variants that might be enough to get some of these VNA firmware developers / manufacturers to be interested enough to support it instead of making everything firmware / device unique.
One thing I don't understand is the whole firmware / protocol business. I gather that the nanovna v2 being open hardware (and open source, maybe, I think?) is something that's not representative of what other devices are / will be. So I don't even know if there's open firmware / protocol documentation for any / many of the other low cost VNAs at this point or what. I saw mention to sniffing the protocol of something or other so I guess that's one way to reverse engineer at least what the serial command / response sequences are for a given firmware/unit, though if that's really all there is to rely on for most of these devices then it's a bit sad state of affairs.
I am wondering if there is NOTHING relevant / compelling about the "boat anchor" APIs, SCPI, whatever for "lowest common denominator" basic VNAs that nobody thought practically of just reusing those protocols exactly or if needed extending them slightly vs. reinventing the wheel incompatibly....
-
Robert Feranec, PCB Layout & Decoupling - Explained why it's so complicated
I've watched a few of his interactive interviews. He does a good job with them.
**
If it's not obvious, the reason including this series here is it explains the basics of PDN design, simulation and measurement. In part 3, they use the Bode 100. Could we use the $50 NanoVNA and a couple hundred bucks of hardware to make this same measurement?
https://www.youtube.com/watch?v=5Ca0Eah7eKI (https://www.youtube.com/watch?v=5Ca0Eah7eKI)
https://www.youtube.com/watch?v=Tt8X6_maj6c (https://www.youtube.com/watch?v=Tt8X6_maj6c)
https://www.youtube.com/watch?v=hZSOhVdzqZk&t=0s (https://www.youtube.com/watch?v=hZSOhVdzqZk&t=0s)
-
A draft manual for 2.0 is now available. Of course the TOC was updated along with the what's new. The main changes are at the end where it describes the difference in the new version and the new PDN measurement feature.
Hi Mr. Smith,
I would like to try out your new PDN measurement feature and may have the chance to borrow some DC-blockers and maybe a professional common mode transformer for short time.
Did you upload the two announced versions 2.0 for both VNAs already?
The last version that is visible for me is p1.08 and for the V2Plus4 it's p1.04 in your GitHUB repository.
However, as for my privat use I would like to build up the blockers and the CMT like yours, would it be possible to post the partlist and the 'how to' for this in more detail some time?
Thank you very much for all this investigations and education up to now!
-
A draft manual for 2.0 is now available. Of course the TOC was updated along with the what's new. The main changes are at the end where it describes the difference in the new version and the new PDN measurement feature.
Hi Mr. Smith,
I would like to try out your new PDN measurement feature and may have the chance to borrow some DC-blockers and maybe a professional common mode transformer for short time.
Did you upload the two announced versions 2.0 for both VNAs already?
The last version that is visible for me is p1.08 and for the V2Plus4 it's p1.04 in your GitHUB repository.
However, as for my privat use I would like to build up the blockers and the CMT like yours, would it be possible to post the partlist and the 'how to' for this in more detail some time?
Thank you very much for all this investigations and education up to now!
Hello. I haven't released the new versions to the public domain yet. I am not sure when you will see them. The document is being reviewed. I am still finding minor problems in the software. For the first time today, I tried it on the the V2Plus4. Once things seem fairly stable, I plan to put together a video demonstrating the new features, most likely using the old hardware. It all takes time.
Someone wrote me how my software would calibrate their V2Plus4 but would throw checksum errors when running sweeps. I've never ran into this and it really makes no sense. So I would like to see if they can supply enough information to replicate what they are seeing. That would be a major bug and makes the software worthless if that is really what is going on. I would like to sort that out before releasing it as well.
The DC blocks shouldn't pose much of a problem but the transformer took some effort to sort out. I am holding out for JohnG's transformer as it sounds like they have a lot of expertise in this area. They don't seem to agree with how Brian collected the data or some of the measurements that have been made. So give them a little time and let's see what they come up with.
If you have a access to a VNA, it would be interesting to measure the performance of the transformer you plan to borrow.
-
Running the new software on the V2 Plus 4. It's really too bad this thing can't out perform that original hardware. Every time I use it, I am reminded just how slow the old hardware/firmware is.
While I have not seen any sort of checksum error I wonder if there is a problem with the newer firmware. I have never has a reason to change mine and it was shipped with git-20201010-86c7055. If you check their store, they don't list it.
What's really odd is when they claim they can cal it but not sweep. Both require data to be read. It's the same section of code. And if there is a checksum, I flag the error and throw out the data. So I don't see how it would calibrate. I use the same commands to control the V2Plus no matter if I am running a calibration or sweeping. It's a really odd problem assuming it actually exists.
-
There are no checksum errors from my unit.
I have one I believe from the first lot of 2021 delivered in April.
The firmware version is git-20201013-32077fd
I am using the Microsoft port driver 10.0.18362.1 that was installed automatically by Windows 10.
I added the through measurement of a Nooelec Inc. 50kHz - 8GHz SMA DC block after normalization with a simple through with 201 point segmented sweep both.
It is important to rewrite the sweep points setting to 201 after each segmented sweep.
Otherwise if this is above 1024 the software hangs sometimes...
-
With the V2Plus4 supporting over 1000 points, I'm not even sure I tested the segmented option with the old software and would not be too surprised if there were problems with it. With 2.0, the code for the segmented sweep has been changed a fair amount. I just ran eight consecutive sweeps with 1024 points and saw no problems.
Starting 40KHz lower than the unit supports may be part of the problem. Then again, your firmware/hardware combo may provide acceptable results down to 10KHz. It would be very easy to coerce values to the limits of what the Nano supports but I see no need for it. The software wasn't written for the beginner and I assume the users knows what they are doing. Taking this approach makes the software more generic and if in the future the limits are changed, there is no need to release new software to support them.
It's also very possible the older software did not restore the original values and you would have to reset everything between runs (which would include the number of data points). The firmware may not like the software setting values out of range. Now that I have a need for segmented sweeps, this feature was rewritten to make it easier to use.
Good to know that you are not seeing the checksum errors with the newer firmware. That person has yet to respond with any additional information.
-
I think we have our checksum problem sorted out. They were not using the stable release and also some of DisLords firmware. The checksum faults appear to be when they are using DisLord's firmware. I have no plans to try and support the firmware of the week so no problem.
-
Been busy with other projects but Flipper and I spent some time going over the entire document. They had some good input that makes it a little easier to read. It's now available on-line.
They were asking about the firmware for the original hardware. I rolled back after running into problems with the latest releases.
https://github.com/qrp73/NanoVNA-Q
I haven't had a lot of time for testing the software. It appears stable enough. Hopefully I will have some time over the next week to put together a short demo and get it uploaded. If there's something you would like to see, now's the time to ask.
-
...
I would like to try out your new PDN measurement feature and may have the chance to borrow some DC-blockers and maybe a professional common mode transformer for short time.
...
Making some progress and have started working on the video to demo the new software. Are you planning to try to use your V2Plus4 or one of the other VNAs? The software for it still needs some work and may not be released at the same time.
I have added the image of the firmware I am using in the original NanoVNA to Github along with a link to their repository.
Hope to have the video and software for the original uploaded this weekend.
-
Looking at the LibreVNA, it seems like they are having problems with their software and firmware. While the moderators of some of the groups (for example https://groups.io/g/NanoVNAV2) have chosen to make them private (which I see it as a dick move), the LibreVNA group seems to want to sensor the posts. That was enough to turn me off of it. Hopefully OWOs team will roll something out that can measure lower frequencies, with a higher resolution (at least at lower frequencies) and an increased upper frequency range beyond the capabilities of the V2Plus4. Even if they kept it closed source, as long at the interface is documented, I would get one based on my experience with the V2Plus4. Even if they just improved the V2Plus4 to allow it to fully replace the original NanoVNA, I would get one.
[/quote]
Hi Joe,
Just a short comment to make the things clear. What's concerning the LibreVNA group at groups.io.
I have asked Jan and he told me that this is unofficial group. It had been created by unknown person before the official LibreVNA group started, so nothing could be done about it.
In any case, You can reach Jan directly.
-
Looking at the LibreVNA, it seems like they are having problems with their software and firmware. While the moderators of some of the groups (for example https://groups.io/g/NanoVNAV2 (https://groups.io/g/NanoVNAV2)) have chosen to make them private (which I see it as a dick move), the LibreVNA group seems to want to sensor the posts. That was enough to turn me off of it. Hopefully OWOs team will roll something out that can measure lower frequencies, with a higher resolution (at least at lower frequencies) and an increased upper frequency range beyond the capabilities of the V2Plus4. Even if they kept it closed source, as long at the interface is documented, I would get one based on my experience with the V2Plus4. Even if they just improved the V2Plus4 to allow it to fully replace the original NanoVNA, I would get one.
Hi Joe,
Regarding the LibreVNA group at groups.io.
I have asked Jan about Your case and he told me that this group had been created before the official LibreVNA group started and is moderated by unknown person, so this is unofficial group and even the creator of VNA (Jan) could do nothing with it.
Sorry to hear that,
Alex
Hello Alex.
Outside of yourself and a few others asking me about it, I wouldn't have attempted to join the LibreVNA group and post. I no longer follow it's progress.
For those of you interested in getting a glimpse of the latest software for the NanoVNA, here you go. I hope to have the software uploaded soon. I plan to leave the latest 1.x releases.
https://www.youtube.com/watch?v=Y8ouApeex78 (https://www.youtube.com/watch?v=Y8ouApeex78)
-
The software that I used to create the video is now available at:
https://github.com/joeqsmith
I have not yet uploaded the software for the V2Plus4. It will need some runtime first but it should be available in the next day or so.
-
Hi Joe,
Just a short comment to make the things clear. What's concerning the LibreVNA group at groups.io.
I have asked Jan and he told me that this is unofficial group. It had been created by unknown person before the official LibreVNA group started, so nothing could be done about it.
In any case, You can reach Jan directly.
If you go to the designer's github account :
https://github.com/jankae/LibreVNA
Under Quick Start, "For general questions or discussions, the LibreVNA group is probably the best place."
The link points to https://groups.io/g/LibreVNA
This is the only group I am aware of. If there is now an official group as you suggest that is no longer censoring the posts, please provide the link to it. You may want to suggest that the designer also provide that new link from their git account as well.
OWO chimed in on their new design as well and provided the following link:
https://nanorfe.com/nanovna-v3.html
Preliminary specifications:
100kHz - 6GHz frequency range without using harmonics (I would like to see 10kHz or lower and at least provide the resolution of the original NanoVNA.)
120dB dynamic range to 3GHz, 100dB dynamic range to 6GHz (120dB ??!! If it could do that at 10kHz, it opens up a whole new market)
Higher dynamic range at 6GHz compared to 50dB dynamic range of existing open source VNAs
0.01dB trace noise
0.1dB typical measurement uncertainty (neglecting cal kit errors)
Superior linearity error compared to existing 6GHz open source VNAs
10k points/s maximum sweep speed (Now we're talking. )
Full two port - measures S11, S21, S12, S22
Adjustable IFBW from 10Hz to 100kHz - can measure narrowband devices
Supports Unknown Thru and other advanced calibration methods
Supports NanoVNA-QT and NanoVNA-Saver software (Don't care)
TDR with millimeter level resolution (Ditch that LCD and let the PC do its thing)
Estimated price $400 (If it ran down to 10kHz with decent resolution, I know a few people that are going to be very interested in it.)
Discussion group: https://groups.io/g/NanoVNAV3
-
Thanks for pointing it out, great specs.
It sounds like the new design from OWO would outperform all others.
-
Hi Joe,
unfortunately there is no CMT availabe in the company laboratories for this PDN ground loop breaking measurement stuff.
So there is nothing to borrow and I need to build it by my own, too.
I have both like you the original NanoVNA-H and the V2plus4 and I strictly only want to use your firmware/software version combination. (Nevertheless, higher data rate would be a desiarable goal, of course...)
For this output resistance measurement / PDN I found a hint to break the loop with some active stuff is possible, too.
This may be possible below your final CMT budget of 200$
Most of your cost for your CMT-design are for the SMA-connectors that is not only for low ohmic resistance, is it?
I also checked the NanoVNA-H schematics if breaking the ground connection of X2 is another way.
Seems that the mixer SA612AD inputs are decoupled anyhow and the X2 ground may be set to 'semi-floating' with some aditional passive components... (That's touching my knowledge limit but stimulates my curiosity:)
Anyway, thanks for uploading the software!!! I need to try it as soon as possible.
-
Hello Joe,
Thank you for updating your software and making an interesting video.
I have downloaded the new software and renamed + replaced it with the original .exe which was included in the installer.
The original works fine, it finds my S-A-A V2 / V2.2 fine - here is what it reports: NanoVNA V2+, Protocol 1, FW 1.2
The new, and even the older versions, will not make the VNA go into 'USB MODE' and in your software the link button goes orange, but the green light never lights up.
I looked into your documentation, and it says it supports the original and V2 Plus, but there is no info on revision 0.1
- is the V2.2 supported in the new 2.0 software?
- if not, can you make it compatible with the V2.2?
Thanks, it is an awesome tool!
Egon
-
Thanks to pointing it out, John.
Yes I had seen the Owo's v.3 newest VNA design specs.
It sounds like the new design from OWO would outperform all present ones.
This really makes no sense to waste time trying to adopt the software for other VNA's.
I should agree with You
As long as the firmware and hardware are stable and the interface is well documented, it's been fairly easy to port the software to different VNAs. As long as there is open communication, we can work around it. With the LibreVNA, they chose to censor the posts. That's really the deal-breaker.
So far, I have not seen that with OWOs group.
-
Hi Joe,
unfortunately there is no CMT availabe in the company laboratories for this PDN ground loop breaking measurement stuff.
So there is nothing to borrow and I need to build it by my own, too.
I have both like you the original NanoVNA-H and the V2plus4 and I strictly only want to use your firmware/software version combination. (Nevertheless, higher data rate would be a desiarable goal, of course...)
For this output resistance measurement / PDN I found a hint to break the loop with some active stuff is possible, too.
This may be possible below your final CMT budget of 200$
Most of your cost for your CMT-design are for the SMA-connectors that is not only for low ohmic resistance, is it?
I also checked the NanoVNA-H schematics if breaking the ground connection of X2 is another way.
Seems that the mixer SA612AD inputs are decoupled anyhow and the X2 ground may be set to 'semi-floating' with some aditional passive components... (That's touching my knowledge limit but stimulates my curiosity:)
Anyway, thanks for uploading the software!!! I need to try it as soon as possible.
For the H4, I suggest you read the following few posts before spending too much time with it.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3586023/#msg3586023 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3586023/#msg3586023)
The last transformer was the highest cost. Around $200 or so. $100 just for the two connectors. The SMAs I used are less expensive. The tape wound cores are also very expensive. You don't need a box with bulkhead connectors. You may be able to find some good cores in some old power supplies at the scrap yard. Maybe consider trying some really inexpensive connectors from China. Another option is to buy something ready made.
Yes, that op-amp solution was talked about in one of the videos I linked. The down side is you may want something with with better performance at higher frequencies. It's all a trade off. This includes the transformer.
I see it all as a learning experience and encourage anyone wanting to try it out to just start experimenting. You don't need to spend a lot of money to learn some basics. If you need something better, you will be in a better position to make good choices. Keep in mind, this whole NanoVNA thing for me started out with my friend Flipper wanting to spend some coin one a real VNA. They had no idea how to use one beyond spending a small amount of time with me. At least now, I think they are smart enough to know what features they need when they finally do buy one.
-
Hello Joe,
Thank you for updating your software and making an interesting video.
I have downloaded the new software and renamed + replaced it with the original .exe which was included in the installer.
The original works fine, it finds my S-A-A V2 / V2.2 fine - here is what it reports: NanoVNA V2+, Protocol 1, FW 1.2
The new, and even the older versions, will not make the VNA go into 'USB MODE' and in your software the link button goes orange, but the green light never lights up.
I looked into your documentation, and it says it supports the original and V2 Plus, but there is no info on revision 0.1
- is the V2.2 supported in the new 2.0 software?
- if not, can you make it compatible with the V2.2?
Thanks, it is an awesome tool!
Egon
Egon,
The only hardware I currently support is the original NanoVNA and V2Plus. The rest are untested. The firmware is a total shit show.
As I explained in the video, 0.1 is used to install the LabView runtime, NIVISA and INI files. As you have found, 0.1 supports the V2Plus but I am not sure why anyone would use it rather than the latest release.
The video, documentation, along with my posts should have made it clear that you need to use the software for your specific VNA. You have downloaded software for the original NanoVNA and are expecting it to work with the V2Plus. I'm not sure why you would think that would ever work but believe me, it will not.
There certainly is a version of 2.0 that supports the V2Plus. I mentioned it here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3595962/#msg3595962 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3595962/#msg3595962)
The video mentions it not being very useful due to the limitations of the V2Plus design. Don't expect the software to fix that.
-
I had ran into a minor problem while testing the 2.00 release for the V2Plus4 which could cause problems with slower PCs. I have made a minor change to turn off the peak detector when a sweep is being performed. This change was also made to the software for the original NanoVNA.
They are both available on-line.
-
I ended up rewriting the peak detector to use a recursive algorithm which greatly improved the performance. No other changes were made. Both programs have been updated and are available.
-
I've had a few people recently ask where to find the software.
-
So this is crazy:
I ordered an original NanoVNA and in fact a Hugen NanoVNA-H (not H4 !) was delivered.
There is some improvements to the -H but not affecting the sampling and software/firmware part.
(Believe the only improvements are in fact the Lion battery, the USB-C and the metal shielding inside. I attached both schematics and there is the same Microcontroller that should behave same if programmed with same firmware, should it?)
It is delivered with the NanoVNA-Q firmware version 1.0.45. (with this it supports down to 10kHz) https://github.com/hugen79/NanoVNA-H
I attached it to Joes software 2.0 and 2.02 and there are no errors and the green light is on and it calibrates and it sets the start and stop frequencies correctly even in segmented sweep but it never displays any curve in any of all the main windows graphs nor in the advanced bode graph.
As the hardware is said to be compatible I installed edy555 0.8.0 https://github.com/ttrftech/NanoVNA/releases/tag/0.8.0 transferred with STs DFU file manager from hex to dfu format and flashed with DfuSe but exactly same behavior. (with this version curiously the standalone device as well as with Joes Software only supports down to 50kHz.)
With this one https://github.com/qrp73/NanoVNA-Q it goes again down to 10kHz.
Now I am curious which version you are using with your original "NanoVNA" . Thought you stuck at the edy555 0.8.0, but this starts at 50kHz !?
-
Tell me you hit the sweep button.
-
Yes, I did a segmented sweep in the picture case.
But there is may be a problem with the autoscaling?
Because after connecting with the Link-Button and first time press the Sweep-Button the Graph scales somehow once.
-
Above my pay grade.
Your pic above my first reply did not have the upper right sweep button engaged.
-
Don't worry.
I'm glad that there is at least you hanging around in this forum to encourage me to keep trying.
-
Let me re-read the manual and have a go at a segmented sweep, as I've never tried it.
BIAB.
-
Which nano do you have?
-H
-H4
without any H ?
It is not related to the segmented sweep, there is no graph displayed at all. It only updates inside the Nanos display.
The data is continuously refreshed in the Setup/Diagnosis->DumpTerminal window
but
it is not updated in the NanoVNA Raw Data window.
-
It is not related to the segmented sweep, there is no graph displayed at all.
Ah... sorry. I misunderstood.
Hmmm... Does this happen with the older version 1.08?
-
Hi,
thanks for trying! Good to knew that this works with 1.0.64 .
Yes, it does the same strange things with the V1.08
But seems that the Raw data is somehow out of range as shown in the attached picture.
Is it related to this INI-File stuff?
-
Is it related to this INI-File stuff?
I wouldn't have a clue. I just like looking at the pretty squiggles.
-
One last question... Did you download and install https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10 before you opened up 2.02?
-
No.
I had already some LabVIEW Runtime versions installed. And VISA was installed, too.
So I only had install the 2011 Runtime and then the V1p04 sofware for the V2plus4 worked.
You are right:
I may need to try the Software V2p01 with the V2plus4, now, to check if this still works.
-
I may need to try the Software V2.02 with the V2plus4, now, to check if this still works.
I believe the plus requires a different version of software, but no harm trying.
-
So this is crazy:
...
I attached it to Joes software 2.0 and 2.02 and there are no errors and the green light is on and it calibrates and it sets the start and stop frequencies correctly even in segmented sweep but it never displays any curve in any of all the main windows graphs nor in the advanced bode graph.
...
(with this version curiously the standalone device as well as with Joes Software only supports down to 50kHz.)
Seems rather obvious. You are not from this country and changed your PCs regional settings to use the comma. I suspect no problem other than failing to read the manual. It's a common problem. If it's not this and you feel there is a problem with my software, you need to provide more detail.
-
I am on your side!
I suspect my error in this area.
But what I have tested already:
I placed the nanovna.ini into the same directory like your *.exe
First I gave it the full content:
[NanoVNA]
server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.paranoid=True
server.tcp.serviceName="My Computer/VI Server"
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"
DebugServerEnabled=False
DebugServerWaitOnLaunch=False
useLocaleDecimalPt=False
Later I deleted all except the last line.
That both did not help....
There may be sometimes more lines different from "NaN +NaN!" sometimes less.
If I switch to "Xman rectangular" and both channels are read there is only "NaN +NaN!" left.
Next I will try to switch the regional setting in windows10 .
Besides this: Why did everything worked some days ago with the V2plus4 combined with the dedicated software V1p04 without nanovna.ini ?
Although sometimes it may sound like I/someone is blaming your software, I never would!!! This is provided free of charge and created with your private time as a hobby, which deserves my full respect and I just hope to get some guidance to fix the problem...
-
With the V2plus4 still everything is fine with both the V1p04 and V2p01
Thanks again for this extraordinary software!
When I observe the raw data in the V2plus4 software both versions there is always a comma separator displayed in the raw data window independent from the existance of the nanovna.ini.
-
With the "original" Nano I switched the regional settings to decimal point and now the Raw Data Display displays this.
With the old calibration done with comma again no graph was displayed and there are mostly "NaN +NaN!" (picture attached)
Then with a new calibration with the decimal point selected in the windows regional settings everything is fine. Yeah!!!
So finally there is these questions left:
Why is the V2plus4 working in any case even without the nanovna.ini and with a comma selected in the regional settings ?
Why is the original Nano not working with the nanovna.ini in my case and needs to have the regional settings switched to deciamal point?
In which directory is the software searching for the INI-file?
Just as a footnote: Normally in Germany they use the decimal point to separate but I had to switch it for some Rigol or Keysight measurement software some month ago.
-
When I observe the raw data in the V2plus4 software both versions there is always a comma separator displayed in the raw data window independent from the existance of the nanovna.ini.
From the manual, LabView changes how the comma is handled when talking to external peripherals depending how the INI is set. The INI does not effect how the data is presented on the display.
I would have no way of knowing what you are doing. Every detail is important. For all I know you may feel that the 1.x and 2.x software shares the same calibration file format and are trying to use a 1.x cal with the 2.x software. I would have to guess as my crystal ball is out for service. Every detail matters. You may feel that firmware for the same hardware should use the same calibration.
For the original NanoVNA
If you read the posts in this forum, you know that DisLord was attempting to add a feature to the firmware to handle the comma. Does other firmware handle the comma differently? I have no desire to look into it. There is a reason I had settled on a version of firmware I use. Of course, if you took the time to read the posts here, you saw the whole first and second discussion about the regional settings. You are experimenting with the latest firmware available for your original NanoVNA, which I have said had problems and also why I abandoned them.
Why is the V2plus4 working in any case even without the nanovna.ini and with a comma selected in the regional settings ?
Let's assume you took the time to read the documentation they published for it. So you know that the V2Plus is using a completely different protocol and where the original NanoVNA uses ASCII, the V2Plus uses? Are the decimal and comma ASCII characters? This should have been obvious.
To sum it all up,
Read more, post less.
Create new calibration files for the software/firmware/hardware/cables/standards you are using at the time.
If you are trying to solve problems like this, don't make your problem even more complex by adding more variables like calibration. Learn to simplify your problems. If possible, learn to split the problem. In your example with the original NanoVNA, while you left out the fact you had changed your regional settings, it was pretty obvious you had. You could have used the default regional settings and standard INI (or no INI) and see if the problem went away. This is what I mean by cutting a problem in half.
If you can't solve your problem, detail every step so someone else can reproduce your findings.
If you like playing with the firmware of the week, expect to run into problems.
If you use one of the regional settings that supports the comma, add the useLocaleDecimalPt=False to the INI file. If you use the decimal, then leave this line out.
-
The following was posted on:
https://groups.io/g/NanoVNAV2/topic/vna_shootout/83798959?p=Created,,,20,1,20,0::recentpostdate%2Fsticky,,,20,2,0,83798959 (https://groups.io/g/NanoVNAV2/topic/vna_shootout/83798959?p=Created,,,20,1,20,0::recentpostdate%2Fsticky,,,20,2,0,83798959)
This is in reference to the previous testing I had performed with DisLords firmware.
On Tue, Jun 29, 2021 at 01:50 PM, Joe Smith wrote:
The firmware I use with the original NanoVNA supports 10kHz but once we get below 20kHz, the noise gets pretty bad.
Hello Joe,
I have measured with the basic nanoVNA and DiSlord firmware 1.0.50, 100 Hz bandwidth,
down to 1 kHz with low noise, see the screenshot below.
More details can be found at:
https://www.rudiswiki.de/wiki9/nanoVNA-Applications#WSPR_Audio_Filter (https://www.rudiswiki.de/wiki9/nanoVNA-Applications#WSPR_Audio_Filter)
Hello Rudi,
If you feel that 1.0.50 is the hot ticket, post a link to the image and I will gladly give it a run.
Hello Joe,
There are newer versions from DiSlord (1.0.64) but I will append the version 1.0.50
for the nanoVNA, which I used for the audio filter measurement.
73, Rudi DL5FA
Attached is the firmware and graph Rudi supplied.
****
Consider this post sticky. I'll add to it.
****
Converted Rudi's DFU image to HEX and attached. I installed it on the original NanoVNA and ran the regression test. This will take a few hours to run. The 10kHz test fails as we would expect as this version will run lower than that.
****
Rudi's graph swept a filter from 1k to 20kHz. While it would be difficult to tell much with this example starting at -20, we can see it dips to about -70 at 10KHz.
To evaluate the difference in the firmware, I plan to run two sweep ranges. 10k-50kHz and 10k-1MHz. This will be done using the same VNA, cables, cal standards and loads. My interested in the lower frequencies is for making PDN measurements and not audio filters. The demands for the Nano are much worse. I will use the resistive standards we came up with and we will be using the shunt thru method using one of the home made common mode transformers.
****
Should mention that the regression tests failed at the standard deviation exceeded the cutoff but I plan to proceed with the testing anyway.
-
Sweeping 10kHz to 1MHz with the 1mOhm standard inserted. Shown with firmware I use from 2019 compared with the image Rudi supplied and my old HP3589A.
I am not sure what is more interesting. How much of a problem the 1.0.50 firmware has, or how well the $50 VNA tracks my vintage HP.
-
From my previous tests, we know the limit of the NanoVNA is about 1mOhm depending on the time of day and wind direction. Here I have gone ahead and inserted the 100uOhm standard, again with a 10kHz to 1MHz sweep range. It appears we gave up about 10dB with the 1.0.50 firmware.
-
Sadly, AppCAD can't handle the uneven frequency steps when I use my poor mans quasi log sweep. If we are wanting to look at the regulators stability, most of the excitement is going to be at the lower frequencies. To get a better idea how the firmware effects the noise, I have changed the sweep range to 10kHz to 50kHz to give us a little better resolution.
Showing the 1mOhm standard. Notice how the firmware from 2019 has a higher noise level as we start to go below 20kHz. This is what I had mentioned in the video. You can run it lower but be aware of the error. But check out once we get beyond 20KHz. It tracks very close to the vintage HP. The 1.0.50... well you can see for yourself.
-
Of course, we have to run the 100uOhm in this same range. And what do you know, it does what we expect.
Those of you following this thread may be looking at the HP's -100dB and ask, how did I measure that 100uOhm resistor. Well, as you can see, that old HP is just not up to the task and my Agilent VNA while it has higher performance, sadly it will not run down this low. The only way I have to measure it is with the Signal Hound. That's one of the few newer bits of equipment I own and I really like it.
-
Of course, I can use my software to run a quasi log sweep and then use it to overlay the data.
I have reloaded my NanoVNA with the old image and plan to stay with it. Again, I had mentioned the regression test and how the new firmware fails the standard deviation. The noise isn't only bad at these lower frequencies. Of course, if you need to actually measure down here like I have been attempting to do, I think you will need to spend more than $50. I had asked OWO if they would consider supporting lower frequencies than 100kHz. They are talking 120dB dynamic range and so far, they are not discludeing the lower bands. Full two ports, and they claim it's fast, real fast. They already have posted that they have considered the narrow band measurements this time around. I'm starting to salivate... :-DD
-
Please, can you attach your old golden firmware image?
I'm still confused which one it is even if I read the whole thread again!
-
Please, can you attach your old golden firmware image?
I'm still confused which one it is even if I read the whole thread again!
Odd as I had specifically written you the other day about this in an attempt to help you get started.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3594970/#msg3594970 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3594970/#msg3594970)
In case you still can't find it, please see the attached. I suspect you are going to have a lot of problems trying to make use the software. Again, it's certainly not for the beginner. It's an engineering tool at best and will require you to spend time reading and doing your own research.
I think back when I created that first video and how many people were whining about me not releasing it. It was very common for people to suggest they would not need support. :-DD :-DD Back then the software wasn't as stable and there was no manual. Now it's a few years old and runs well enough that I use it, and for those wanting to try it, there's a few hundred page manual to tell them how.
-
:palm: Found! :-+
Just a question regarding the CMT:
Is it worth it to try this toride from digi-key:
2258-T60006L2050W565-ND
399-19161-ND
399-ESD-R-57S-ND
-
Is it worth it to try this toride from digi-key:
2258-T60006L2050W565-ND
399-19161-ND
399-ESD-R-57S-ND
If your goal is to meet or improve on the Picotest transformer, then I would just suggest buying one. If you don't need the wide bandwidth, Omicron offers one that costs much less.
If your goal is to learn about material selection and winding techniques, I think anything is fine. You should be able to use the VNA to compare the data sheets with the data you collect. I could see this exorcise being helpful. From your posts, it seems you are just starting out. I suggest not spending anything. Again, I would just go to the local scrap yards and see what you can turn up. You don't need to know what the cores are to learn something.
-
There was some discussion on material selection not too long ago. Based on your part numbers, I suggest you take the time to read what was posted. It may save you some time and money.
https://www.eevblog.com/forum/rf-microwave/impedance-measurement-with-vna-using-series-shuntseries-through-methods/msg3564573/#msg3564573 (https://www.eevblog.com/forum/rf-microwave/impedance-measurement-with-vna-using-series-shuntseries-through-methods/msg3564573/#msg3564573)
-
While running that last little experiment for Rudi, I needed to add support to save the larger segmented datasets to Toushstone format to allow me to compare it with the old HP. Of course it doesn't address the fact that AppCAD can't handle the quasi log data. I may add my own data viewer later on as AppCAD had problems with different data set sizes as well. The software has an import for single port Touchstone files but it is very limited.
Anyway both programs have been updated and are now available.
-
Any ideas what the cause of the error with the new firmwares are?
DisLord is quite responsive when it comes to fixing bugs and adding
features, language barrier could be an issue ...
-
A post from our friend OWO:
Lower frequencies, possibly. I'm investigating a new technique for getting around the LF limitations of the mixer. If it works out then down to 10kHz could be possible.
I am now laying in a pool of my own drool. I understand they plan to stay with basically the same protocol as the V2Plus4. This should make supporting it fairly simple.
-
Any ideas what the cause of the error with the new firmwares are?
DisLord is quite responsive when it comes to fixing bugs and adding
features, language barrier could be an issue ...
I suspect part of the problem is in these features you mention. While Rudi's post is looking at audio filters, I would have expected them to use other equipment to run their experiments (sound card for example). If people interested in audio were the catalyst for pushing the lower frequency limit, its a shame as it appears to have hurt the NanoVNA's performance. Of course, there were other problems we have talked about in this thread which were solved a few years back (Thanks to the locals) but it seems were never adopted into the main releases.
-
I don't remember many features related to low frequency work, but I will read the posts in
this thread and see what issues others had.
In the meantime I would urge everyone, that has found a bug, to open an issue at: https://github.com/DiSlord/NanoVNA-D/issues
OSS is about user feedback ...
-
It may be difficult in some cases to define what's a bug. In the case extending the lower frequency, I can imagine you would have a group of audio people thinking this was a very smart thing to do and promoting what a great feature it is. Contrast that to someone attempting to measure very low signals and pushing the hardware for all it has to offer. Who's right? Others may desire faster sweep rates while giving up stable data. Are these design trade offs or bugs? What may help one group may hinder another. I can only speak from my own perspective.
Rather than spending time trying to chase down such matters, I just stay with with a two year old version that was good enough to make the device somewhat useful. For a $50 VNA, with the right firmware, it can throw up some pretty impressive data.
I do wonder how well Rudi's image actually performs at 1kHz. Obviously they are happy with the data but I wonder how the it would compare against an instrument designed for lower frequency applications......
Shown is Rudi's 1.0.50 image installed into my original NanoVNA with a 50,60 and 70dB attenuator inserted. What is interesting is when we compare this with the data Rudi had supplied. Do you think that is really what their filter looks like? Maybe...
Now lets run that same 70dB attenuator on my vintage HP3589A.
I really question why any effort was placed in pushing the NanoVNA below 10kHz, especially when it is a detriment to the performance above 10kHz.
-
> I do wonder how well Rudi's image actually performs at 1kHz.
Hello Joe,
There are 2 parameters I did not mention in my post:
1. The scan bandwidth was 100 Hz.
2. The Audio Filter was designed for 600 Ohm impedance.
The whole story is documented at:
https://www.rudiswiki.de/wiki9/nanoVNA-Applications#WSPR_Audio_Filter (https://www.rudiswiki.de/wiki9/nanoVNA-Applications#WSPR_Audio_Filter)
73, Rudi DL5FA
-
Hi Joe,
now that I saw an image of 'regression.PNG' in message # 1157 so I wonder exactly what you are testing?
Specifically, what does the test cover? What are you examining and with what characteristics?
So far, the information on this has been so much that it does not pass this test. OK, but what does this test do?
It is not found in published programs, so guesswork remains.
What do you expect from this hardware? Maybe the same expectation as the referenced HP3589A?
I think since the Chinese copied this device and started manufacturing it with some bugs, you have been reading or reviewing information about it ever since. I understand you also want to use it for crystal filter sorting. If you look at the improvements from the manufacturer or the original developer and the others, you will see that neither is aimed at this. So I would love to read about what your expectations are for you. But not that the frequency command has since been removed from shell commands. This is not true, 'freq' and 'frequencies' are still existing commands and can be easily checked with any terminal prg.
To the best of my knowledge, DiSlord has done and will do a lot in our spare time to make it easier for our users to use.
This includes firmware. The regional '.' use (separating the integer and decimal characters) was discussed in the software created by OneOfEleven and solved the automatic recognition.
No, I'm not asking you to get involved, I just remarked that She did. This makes your program great to use if every step in the process is followed. This is aided by the manual, which users tend to read last when they get stuck in what they think is correct.
Finally, I note that it is a novelty for many of us to measure with VNA.
I’m not even talking about how many options we don’t use or just need it sometimes
Thank you for reading..
-
Hi Joe,
now that I saw an image of 'regression.PNG' in message # 1157 so I wonder exactly what you are testing?
Specifically, what does the test cover? What are you examining and with what characteristics?
So far, the information on this has been so much that it does not pass this test. OK, but what does this test do?
Hello.
First, that was a well written post.
Its been almost two years since I was actively involved with the firmware. If you're interested in the background and have no interest in the context, I would start reading on page 21.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2732360/#msg2732360 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2732360/#msg2732360)
It is not found in published programs, so guesswork remains.
That is correct. When I decided to release the software to the public, three things needed to happen. Move to a common code base (make it easier to maintain), document the software (avoid simple questions) and remove features no longer in use (clean it up). I had been using the Nano over a year by then and I had long stopped chasing firmware.
I would imagine the people working on firmware have their own regression tests they use to insure the quality of the code they put out. If you're interested in seeing what is being done today, I would start there.
What do you expect from this hardware? Maybe the same expectation as the referenced HP3589A?
The 3589A is limited to 150MHz. It can perform measure S11 but requires an external coupler. I use it a fair amount for low frequency work. I also have a 1970s 8754A. It supports up to 2.6GHz. It includes a transfer relay in the test set allowing it to make full 2-port S-parameters. You can't use it for narrow band work. It drifts a fair amount. On the low end, they claim it's good for 4MHz. It has a mechanical interface... While very crude, I learned most of the basic math from it. It was replaced it with a vintage Agilent PNA. Nice unit. 4 receiver, .... My only complaint with it is the low end is limited to 300kHz.
My point, I don't own a do all VNA that I would consider a gold standard. My home lab is more an active historical museum. Each bit of equipment has it's place. As I have stated many times, my only expectation for the NanoVNA was to help educate a friend of mine on VNAs. It has done that job well. It's $50 and can put out some impressive data in the right hands.
**********
To make my personal expectations a little clearer, to use the NanoVNA as an educational tool it actually has to work. This means the data coming off it should be void of random errors. The unit should never hang (lockup), especially to the point it requires a power cycle to clear it. Of course, it should meet what ever the claimed specs are. The better the data coming off the unit, the more usable it is for experimenting. Hope that helps answer your questions.
I think since the Chinese copied this device and started manufacturing it with some bugs, you have been reading or reviewing information about it ever since. I understand you also want to use it for crystal filter sorting. If you look at the improvements from the manufacturer or the original developer and the others, you will see that neither is aimed at this. So I would love to read about what your expectations are for you.
I was asked by a viewer about building a crystal filter. It wasn't anything I had a need for. I did put together a simple test fixture and some software that allows measuring them. That's in the manual, documented in this thread and there is also another thread dedicated to it.
Had our friend Purpose not been trying to make their own filter using the NanoVNA, I doubt I would have made the software public. I saw what they were attempting to do and thought some of what I had done may be useful.
I really had no expectation when putting this software and fixture together. It was more just a learning exorcise. While I posted a fair amount of data comparing my test results for the crystals as well as the filters with other means, I was never able to obtain a standard crystal.
But not that the frequency command has since been removed from shell commands. This is not true, 'freq' and 'frequencies' are still existing commands and can be easily checked with any terminal prg.
I doubt you will find where I stated or wrote that the command was removed from the shell command or the firmware. What you will find is I stated my software no longer supports it. This is very much a true statement and has been discussed here.
To the best of my knowledge, DiSlord has done and will do a lot in our spare time to make it easier for our users to use. This includes firmware. The regional '.' use (separating the integer and decimal characters) was discussed in the software created by OneOfEleven and solved the automatic recognition.
I have no doubts that various people will continue to make their own changes to the firmware. That seems to be a very popular thing to do since the NanoVNA became available. I have little interest in it.
No, I'm not asking you to get involved, I just remarked that She did. This makes your program great to use if every step in the process is followed. This is aided by the manual, which users tend to read last when they get stuck in what they think is correct.
Finally, I note that it is a novelty for many of us to measure with VNA.
I’m not even talking about how many options we don’t use or just need it sometimes
Thank you for reading..
While I have literally had people tell me the NanoVNA is an antenna analyzer, my friend I am attempting to help, has no understanding or interest in radio. While one radio hobbyists talked about measuring SWR three places beyond the decimal, we are using the Nano to learn about circuit design. I suspect that you will find that the features these two people use differ.
-
Most of the day was spent porting the HP3589A software to use the common code and updating it to include the 2.0 features. Needs a bit more work but usable.
-
Dear Mr. Smith,
Please allow me to congratulate you for your impressive work and for the amability to share it to the public!
What's my story, on the short, and why I am writing to you ?
I purchased a nanoVNA_V2 Plus4 in the hope that it would help my old father to measure crystals and to learn to build& tune his own SSB filters.
I already have a VNWA3-E that I used for such tasks, but my father asked me to find a cheaper solution (if possible), as his own "toy" for personal experiments and learning.
So, I ordered a NanoVNA V2 Plus4 on 04/04.2021 and after 73 days, I managed to pick it up (on 17Jun2021).
Before buying the device, I read the disclaimer on the site, the one that OwO quoted there: " the V2 is not suited to very narrowband measurements (coherent bandwidth <1kHz) because of the fast switching of the transmit and receive paths. In practice this only becomes a problem when measuring crystals (does not affect SAW or any other filters) " .
Hmmm... "any other filters"...
Well, now I am *very* dissapointed, because the V2_Plus4 fails to read a classic 10.7 MHz SSB DIY ladder filter (look at my first attached screenshot, where I compared the same filter sweeped with the VNWA3 and with the NanoVNA V2Plus4):
(https://i.postimg.cc/J7fKzxCZ/VNWA3-vs-Nano-VNA-v2-Plus4.jpg)
I've been also disappointed to find out that neither VNA-QT or NanoVNA-Saver cannot offer some very useful functions as zooming into the bandwidth of the filter or moving the markers directly with the mouse. So, the only way to "zoom" is to see first a larger characteristic, then establish the new needed limits, make a new sweep setting and finally, a new calibration.
That's horrible, eating a lot of time and nerves.
Finally, I borrowed a NanoVNA V1 (2.8" LCD) from a friend, to see if I may normally sweep an SSB filter with it.
Yesterday, I discovered your excellent software for NanoVNA while I was seeking for alternatives to NanoVNA-saver and VNA-QT.
Until then, I read about 80% of the manual, I installed your software (1.0 and then the latest released binaries) and I started to play with both versions of it, for NanoVNA V1 and also for NanoVNA V2Plus4.
Not long after, I found out that you were right when you mentioned that NanoVNA V1 crashes for longer operating times.
This is a big and frustrating problem. Yes, I know that this is it (firmware/hardware), but I mentioned just for "the record" :)
V2 Plus4 is performing well, but cannot sweep narrowband devices, that is clear.
However, I encountered a problem while using your very nice software: after SOLT calibration, the sweep is not working.
The problem occurs with both NanoVNA V1 and V2 Plus4, and I tend to think it's more of an operating error (by my fault). Maybe I'm doing something wrong...
Steps:
1) Power on NanoVNA
2) Launching your software
3) Go to "Setup/Diagnostics" -> Select NanoPort (ComX) -> Click on "Link" button (and wait to became green);
4) Check the status form to see link confirmation
(https://i.postimg.cc/0NK0vKXc/1-link-nanovna-v2plus.jpg)
5) Check the device LCD and see "USB PC" message
6) Return to "Main" menu of your software and establish the Start & Stop freqs, then the number of sweep points;
7) Start the filter sweep for test, without calibration; check S21 using <Xmsn rectangular>, check S11 using <Reflection Coeff> and check the <Impd Smith> graphs. The sweep is working (except the bad waveform due to the V2 Plus4 narrowband problems):
(https://i.postimg.cc/j5VQSqGK/2-S21-d-B-unclibrated-nanovna-v2plus4.jpg)
8 ) Deactivate sweeping, check the <ChnRef> button to be inactive and then starting the SOLT calibration using <2PortCal> button, as you described in the manual, at page 49 /chapter 12.8: SOLT Calibration. Start = 10.69 MHz, Stop = 10.704 MHz, 201 points.
9) Saving the calibration in a distinct, separate file.
10) Starting to sweep -> and see that nothing is happening:
(https://i.postimg.cc/BQwFvQKy/3-S21-Smith-after-calibration-nanovna-v2plus4.jpg)
Well, sorry for such a large text, but I don't know what to do, how to debug from this point !
Please give me some help, if possible.
In the hope of your answer, please allow me to wish you all the best and to encourage you to keep the good work on !
Best regards,
Bob
-
|O |O |O |O |O :palm: :palm: :palm: :palm: :-[ :-[ :-[ :-[
There was a pretty major bug in both versions of the software that would cause problems when using third party Touchstone viewers. For details, please read the attached link. This problem has been there since I made that video demonstrating how to use the NanoVNA to model a component used in a SPICE simulation.
Both programs have been corrected and are now available.
https://www.eevblog.com/forum/rf-microwave/s-parameter-plotting-software/msg3600608/#msg3600608 (https://www.eevblog.com/forum/rf-microwave/s-parameter-plotting-software/msg3600608/#msg3600608)
-
Bob,
The best work around I have found for the V2Plus4's short comings are to buy the original NanoVNA. If your dad works below 300MHz (which it sound like he does) that is really the better choice. Of course, if he is mostly working above 300MHz, that V2Plus4 is really a nice unit.
I paid under $200 w/ shipping for the two V2Plus VNAs. Not a bad deal at all considering what they can do. Go back a few pages and you will find a discussion with the designer about the narrow band. When I bought mine, I don't think that was on their ad.
Looks like you are using old software. 0.1 is the initial release and 1.04 is also now fairly old.
However, I encountered a problem while using your very nice software: after SOLT calibration, the sweep is not working.
The problem occurs with both NanoVNA V1 and V2 Plus4, and I tend to think it's more of an operating error (by my fault). Maybe I'm doing something wrong...
Steps:
1) Power on NanoVNA
2) Launching your software
3) Go to "Setup/Diagnostics" -> Select NanoPort (ComX) -> Click on "Link" button (and wait to became green);
4) Check the status form to see link confirmation
You could save that setup. Keep in mind though that the new software uses a different defaults file.
5) Check the device LCD and see "USB PC" message
6) Return to "Main" menu of your software and establish the Start & Stop freqs, then the number of sweep points;
7) Start the filter sweep for test, without calibration; check S21 using <Xmsn rectangular>, check S11 using <Reflection Coeff> and check the <Impd Smith> graphs. The sweep is working (except the bad waveform due to the V2 Plus4 narrowband problems):
So far, sounds normal.
8 ) Deactivate sweeping, check the <ChnRef> button to be inactive and then starting the SOLT calibration using <2PortCal> button, as you described in the manual, at page 49 /chapter 12.8: SOLT Calibration. Start = 10.69 MHz, Stop = 10.704 MHz, 201 points.
9) Saving the calibration in a distinct, separate file.
10) Starting to sweep -> and see that nothing is happening:
Well, (10.704000 - 10.690000) / 201 points is 69.65 Hz per point.
Keep in mind that this is an engineering tool and not written for the beginner. You are free set the parameters to anything you like as I assume people know what it is they want to do.
Well, sorry for such a large text, but I don't know what to do, how to debug from this point !
Please give me some help, if possible.
Load the current software and use some reasonable settings. Then let me know if you still have problems. Just as a sanity test, shown with a 12MHz 10-pole crystal filter inserted using interpolation.
-
5 months ago, I made this review of the V2Plus4. At 9:15 or so in, I talk about the narrow band problems.
***
At 45 mins in I show this 12MHz 10-pole filter but more interesting I show a 1GHz interdigital filter being ran on the original NanoVNA, the V2Plus4 and well as my vintage Agilent PNA. I'm pretty happy with the results I have been able to achieve with all of these low cost VNAs when/if I can find working firmware.
https://www.youtube.com/watch?v=XaYBpPCo1qk (https://www.youtube.com/watch?v=XaYBpPCo1qk)
-
I will admit fault for bringing price/performance expectations of 3GHz VNAs to unrealistic and unsustainable levels. Now of course when you have to achieve >90dB dynamic range and work up to many GHz in a under $200 budget, some compromises have to be made, so the architecture of all V2 devices are not suitable for measuring crystals. A quick google for ssb ladder filter shows it's a filter built out of crystals, so it's clear that it can not be measured with a V2. It has been in the documentation and product descriptions since the first time the issue was reported.
VNWA 3E is a good choice if you need to measure crystals and you need something reliable.
-
Thanks Joe!
Read more, post less 👍
I just wanted to report that the new upload seems to be working with the V2_2, - https://github.com/joeqsmith/NanoVNA_Software/blob/NanoVNA_V2Plus/NanoVNA_V2Plus_2p03.zip
You are amazing!
Edit - Yes, I have installed the version 0.1 installer program first: https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10
- sorry, didn't mean to confuse anybody. Github can imho be a hard place to find the 'correct' versions, especially when it branches out
Yes, Joe has an Excellent resource/starting page: https://github.com/joeqsmith/NanoVNA_Software 👍
-
Thanks Joe!
Read more, post less 👍
I just wanted to report that the new upload seems to be working with the V2_2, - https://github.com/joeqsmith/NanoVNA_Software/blob/NanoVNA_V2Plus/NanoVNA_V2Plus_2p03.zip
You are amazing!
I suspect more than one person has been led astray by using direct links like you have done. Story goes something like this:
My buddy put a link to this guys software on their twitbook page and I downloaded it. I tried to run the EXE but it says I need some runtime engine. I went to NIs site and downloaded the latest runtime and it still does not work. Eventually I figured out that the software requires a specific runtime. I downloaded that and now have the software running but it won't communicate with my device.
This ends with me getting an email how 1) LabView sucks 2) my software doesn't work :-DD
If the buddy posted a link to the installer and the story changes to:
It has all these files that I don't know what to do with (asks his buddy for help and installs 7-Zip).
They get the software installed and are proud of themselves for a job well done. They post a few screen shots to their own twitbook account to show off their accomplishments. Then they try to talk with their old NanoVNA with it and realize it does not work and I get another email asking for help.
After so many amateur radio hobbyists wrote me who claimed they did not need support, I'm surprised of the number of simple PC questions from this group that could be avoided if they only took the time to read. Guessing that reading, memorizing rules and learning some simple code is no longer a requirement for getting a license.
If you want to post links to the software, please use the main page. Someone may actually read the first few sentences of the README file and avoid some of the common problems.
Anyway, I'm glad you were able to get your setup working with the latest software.
-
I will admit fault for bringing price/performance expectations of 3GHz VNAs to unrealistic and unsustainable levels. Now of course when you have to achieve >90dB dynamic range and work up to many GHz in a under $200 budget, some compromises have to be made, so the architecture of all V2 devices are not suitable for measuring crystals. A quick google for ssb ladder filter shows it's a filter built out of crystals, so it's clear that it can not be measured with a V2. It has been in the documentation and product descriptions since the first time the issue was reported.
VNWA 3E is a good choice if you need to measure crystals and you need something reliable.
Looks like they want $460 for that VNWA 3E. Really, to measure crystals my software coupled to the $50 original NanoVNA gets the job done. You can make a database of your parts, you can even have the software sort the parts for your specific design.
In your case, the V2Plus4 does a really nice job for experimenting at higher frequencies. Its some very impressive hardware. Combined with the original NanoVNA, it would seem to cover most of the RF hobbyists needs.
Your latest VNA is what I am interested in. If you manage to pull off the low freq and keep the noise down and dynamic range up, really, what else is out there? $6600 won't touch the lower frequency.
https://www.picotech.com/vector-network-analyzer/picovna/picovna-series (https://www.picotech.com/vector-network-analyzer/picovna/picovna-series)
You could go with Copper Mountain for over $10k. Even on the used market, I couldn't find anything decent that covered that range. This is why I have two different VNAs. It seems you are really setting a high goal for yourself. It may not be as popular due to the higher costs but you may find it being used in all new applications.
20:36 in, testing some crystals with the original NanoVNA and my software.
https://www.youtube.com/watch?v=scZ3kZ4Q2sQ (https://www.youtube.com/watch?v=scZ3kZ4Q2sQ)
-
Pushing the 2-port 120dB 10kHz - 6GHz is there much else beyond the CopperMountain? If it were not for that $14,000 price tag, I would own one of these for my hobby use. Think they would sell me one for $500? :-DD I want to see that V3 or yours.
https://coppermountaintech.com/vna/s5065-2-port-6-5-ghz-analyzer/
-
Pushing the 2-port 120dB 10kHz - 6GHz is there much else beyond the CopperMountain?
The new Rohde & Schwarz ZNB range of analyzers has 4.5 GHz and 8.5 GHz models that start at 9 kHz. Current used prices range from about 20,000 Euros for a 4.5 GHz two port model. We'll have to wait a couple of years, I think. :) I have a predecessor model that was discontinued a year ago or so. It is specified down to 300 kHz, but actually starts at 150 kHz.
The problem is to design a reflectometer that goes down to kHz frequencies and is very broadband at the same time (i.e., up into the GHz range). When using a resistive bridge you have to detect the voltage across the bridge, i.e., convert from balanced to unbalanced. Up in the GHz range you will have to use a ferrite balun which puts a lower limit on the frequency range. But if you restrict yourself to a couple of hundred MHz, say, a balanced mixer with Gilbert cell alone will do. I think the original nanoVNA follows that approach. When there are no extreme budget constraints, one could aim at improving that approach (lower noise mixer and IF amplifier, low phase noise synthesizer, better ADC, better shielding and decoupling, etc). Should be doable, but certainly is a lot of work.
-
OWO had tossed out 400-$500 and mentioned dropping the display to help save costs. For some reason, I have a feeling that people interested in such a device are aware of the costs. Flipper and I may be the only two customers. :-DD They had a sign up, I assume to get some idea on the level of interest.
https://nanorfe.com/nanovna-v3.html
I wondered if there was some sort of override for that old PNA I have that would allow it to run lower but with reduced performance. I asked in the groups but no response.
On a side note, METAS approved my request to use their software. I have downloaded it along with the documentation and will start going over it. I provided them the link to the forum for details about my findings and have offered to help.
-
Good evening Mr. Smith !
The best work around I have found for the V2Plus4's short comings are to buy the original NanoVNA. If your dad works below 300MHz (which it sound like he does) that is really the better choice.
Well, I also tested the original NanoVNA too. If you will be so kind to help me to solve the problem that I've encountered while trying to use your nice software, probably I will buy it for my dad and help him to use your software for sorting xtals and tuning an SSB filter :)
Looks like you are using old software. 0.1 is the initial release and 1.04 is also now fairly old.
In the screenshot that I posted, yes, was the 1.04. But I tried also with all the other versions, including the last one (2.03), right in this evening.
The problem that I encountered still remain the same :(
At this point, please let me try to explain the problem again.
- the first step is to be sure that the link with the NanoVNA V2 Plus4 is active;
- then, I return to the Main screen and I set some limits for the sweep. For example, 10.690M-10.704M with 201 points, or as you suggested to me, 11.99475M with a 50KHz span;
- after that, *without calibration*, when I start sweeping, all is working, the sweep is working, the graphs appears (Smith, S11, S21, etc.);
- if I stop the sweep and make calibration with the values that I worked, well... after that, when I'm trying to start again the sweep, it doesn't work, nothing is happening, nothing is moving, nothing is drawed on the graphs. Everything looks as stoned |O
I would like to mention that I tried also on a separate, fresh installed laptop, with the same results.
I used only Windows 10 Pro (an old version on my desktop, and an updated one on my laptop).
I tried also with different firmware on the NanoVNA V2 Plus4 (the stock one - 20201013 stable, and with the 20210621 experimental).
Well, (10.704000 - 10.690000) / 201 points is 69.65 Hz per point.
Keep in mind that this is an engineering tool and not written for the beginner.
You are free set the parameters to anything you like as I assume people know what it is they want to do.
Well, I understand your advice and warning.
Probably, in the case of your software, the same GIGO principle as with LTSpice is working: Garbage In -> Garbage Out.
You are 100% right, but something is missing for me. That's why I'm asking you for help !
Well, you said that a span of 14KHz with 69.65 Hz per point is a wrong setup? If so, why? Please enlight me ...
I tried to use NanoVNA-Saver, with the same settings, and with 69.65Hz/step is working:
(https://i.postimg.cc/W4ckJkFh/Screenshot-313.png)
Load the current software and use some reasonable settings. Then let me know if you still have problems. Just as a sanity test, shown with a 12MHz 10-pole crystal filter inserted using interpolation.
Well, could you explain to me what do you mean by "reasonable settings" ? Here I think I have a problem, please help me understand. :palm:
I tried your setup, 11.99475M with a 50KHz span and 201 pts. Is working as long as I don't try to calibrate with these settings.
After SOLT calibration, the sweep is not working / not starting.
And as I already mentioned, the problem occurs with both NanoVNA V1 and V2 Plus4; the same problem on desktop PC and on the laptop.
That's why I tend to think that's more of an operating error (by my fault).
Maybe I'm doing something wrong... but I can't understand where I'm wrong !
So please, try to help me to pass this step :)
Believe me, I 100% read the manual and followed the steps described there.
Thanks a lot and have a nice day,
Bob
-
In the screenshot that I posted, yes, was the 1.04.
Actually, look at your post again. first was 0.10 then 1.04. Again, just to be clear, I have told you that the V2Plus4 will not make these measurements. Odd as I have had a few other people writing me with similar stories. I think they feel the software some how magically overcomes the hardware limitations. The feature is there, it must work. :-DD What really funny is no amount of documentation, videos, or posts from the designer gets through. The NanoVNA is now a religion.
Ok, back to engineering 101.
At this point, please let me try to explain the problem again.
- the first step is to be sure that the link with the NanoVNA V2 Plus4 is active;
- then, I return to the Main screen and I set some limits for the sweep. For example, 10.690M-10.704M with 201 points, or as you suggested to me, 11.99475M with a 50KHz span;
- after that, *without calibration*, when I start sweeping, all is working, the sweep is working, the graphs appears (Smith, S11, S21, etc.);
I did not suggest that at all. Instead I wrote:
Load the current software and use some reasonable settings. Then let me know if you still have problems.
50,000 / 201 = 248Hz per point. Seems you didn't understand OWOs response. But no matter. I will continue to allow you to bang your head into the wall. :-DD The rest makes sense.
- if I stop the sweep and make calibration with the values that I worked, well... after that, when I'm trying to start again the sweep, it doesn't work, nothing is happening, nothing is moving, nothing is drawed on the graphs. Everything looks as stoned |O
I would like to mention that I tried also on a separate, fresh installed laptop, with the same results.
I used only Windows 10 Pro (an old version on my desktop, and an updated one on my laptop).
I tried also with different firmware on the NanoVNA V2 Plus4 (the stock one - 20201013 stable, and with the 20210621 experimental).
I am not sure why you would think the PC would have anything to do with it but ok. Firmware could certainly cause problems but I don't thing that's causing what you are seeing.
Well, I understand your advice and warning.
Probably, in the case of your software, the same GIGO principle as with LTSpice is working: Garbage In -> Garbage Out.
You are 100% right, but something is missing for me. That's why I'm asking you for help !
Yes, GIGO or SISO.
Well, you said that a span of 14KHz with 69.65 Hz per point is a wrong setup? If so, why? Please enlight me ...
OWO already covered that with you.
I tried to use NanoVNA-Saver, with the same settings, and with 69.65Hz/step is working:
I am not at all surprised that different software would have different behaviors.
Well, could you explain to me what do you mean by "reasonable settings" ? Here I think I have a problem, please help me understand. :palm:
I tried your setup, 11.99475M with a 50KHz span and 201 pts. Is working as long as I don't try to calibrate with these settings.
After SOLT calibration, the sweep is not working / not starting.
And as I already mentioned, the problem occurs with both NanoVNA V1 and V2 Plus4
; the same problem on desktop PC and on the laptop.
That's why I tend to think that's more of an operating error (by my fault).
Maybe I'm doing something wrong... but I can't understand where I'm wrong !
So please, try to help me to pass this step :)
Believe me, I 100% read the manual and followed the steps described there.
Thanks a lot and have a nice day,
Bob
Odd, as I would expect the original design would have no problem. I would also suggest that you stop wasting time with the V2Plus4. I suspect you left out one or two very important details. I suspect is may have to do with your gold standard software and how it works.
Attached is a screen shot of my latest software for the original NanoVNA using your settings. Note that I have ran a full SOLT on it using these same settings. Shown with the home made 50dB attenuator attached. There's no magic... It just works as I would expect.
So, there are two possible answers. When it appears stoned as you put it, what is the CPU usage? You have ran so many combos and done your absolute best to muddy the waters so I am not sure if you ran the 1.x software with the original NanoVNA or not. Again, learn to divide your problems down. In this case, don't play with every PC, Nano and firmware known. It's not helpful.
-
I setup the V2Plus4 and followed the same procedure, using your settings. Again, full SOLT using your settings. Shown with the same homemade 50dB attenuator inserted. My setup appears as expected.
Obviously you are attempting to measure crystals which again is not going to work but the attenuator should be fine.
You could try the exact same firmware but the fact you have the same problem with the other software and the original NanoVNA tells me you are leaving out some important detail.
***
grammar was poor, real poor...
-
Using the latest software for the original NanoVNA to look at a 10MHz crystal with a 500Hz span. Full SOLT cal.
This version is for all of the people outside of the USA who are having trouble with their regional settings. While I thought the manual was fairly descriptive, it's apparent that reading is no longer a basic life skill. I plan to dumb down the software for this group (mostly amateur radio hobbyists BTW). For what ever reason, this group feels the need to fill my personal email inbox. The same group that so many told me they could run it without support. :-DD
Shown with German regional settings and no INI file. Some of you have figured out this doesn't pertain to the V2Plus4.
I would like to sort out bobinuta's problem before I release it in case there actually is a problem with the software. While we have software that can capture the screen to a video and Youtube allowing the world to view it, it seems a crystal ball is still required in some cases. Mine is still out for service waiting on parts that the automotive companies are hording. So be patient.
****
Just a side note. I have attached the data collected for this same crystal properly measured with the same NanoVNA and cables. While, as I stated, the VNA was fully calibrated, I am just inserting the crystal between port 1 & 2. When I started working on the software to make these measurements, I would commonly find people posting how they were measuring the parts this way. What a difference in the readings.... I wonder which is right.
-
8 ) Deactivate sweeping, check the <ChnRef> button to be inactive and then starting the SOLT calibration using <2PortCal> button, as you described in the manual, at page 49 /chapter 12.8: SOLT Calibration. Start = 10.69 MHz, Stop = 10.704 MHz, 201 points.
9) Saving the calibration in a distinct, separate file.
10) Starting to sweep -> and see that nothing is happening:
Notice in 8) they turn off the sweep. They then check the ChnRef (assume Chn-Ref) button to be inactive. The manual states: "Select CHn-Ref to disable the normalization.". This note is there because I assume the reader is not jumping into the middle of the document and following it. In the previous sections, the VNA was using normalization.
Of course they show 10.704 and the screen shot shows 10.702. I doubt this has anything to do with it but I assumed it was a typo and used 702. They set the points to 201. Again, the port and points should have been stored in the defaults but oh well. Shouldn't be a problem if you like entering these settings every time.
They then run through the cal. Notice the never enable the sweeps so the VNA is collecting a whole lot of nothing (which is why the numbers are so out of joint). They finish up the cal and save it. Then decide to enable the sweeps. Odd they felt the need to turn them off. I just let the thing run all the time.
Next they state nothing is happening. Now, I doubt that's the case. I suspect the software is collecting the data but because they fucked up the calibration by turning off the sweeps, the data shown is worthless. Of course, the software allows you to view the raw data but I guess they didn't find that feature.
Well, sorry for such a large text, but I don't know what to do, how to debug from this point !
Now did the manual at any point in the section they refer to talk about turning off the sweeps. Nope. I wonder if other software requires you to turn them off and this is why they thought it was the right thing to do. What's odd is I can't see how anyone would think that with the sweeps turned off so the PC is collecting nothing that it would somehow magically have data for the calibration.
Like the regional settings, I may have to just dumb the whole software down for the radio group. No amateur left behind. Time to go check my antennas SWR.
-
No word from Bob on if they actually did turn off the sweeps when running the cal and if allowing it to collect the data solved their problem. Thinking about dumbing down the software, I bounced it off my friend Flipper. I think the problem we both see with doing this is that we don't want the software to be limited or trying to second guess what we are using it for. It made sense to automate the regional settings as it's not related to collecting data. Flipper tossed out we could make a Fisher Price looking My First VNA program that is nothing more than an SWR meter.
The other people that I have been in contact with about software problems are now resolved. The only real bug was with someone using an earlier version of 2.x with the poorly written peak find algorithm. Running the latest release solved it.
Rather than continue to wait on Bob, I will assume they sorted out their problem. 2.05 has now been released and is available for download. The only change is the auto detection of the regional settings and the handling of the decimal. If you are using the comma rather than the period, after you install this software you should be able to remove the INI file and it should continue to work.
The attached is from a paper put out by a Mike Watts WY6K Titled: NanoVNA Tips for New and Prospective Users
I had watched one of IMSAI's early videos showing a transfer relay hooked to their NanoVNA but with no software to calibrate it. Seems like a nice enough guy. I suspect that Mike's hearing and vision have been damaged from all that RF. We sound nothing alike, different test equipment and different presentation styles. When I show a transfer relay connected to the NanoVNA, I show my software running a full 2-port cal and T-check to validate it. Let me assure you we are not the same person with two accounts. We wish Mikes overall health improves.
***
poor wording
-
Good evening Mr. Smith!
Again, just to be clear, I have told you that the V2Plus4 will not make these measurements. [...]
About the fact that NanoVNA V2 (and especially V2 Plus4) cannot sweep for narrowband devices, this chapter is clear .
I'm not expecting to anything magic. :)
So, until yesterday, I used V2 Plus4 with your software, only for two reasons:
- in contrast to the NanoVNA V1, the V2 Plus4's screen provides an indication of the USB link with the PC; that way, at least, I know there's an established connection.
- V2 Plus4 is more stable in long term operation and does not crash suddenly, as V1 does.
Yesterday I sold the V2Plus4 and I was left only with V1.
To be better understood at this point, I would like to mention again that my problem *was not* the fact that V2 Plus4 cannot be used for crystal sweep (that was only a disappointing finding), but the fact that *in my particular situation*, the sweep in your software (NanoVNA V2 Plus4) won't start *after* calibration is completed ! And this issue is the only one for which I asked for your support - because nobody could know better an applicaton as its author...
Seems you didn't understand OWOs response.
Well, that's because in the OwO's reply, I don't see anything connected with my initial question that I asked you.
That one about why the sweep don't start after full calibration of the NanoVNA V2 Plus4 when using your software.
Just for the record, I quote below the Owo's reply:
I will admit fault for bringing price/performance expectations of 3GHz VNAs to unrealistic and unsustainable levels. Now of course when you have to achieve >90dB dynamic range and work up to many GHz in a under $200 budget, some compromises have to be made, so the architecture of all V2 devices are not suitable for measuring crystals. A quick google for ssb ladder filter shows it's a filter built out of crystals, so it's clear that it can not be measured with a V2. It has been in the documentation and product descriptions since the first time the issue was reported. [...]
As anybody can see, OwO's reply has nothing to do with what I asked you.
But no matter. I will continue to allow you to bang your head into the wall.
Well, please allow me to congratulate you for such a very professional, collegial and amiable answer !
I am not sure why you would think the PC would have anything to do with it
Well, here are some reasons:
- I'm not a software engineer who builds OS, drivers and applications, so I don't have where from to know how all together could interact with the (nano)VNA hardware/firmware *and* with your software. For example, I read in your GitHub notices that "This software has been tested on Windows 10 only. It uses the 32-bit version of LabView 2011, SP1 [...]".
Well, I am using W10Pro/64bits. I have no ideea if this could be a problem or not. Probably not, but as a software author, you are the one who knows better, so I would have expected the answers from you, not from anyone else.
- Generally, I use to read the installation instructions, both for my own understanding and as a term of respect for their authors. Also, I understand the term RTFM ;-) That is exactly what I did also with the manual of your software - as you recommended.
After I saw that the software is linked with the NanoVNA *and* the sweep works without calibration, well... I though that the problem could be in someother place, like OS version, drivers, chipset, platform, etc.
Well, you said that a span of 14KHz with 69.65 Hz per point is a wrong setup? If so, why? Please enlight me ...
OWO already covered that with you.
If you're referring to the same OwO answer (which I've already quoted above) well, then I don't see where the issue is. I don't see any explanations in his answer about how to "use some reasonable settings" in your software... or about why the sweep don't start after full SOLT calibration. Am I wrong ?
I would also suggest that you stop wasting time with the V2Plus4.
And as you can see, that's exactly what I did :)
Odd, as I would expect the original design would have no problem. [...]I suspect you left out one or two very important details. I suspect is may have to do with your gold standard software and how it works.
Mr. Smith, I don't have any "gold standard" software for the NanoVNA.
However, your software could be a good candidate for such a title, if you would like to give me the necessary support to be able to solve the problems that prevent me from being able to use it (now, at least, for the original NanoVNA).
Attached is a screen shot of my latest software for the original NanoVNA using your settings. Note that I have ran a full SOLT on it using these same settings. Shown with the home made 50dB attenuator attached. There's no magic... It just works as I would expect.
Mr. Smith, I am 100% sure that your software works very well and I suppose that something was wrong on my side.
I haven't said anything different so far!
That is also the reason why I asked for your support. As you noticed, I followed all the steps you specified, the application (NanoVNA V2 Plus4) started, sweeped without being calibrated, but after full calibration, the sweep did not started again. I'm sure something is missing, but I have no one else to ask but the author of the software himself ...
Anyway, now the NanoVNA V2 Plus4 is gone, so I'll try to use the original one (NanoVNA V1).
So, there are two possible answers. When it appears stoned as you put it, what is the CPU usage?
About 5% to 8%, please see the screenshot below:
(https://i.postimg.cc/pLb8xq77/resource-CPU-Nano-VNA.jpg)
You have ran so many combos and done your absolute best to muddy the waters
Hmm. I just tried your software in its both versions, with two distinct devices: the NanoVNA V2 Plus4 (with the appropriate software version, as you noticed from the screenshots) and the original NanoVNA (V1) with your NanoVNA.exe (v2.03).
so I am not sure if you ran the 1.x software with the original NanoVNA or not.
I tried, of course. But only for test, to see if something is moving.
Until yesterday (when I sold the V2 Plus4 device) I tried to work with the V2Plus4.
Since I was left with only NanoVNA V1 (the original one), I will come back with a feedback.
By the way, the firmware version on my NanoVNA V1 is 0.8.0 (the last official one).
I hope that this is OK...
Best regards,
Bob
-
Good evening again!
I setup the V2Plus4 and followed the same procedure, using your settings. Again, full SOLT using your settings. Shown with the same homemade 50dB attenuator inserted. My setup appears as expected.
I have no doubt that you could not have problems with your own software!
Obviously you are attempting to measure crystals which again is not going to work but the attenuator should be fine.
After it was clear that V2Plus4 cannot measure crystals, I left this task to the original V1.
the fact you have the same problem with the other software and the original NanoVNA tells me you are leaving out some important detail.
As I already said, I'm sure the problem is around here, somewhere, and not there! :)
grammar was poor, real poor...
Well, I don't claim to have a degree in English and I don't live in a country where I speak English all of the day. It is very probable that if you had reasons to try a conversation in Romanian, it would also happen to you to make certain mistakes.
No word from Bob on if they actually did turn off the sweeps when running the cal and if allowing it to collect the data solved their problem.
Not a word, because I didn't have time to deal with the NanoVNA. I read what you wrote in the meantime.
Now did the manual at any point in the section they refer to talk about turning off the sweeps. Nope. I wonder if other software requires you to turn them off and this is why they thought it was the right thing to do.
Yes, it's true that I stopped the sweep, because that's how I was used to work with the other software (including the one from VNWA3-E).
Actually, I didn't find anywhere in your software manual that the sweep must be allowed to run when running the SOLT calibration!
I will come back after a new test, with ChnRef pressed and the sweep uninterrupted.
Thanks for the hint!
They then run through the cal. Notice the never enable the sweeps so the VNA is collecting a whole lot of nothing (which is why the numbers are so out of joint). They finish up the cal and save it. Then decide to enable the sweeps. Odd they felt the need to turn them off. I just let the thing run all the time. [...]
Next they state nothing is happening. Now, I doubt that's the case. I suspect the software is collecting the data but because they fucked up the calibration by turning off the sweeps, the data shown is worthless. Of course, the software allows you to view the raw data but I guess they didn't find that feature. [...]
I may have to just dumb the whole software down for the radio group. No amateur left behind. Time to go check my antennas SWR.
It's very interesting that you speak as if you were addressing an amphitheater audience or an alien park. :-DD
Well, if you don't like amateurs, then maybe it would have been better not to address such an audience.
If you are a great pro and others do not have your knowledge, you should expect mistakes due to a way of thinking that very few amateurs can have, because they do not have the knowledge or practice that a 'pro' can have.
It's up to you whether you enjoy helping and teaching others, or not. If that's what you want, it's normal to meet stupid questions and mistakes. Here's the difference between an amateur and a pro. But few professionals have talent and didactic motivation, unfortunately. If you also address the amateur area, do not expect a professional level from them.
Also, if you enjoy teaching others, a good practice would be to try to be less critical. I am immune to such details anyway. :-DD
Berst regards,
Bob
-
I will come back after a new test, with ChnRef pressed and the sweep uninterrupted.
Dear Mr. Smith,
I used your NanoVNA software as you proposed and now everything works and makes sense!
Thanks for your time!
As you can see, it was enough to make some clarifications that you would not have addressed to professionals, but which were of real use to a hobbyist like me. I don't think it was that hard, was it? :)
Below is a video clip with a duration of approx. 1:30 min. and screenshots that demonstrate the operation of your NanoVNA.exe software (v.2.05) by controlling the original NanoVNA V1 model.
Once here, I want to mention that I never considered a VNA as a simple antenna analyzer. I know very well what the difference is and I also understand the reasons for this unwanted confusion. However, you must also understand the point of view of an amateur, who cannot think like a pro. The fact that NanoVNA offers the functions of a vector analyzer (even if not the accuracy of a professional one) at a very low price makes it accessible to amateurs who took a scalar antenna analyzer as a reference device, not long ago.
Certainly, if you'll overcome the moments when amateurs will ask you unexpected and maybe uninspired questions (or which betray a lack of specialized knowledge), you will create an excellent image for you - and your software will be viewed with great confidence.
Next week I will go on vacation, but after I'll be back 8) , I hope to do some more reviews of your software, or to ask you about some of its features (which may be useful in completing the user manual).
Best regards,
Bob
VIDEO:
Using Joe Q Smith's NanoVNA.exe software (https://www.youtube.com/watch?v=P-esHlhsM9M)
SCREENSHOTS (click to enlarge):
1. The LOAD standard itself (Smith diagram)
(https://i.postimg.cc/dV9SMk1b/1-50ohm-standard-Smith-t.jpg) (https://i.postimg.cc/W3x5m0Wk/1-50ohm-standard-Smith.jpg)
2. The LOAD standard itself (impedance)
(https://i.postimg.cc/yNYp713k/2-50ohm-standard-Z-t.jpg) (https://i.postimg.cc/yx9vLWtr/2-50ohm-standard-Z.jpg)
3. The LOAD standard itself (S11 / Return Loss)
(https://i.postimg.cc/cJ99HpfT/3-50ohm-standard-S11-t.jpg) (https://i.postimg.cc/gkVgRXvx/3-50ohm-standard-S11.jpg)
4. The OPEN standard itself (Smith diagram)
(https://i.postimg.cc/sXMnZTcz/4-OPEN-standard-Smith-t.jpg) (https://i.postimg.cc/wj90kqV0/4-OPEN-standard-Smith.jpg)
5. The SHORT standard itself (Smith diagram)
(https://i.postimg.cc/ZYy7bDnF/5-SHORT-standard-Smith-t.jpg) (https://i.postimg.cc/zfc75n1c/5-SHORT-standard-Smith.jpg)
6. The 10.7 MHz - 5 crystals ladder home-made SSB filter, unadapted (Smith diagram)
(https://i.postimg.cc/L6KynBZd/6-10k7-MHz-SSB-filter-Smith-t.jpg) (https://i.postimg.cc/cJHhVFP3/6-10k7-MHz-SSB-filter-Smith.jpg)
7. The 10.7 MHz - 5 crystals ladder home-made SSB filter, unadapted (transmission S21)
(https://i.postimg.cc/2STTcs9m/7-10k7-MHz-SSB-filter-S21-t.jpg) (https://i.postimg.cc/Znrxr2vG/7-10k7-MHz-SSB-filter-S21.jpg)
8. The 10.7 MHz - 5 crystals ladder home-made SSB filter, unadapted ( reflection coefficient S11)
(https://i.postimg.cc/vBxzmcYH/8-10k7-MHz-SSB-filter-S11-t.jpg) (https://i.postimg.cc/fWXCntq8/8-10k7-MHz-SSB-filter-S11.jpg)
9. The 10.7 MHz - 5 crystals ladder home-made SSB filter, unadapted ( impedance)
(https://i.postimg.cc/Gt0jTdtP/9-10k7-MHz-SSB-filter-Z-t.jpg) (https://i.postimg.cc/15QH9mLs/9-10k7-MHz-SSB-filter-Z.jpg)
10. Raw data for the same filter:
(https://i.postimg.cc/TYJch86m/10-10k7-MHz-SSB-filter-rawdata-t.jpg) (https://i.postimg.cc/jSq478x1/10-10k7-MHz-SSB-filter-rawdata.jpg)
Attached is the Touchstone s2p file for this filter (sweep only from A to B port).
-
Yesterday I sold the V2Plus4 and I was left only with V1.
... the fact that V2 Plus4 cannot be used for crystal sweep (that was only a disappointing finding), ...
FYI OWO had posted firmware for the V2Plus4 which may allow it to make these measurements. It was not an official release and I have no plans to try it.
Just for the record, I quote below the Owo's reply:
Actually, I had included the reference but no matter.
By the way, the firmware version on my NanoVNA V1 is 0.8.0 (the last official one).
I hope that this is OK...
I've posted I had problems when using that version with my software but you are certainly free to run any firmware you like.
grammar was poor, real poor...
Well, I don't claim to have a degree in English and I don't live in a country where I speak English all of the day. It is very probable that if you had reasons to try a conversation in Romanian, it would also happen to you to make certain mistakes.
You will notice that the post was edited by myself. Often I will post a series of * followed by the reason for the change. In this case, my poor grammar made it difficult for even me, the person who wrote it, follow.
Now did the manual at any point in the section they refer to talk about turning off the sweeps. Nope. I wonder if other software requires you to turn them off and this is why they thought it was the right thing to do.
Yes, it's true that I stopped the sweep, because that's how I was used to work with the other software (including the one from VNWA3-E).
Actually, I didn't find anywhere in your software manual that the sweep must be allowed to run when running the SOLT calibration!
I will come back after a new test, with ChnRef pressed and the sweep uninterrupted.
Again, I would expect the reader to follow along in the manual. In section 12.5, Displaying Data it states "Select the Sweep button and the software will begin collecting data from the V2+. " . After this the manual never states to turn it off. And while my house does not have a manual explaining to turn the light switch to the on position in order to be able to see when it gets too dark, I certainly know that for my childhood. Again, the software is not for the beginner.
Too funny. It's as if you are not wanting to understand what these buttons do and want to just press them at random. 12.6 Normalization Example, covers using Chn-Ref rather than running a full calibration. By the time the reader gets to to 12.8 SOLT Calibration, the CHn-Ref is still active and the second sentence is to turn it off. Random button pressing is never going to work. You need to learn what each button does to leverage its use.
It's very interesting that you speak as if you were addressing an amphitheater audience or an alien park. :-DD
Well, if you don't like amateurs, then maybe it would have been better not to address such an audience.
Additionally, there have been ongoing efforts to create other software for the NanoVNAs. I have not been following their development but understand these programs have been largely adopted by the radio community. My software was not written for this group. It was designed as an engineering tool for the RF experimenter. Having other software available should help reduce the effort required to support this package.
The manual is clear that the software was not written for the amateurs. It's not a matter of liking or disliking but rather the amount of support many from this group will require. After so many from this group continuously whined about my not releasing the early versions of the software, I knew if I ever released it that this group would require the most support.
I will come back after a new test, with ChnRef pressed and the sweep uninterrupted.
Dear Mr. Smith,
I used your NanoVNA software as you proposed and now everything works and makes sense!
Thanks for your time!
I doubt it actually makes sense. Read the manual on normalization and run some experiments until you understand what that button actually does.
As you can see, it was enough to make some clarifications that you would not have addressed to professionals, but which were of real use to a hobbyist like me. I don't think it was that hard, was it? :)
I would guess that I spent 10 hours this week answering questions from the amateur group. Most with the need to write me directly about their own personal problems. I suspect they don't want to ask questions in a public forum as they feel they are experts and it looks bad in front of their peers (ego). Even though you had problems with turning on the light switch so to speak, at least you put it out there on a public forum so others could learn. For that, you have my respect.
..However, you must also understand the point of view of an amateur, who cannot think like a pro.
I had an amateur license early on which consisted of memorizing the materials and playing them back. Everything you need to know is handed to you. In engineering its learning to use the materials to solve other problems. That learning starts with a higher education and takes a life time. It's not that the amateurs could not learn these skills, I just suspect most have little interest in such things. Many of them I knew growing up were really just wanting the modern cell phone. They would buy their radios and antennas, hook them up and start blabbing (they call it advancing the art).
-
Good morning Mr. Smith,
Thank you for the reply and comments!
FYI OWO had posted firmware for the V2Plus4 which may allow it to make these measurements. It was not an official release and I have no plans to try it.
Are you referring to this post?
https://groups.io/g/NanoVNAV2/message/2133 (https://groups.io/g/NanoVNAV2/message/2133)
Actually, I had included the reference but no matter.
Well, I think it matters. Because if I had found such a reference, I would not have asked. It is also possible that it was not too obvious and then I did not notice it, in which case I apologize.
I've posted I had problems when using that version with my software but you are certainly free to run any firmware you like.
Probably somewhere in the posts starting from the page 20 of this topic ::).
I didn't have time to read and digest all those posts, but I'll look over them after I return from vacation.
You will notice that the post was edited by myself. Often I will post a series of * followed by the reason for the change. In this case, my poor grammar made it difficult for even me, the person who wrote it, follow.
Well, see? A matter of interpreting expressions and practicing English fluently. My apologies!
Now did the manual at any point in the section they refer to talk about turning off the sweeps. Nope. I wonder if other software requires you to turn them off [...]
Mr. Smith, in other software it is not stipulated directly, but it can be seen from their use. As an example, NanoVNA-Saver or VNWA-3 software. When you calibrate the device, the sweep is turned on automatically only when the calibration standards are applied and when the user presses the corresponding buttons. After completing the calibration operations, the sweep is inactive and can be turned on by the user when needed.
I also used other older analyzers, such as the HP8714B, where things are pretty much the same: you calibrate it and start the sweep manually, when you want.
Now I hope you understand that once I used other systems that behaved relatively identically, I couldn't guess that your software is based on a slightly different philosophy :)
Again, I would expect the reader to follow along in the manual. In section 12.5, Displaying Data it states "Select the Sweep button and the software will begin collecting data from the V2+. " . After this the manual never states to turn it off. [...]
Again, the software is not for the beginner.
I have noticed that you often mention that your software is not for beginners. It's very good that you say this, but it depends on what you mean by beginners. Personally, I have nothing to do with the RF pro area, but I have a basic understanding of the principles of operation of a VNA, and since 2012 and until now I have had access and used several types on the amateur market (eg: miniVNA series, N2PK VNA, DG8SAQ VNWA-3E, MetroVNA Deluxe) and with some older professional VNAs (such as HP8714B) or slightly newer stuff, such as Agilent N9912A (portable), Anritsu MS46322A.
However, the particularities of design and use (including menus, functions, names) may differ from one example to another.
The same happened with your software, and it will probably happen again and the learning curve will be quite steep.
Too funny. It's as if you are not wanting to understand what these buttons do and want to just press them at random. 12.6 Normalization Example, covers using Chn-Ref rather than running a full calibration. By the time the reader gets to to 12.8 SOLT Calibration, the CHn-Ref is still active and the second sentence is to turn it off. Random button pressing is never going to work. You need to learn what each button does to leverage its use. [...]
Additionally, there have been ongoing efforts to create other software for the NanoVNAs. I have not been following their development but understand these programs have been largely adopted by the radio community. My software was not written for this group. It was designed as an engineering tool for the RF experimenter.
Mr. Smith, again - it is clear that you designed the software first for your personal use (maybe some friends) and probably without the intention of giving it in that form to others. Therefore, its use is less intuitive.
In the case of the series products, most manufacturers have implemented similar functions and modes of operation, to reduce the learning curve and to ensure that the potential buyer (user) will not be discouraged.
I encountered a different situation with Rohde & Schwarz products, which have different and less intuitive menus than those from HP, for example. However, for each device, there are very clearly stated procedures that leave no room for interpretations based on previous experiences.
In your case, you have a software that you offer for free and as in the case of Linux, people should expect that you will not have the time (and probably not the disposition) to document each element. So the RTFM is the best for every potential user, *but* the direct advice from the author is essential.
I already understood you, it remains to be seen how you will want to treat what you started, if you want to help amateurs with items from the pro area and if observations such as those made by me can cause you to add details to the user manual which you may not have thought of.
Obviously, it's up to you first :)
The manual is clear that the software was not written for the amateurs. It's not a matter of liking or disliking but rather the amount of support many from this group will require.
Mr. Smith, you are not alone, believe me :)
As I exemplified above, it is not a matter of amateur or professional to deduce that the sweep must be active when you do the calibration. And also, although you posted pictures in the manual, the fact that you have to use ChnRef ON to calibrate and OFF after that, is less visible (although you are right that you wrote about it).
Believe me, I also turned to a friend with experience in the field, who did not "catch" the trick of using your software, even after 15 minutes of remote session on my PC.
It's like switching from HP/Anritsu to R&S. 8)
Your software seems very cool and elaborate, but it still needs some additional documentation.
But once here, the contributions of those who will want to post (as I am willing to do) may help and eventually convince you to include additional explanations in your future revisions of the user manual ;)
Later, you can also do something else, if you like: extra paid support. You can get an advanced edition of the manual, which includes more examples and detailed explanations, for a fee. If it has an affordable price, people will definitely buy it.
I doubt it actually makes sense. Read the manual on normalization and run some experiments until you understand what that button actually does.
Be sure I will ::)
Now, the nanoVNA is with my father, so that he can get used to it a little, and I go on vacation. When I return, I will resume the experiments and digging ;-)
But don't be so sure that what I saw and what I already read about your software, it didn't make sense.
Regarding normalization, if it has the same meaning as the one I used for the old HP8714B, then you may have already understood ;-)
There, the procedure has been named "Normalization Calibration".
The analyzer stores measured data taken ( DUT not connected) into memory, and divides subsequent measured data by the stored data in order to remove frequency response errors. On that device, the normalization calibration could be used either for transmission or for a reflection measurement. At the end of the procedure, the DUT is inserted and when starting sweep, the data displayed is the transmission coefficient for the DUT (including all the connectors and cables) divided by the transmission coefficient for the connectors and cables alone.
So, do you think that in the case of your software, the normalization process does the same thing?
I would guess that I spent 10 hours this week answering questions from the amateur group. Most with the need to write me directly about their own personal problems. I suspect they don't want to ask questions in a public forum as they feel they are experts and it looks bad in front of their peers (ego).
With all due respect, but honestly, I think it's exactly the opposite. 8)
In general, a beginner is intimidated when dealing with more experienced people, or even worse, with professionals who "take them up" or throw them a dry and harsh "RTFM" >:D
But this is not my case, as I said and as you noticed.
After all, that's the purpose of forums: to provide quick support to those in need. Not to send them to read volumes of technical literature (if not). It is true that in the case of your software, both variants can be applied: both the short one, but also RTFM, without which the use cannot be deepened.
Even though you had problems with turning on the light switch so to speak, at least you put it out there on a public forum so others could learn. For that, you have my respect.
Thank you for your understanding and I assure you that the feeling of respect is mutual !
Chapeau bas, Mr. Smith!
(https://i.postimg.cc/MT9xSW9G/chapeaubas1-transp.gif)
I also assure you that I have always enjoyed to share with those around me some of the experience I have gained, as much as it is.
In engineering its learning to use the materials to solve other problems. That learning starts with a higher education and takes a life time.
Believe me I know and understand this aspect. I am also an engineer, but not in the RF field.
It's not that the amateurs could not learn these skills, I just suspect most have little interest in such things.
Many of the radio amateurs are also engineers (and even in the area of RF or telecommunications), a good part of them are even involved in complex projects (for example, space communications, satellites, etc.). Some of them are even employees of companies that produce equipment for amateur radio (Icom, Kenwood, Yaesu, etc.) or for the professional area.
Many of the special software used by radio amateurs were designed by their colleagues in the professional field.
However, the hams who do not work in the professional area, have minimal needs to learn radio engineering and should not be treated "from above". On the contrary, they need a help to overcome some barriers and to be able to use some cheap devices (such as NanoVNA) with the help of specialized software (such as the one you released) to achieve their small hobby goals - those that produce them joy.
I was always happy when I was able to produce a smile of joy on the face of an amateur radio colleague whom I helped to build a project, to tune an antenna, or to understand something specific. And I am convinced that you know this feeling too!
I'm ending here my reply and the plea for the amateurs, thanking you for your understanding and congratulating you for the work you've done when making this software. I also express my hope that by understanding the above, especially from the perspective of a former ham, you will treat amateurs with more understanding ;-)
Best regards,
Bob
-
Good morning Mr. Smith,
Thank you for the reply and comments!
Thanks for hanging in there.
I suspect you don't always look at the attachments which leads to some of your confusion.
Mr. Smith, in other software it is not stipulated directly, but it can be seen from their use. As an example, NanoVNA-Saver or VNWA-3 software. When you calibrate the device, the sweep is turned on automatically only when the calibration standards are applied and when the user presses the corresponding buttons. After completing the calibration operations, the sweep is inactive and can be turned on by the user when needed.
I looked at one of the very first open sourced programs when they had just started to develop it to make sure it connected and provide that feedback. Outside of that, I've only looked at the software supplied with the low cost VNAs. I wrote the original software 20 some years ago and continue to develop it. I show the software from 2002 working with my first VNA and a home made converter.
https://www.eevblog.com/forum/testgear/agilent-e835xa-pna-vna-notes/msg3604844/#msg3604844 (https://www.eevblog.com/forum/testgear/agilent-e835xa-pna-vna-notes/msg3604844/#msg3604844)
Outside of using an 8753, at that time I had no other experience with VNAs or their UI.
Mr. Smith, again - it is clear that you designed the software first for your personal use (maybe some friends) and probably without the intention of giving it in that form to others. Therefore, its use is less intuitive.
In the case of the series products, most manufacturers have implemented similar functions and modes of operation, to reduce the learning curve and to ensure that the potential buyer (user) will not be discouraged.
I try to discourage people from using my software. It's free. Support, well if you you can't do your own research or even be bothered to review the materials provided, expect to be called out. While user's (especially the amateur radio group) view themselves as customers, I don't. This is my business model. :-DD If you can make use of it, fine.
I already understood you, it remains to be seen how you will want to treat what you started, if you want to help amateurs with items from the pro area and if observations such as those made by me can cause you to add details to the user manual which you may not have thought of.
Obviously, it's up to you first :)
The majority of amateur radio operators who have contacted me have made it clear that they are entitled, demanding, like to whine and their license makes them an expert. It's a really an odd trend and not what I would have expected. I have no interest in working with such people at any level.
And also, although you posted pictures in the manual, the fact that you have to use ChnRef ON to calibrate and OFF after that, is less visible (although you are right that you wrote about it).
Odd that you are still not understanding the Chn-Ref. You would never set Chn-Ref ON before running a SOLT. Of course, the software will allow it and assumes you know what you are doing. With so many videos walking you through the basics and my continuing to point out you're not understanding it, I am surprised.
Believe me, I also turned to a friend with experience in the field, who did not "catch" the trick of using your software, even after 15 minutes of remote session on my PC.
It's like switching from HP/Anritsu to R&S. 8)
With you showing them the ropes, it doesn't surprise me at all.
Later, you can also do something else, if you like: extra paid support. You can get an advanced edition of the manual, which includes more examples and detailed explanations, for a fee. If it has an affordable price, people will definitely buy it.
You have no idea of the time and effort I have put into testing handheld DMMs. Sure the meters cost money as well but that's hardly worth mentioning. I have never asked people to join my non-existent Patrion, click that bell, subscribe and like, and ads are disabled. Outside of the EEVBLOG, I have no social media presence, no twittbook accounts. I have never asked anything from my followers other than not to whine. If people get something out of what I post great. Don't like the content, find a better channel. I work on what I want, when I want and once in a while share it.
Regarding normalization, if it has the same meaning as the one I used for the old HP8714B, then you may have already understood ;-)
There, the procedure has been named "Normalization Calibration".
The analyzer stores measured data taken ( DUT not connected) into memory, and divides subsequent measured data by the stored data in order to remove frequency response errors. On that device, the normalization calibration could be used either for transmission or for a reflection measurement. At the end of the procedure, the DUT is inserted and when starting sweep, the data displayed is the transmission coefficient for the DUT (including all the connectors and cables) divided by the transmission coefficient for the connectors and cables alone.
So, do you think that in the case of your software, the normalization process does the same thing?
My first VNA was all mechanical. The storage normalizer was an add-on and allows subtracting the reference (and a few other tricks). There was no means to run a SOLT calibration. Or course, add a PC with some software and that can be resolved. Of course, normalize still has its place and why I continue to support it.
Believe me I know and understand this aspect. I am also an engineer, but not in the RF field.
On this forum, Dave has made it clear that everyone is an engineer who wants to call themselves such. So, sure. When I talk about engineers in the context of my software, I am assuming they hold a BS or MS in EE. Again, I'm not suggesting that it is required but that is the target audience (of one).
****
Cleanup.
Also, thinking about paid support. A friend of mine had brought me a product they had bought used and asked if I could check it out. It worked really well and I was so impressed with the design I got in touch with the company who produced it as it was no longer being offered. I spoke with sales as well as the designer explaining how impressed I was and how I was so surprised they stopped selling it.
What had happened is they made a very nice product and sold it to a market that had no clue how to use it. They were so swamped with trying to answer the basic questions (IMO it had a well written manual) that they could not focus other parts of the business. So they dropped it.
-
I've been looking back into the lockup problems that caused me to pack up the V2Plus. Enough time had passed I wanted to see if the new firmware addressed the problem. Attached picture is showing the version I am currently testing (nothing more than staying connected and collecting data). If this version will stay running for 24 hours non-stop, I will have a look to see if has any problems that would prevent it's use with my software.
https://groups.io/g/NanoVNAV2/topic/84446397?p=Created,,,20,2,0,0::recentpostdate/sticky,,,20,2,0,84446397
I wonder if the people writing the firmware are even aware that they addressed the lockup problem or if they just got lucky. :-DD If you enjoy endlessly reprogramming your devices and wasting time hunting problems like this one, I highly recommend these low cost VNAs. Endless fun. :-DD :palm:
***
missing words...
-
Hi, Joe,
There is now an alternative FW for all V2-2 versions, ported from NanoVNA by Dislord,
check this link
https://groups.io/g/nanovna-users/topic/84427595
Though haven't tried it yet
-
Hi, Joe,
There is now an alternative FW for all V2-2 versions, ported from NanoVNA by Dislord,
check this link
https://groups.io/g/nanovna-users/topic/84427595 (https://groups.io/g/nanovna-users/topic/84427595)
Though haven't tried it yet
I had spent a fair bit of time trying some of their firmware on an H4 I had purchased recently. I would have no reason to try their firmware on other devices. If you are interested in reading more about that testing:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3579600/#msg3579600 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3579600/#msg3579600)
The V2Plus has ran for 24 hours using various settings without a single lockup. :-+ It's never been this stable. Next step is to see if it will put out some good numbers.
If you don't have access to the groups.io because of their dick move to lock it, use the mirrored site:
https://nanorfe.com/forum/V2-Plus-Firmware.html (https://nanorfe.com/forum/V2-Plus-Firmware.html)
-
Thanks for the software and the excellent documentation. I have had no trouble following the instructions and getting the software up and running with my NanoVNA V2Plus4.
I do have one difficulty, which has to do with readability. On my Win 10 computer with 1600 x 1200 monitor, the software window is small and hard to read. After playing with many settings, the only workaround I can find is to change the monitor resolution to 1280 x 800, which helps some, but messes up my Windows desktop (rearranges the icons), and adds a little blur to the display.
Do you know if this is a fundamental limitation of the National Instruments platform used to develop the software? If so, I can at least quit fiddling with it.
Thanks,
John
-
Thanks for the software and the excellent documentation. I have had no trouble following the instructions and getting the software up and running with my NanoVNA V2Plus4.
I do have one difficulty, which has to do with readability. On my Win 10 computer with 1600 x 1200 monitor, the software window is small and hard to read. After playing with many settings, the only workaround I can find is to change the monitor resolution to 1280 x 800, which helps some, but messes up my Windows desktop (rearranges the icons), and adds a little blur to the display.
Do you know if this is a fundamental limitation of the National Instruments platform used to develop the software? If so, I can at least quit fiddling with it.
Thanks,
John
Who knows what you were expecting. Maybe you expect the graphs to scale. Obviously the font sizes are fixed. There are videos on YT about designing software with LabView using the autoscaling if you are interested in learning about it.
I've run my VNA software on 1280X1024 19", 1920X1080 27" and 1920X1200 24" and its very easy for me to read on them all. It is designed to run on my laptop which has a 17" display.
You should consider running one of the popular open source programs. If you really have some need to run my software and your choice of monitors was poor for your eyesight, just buy a new monitor. They are cheap.
-
I just gave this firmware a shot. Generally, it is amazing with more features, however it still has bugs for now.
I noticed this firmware could not measure the correct results in low freq band on the V2_2 hardware, e.g. from 50kHz to 100kHz. The official firmware has no problem.
Hi, Joe,
There is now an alternative FW for all V2-2 versions, ported from NanoVNA by Dislord,
check this link
https://groups.io/g/nanovna-users/topic/84427595
Though haven't tried it yet
-
> I noticed this firmware could not measure the correct results in low freq band on the V2_2 hardware, e.g. from 50kHz to 100kHz. The official firmware has no problem.
This can related to output power for SI5351 (i add option for select it, See STIMULUS->CFG SWEEP->TX POWER, for low freq range need select minimum SI -10dB), i add fix for this in next.
PS also in this fw real frequency step in < 140 MHz range = 1Hz
-
Who knows what you were expecting. Maybe you expect the graphs to scale. Obviously the font sizes are fixed. There are videos on YT about designing software with LabView using the autoscaling if you are interested in learning about it.
I've run my VNA software on 1280X1024 19", 1920X1080 27" and 1920X1200 24" and its very easy for me to read on them all. It is designed to run on my laptop which has a 17" display.
You should consider running one of the popular open source programs. If you really have some need to run my software and your choice of monitors was poor for your eyesight, just buy a new monitor. They are cheap.
It appears the display resolution of the software interface is fixed. That's the answer I was looking for, and I have no further expectations because it is free.
John
-
Who knows what you were expecting. Maybe you expect the graphs to scale. Obviously the font sizes are fixed. There are videos on YT about designing software with LabView using the autoscaling if you are interested in learning about it.
I've run my VNA software on 1280X1024 19", 1920X1080 27" and 1920X1200 24" and its very easy for me to read on them all. It is designed to run on my laptop which has a 17" display.
You should consider running one of the popular open source programs. If you really have some need to run my software and your choice of monitors was poor for your eyesight, just buy a new monitor. They are cheap.
It appears the display resolution of the software interface is fixed. That's the answer I was looking for, and I have no further expectations because it is free.
John
Again, I'm not sure how you expected it to work. Most software I use will not scale the fonts. It could be done (selecting a different font for example) but it's uncommon. LabView will allow most graphics to be scaled. Currently the software uses graphs that were manually drawn using a CAD program and saved off as raster images. If I settled on the standard graphics, these could easily be scaled but I wanted my own graphics.
Buying a monitor that is easy for you to read would seem like a must, just for your normal use.
****
Windows 10 does have that magnifier built into it. Really a poor solution IMO, but it's there.
-
I finally had some time to put a short video together showing flippers printed torque wrenches.
https://www.youtube.com/watch?v=K8lsSiZyAyY (https://www.youtube.com/watch?v=K8lsSiZyAyY)
-
Thanks a lot JoeSmith for this excellent SW. I am learning to use it... Available options are massive, but I believe it is very powerful.
As for the readability issue on high density screens, I think I found a solution in Win10 that works nicely.
In C:\Program Files (x86)\NanoVNA_V2Plus right-click the .exe, select "properties" tab "compatibility"
Click "Change high DPI settings"
Select "High DPI scaling override" option "System (enhanced)"
In my case that made the display crisp and clear and very well readable. Only drawback is that some vertically rotated graph legends were cut off, but I can imagine what they say.
Best
Al
-
As for the readability issue on high density screens, I think I found a solution in Win10 that works nicely.
John was having problems with a 1600 x 1200 monitor. I have used it on monitors up to 1920X1200 24" with no problems. John fails to provide details about the size the monitor they are using. If my crystal ball would ever get repaired then maybe I could see it was an 4" LCD.
I would expect with the display and keyboard being most peoples primary interface to the PC, that you buy something that fits you. Especially if you use the computer often. There are 1600X1200 17" monitors fairly cheap but with my ageing eyesight, at that ratio I would have no use for one.
-
Forgot to mention that I am using a Surface with 2160x1440 resolution. The unmodified / standard magnified window was blurry and difficult to read. With the settings above it is crisp and clean.
BR
-
Forgot to mention that I am using a Surface with 2160x1440 resolution. The unmodified / standard magnified window was blurry and difficult to read. With the settings above it is crisp and clean.
BR
12" display? Do you have the docking station with a separate monitor?
-
10" display, no docking
-
Wow!! No wonder you were having problems viewing it. Maybe John was attempting to run it on a small tablet as well.
-
@joeqsmith thanks again for sharing this incredible piece of SW. I still can't believe I am using a little cheap box with this professional interface.
I am trying to analyze the recorded sweep data in Igorpro for prototyping a medical radar application (trying to visualize heartbeat / breathing by analyzing the phase of the signal reflected by the body surface).
If you find the time, could you provide some short hint how the binary sweep data are structured in the recorded sweep file? Little / big endian, byte index, port1 port2 interleave,...
Thanks a lot in advance, best regards
Albrecht
-
Someone else asked a similar question. If you know what format you need, document it. Make sure you include every detail. It can be ASCII or anything else you want.
-
What I need would be similar to a touchstone s2p file:
Columns
Freq Re{S11} Im{S11} Re{S21} Im{S21}
or alternatively
Freq MagS11 PhS11 MagS21 PhS21
Lines
Freq1
Freq2
...
Freq1
Freq2
...
for continuous sweeps
If it is ASCII or binary doesn't matter, I could read both as long as I know the header / offset and byte structure of the binary.
-
Which software are you are using? I may add it to the main program is why I ask.
Let's assume ASCII, do you want the frequency in Hz? SI units? What? Same for Mag in dB and phase in degrees?
Are you wanting to use a SPACE, 0x20 for the delimiter as shown?
How do you want to mark the end of line? CR? CRLF? LF?
***
Also, I don't understand the Freq1 showing up twice in your example.
-
First, thanks a lot for your help! I really appreciate it.
I am using a software called IgorPro, that I am familiar with. It is similar to Mathlab, but is more powerful in doing complex math in (almost) real time, therefore cool for prototyping, later I am planning to retrieve the data directly using the com port of the Nanovna. Igor can read any data structure as long as I can tell it the structure.
So for your questions, anything that is most convenient for you when programming. Freq in Hz Mag in dB and phase in ° would be fine. It is however no problem to convert from other units if this would save your time. Space as delimiter and CR EOL would be fine too. Or if binary the byte structure of the float and the indexing / header length would be all that is required to read it.
With the freq1 showing twice (looping) I mean the recording should loop through the frequencies for multiple repeated sweeps... Of course it would be enough to have the frequencies only once, they do not need to be repeated
-
When I asked
Which software are you are using? I may add it to the main program is why I ask.
I am referring to my software. I would have no way to add anything to IgorPro. No matter as it sounds like you shouldn't have any problems then working with the binary file directly.
FREQ (double)
CHANNEL0&1 (double complex)
The data is contiguous.
-
Sorry, I misunderstood you. Using your latest release r2.0.3 with a NanoV2+4.
Should be able to read your binary, but do not understand yet. Your bin file seems to have a header, do you know how long that is / where the data block starts?
FREQ (double)
CHANNEL0&1 (double complex)
means
FREQ (double)
CHANNEL0(double complex)
CHANNEL1(double complex)
?
I am reading the Labview specs right now, I think I am finding the definitions. Looks like double complex is 64bit real 64bit imaginary. Will try to figure it out, thanks a lot!
edit: With the freqs being repeated I should be able to find the data block/ header end. Will bug you only again if I can't figure it out
-
Yes, channe0 followed by channel 1. Yes, double is 64-bit. Yes complex will store both the real and imaginary component to two separate 64-bit numbers. The header is from prepending the array size. Data is stored big-endian.
-
Thanks a lot. That will do
-
If you get stuck, let me know. It would only take a few minutes to write a translator.
***
Good to see someone attempting to use it for something other than VSWR. I was trying to measure various liquids with the V2Plus4 using a simple home made coaxial probe.
https://www.mdpi.com/2075-4418/8/2/40/pdf (https://www.mdpi.com/2075-4418/8/2/40/pdf)
https://www.keysight.com/us/en/product/N1501A/dielectric-probe-kit.html (https://www.keysight.com/us/en/product/N1501A/dielectric-probe-kit.html)
-
Your remark about prepending array size put me right on track :-+
I guess it goes like: Uint size, frequencies, Uint size, Ch1 complex, etc.
I started with VSWR too, was fun to try-and-error a Vivaldi out of copper tape. When the Smith chart shows a bit too much inductance, cut some tape and make the coupling capa larger... Works like a charm, got the SWR below 1.2 in the entire 2.4 G ISM band (need directional antennas for the radar). Now I have the rough shape, will cut it out of copper sheet and put it in a can (side lope suppression) to reduce direct path reception.
Its amazing what this little thing can do, but your software is definitively the icing on the cake. Reference subtraction, all the options for stimulus, automatic marker placement, ... incredible. :-+ :-+ :-+ :clap:
-
In the case of this software, I've used Touchstone which isn't going to work for cases like this where we want to look at continuous sweeps. If I need to interface with another program, I will normally use CSV. Normally when I want to look at the trends (for example watching how the wife's nail polish cures), I just load it into that 3D viewer. It slices up the data by sweeps over time. Besides surface, you can also select scatter plots.
In your case, you need to know how many samples make up a single sweep, then parse the data. Easy enough to look for the frequency to repeat.
-
Nail polish curing control by RF :-DD You made my day!
I am planning to fft the sweep data and then digitally filter out a certain radar range / frequency window. Then look at phase shift in this window.
It's late here now, with the hexeditor I do understand the structure of the file now. The sample number seems to be written in front of each data block as UINT32. Will try to read the binary tomorrow.
-
Just copy the file and unzip it. It will prompt you for a binary input file and a CSV output file.
Output will be freq(Hz), real,img,real,img
2360000000.000000,0.454178,0.164357,-0.000022,-0.000037
2360050000.000000,0.454497,0.164947,0.000059,-0.000095
****
Moved to Github
-
Wow. I am speechless. I owe you a case of good beer or a good bottle of Bordeau, your choice! Thank you so much. Will try to make that happen with my next trip to the US!
You saved me a day of programming, min...
Tomorrow I will use your translator. Cheers
-
:-DD If I showed you the software in LabView, you would laugh. This was maybe 10 minutes of work, really! Of course, it also looks like a 10 minute program. Let me know how it works out.
-
Doesn't matter how long it took you. I am using your software, and now you're even cooking extra dishes...
I tried it of course right away, with data where I recorded the radar echo from my body. Raw data already show some action in a certain frequency band which probably translates to a range distance. Now it is 1am here and I need to get some sleep. Thanks and I will keep you posted on my adventures...
-
Good to hear it may do what you need. I have created a branch named Utilities and have included the EXE there as others may find it helpful. I made a small change where it now just asks for the binary file and will use the same name for the output but with the CSV extension.
***
Almost forgot,
https://www.eevblog.com/forum/rf-microwave/fingernail-polish-and-rf-front-ends-do-they-mix/msg3079836/#msg3079836 (https://www.eevblog.com/forum/rf-microwave/fingernail-polish-and-rf-front-ends-do-they-mix/msg3079836/#msg3079836)
-
Now with your tool removing any of my lame excuses the old brain is fuming with complex calculus...
A humble suggestion for the user interface of your SW if I may. I find it all super self explaining, except what was confusing to me was that there are two separate stimulus ranges/modes: the first one center/span, the second min/max. If you click on either of these titles or numbers, you activate that range. Only visible by the freq scale in the graphs, not where you click.
And when you load a calibration, it (reasonably) activates the min/max range that was active during that calibration, I find very cool, after I got it :o.
So if I may suggest to draw a frame around each of the two stim range value blocks and somehow indicate which one is currently active, would help dummies like myself. Took me a while to figure this out, I inadvertently switched stim freq range more than once. You wrote about it somewhere in the manual, but it is a bit hidden in the deep.
-
Wow, that looks like total ass. I assume that is on your 10" Surface Pro. If you don't change the settings
Select "High DPI scaling override" option "System (enhanced)"
, is is still mangled up like this?
except what was confusing to me was that there are two separate stimulus ranges/modes: the first one center/span, the second min/max.
It's not that simple. There is also CW and segmented sweeps. For segmented, there is quasi log and linear. In segmented, the Span will have a different purpose and the order that the data is entered will become very important. In some cases the transmission graph will not reflect the current sweep range.
I have no doubt that all of these settings can pose a huge problem for the random button pusher who just wants to try things without taking the time to learn how they work. I fully understand that we are living in the age of expertise. I doubt very much that adding a simple box around a few widgets will do anything to help and may even further confuse this group. Not to mention, a change like this needs to be tested, documented and maintained.
You wrote about it somewhere in the manual, but it is a bit hidden in the deep.
No doubt that manual is very sparse and non-professional. Your dealing with a home project, not a commercial product.
Good book on the subject:
https://www.youtube.com/watch?v=EiDqPBVODHQ (https://www.youtube.com/watch?v=EiDqPBVODHQ)
-
Joe, thanks a lot again. Got it to work. Using your software recording breathing and heartbeat with RADAR using a NanoVNA V2+4. I transmitted CW 2.4 GHz using my makeshift Vivaldi antenna at port 1, receiving the reflected wave (doppler effect for movement of my chest wall) with a simple stub at port 2. Calculated phase of S21 with atan2(i,r). Range was about 1 m.
Pics:
Setup
Unfiltered moving in, three breath, holding breath, three breath, moving out.
filtered with a 3 Hz lowpass, showing the heartbeat. Same data.
-
Thanks for the update. It's maybe the most bizarre use of a VNA I have come across.
I am still curious about the poor front panel layout being tied to your scaling settings. If you turn that off, does everything look lined up, buttons the same size, no over lap.... I suspect that it causes the OS to choose a different font which is causing the alignment problems.
-
Hi Joe,
would you have an idea what the actual sampling rate is when recording raw CW data with the V2+4 and if it can be changed without going into the firmware?
Edit: I noticed that when I reduce in your SW / CW mode the "Points" to 20 the refresh of the SW gets very fast, when I reduce it further it does not accept any input anymore, seems too busy refreshing the graphs and numbers, need to kill it with task manager. I did not see any difference when I changed the "Sam/Dec" entry.
(As for my scrambled screenshot since I know most labels by heart now I do not need geezer glasses anymore and went back to the original un-garbled magnification)
My application is not so bizarre for a medical person, since it can measure vital parameters without touching the patient and from a distance through clothing and bedding. Medically extremely valuable...
Cheers
Albrecht
-
Joe, thanks a lot again. Got it to work. Using your software recording breathing and heartbeat with RADAR using a NanoVNA V2+4. I transmitted CW 2.4 GHz using my makeshift Vivaldi antenna at port 1, receiving the reflected wave (doppler effect for movement of my chest wall) with a simple stub at port 2. Calculated phase of S21 with atan2(i,r). Range was about 1 m.
Pics:
Setup
Unfiltered moving in, three breath, holding breath, three breath, moving out.
filtered with a 3 Hz lowpass, showing the heartbeat. Same data.
There´s some firmware for plus with CW?
Can you please tell me wich?
Thanks
-
The V2+4 standard firmware can do CW. https://nanorfe.com/nanovna-v2-user-manual.html "Zero span". I am using stock FW 1.2 it came with. In Joe's SW you can simply select/enter a CW frequency, it will do CW and even record the raw data. Only thing I couldn't figure out so far is the sample rate and whether it can be manipulated with the number of point settings
Edit: FW version on display git-20210538-412578c
Even standalone you have an entry in the menu "stimulus" "CW FREQ"
-
I suspect it's the OS changing the fonts. One of the problems when distributing LabView code is the various PCs may not have the same fonts loaded. You would think it would include the required fonts when installing the software but I suspect some fonts are protected by license. To work around it, it's best to use fonts that are the most common.
Your question about the sample rate isn't something I have looked into. We know the time to pull down a 400 point data set requires one second. So something in the order of 2.5mS (which would include switching between ports). Acquiring less data points will reduce the update rate but I doubt it is linear. I did try setting it to 25 points it seems to update around 65mSish. While changing the number of samples may not effect the hardware sample rate, it will certainly increase the overall uncertainly. Consider we are now spending more time dealing with the overhead to send the data.
I suspect you are really wanting to know how fast the hardware samples. Depending how the firmware was written, it may not be a constant. The easiest thing may be to ask OWO. Another option may be to look at the drive side of R301 and see how fast the receiver's input selection switch toggles.
**
Wording
-
For fun, we can attempt to measure it indirectly. From the manual for the V2Plus4, we know it will be dependent on the frequency range.
For starts, I have set the number of data points to 31, Center to 13MHz and a span of 1MHz. Notice my software shows a sweep time of 208mS. Now lets look at the output signal with my Signal Hound. We can see the time between sweeps is 207mS. But the actual time the VNA is sweeping is 45mS. It appears like it is close to 689SPS. We have lost about 75% of our data.
-
I transmitted CW 2.4 GHz using my makeshift Vivaldi antenna at port 1, receiving the reflected wave (doppler effect for movement of my chest wall) with a simple stub at port 2.
Let's see how it behaves at the frequency you are using. Again, setting the center to 2.4GHz with a 1MHz span and 31 points. Notice now that my software reports a sweep time of roughly 80mS (again, I lot of uncertainty in this measurement). Looking at the Signal Hound, the time between sweeps is roughly 78mS. The time the VNA is sweeping is about 17.3mS. Or 1.8KSPS. Much faster as we would expect from the manual. Notice that the duty cycle is roughly the same and we are still discarding 75% of the data.
-
Looking at zero span (CW), the the VNA appears to leave the output active. The time to collect the data appears to be the same as with swept. Guessing it has no effect on the actual sample rate.
***
The V2Plus4 was again set to 2.4GHz, 1MHz span, 31 points. The Signal Hound is set to zero span mode. We can now get a better idea what the data stream looks like. It appears that they are running at 2KSPS but as you can see, there is repeating pattern. I'm sure OWO would know the cause of this. That or I would need to have a look at the firmware.
-
With the Signal Hound set to 40 MS/s, zero span, it appears that the pattern is not always 4 X 500us period pulses followed by the runt and short. Where the markers are, note there were six.
The Signal Hound has a decent library allowing you to control it with an external PC. I've had mine for a few years now and really like it. I made a little demo of it decoding one my my DMMs radios. I mention it as it may be a better solution for what you are attempting to do.
https://www.youtube.com/watch?v=Mkec-Eyhg7c (https://www.youtube.com/watch?v=Mkec-Eyhg7c)
-
If you want to see some of the earlier work where I was reverse engineering the interface, 30 minutes of agony.
https://www.youtube.com/watch?v=f1UtLpSZ2W0 (https://www.youtube.com/watch?v=f1UtLpSZ2W0)
-
Thank you, very helpful insights. Need to read it a cpl of times to understand it, will do some measurements using a SDR as a spectrum analyzer. The data stream in the FIFO seems to be at 400 SPS with CW 2.4 GHz 101 pts, interesting how it switches even in CW mode. Need to do some scrounging there.
-
If you want to see some of the earlier work where I was reverse engineering the interface, 30 minutes of agony.
https://www.youtube.com/watch?v=f1UtLpSZ2W0 (https://www.youtube.com/watch?v=f1UtLpSZ2W0)
Which kind of receiver are you using?
-
Thank you, very helpful insights. Need to read it a cpl of times to understand it, will do some measurements using a SDR as a spectrum analyzer. The data stream in the FIFO seems to be at 400 SPS with CW 2.4 GHz 101 pts, interesting how it switches even in CW mode. Need to do some scrounging there.
I think you will need to be very clear about what you are asking. With my software set as you suggest, it takes about 250ms to update. 2.5ms/sample or 400Hz. Pretty much what the manual states at 400 samples per second. We are a 1/4 the amount of data, so 1/4 the time. Again, this may have little to do with the actual sample rate. It really depends what you are trying to ask.
One thing to be aware of is when using CW, the interface is not very reliable. I never sorted out the root cause but suspect there is a problem with my software.
-
Which kind of receiver are you using?
:-// :-// I am not sure what you are asking. If you are interested in more detail, I suggest actually watching the video you linked.
-
ALW, check what my software is reporting for sweep time with your setup. Is it a stable 250ms or does it jump around to 500, 750 ms?
-
As you said, the SW is a bit bitchy in CW mode. It looks like, if I click on pnts first, CWfrequ 2nd, sweep time is around 250 ms. If I click the other way round (last click on pnts), the reference subtraction in the polar plot is not working anymore and the sweep time is indicated at around 450.
However, I figured that out early on that you need to do a click on CW frequ as last action in order to have CW working. I use your ref-sub feature for all my radar tests, and it messes completely up if you do not follow that rule.
When going to your raw data tab, it looks that clicking on "points" activates a frequ sweep mode, abandoning the CW mode previously selected.
(That is one of the reasons why I suggested earlier to indicate somehow if we are in "center span" "min/max" or "CW" mode)
Interestingly, the S21 data recorded seem to come with 5 ms interval. This may mean, that the 2.5 ms is for S11 and S21 combined
-
The order is by design. The manual warns about the importance of ordering but I don't think I go into the details for CW.
Selecting the points will program the VNA with whatever the current start and stop frequencies are. Selecting CW will override the step size, forcing it to zero. If you select anything other than CW last, that step size will be overwritten.
Assuming that you enter CW correctly and you are seeing around 250ms, how much does it jump around if you watch it for 30 seconds or so? +/-50ms or +250ms or more?
-
251-265 ms
However, immediately(1st 10 s) after switching to the task it is more span. Seems to relate to cpu load somehow
I played with the num of points a bit and it is reasonably always a factor of 2.5 give or take 5%. When you activate the raw data tab that slows it down a bit.
-
That's much better than I was expecting compared with my PC. There is a newer version that I had corrected the units case (K vs k) and I will go ahead and addresses this problem with CW to make it a bit more robust.
Attached, I have further aggravated the problem prior to adding the change. With these being very minor changes and yours being stable, I won't worry about releasing it.
(That is one of the reasons why I suggested earlier to indicate somehow if we are in "center span" "min/max" or "CW" mode)
Interestingly, the S21 data recorded seem to come with 5 ms interval. This may mean, that the 2.5 ms is for S11 and S21 combined
It will always be in the last mode selected, unless you change the number of points. As I mentioned, there is also the segmented sweep to consider. A simple way would be to change the fonts colors to reflect the mode currently selected. Basically as shown.
IMPORTANT!!!!
There is an order to selecting the data. The software will always program the V2+ to the last setting you made. If you change Fcenter, the software will use the center and span to calculate the new range. If you change Fmin, the software will use the min (start) and max (stop) to calculate the range. If you were to program the min and max first, then change the span, the V2+’s start and stop would change.
Also, changing the number of points will cause the software to recalculate the sweep range based on the min (start) and max (stop).
-
Let me know if you want to try it.
-
Interestingly, the S21 data recorded seem to come with 5 ms interval. This may mean, that the 2.5 ms is for S11 and S21 combined
The V2Plus sends everything for each data point. It's not like the original NanoVNA in that regard where you can pick a choose what you want.
The software does not discretely write every sample it receives. Rather it places the entire swept data set into a queue. Once an entire error free data set has been received, the software then writes it to the file and plots it to the screen. So for 101 data points, I am expecting the software to write out 101 data points for both channels every 250ms.
***
Setting the software for 2.4GHz CW, 101 data points and recording for 1 minute, should provide 60 * 4 *101 = 24,240 points.
Letting it record and timing it by hand, using that converter I provided and importing to Excel, it seems to work out.
-
Let me know if you want to try it.
Sure I want to try it! I like the coloring of the font.
As for my application, I will try to record a pendulum movement with video and with the nano radar for getting the time base tested.
-
Let me know if you want to try it.
Sure I want to try it! I like the coloring of the font.
As for my application, I will try to record a pendulum movement with video and with the nano radar for getting the time base tested.
2.04 is on-line. Minimal testing but the changes were fairly minor.
-
Rather than a pendulum, I am just moving the connectors. I start out fairly slow then increased my speed. You may need a fairly fast camera and a few hundred hz pendulum.
Depending what you have on-hand for equipment, maybe just use an ARB in burst mode. Or just connect the two ports with a switch and pulse it. I think those GaAs parts I used would switch well below 10ns. Certainly fast enough for this experiment.
I have that first gen transfer relay that would work fine for this. I could easily collect the data for you if you knew how you wanted to run it.
-
I placed the GaAs xfer relay between the two ports and controlled it from the Arb. Starting at 100mHz and stepping 100mHz to 1Hz. Then incrementing by 1Hz to 10Hz. Then incrementing by 10Hz, and so on. Using 500MHz 101 data points to stay well within the range of the switches.
Its a simple test so if you find the data useful, I can run it how ever you want.
-
Switching at a fixed 100Hz 50% DC.
-
Switching at 500Hz.
***
Should add that I had changed to 401 data points to collect this data.
-
Didn't look at the rest yet, it's late here. But your 100Hz data look like 2 points up, 2 points down. That means we are sampling at 200 Hz / 5 ms interval, correct? Will call it a day now, thanks a lot for the help.
-
The Signal Hound was measuring a sample rate of around 500us (2kHz). At 1kHz we can see it starting to alias as we would expect.
It does all appear to make sense.
-
Didn't look at the rest yet, it's late here. But your 100Hz data look like 2 points up, 2 points down. That means we are sampling at 200 Hz / 5 ms interval, correct? Will call it a day now, thanks a lot for the help.
Notice on the 500Hz dataset, we have 2 points up, 2 points down or 4 X 500Hz or 2KHz, or 500us which is what we had measured with the Signal Hound.
****
From the manual, we know they at least mention you can get 400 points per second out of it. It needs to at least be able to sample at 400sps to achieve that.
https://nanorfe.com/nanovna-v2-user-manual.html
-
your stepped switch interval was very helpful. I marked the switch event row number and did the math (see attached table). The sampling rate of the NanoV2+4 FW is 200 Hz, which I was also told in https://groups.io/g/NanoVNAV2/messages?expanded=1&msgnum=2336 (https://groups.io/g/NanoVNAV2/messages?expanded=1&msgnum=2336)
Your 100 Hz switch shows 2 points up, 2 down, also in agreement with a 200 Hz sampling rate. With the 500 Hz switching you are switching faster than recording, showing some harmonic of the two rates I guess.
The tx behavior you see with the spectrum analyzer is a different chapter IMHO.
Thanks!
-
Sample rate 200 Hz puts my radar heartbeat recording into a healthy corner, at about 120 beats per min showing my excitement about the radar working (I started getting worried, if it was a 500 Hz sample rate I may have needed intensive care :-DD)
-
your stepped switch interval was very helpful. I marked the switch event row number and did the math (see attached table). The sampling rate of the NanoV2+4 FW is 200 Hz, which I was also told in https://groups.io/g/NanoVNAV2/messages?expanded=1&msgnum=2336 (https://groups.io/g/NanoVNAV2/messages?expanded=1&msgnum=2336)
Your 100 Hz switch shows 2 points up, 2 down, also in agreement with a 200 Hz sampling rate. With the 500 Hz switching you are switching faster than recording, showing some harmonic of the two rates I guess.
The tx behavior you see with the spectrum analyzer is a different chapter IMHO.
Thanks!
It's certainly possible it's aliasing the crap out of it at 500.
100Hz is a period of 0.010 seconds. 2 points per level or 4 points per period. 10ms / 4 is 2.5ms per sample, or 400Hz (1 / 2.5ms). Not 200.
Also, the 400 samples per second called out in the manual makes no sense with a 200Hz sample rate.
When you ask a question on the internet, be careful about what you are asking and who you are asking. Like an under sampled system, it's very easy to be led astray.
***
Knowing its 4 points per period, you know its 4 X 100Hz, or 400Hz.
-
Let me know what you think about that color selection. Try all the various modes. If you think it would be helpful, I may add it to the software for the original.
-
In your stepped switching expt you switched at 100 mHz meaning your switching interval (event to event, no matter if up or down) was 10 s initially, then 5 s, then 3 1/3 s and so on, correct?
Yes, I love your font color indicator. Now I would have known right away what mode I am in right now, would have steepened my learning curve of your SW massively :-) . Another thought I had: one could simply change all the numbers according to the last defining input. E.g. CWmode: fmax=fmin=fcenter, span = 0. Max/Min mode: Fcenter=(fmax+fmin)/2, span = fmax-fmin etc.
-
In your stepped switching expt you switched at 100 mHz meaning your switching interval (event to event, no matter if up or down) was 10 s initially, then 5 s, then 3 1/3 s and so on, correct?
I think so but don't quote me on it. Was more just to give you some idea what could be done if you wanted to try and collect some data this way. There may not even be enough data to make heads or tails out of it. I didn't get any feedback from you, so I forged ahead with the fixed rates.
-
Yes, I love your font color indicator. Now I would have known right away what mode I am in right now, would have steepened my learning curve of your SW massively :-) . Another thought I had: one could simply change all the numbers according to the last defining input. E.g. CWmode: fMax=fmin, span = 0.
Not a fan of having the software overwrite the controls. Random button pushers will end up having to reenter their settings often.
-
Getting your point, but I guess we are coming from different worlds in this regard. In the medical device industry we are trying to make a user interface as intuitive and foolproof as possible. We need to take the buttonpushers (and worse) along. The insulin pump must be also usable by grandma... Big companies have entire usability departments dedicated to this.
Here, I believe it is just 3 different ways to enter the same parameters in the end. Those parameters are interdependent, and it would be more logic and intuitive if the entries would reflect those dependencies IMHO.
But, having said that, grandma will probably not use the VNA...
-
Getting your point, but I guess we are coming from different worlds in this regard. In the medical device industry we are trying to make a user interface as intuitive and foolproof as possible. We need to take the buttonpushers (and worse) along. The insulin pump must be also usable by grandma... Big companies have entire usability departments dedicated to this.
Here, I believe it is just 3 different ways to enter the same parameters in the end. Those parameters are interdependent, and it would be more logic and intuitive if the entries would reflect those dependencies IMHO.
But, having said that, grandma will probably not use the VNA...
For my software, there is no big company or usability department. It's a home project intended to be used by engineers (EEs) starting out in RF. Of course, there are the radio hobbyists who write me about their troubles trying to read their SWR before they enter their next contest (advancing the art). They are an aging group and I am sure include some grandmas as well. :-DD
In my case, there is no "need" to support anyone as there are no customers. There's no business, no profits and a fair amount of lost time. It's a hobby. Comparing it to any business in any sector makes no sense.
If you read the manual for the V2Plus4, to set the sweep range you have a Start and Step frequency. That's it. Yes, CW, start/stop, center/span all get converted into these two numbers. Yes, the UI could just present these two numbers and be done with it. The software also supports a handful of VNAs. Each is unique in how they are controlled but I could convert them to use the start and step. To be clear, I could but won't.
UIs are a very subjective topic. MBAs love this stuff because it's not requiring any technical skills. Everyone will have an opinion about how it should work, look, scale..... Personally, I see it as a black hole and for a home project, it's not my area of interest. One more reason I use LabView....
That said, I have not bought test equipment because the company appeared to hire all new staff with new managers and failed to look at all of their previous products and how they worked. The new groups are made up of only the best people and have great new ideas. They want to show the right way to do it because the old way is just old. So, I fully agree when it comes to a real company, they better have there act together.
-
You were right. I did my "pendulum" experiment with a slowly swinging iron suspended from the ceiling with a 1m chord as radar reflector. The graph shows the S21 phase in red, the analysis of video of the swing of the iron (using a program called kinovea) in blue. So the time base for the blue curve is the video frame rate of 30 fps. Result: The sampling rate of the NanoV2+4 is 400 Hz at 2.4 GHz CW with 101 points per "sweep", as advertised in the manual.
(The superimposed swing in the radar phase comes from a circular swinging movement of the iron, the blue curve shows only 1D)
So I guess in your stepped interval expt switching frequency was referencing to a full switching period (on/off).
-
Glad that things are starting to make some sense.
So I guess in your stepped interval expt switching frequency was referencing to a full switching period (on/off).
100Hz is a period of 10ms. It's a 50% duty cycle, so for 5ms the switch is on and 5ms its off. Think of it as a single pole single throw switch across port 1&2. System was not calibrated as we are interested in time.
It will be interesting to see how people will feel about you suggesting you are pointing a microwave radar system at them. :-DD Will suggesting it's -20dB have any effect? Of course the same people who claim you caused all their heath problems, will jump on their cell phones for hours at a time with their wireless ear buds plugged in. :-DD
****
Once you are certain of your findings, you may want to reply in the groups.io. It may help prevent spreading misinformation.
-
It is medically totally innocent. First, the only effect a cm wave has on the body is heating. The power used here is less than Wifi, BT etc., and heating is not measurable. Sitting in the sun is way worse in this respect. 2nd, as you can see, the waves are totally reflected at the conductive skin surface.
There were however some nasty accidents in the early times of radar (40s) when workers were doing stuff on the roof in front of active kW antennas at lower freqs where reflection is incomplete. They were effectively fried, and because humans have no temp sense inside the body they did not notice until some hours later when it was too late...
-
****
Once you are certain of your findings, you may want to reply in the groups.io. It may help prevent spreading misinformation.
Good point. Done.
-
You should be putting together a little video showing your efforts.
***
I did my "pendulum" experiment with a slowly swinging iron suspended from the ceiling with a 1m chord as radar reflector.
We can then see your soldering iron, clothes iron, golf iron..... hanging from the ceiling and swaying.
-
I have released 2.06 for the original NanoVNA which included the units case corrections and colored fonts for the range selected. Again, minimal testing was done on this version.
-
A bit more detail on the slow pendulum radar experiment with the Nano2+4 at CW 2.4GHz:
Centered IQ by nulling the DC, then unwrapping the atan2 phase with 2pi. The nano seems quite stable in frequency and phase, pretty low noise (Wifi was on!), and is drawing nice circles. Unfiltered complex S21 polar over 15 s below.
Then horizontal displacement taken from video in blue (not taken simultaneously) and the 10Hz filtered phase in red. Video rate was 30fps, sampling rate of the Nano is 400 Hz.
Last unfiltered S21 phase (now unwrapped and quadrature corrected).
-
What is the target you are using and can you explain the video?
-
Target is an old iron appr. 1kg, swinging/suspended from the ceiling with appr. 1 m chord. Amplitude appr. 4 cm. The 1st image is a still from the video, the lower corner was marked and tracked in kinovea to record it's horizontal movement.
The iron is reflecting the radar beam from a Vivaldi antenna connected to port 1 visible in the 2nd image upper right corner. Reception of reflected signal with a stub dipole connected to port 2.
-
....video frame rate of 30 fps...
And how does the camera with it's 30fps fit in? How do you get the signal off of it?
***
Hey, you have that new software loaded and running!
-
Its done with a software called Kinovea, normally used by sports physiologists to track the movement of joints and arms/ legs in video: https://www.kinovea.org/ (https://www.kinovea.org/)
(https://www.kinovea.org/images/pitches/tracking.gif)
You can place a marker on a feature in the video and it will track that corner / contour and create a displacement/time diagram. Cool software, I (ab)used it for tuning the suspension of my motorbike :-DD
This type of image analysis is btw based on IFFT of the image to get into the space domain.
Thats how I created the blue curve. The horizontal displacement is in pixels per second, but I do not care about the amplitude of the movement, only about the time base which is now the frame rate of the phone camera. Amplitude I have already in the phase shift of S21, which is appr. 6.2 cm (half wavelength) for 360° shift because the beam goes forth and back.
Of course I have your SW running, couldn't do all this without it!
-
I just assumed that was your math library. That is some very slick software and now I can see I have one more thing to look into.
You still ride a motorbike? I have a bit of a 2-wheel addiction myself. They can be a lot of fun.
https://www.youtube.com/watch?v=sYUw1S9SESU (https://www.youtube.com/watch?v=sYUw1S9SESU)
-
Yup
-
Very nice bike.
***
A couple of old geezers with sport bikes playing with their VNAs... :-DD
-
It has a lot of character. When you open the throttle she is tilting to the side for the inertia of the longitudinal crankshaft ;D Becomes second nature after a while to steer this out... I love them naked and air-cooled, and I love torque in the low revs.
Yours is a real hotrod!
As long as we are playing with bikes and waves, we are alive... Toys tend to get more complex with age
-
I was talking with a friend the other day about the late Angus McPhail. You can't have a discussion about off the spectrum bikes without including him. :-DD
And for those who have never heard of the Jade Warrior, have a look.
https://www.youtube.com/watch?v=g_g6C1GoxmE (https://www.youtube.com/watch?v=g_g6C1GoxmE)
-
A good transfer relay may set you back more than $500 so I can understand trying to find cheaper alternatives. Attached are two circuits.
Circuit 1 uses a DPDT coaxial switch and a couple of tees.
Circuit 2, my personal favorite, uses two VNAs with a couple of tees.
Assuming that the goal is to work within the full frequency range of the NanoVNA and no loss of performance, how many potential problems can you identify?
***
For a more details
https://nanorfe.com/forum/T-Check-with-LabView-NanoVNA.html (https://nanorfe.com/forum/T-Check-with-LabView-NanoVNA.html)
DPDT switch being proposed for circuit 1
https://www.rfparts.com/72-2-p.html (https://www.rfparts.com/72-2-p.html)
For circuit 1 we are talking about a manual switch. Without major modifications, it would be difficult to automate. I had seen a video with a guy hooking up an actual transfer relay to a NanoVNA but they also had no way to control or calibrate it. My old 8754As test set has two buttons on the front to select the direction which I am sure many people used back then. My software will control a transfer relay and allow you to calibrate with one in the signal path but there are no provisions for a manually controlled one. Someone would need to add support to the open sourced projects. While having to manually change the state may not be the most effective way to work, it doesn't really degrade the performance. So, no points given for that one.
***
Additional points awarded for coming up with your own circuit. Swapping the cables is a negative points.
-
Two Ts will work, but really, what you probably want is either a 50 ohm resistor in series with each port, or a 2 way divider. That way, the impedances presented to the UUT will be 50 ohms (not 25 ohms). The 25 ohms would calibrate out, but some UUTs (amplifiers) may not like the mismatch.
I'm experimenting with this right now.
-
Two Ts will work, but really, what you probably want is either a 50 ohm resistor in series with each port, or a 2 way divider. That way, the impedances presented to the UUT will be 50 ohms (not 25 ohms). The 25 ohms would calibrate out, but some UUTs (amplifiers) may not like the mismatch.
I'm experimenting with this right now.
In this case we know "works" was defined by: No reason it won't work - at least to the performance of the NanoVNA.
With nothing more than Ts to couple the two VNAs, even with the added stubs, poor termination, 25 ohms, running the VNAs asynch, the system will perform to the same level as using one VNA properly.
There was an paper I came across that was talking about common problems beginners have with VNAs. One of the most common problems was the beginner feels they can calibrate out every error. :-DD I remember thinking the person that wrote that paper had some pretty good stories to tell.
As far as what you probably want
, I went over that some time ago and wasn't able to come up with anything worth documenting. This is why an actual transfer relay was used. Sprinkling in a few 50 ohm resistors isn't something I would consider.
The DPDT may be acceptable at low frequencies with the added unterminated stubs. Even with the cables bent to their tightest radius, that stub makes zero sense to me and I see no reason to take the hit in performance. It may be perfectly fine for the person who posted it.
-
If you like sprinkling resistors around, you could use two back to back splitters to improve the match. Fairly low cost and would work over a fairly wide range. With 6dB loss each and not addressing the asynchronous operation, I wouldn't think anyone would consider it a working solution. :-DD
-
has the nano vna been made to work at 2.4ghz yet,ie for wifi antenna tuning?
-
has the nano vna been made to work at 2.4ghz yet,ie for wifi antenna tuning?
If there is, it's nothing I would use. The performance really suffers as you move above 300MHz. The following section compares my original NanoVNA against a vintage PNA while looking at a GHz filter. Results are very poor as we would expect. I do like the OWOs V2P4 that is shown. If you are looking for a low cost VNA to work above 300MHz, it's a good choice. The video is a review for it.
https://youtu.be/XaYBpPCo1qk?list=PLZSS2ajxhiQD2gftdurGQoyGpUM_HobNI&t=2733
-
I'm experimenting with this right now.
And how did that turn out?
-
Hi, this not seems a CW
-
Joe, thanks a lot again. Got it to work. Using your software recording breathing and heartbeat with RADAR using a NanoVNA V2+4. I transmitted CW 2.4 GHz using my makeshift Vivaldi antenna at port 1, receiving the reflected wave (doppler effect for movement of my chest wall) with a simple stub at port 2. Calculated phase of S21 with atan2(i,r). Range was about 1 m.
Pics:
Setup
Unfiltered moving in, three breath, holding breath, three breath, moving out.
filtered with a 3 Hz lowpass, showing the heartbeat. Same data.
This is a CW
There´s some firmware for plus with CW?
Can you please tell me wich?
Thanks
-
Hi, this not seems a CW
Start reading here:
https://www.eevblog.com/forum/testgear/nanovna-v2-aka-s-a-a-2/msg3205780/#msg3205780 (https://www.eevblog.com/forum/testgear/nanovna-v2-aka-s-a-a-2/msg3205780/#msg3205780)
-
...
I started with VSWR too, was fun to try-and-error a Vivaldi out of copper tape. When the Smith chart shows a bit too much inductance, cut some tape and make the coupling capa larger... Works like a charm, got the SWR below 1.2 in the entire 2.4 G ISM band (need directional antennas for the radar). Now I have the rough shape, will cut it out of copper sheet and put it in a can (side lope suppression) to reduce direct path reception.
Its amazing what this little thing can do, but your software is definitively the icing on the cake. Reference subtraction, all the options for stimulus, automatic marker placement, ... incredible. :-+ :-+ :-+ :clap:
For fun I attempted to use the picture of your antenna to replicate it. Also, for fun I thought I would show the VSWR with the V2P4 uncalibrated (yellow trace) and then calibrated (1G - 3GHz range). Also shown are a few other Vivaldi antennas I had made.
-
Swag at a new antenna.
-
Reading up on the inverse chirp z-transform.
https://coppermountaintech.com/wp-content/uploads/2019/09/Time-Domain-Analysis.pdf (https://coppermountaintech.com/wp-content/uploads/2019/09/Time-Domain-Analysis.pdf)
https://www.sbrt.org.br/sbrt2017/anais/1570359870.pdf (https://www.sbrt.org.br/sbrt2017/anais/1570359870.pdf)
https://www.nature.com/articles/s41598-020-60878-7.pdf?proof=t (https://www.nature.com/articles/s41598-020-60878-7.pdf?proof=t)
-
There is a new version now in the works. Most of the changes are for the TDR measurements but I have added some other features as well.
-
What hardware variant/trusted seller do you recommend that gives the best results for the software, I've seen a (most likely fake clone of fake clone) NanoVNA of a friend that was frankly speaking a piece of junk, never producing 2 similar measurements in a row |O.
So is there a trusted reliable seller somewhere, preferably in EU, best in DE, but wherever it is if it ships in DE is OK.
Many thanks for your software,
DC1MC
-
What hardware variant/trusted seller do you recommend that gives the best results for the software, I've seen a (most likely fake clone of fake clone) NanoVNA of a friend that was frankly speaking a piece of junk, never producing 2 similar measurements in a row |O.
So is there a trusted reliable seller somewhere, preferably in EU, best in DE, but wherever it is if it ships in DE is OK.
Many thanks for your software,
DC1MC
I see that question posted a lot. I really don't have a lot of experience with the different manufactures. I bought the V2Plus and V2Plus4 directly from OWOs company. The H4 appears to be well put together kit, but I have no idea who produced it. I am also not sure where my friend bought the two original NanoVNAs.
As far as making a recommendation on what to buy, it depends on how much you want to spend and how you plan to use it. The firmware has been by far the biggest problem I have ran into.
If you do not need narrow band measurements and plan to work above 300MHz, the V2Plus4 would be my pick out of the low cost VNAs. If you want to work below 300MHz and need barrow band, or if you want to make PDN measurements, get the original NanoVNA. If you need both, I would buy both products.
If you're the typical radio hobbyist and want to measure your antennas SWR out to three places beyond the decimal, stop kidding yourself and buy an SWR meter.
As far as your friends comment, its hard to say. They would need to post some actual data, their setup.... before I could offer any input. You read some of the things people post, like using a couple of VNAs and Ts to make full 2-port measurements or connecting their VNA directly to their radios PA and you get the idea that many users are just starting to learn some basics. I wouldn't look to them for advice. (All actual posts BTW. You can't make this stuff up.)
I've shown a lot of tests using these low cost VNAs and have been pretty impressed with the data I have pulled from them. Obviously working at higher frequencies will require more care to avoid measurement errors. If your friend has a blog where they are posting their test results, provide a link and I will have a look at it.
***
-
What hardware variant/trusted seller do you recommend that gives the best results for the software, I've seen a (most likely fake clone of fake clone) NanoVNA of a friend that was frankly speaking a piece of junk, never producing 2 similar measurements in a row |O.
So is there a trusted reliable seller somewhere, preferably in EU, best in DE, but wherever it is if it ships in DE is OK.
Many thanks for your software,
DC1MC
This is the manufacturer (Hugen) of Nano H and H4, TinySA etc: https://nanovna.com/?page_id=121
I would suggest that you get the H4 as it is a more capable device with standards that have been characterized (search for Kurt Poulsen's calibration data).
-
What hardware variant/trusted seller do you recommend that gives the best results for the software, I've seen a (most likely fake clone of fake clone) NanoVNA of a friend that was frankly speaking a piece of junk, never producing 2 similar measurements in a row |O.
So is there a trusted reliable seller somewhere, preferably in EU, best in DE, but wherever it is if it ships in DE is OK.
Many thanks for your software,
DC1MC
This is the manufacturer (Hugen) of Nano H and H4, TinySA etc: https://nanovna.com/?page_id=121
I would suggest that you get the H4 as it is a more capable device with standards that have been characterized (search for Kurt Poulsen's calibration data).
Thanks for the tip, the H4 variant is also called "Hugen 3.4 with a 4" screen"?
"This VNA is the latest official 3.4 Hugen version, it has a TFT touch screen available in 2 sizes 2.8 "(7.1cm) and 4" (10.1cm), power supply by USB-C cable (supplied) or internal battery included 650mAh or 1950mAh (H4)."
Cheers,
DC1MC
-
What hardware variant/trusted seller do you recommend that gives the best results for the software, I've seen a (most likely fake clone of fake clone) NanoVNA of a friend that was frankly speaking a piece of junk, never producing 2 similar measurements in a row |O.
So is there a trusted reliable seller somewhere, preferably in EU, best in DE, but wherever it is if it ships in DE is OK.
Many thanks for your software,
DC1MC
This is the manufacturer (Hugen) of Nano H and H4, TinySA etc: https://nanovna.com/?page_id=121 (https://nanovna.com/?page_id=121)
I would suggest that you get the H4 as it is a more capable device with standards that have been characterized (search for Kurt Poulsen's calibration data).
Thanks for the tip, the H4 variant is also called "Hugen 3.4 with a 4" screen"?
"This VNA is the latest official 3.4 Hugen version, it has a TFT touch screen available in 2 sizes 2.8 "(7.1cm) and 4" (10.1cm), power supply by USB-C cable (supplied) or internal battery included 650mAh or 1950mAh (H4)."
Cheers,
DC1MC
I have some "NanoVNA-H4" that never sees any use due to the lack of stable firmware for it. It appears to have similar problems that I saw with the original Nanovna a few years ago. It cost about $100 USD. I bought it after someone here was posting about having problems when trying to use my software with it. While some newer firmware allows it to support more data points, it's plagued with problems. The focus seems more on adding features than fixing problems. If you are planning to run headless, why pay for the larger LCD. I would save the $50 and get the original if you are working below 300MHz, need narrow band or want to measure PDNs.
You may even be better off with a spectrum analyzer and tracking generator. It really depends. I assume you are posting here because you want to use my software for some reason.
If you are a beginner and just wanting to learn some basics, I wouldn't worry too much about the standards or cables. Of course, your goals may be different. I had someone post me about trying to use one of these low cost VNAs to look at a metrology grade Beatty standard with 10 samples or some such nonsense because it apparently improves the edge rates. There is a lot you could learn a lot from just reading the papers published by HP.
First 10 minutes or so discusses the VNAs I have and their shortcomings.
https://www.youtube.com/watch?v=Y8ouApeex78 (https://www.youtube.com/watch?v=Y8ouApeex78)
-
Thanks for the tip, the H4 variant is also called "Hugen 3.4 with a 4" screen"?
"This VNA is the latest official 3.4 Hugen version, it has a TFT touch screen available in 2 sizes 2.8 "(7.1cm) and 4" (10.1cm), power supply by USB-C cable (supplied) or internal battery included 650mAh or 1950mAh (H4)."
Cheers,
DC1MC
Yes that's the one. AFAIK only the 4" version gets the new hardware updates (new lower noise DC-DC converter, microsd slot etc).
-
I have some "NanoVNA-H4" that never sees any use due to the lack of stable firmware for it. It appears to have similar problems that I saw with the original Nanovna a few years ago. It cost about $100 USD. I bought it after someone here was posting about having problems when trying to use my software with it. While some newer firmware allows it to support more data points, it's plagued with problems. The focus seems more on adding features than fixing problems. If you are planning to run headless, why pay for the larger LCD. I would save the $50 and get the original if you are working below 300MHz, need narrow band or want to measure PDNs.
I haven't had any issues with H4 and DisLord firmware (I believe that all H4 in production come with his firmware) but I only use NanoVNASaver.
Anyway please post your issues at https://github.com/DiSlord/NanoVNA-D/issues or https://groups.io/g/nanovna-beta-test/
Hugen has raised the price recently, I got my H4 last November, from his store, for less than $60. Current price is ~$80 (with shipping).
-
I have some "NanoVNA-H4" that never sees any use due to the lack of stable firmware for it. It appears to have similar problems that I saw with the original Nanovna a few years ago. It cost about $100 USD. I bought it after someone here was posting about having problems when trying to use my software with it. While some newer firmware allows it to support more data points, it's plagued with problems. The focus seems more on adding features than fixing problems. If you are planning to run headless, why pay for the larger LCD. I would save the $50 and get the original if you are working below 300MHz, need narrow band or want to measure PDNs.
I haven't had any issues with H4 and DisLord firmware (I believe that all H4 in production come with his firmware) but I only use NanoVNASaver.
Anyway please post your issues at https://github.com/DiSlord/NanoVNA-D/issues (https://github.com/DiSlord/NanoVNA-D/issues) or https://groups.io/g/nanovna-beta-test/ (https://groups.io/g/nanovna-beta-test/)
Hugen has raised the price recently, I got my H4 last November, from his store, for less than $60. Current price is ~$80 (with shipping).
I have no plans to invest any more time into the H4. If you're interested, you may find the discussion about some of the problems I mention with the H4 here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3577360/#msg3577360 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3577360/#msg3577360)
-
I have no plans to invest any more time into the H4. If you're interested, you may find the discussion about some of the problems I mention with the H4 here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3577360/#msg3577360 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3577360/#msg3577360)
Browsed the next few pages, his English proficiency certainly did not help with diagnosing the issue.
Anyway can you link to the firmware that works for you, if I get some free time I would like to compare
the results that I get with it and with the latest firmware from DisLord.
-
I have no plans to invest any more time into the H4. If you're interested, you may find the discussion about some of the problems I mention with the H4 here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3577360/#msg3577360 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3577360/#msg3577360)
Browsed the next few pages, his English proficiency certainly did not help with diagnosing the issue.
Anyway can you link to the firmware that works for you, if I get some free time I would like to compare
the results that I get with it and with the latest firmware from DisLord.
I never found a version of firmware that would work with my H4. If I did, we wouldn't be having this conversation.
For the original NanoVNA, I am still using the version that some of the locals here had worked on to correct some of the problems. That version is stored with the software. For the V2Plus4, I am using the firmware that was supplied with it. That's been stable from the start.
-
I never found a version of firmware that would work with my H4. If I did, we wouldn't be having this conversation.
For the original NanoVNA, I am still using the version that some of the locals here had worked on to correct some of the problems. That version is stored with the software. For the V2Plus4, I am using the firmware that was supplied with it. That's been stable from the start.
I was referring to firmware for the 2.8" version. Where is that file stored again? I browsed your github page and listed
the files in the multi part archives (haven't seen a multi part archive in years ;) ) but nothing there resembles the firmware
for the nano.
-
As I mentioned, the spanned ZIP is because Github limits the file sizes. Take the time to read the README file or a least the first few sentences. That should get you started. You do not need to DL the entire LV runtime to get the firmware.
If you like, you can also post the location and version of the firmware you feel is working and I can run it through my simple regression test.
***
The updates to the software is pretty much finished and tested. I need to get the manual updated as well. The plan is to again make a short video to demonstrate the changes.
If there is something specific anyone would like to see demo'ed, feel free to ask and I'll try to include it.
-
Preview of the latest release.
https://www.youtube.com/watch?v=dI2LjW_joXA (https://www.youtube.com/watch?v=dI2LjW_joXA)
-
So I was close to cutting it loose, but someone had asked about adding additional features for characterizing amplifiers.
https://nanorfe.com/forum/Preview-of-my-latest-software-updates.html
For just adding the B factory mentioned, it's a simple enough thing to do. Maybe use the two scales off the main plot. Adding the stability circles may be more difficult depending what people would want to see. Also seems like other stability factors may be useful... I think I would end up just adding a whole new tab to the advanced menu specifically for amplifier design.
With these low cost VNAs not being a 2-port analyzer, we are back to needing a transfer relay. Or OWO needs to move ahead... :-+
Just curious if anyone here has any interest in such a feature. If so, any thought on how to present the data? Any tools you are currently using?
-
Adding something like this on a separate tab would be simple enough. Maybe allow user to select between gain and stability circles on the same graphs... I try to keep the basics on that main menu and jamming it onto that may be a bit much.
-
Adding something like this on a separate tab would be simple enough. Maybe allow user to select between gain and stability circles on the same graphs... I try to keep the basics on that main menu and jamming it onto that may be a bit much.
Hi, Joe,
that would be great to see this new stability analysys features.
The basic idea behind the request I've posted was to have several graphs, as described in this introductory paper by Les Besser:
https://designingelectronics.com/pdfs/AvoidingRFOscillation.pdf
This would utilise K-factor, B-factor (aka the determinant of the S-matrix), and the mu-factor.
Other graphs, including the Source & Load stability circles, might be helpful in case the more detailed study is needed.
From available books about VNA Measurements, some good examples could be taken, f.e., from
Joel Dunsmore's
Handbook of Microwave Component Measurements
others examples could be taken, f.e., from NI-AWR software or Keysight ADS documentation, etc.
Alex
-
Are you using these tools (ADS AWR) today? It may be helpful to see some screenshots of how you would like the data formatted. It may also be helpful for you to go through an example using these tools.
Also, I am very curious what you are using for your setup? Which VNA, transfer relay? Could you post a picture? You're the first person that I've seen mention using, or wanting to use all four S-parameters.
Shown are both the stability and mapping circles. They, along with the readouts are selected by the cursor.
-
After some thought, the plan is to add onto the 2-Port Plot tab.
-
After some thought, the plan is to add onto the 2-Port Plot tab.
That's would be OK, thank You.
Though I am unfamiliar with Unilateral factor.
Does it have the same definition as the mu-factor mentioned in the .pdf paper above?
In fact, most modern VNAs have this stability analysis option built-in.
At my previous job I had access to all these tools, but unfortunately, now I've been fired out, so now I am just in a process of setting up my home lab, where I cannot afford any expensive equipment.
For me it's just a hobby now, nothing more.
I shall post here some images with stability analysis graphs, but not too soon.
What's might be interesting to see in the SW features is the ability to plot a family of load stability circles on one graph simultaneously in case of broadband stability analysis, for implemented frequency sweep, as it is shown in the last section of L. Besser paper
Thanks,
Alex
-
After some thought, the plan is to add onto the 2-Port Plot tab.
That's would be OK, thank You.
Though I am unfamiliar with Unilateral factor.
Does it have the same definition as the mu-factor mentioned in the .pdf paper above?
In fact, most modern VNAs have this stability analysis option built-in.
At my previous job I had access to all these tools, but unfortunately, now I've been fired out, so now I am just in a process of setting up my home lab, where I cannot afford any expensive equipment.
For me it's just a hobby now, nothing more.
I shall post here some images with stability analysis graphs, but not too soon.
What's might be interesting to see in the SW features is the ability to plot a family of load stability circles on one graph simultaneously in case of broadband stability analysis, for implemented frequency sweep, as it is shown in the last section of L. Besser paper
Thanks,
Alex
That's too bad as I anticipated with you asking, you had a way to verify the results but it sounds like you don't have a way to run the software.
The Unilateral factor is not the same as Mu. I have the calculations for u1 and u2 but am not displaying them in my software yet. See if you can get to the following link:
https://edadocs.software.keysight.com/pages/viewpage.action?pageId=5920607
Plotting a family of circles is easily done in a text book, but I'm not sure how it would be accomplished in the real world. These are data formatting questions that I had hoped you would clear up by showing how your tools work. Considering there is a circle for each point collected. Even the original NanoVNA will capture 101 data points, so 101 circles. OWO mentions the V3 supporting 10,000 data points.
https://nanorfe.com/nanovna-v3.html
Calculating 10,000 data sets shouldn't pose much of a problem but plotting them may be a bit much. The METAS and AppCAD software doesn't support amplifier stability.
-
Because AppCAD and METAS are so limited, I started to look for another program to perform some sort of sanity check. This program is JAVA based and may be helpful.
https://personal.utdallas.edu/~frensley/
I have included the touchstone file created with the V2Plus4 that was used to generate the attached plots. At least my math appears to be correct for the stability coefficients, or at least matches up with what they show. A good sign.
Notice that they have some support for gain as well which is something I may add. They do not support the stability circles. Maybe there are other free tools that could be used to verify this part.
In fact, most modern VNAs have this stability analysis option built-in.
The old Agilent PNA I bought doesn't have any features like this. They don't even include TDR with the base install. Maybe someone with a new VNA can load the file and show some screen shots.
-
CMTs software does not appear to have support for it.
-
After much hair pulling, the power calculation is sorted or at least matches with the Texan's software.
-
Because AppCAD and METAS are so limited, I started to look for another program to perform some sort of sanity check. This program is JAVA based and may be helpful.
https://personal.utdallas.edu/~frensley/
I have included the touchstone file created with the V2Plus4 that was used to generate the attached plots. At least my math appears to be correct for the stability coefficients, or at least matches up with what they show. A good sign.
Notice that they have some support for gain as well which is something I may add. They do not support the stability circles. Maybe there are other free tools that could be used to verify this part.
Thank You very much for the links, Joe.
This seems to be a very helpful tool, I shall give it a try when I have some more spare time.
The Available gain graphs are also very interesting feature, thanks!
You are correct, I don't have all the necessary setup to perform the SW tests right now.
I ve got several SpDT SMA coax switches from Anritsu that I plan to adopt in tests.
Besides, I do have a low-cost VNA at hand that supports extracting full 2-port set of S-parameters from the DUT.
Thanks,
Alex
-
Thank You very much for the links, Joe.
This seems to be a very helpful tool, I shall give it a try when I have some more spare time.
The Available gain graphs are also very interesting feature, thanks!
You are correct, I don't have all the necessary setup to perform the SW tests right now.
I ve got several SpDT SMA coax switches from Anritsu that I plan to adopt in tests.
Besides, I do have a low-cost VNA at hand that supports extracting full 2-port set of S-parameters from the DUT.
Thanks,
Alex
Assuming your VNA supports Touchstone, maybe you can use it for your amplifier designs. I had long ago removed JAVA and had to install it just for this app. If you are aware of any better Touchstone post processors that can do some of the things you want, just provide a link.
In fact, most modern VNAs have this stability analysis option built-in.
I looked at Keysight and did not see where they had anything like stability circles included in their software. If CopperMountainTech and Keysight don't support it, I am wondering which models do?
The problem I see with using two discrete DPDT coaxial switches is you are placing unterminated stubs on the transmission lines. Maybe it won't matter for what you are doing.
Which low cost VNA are you using that has support for 2-ports? Depending on the specs, it may be worth porting the software to it.
-
While searching for tools to validate my math, I ended up watching a very basic video showing all the details for the stability circles. Attached is the output from my math which if you watch the video, seems to match up.
https://www.youtube.com/watch?v=aPy_X67YbLk (https://www.youtube.com/watch?v=aPy_X67YbLk)
-
Time to start working on the documentation. Attached showing the stability menu. Poor amplifier.
-
After some thought, the plan is to add onto the 2-Port Plot tab.
What's might be interesting to see in the SW features is the ability to plot a family of load stability circles on one graph simultaneously in case of broadband stability analysis, for implemented frequency sweep, as it is shown in the last section of L. Besser paper
Thanks,
Alex
Plotting a family of circles is easily done in a text book, but I'm not sure how it would be accomplished in the real world. These are data formatting questions that I had hoped you would clear up by showing how your tools work. Considering there is a circle for each point collected. Even the original NanoVNA will capture 101 data points, so 101 circles. OWO mentions the V3 supporting 10,000 data points.
Calculating 10,000 data sets shouldn't pose much of a problem but plotting them may be a bit much.
One way to avoid the mess would be to concatenate all the circles into one array and plot that as a single graph. Of course that would be a fairly large array but Labview can handle that much easier than trying to graph several discrete circles.
-
One way to avoid the mess would be to concatenate all the circles into one array and plot that as a single graph. Of course that would be a fairly large array but Labview can handle that much easier than trying to graph several discrete circles.
That's very nice, would be great,
Thank You !
Concerning the stability graphs in the VNAs, as far as I know, Rohde Schwartz analyzers have them as an option (but only K, mu1 & mu2 plots).
I've believe that Keysigh have this option for VNA, too, as far as I have seen it's description in Joel,'s textbook.
Which low cost VNA are you using that has support for 2-ports? Depending on the specs, it may be worth porting the software to it.
I have Jan's open source VNA, it's a fairly new project,
the USB protocol they had implemented is still a subject to minor changes as the SW is still under development.
As we had discussed previously, this work is still in progress, and it is not properly documented yet.
-
Which low cost VNA are you using that has support for 2-ports? Depending on the specs, it may be worth porting the software to it.
[/quote]
I have Jan's open source VNA, it's a fairly new project,
the USB protocol they had implemented is still a subject to minor changes as the SW is still under development.
As we had discussed previously, this work is still in progress, and it is not properly documented yet.
[/quote]
I tried downloading their latest software and loaded in that last Touchstone file. I don't see how you plot the stability with it. It seems very limited for such an expensive device. Are you using a different program with it?
-
I looked at Keysight and did not see where they had anything like stability circles included in their software. If CopperMountainTech and Keysight don't support it, I am wondering which models do?
I have double checked Joel's textbook and it appears that formerly Agilent VNA's SW had a built-in equation editor, which made it possible to plot the stability factor plots on the screen.
The user just had to enter the necessary maths equation with S-parameters there.
But the book also states that more recent analyzers already have this plots for K, delta and mu factors available, together with the test=Pass or Fail criterion.
All other calculations could be done as post-processing in external SW, I assume something like Matlab, after the S-parameters export in Touchstone format.
Jan's VNA also has this Touchstone format S-parameters export feature and some kind of built-in equation editor, too.
So, in theory, it's possible to do the job. But in practice it might be limited to different measurements errors.
-
I looked at Keysight and did not see where they had anything like stability circles included in their software. If CopperMountainTech and Keysight don't support it, I am wondering which models do?
I have double checked Joel's textbook and it appears that formerly Agilent VNA's SW had a built-in equation editor, which made it possible to plot the stability factor plots on the screen.
The user just had to enter the necessary maths equation with S-parameters there.
But the book also states that more recent analyzers already have this plots for K, delta and mu factors available, together with the test=Pass or Fail criterion.
All other calculations could be done as post-processing in external SW, I assume something like Matlab, after the S-parameters export in Touchstone format.
Jan's VNA also has this Touchstone format S-parameters export feature and some kind of built-in equation editor, too.
So, in theory, it's possible to do the job. But in practice it might be limited to different measurements errors.
I was thinking that In fact, most modern VNAs have this stability analysis option built-in.
did not mean you would have to buy Matlab or use the built in equation editor to process the data. Rather I am expecting a single button or menu option that plots the family of stability circles along with all the factors you are asking about. I've spent a few hours putting the code together and would expect anything I show would be a pale compared with the what the larger companies like Copper Mountain Tech and Keysight offer. Oddly enough, I am not finding these features.
What would be interesting is to use the internal equation editor to plot the family of stability circles you asked about, even with a small data set. Some of my old equipment supports a way to write custom code that runs native to the instruments. I've never had a use for it as the desktop PCs will normally have far more capability. With Jan's VNA running headless, you're already running on the PC. This is where changing to a new version of LabView could improve things.
-
Concerning the stability graphs in the VNAs, as far as I know, Rohde Schwartz analyzers have them as an option (but only K, mu1 & mu2 plots).
I had a look at RS and also could not find anything showing stability circles.
https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/application_notes/1ez65/1EZ65.pdf
Searching on Google images, I couldn't locate a single screen shot of ANY vendor showing this feature. I suspect that doing a family of them like I show would be too CPU intensive. Or maybe they don't get a lot of requests for it from their customers. Too bad Brian and Joel from Copper Mountain Tech and Keysight don't chime in. They may be able to provide some much needed background on it.
Shown using the typical stability circles. I have not rolled it into my software yet.
-
Concerning the stability graphs in the VNAs, as far as I know, Rohde Schwartz analyzers have them as an option (but only K, mu1 & mu2 plots).
I had a look at RS and also could not find anything showing stability circles.
https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/application_notes/1ez65/1EZ65.pdf
Searching on Google images, I couldn't locate a single screen shot of ANY vendor showing this feature. I suspect that doing a family of them like I show would be too CPU intensive. Or maybe they don't get a lot of requests for it from their customers. Too bad Brian and Joel from Copper Mountain Tech and Keysight don't chime in. They may be able to provide some much needed background on it.
Shown using the typical stability circles. I have not rolled it into my software yet.
Yes, You're correct, the "stability circles" is a feature that is still unavailable in VNAs.
I just wanted to point out that "stability factors" plots are already available in most modern VNAs.
This caused some misunderstanding, I guess.
Sorry about that
-
Yes, You're correct, the stability circles is a feature that is still unavailable in VNAs.
It is partly explained by the fact that mu1 & mu2 are considered enough for checking DUT amp behaviour.
Also, Your should not expect much from the CopperMountain as far as at is just a spin-off from a Russian Planar company.
I assume you had a reason for wanting to see the stability circles plotted. Were you asking just to see if I was able to plot them using LabView? If so, hopefully I have answered that question for you.
If I had the disposable cash, I would have ended up with a CopperMountain product. Specifically, the one Brian used to measure that common mode coaxial transformer for us.
I watched this series from Keysight on stability. Part 1 mentions some of other factors used.
https://www.youtube.com/watch?v=kVPzU7Eszk4 (https://www.youtube.com/watch?v=kVPzU7Eszk4)
-
Hi,
I want to present my development for impedance measurement and matching network design. Software working with S-A-A V2, NanoVNA V2 and NanoVNA-F V2. Its easy to use and freeware. Include user manual in PDF format.
A short video demonstrating the main features of the program.
https://www.youtube.com/watch?v=4y7B7rqwTO0 (https://www.youtube.com/watch?v=4y7B7rqwTO0)
You can download software here (http://www.ur5ffr.com/download/file.php?id=1814)
-
Demonstration of the stability circles after Alextsu's request.
https://www.youtube.com/watch?v=FuGWyXjSetI (https://www.youtube.com/watch?v=FuGWyXjSetI)
-
Both programs for the original and V2+4, along with the manual have been uploaded to Github. The older software has been removed.
-
just wondered if there are any versions of the nano vna that cover 2.4ghz wifi?
-
just wondered if there are any versions of the nano vna that cover 2.4ghz wifi?
https://nanorfe.com/nanovna-v2.html (https://nanorfe.com/nanovna-v2.html)
I had made a review for the V2+4
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3427308/#msg3427308 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3427308/#msg3427308)
Here are a few other low cost VNAs:
https://github.com/jankae/LibreVNA (https://github.com/jankae/LibreVNA)
https://www.arinst.net/ (https://www.arinst.net/)
http://www.mtinst.com/wiki/index.php/VNA6000C (http://www.mtinst.com/wiki/index.php/VNA6000C)
-
so is that a yes or no?,my nanovna is the one that had a 2.8 inch screen but i swapped the screen for a 3 inch screen from aliexpess,just wondered if firmware will make it work for 2.4 ghz,im sure it goes to 300mhz and 900 using harmonics.
-
so is that a yes or no?,my nanovna is the one that had a 2.8 inch screen but i swapped the screen for a 3 inch screen from aliexpess,just wondered if firmware will make it work for 2.4 ghz,im sure it goes to 300mhz and 900 using harmonics.
It depends what you are asking. From your original question, "just wondered if there are any versions of the nano vna that cover 2.4ghz wifi?", there are at least two models of the NanoVNA that have an upper frequency beyond 2.4GHz. So YES to question 1. I provided a link to them. I suspect now what you really want to know is if firmware is available that will allow the original NanoVNA to work past 2.4GHz. That, I don't know, but, if there was I can't see it being of any use. The performance is poor once you move past 300MHz. Still, if all you care about is the frequency, then maybe.
**
I recently posted some data for the original NanoVNA, H4, V2P and V2P4. You can get some idea about the noise and dynamic range. Both the H4 and my original NanoVNA have firmware that support up to 1.5GHz. Doubling that, is certainly going to make matters much worse. Maybe you only need 1dB of dynamic range.
https://nanorfe.com/forum/VNA-output-level.html
-
Hello, Joe,
Thanks for adding all the new features, looks great! Very nice!
Though I had not tried them yet, but I have a question:
May be it's possible to add an "S2P load" button to UI?
I was thinking of possibility to use the new SW features to work directly with imported .S2P Touchstone files,
is it possible?
Also, when I try to Save or Load any S1P files in Your app, they all are stored or read only with a comma "," in the decimal point format, while all other Touchstone use dot "." decimal point separator.
Is this by default or due to some regional LabView settings I have to tune?
Any suggestions about that?
Thank You!
-
Hello, Joe,
Thanks for adding all the new features, looks great! Very nice!
Though I had not tried them yet, but I have a question:
May be it's possible to add an "S2P load" button to UI?
I was thinking of possibility to use the new SW features to work directly with imported .S2P Touchstone files,
is it possible?
Also, when I try to Save or Load any S1P files in Your app, they all are stored or read only with a comma "," in the decimal point format, while all other Touchstone use dot "." decimal point separator.
Is this by default or due to some regional LabView settings I have to tune?
Any suggestions about that?
Thank You!
I could read the S2P files as well and have thought about dropping S1P all together. I also thought about writing a complete viewer. For now, I still use AppCAD and METAS. Both are free. Both have their limitations. Another option is to use the software that came with your VNA.
Keep in mind, that the viewer that is built into my software is currently VERY limited. I just don't have much of a need and would rather use a third party tool if at all possible.
There could very well be a regional problem with one or both applications. The V2+ uses binary and so talking with the device was never a problem. The original NanoVNA used ASCII. I added an autotest for the regional settings but it is only for the original NanoVNA. I have not considered the Touchstone files but I would not be at all surprised that they are also effected by the regional settings. There is a section in the manual on how to change these settings in the INI file. You could try that and report back if it solves your problem. If so, I may be able to correct that in software as well.
-
Looking at my software, the regional settings would effect the Touchstone files for all of my programs. I can certainly change my software to display the comma like you're used to but write text files with the decimal.
I would have thought that countries using the comma separator would want that across the board. But it sounds like in some cases you want the comma and others you don't. I don't see in the standard where they specifically mandate the separator.
Before I make any changes, I would be interested in hearing from those of you living in these areas if you want the Touchstone to reflect your regional settings, always use the decimal, or keep it as is and use the INI file? It's quick change for me, so no big deal but let's make sure that it's the right solution.
-
Looking at my software, the regional settings would effect the Touchstone files for all of my programs. I can certainly change my software to display the comma like you're used to but write text files with the decimal.
I would have thought that countries using the comma separator would want that across the board. But it sounds like in some cases you want the comma and others you don't. I don't see in the standard where they specifically mandate the separator.
Before I make any changes, I would be interested in hearing from those of you living in these areas if you want the Touchstone to reflect your regional settings, always use the decimal, or keep it as is and use the INI file? It's quick change for me, so no big deal but let's make sure that it's the right solution.
Hello, Joe,
Thanks for comments on this issue!
For sure, to make all the S2P files export-import process straightforward, the Touchstone files should always use a dot separator.
This is the only way to work with S2P files in other SW tools correctly.
In all other cases, I suppose, comma or dot don't really matters.
Thanks,
Alex
-
I'm sure you are aware that I posted in the IOgroups as well. Outside of you, zero feedback.
I wonder how you deal with other software tools. It is that the culture is so tied to the comma that you just can't get rid of it? Now you're stuck with some sort of hybrid case? Maybe similar to the USA and the metric system. We just can't seem to pitch the old British units. But I digress.
Let me give the whole Touchstone subject some thought. The import was added for my own testing and is not generic. This really needs to be created from scratch. It also only stores to memory which again is not very useful.
In the mean time, you should be able to change the INI file to handle the writes.
-
I rewrote the Touchstone import from scratch. It supports (DB, MA, RI) (G, M, K and Hz) formats. It should handle both S1P and S2P automatically. It checks for the frequency to increase and no tokens after any data is found. Comments are allowed throughout the file. The software expects at least one space (0x20) to be used as a delimiter. Some files will used more than one space. Others will end the line with a space. The software handles these cases as well.
I had discovered AppCAD actually has support for stability circles. When I tried to feed it a TS file from the Youtube example, I also learned that it requires at least two data points. So, I replicated the dataset and increased the frequency. (see attached TS file).
While testing, I also found that my last software has a MAJOR bug with the stability circles. When I went from my test code to the actual subroutine, I screwed up the math. So, both of those versions are wrong!
The software now exports Touchstone files with the decimal point. It also expects the decimal to be used on any files you import. Attached shows the original test code, AppCAD, RF Assistant and my latest 2.06 software showing the attached Touchstone file.
If you have Touchstone files you would like to try as test cases, go ahead and upload them and I can run them through.
-
I rewrote the Touchstone import from scratch. It supports (DB, MA, RI) (G, M, K and Hz) formats. It should handle both S1P and S2P automatically. It checks for the frequency to increase and no tokens after any data is found. Comments are allowed throughout the file. The software expects at least one space (0x20) to be used as a delimiter. Some files will used more than one space. Others will end the line with a space. The software handles these cases as well.
Thank You, that's great!
Do You mean that the space delimeter is expected for comments or for data?
As I understand, usually the TS files use TAB delimeter for data and space delimeter for comments.
...
The software now exports Touchstone files with the decimal point. It also expects the decimal to be used on any files you import. Attached shows the original test code, AppCAD, RF Assistant and my latest 2.06 software showing the attached Touchstone file.
If you have Touchstone files you would like to try as test cases, go ahead and upload them and I can run them through.
Attached is a pair of .S2P files I have at hand, one of them (named "Ports 1,2 open"), had been taken from Jan's VNA ports isolation test (with both ports open, 0-6 GHz span).This comes with a screenshot.
You might also test SW with the example files from AppCAD's folder.
By the way, the problem I had previously with the regional settings, had been solved by editing the .ini file.
One problem I had noticed while trying to load S2P files in Your SW (V2+4 vers.2.05) is that I could not get the "2-port plots" in the "Advanced" tab updated when I load a new S2P file. Pressing the "Stability" button in the Main tab seems to have no effect on this graphs.
AppCad is a nice app, but is a bit tricky to use, it often throws errors like "Imput must be a Numeric Value".
-
Do You mean that the space delimeter is expected for comments or for data?
As I understand, usually the TS files use TAB delimeter for data and space delimeter for comments.
From the 1.1 standard:
2. Only ASCII characters, as defined in ANSI Standard X3.4-1986, may be used in a Touchstone file. The use of characters with codes greater than hexadecimal 07E is not allowed. Also, ASCII control characters (those numerically less than hexadecimal 20) are not allowed, except for tabs or in a line termination sequence (carriage-return or carriage-return/line-feed combination).
Note: The use of Tab characters is strongly discouraged.
I will do my part to discourage the use of the Tab and not support it. I also do not support the newer standards.
Attached is a pair of .S2P files I have at hand, one of them (named "Ports 1,2 open"), had been taken from Jan's VNA ports isolation test (with both ports open, 0-6 GHz span).This comes with a screenshot.
You might also test SW with the example files from AppCAD's folder.
I had ran the one from the RFAssistant with no problem. The one you uploaded from Jan's VNA will also loads just fine. Timely post as I had collected that same data for the two V2Plus VNAs I have. The Jan VNA seems to add a filter of sorts after 3GHz to improve the dynamic range. I would guess it is slower running sweeps above 3GHz compared with ones below it. If you can turn this off, we could compare all three.
I also show the data below 1.5GHz. The real advantage would be getting all four S-parameters and much better dynamic range above 1.5GHz. Still you give up a lot on the low end.
By the way, the problem I had previously with the regional settings, had been solved by editing the .ini file.
One problem I had noticed while trying to load S2P files in Your SW (V2+4 vers.2.05) is that I could not get the "2-port plots" in the "Advanced" tab updated when I load a new S2P file. Pressing the "Stability" button in the Main tab seems to have no effect on this graphs.
AppCad is a nice app, but is a bit tricky to use, it often throws errors like "Imput must be a Numeric Value".
You can not load S2P files with my software. Well, you can try but it will ignore the data beyond S11. It will also strip the first five lines no matter what. It also only supports one mode (not sure which but I suspect dB). Again, it is VERY ridged and was added for my own testing, not as a generic viewer for the general user. That's why I never demo'ed it or document it. Even if you had a file that met all the criteria, it can only load it into memory. That means you can't run any math on it. You can only view the data. It's virtually a useless feature for everyone but myself. Of course, the next release may change that.
Also, from the other feedback, I may add the ability to not overwrite the autoscale when in the rectangular modes.
-
The new software is now available.
Auto regional support for Touchstone files
Touchstone file import
Able to manually turn off the vertical autoscale on the main graph for all rectangular plots
Fix a major bug in the stability circles
-
Thanks for NanoVNA channel isolation plots.
Considering Jan's VNA (LibreVNA), the dynamic range fades above 3 GHz probably due to HW or components RF leakage, or presence of higher-order EM modes. It's still unclear how to get rid of this effect, this might need a partial PCB or HW redesign.
While it had been reported by some NanoVNA users previously, that RF (ferrite) absorbing sheets may help to improve the channel isolation, this seems to have insignificant effect in Jan's VNA case. I had tried some special RF absorbing materials, but couldn't see any improvements in DR.
-
They may not implement the leakage coefficient. I added support for it after purchasing the V2+. Initial tests showed poor dynamic range. OWO had chimed in and suggested adding it. Normally you would not use this term as it causes more harm than good but with the V2+ we see a fairly decent improvement above 3GHz. Looking at your entire set, you can see really see the contrast. It looks like they filter the data differently above 3GHz.
Too bad they didn't use the same protocol as one of the other VNAs. They could have used some of the preexisting software to test with.
-
They may not implement the leakage coefficient. I added support for it after purchasing the V2+. Initial tests showed poor dynamic range. OWO had chimed in and suggested adding it. Normally you would not use this term as it causes more harm than good but with the V2+ we see a fairly decent improvement above 3GHz. Looking at your entire set, you can see really see the contrast. It looks like they filter the data differently above 3GHz.
Interesting solution.
Do You mean some extra maths is used while performing calibration?
Too bad they didn't use the same protocol as one of the other VNAs. They could have used some of the preexisting software to test with.
In general, Jan's VNA has a built-in SCPI server, and its SCPI communication protocol is described in details in the "programming guide".
Makes it possible to integrate with other programms
-
Interesting solution.
Do You mean some extra maths is used while performing calibration?
Yes.
http://emlab.uiuc.edu/ece451/appnotes/Rytting_NAModels.pdf (http://emlab.uiuc.edu/ece451/appnotes/Rytting_NAModels.pdf)
In general, Jan's VNA has a built-in SCPI server, and its SCPI communication protocol is described in details in the "programming guide".
Makes it possible to integrate with other programms
It's not been too much effort to interface with these custom one-off protocols using LabView. I like the simple interface of the V2Plus and hope they just expand on that for the V3 (assuming that they ever produce it). Some of my older TE uses SCPI over GPIB.
I have not looked into any of the manuals for your VNA. It's hard to believe that it would be as complicated as that vintage PNA I bought. There's a lot going on in that system. Still LabView makes easy work of it for the most part.
-
Glancing through the manual for your VNA, it appears that they have given you a way to hook into their software but not directly run the VNA. Surely they wouldn't do that but that's what it seems like. So you can basically automate the VNAs controls but you use their software to collect and display the data. If this is what they have done, why?
Maybe there is another manual beyond the SCPI Programming Guide that provides lower level details to directly interface with it.
-
I had started to upload the new software untested but decided to spend some time checking the V2Plus release. Both are now up on Github but I have not tried the software for the original NanoVNA. The changes were minimal and it uses the same code base but you never know.
To turn off the autoscale just right click on the scale you want to turn off, then select AutoScale Y. You can then select the max or min value and overwrite them with what ever you want. To enable the autoscale, just re-select the AutoScale Y. For transmission, you can turn off both the gain and the phase independently. When you change the function, the software will automatically revert to autoscale. This is transparent for me but gives those of you who want it, a way to disable it.
-
A few bugs were found in both programs. These have been corrected and TDR has been added to the post processing.
-
Glancing through the manual for your VNA, it appears that they have given you a way to hook into their software but not directly run the VNA. Surely they wouldn't do that but that's what it seems like. So you can basically automate the VNAs controls but you use their software to collect and display the data. If this is what they have done, why?
Maybe there is another manual beyond the SCPI Programming Guide that provides lower level details to directly interface with it.
Yes, You are correct.
There are no other manuals available.
-
A few bugs were found in both programs. These have been corrected and TDR has been added to the post processing.
While performing some simple tests with SW NanoVNA v2+4 rev.2.07, trying .s2p file import test, I see that a small bug with Stability Circles plots still remains.
The Stability Circles plots at Main tab differs from the same plots at Advanced-2 port - Stability tab for S11 plot.
I have tested calculation with RF Assistant app with provided FHX13X .s2p file.
While Stab. Circles plots at Main tab in Your app appear to be correct, the yellow circle at Advanced tab for S11 differs from the pink one at Main tab graph
-
A few bugs were found in both programs. These have been corrected and TDR has been added to the post processing.
While performing some simple tests with SW NanoVNA v2+4 rev.2.07, trying .s2p file import test, I see that a small bug with Stability Circles plots still remains.
The Stability Circles plots at Main tab differs from the same plots at Advanced-2 port - Stability tab for S11 plot.
I have tested calculation with RF Assistant app with provided FHX13X .s2p file.
While Stab. Circles plots at Main tab in Your app appear to be correct, the yellow circle at Advanced tab for S11 differs from the pink one at Main tab graph
Good to see you testing it. I had validated the stability circles using that Touchstone file I supplied from that Youtube video I linked. Of course that works. The problem was I had forgotten to add the index to all of the parameters. In the case of the YT file, there are only two entries and both are the same. So the missing index caused no problems.
These are the changes planned for 2.08:
2.08
Add distance units to the TDR graph
Add threshold selection to TDR graph using cursors
Throttle time between calculations
Add missing index for stability circle parameters
Add a plot refresh to stability selection
Force states of gain and phase selection to defaults when selecting stability
-
FYI, I had noticed that a new group has been added.
https://groups.io/g/liteVNA
liteVNA - 6GHz vector network analyzer in the same size as NanoVNA.
-
Both programs have been updated and are now available.
-
Using the V2 Plus 4 to sweep the home made Vivaldi antenna.
https://www.youtube.com/watch?v=eeVMz3mwJ6s (https://www.youtube.com/watch?v=eeVMz3mwJ6s)
-
Sweeping the same antenna with 4 data points vs 720. With it using the CW mode, we only need one data point. So sweeping 720 angles only requires a few minutes.
-
The yellow and purple are the same setup, both with 1440 data points. Each data point is an average of 51 samples. The yellow trace is with me in the lab causing all sorts of reflections. I left for the purple. The blue is two bent wires to form a dipole. No attempt was made to tune it.
The second set of plots it the same untuned wire dipole but operating 1.5, 2.4 and 3GHz. I would need to make up some sort of mechanical fixture as there is a lot of play.
-
FYI, I had noticed that a new group has been added.
https://groups.io/g/liteVNA
liteVNA - 6GHz vector network analyzer in the same size as NanoVNA.
This is a new gen of V2 with enhanced DR & freq. limits, a new V2 design from Hugen.
Still this is not a full 2-port, one direction only.
It should be compatible with old V2 & V2+ in terms of communication protocol.
So possible it would work with Your SW.
It's FW code is written & compiled by DiSlord.
------------
-
New version shows much better performance for stability graphs, thanks!
Sorry for the lame question, what's the meaning of yellow circles plotted around S11 & S22 traced shown at Advanced Tab for Stability?
-
I did finding their site where you can DL the manual for the new LiteVNA. Maybe someone will benchmark it against the others.
https://zeenko.tech/litevna?spm=a2g0o.detail.1000023.1.b5a97ff8tHYEOr
Yellow are the mapping circles.
-
New version shows much better performance for stability graphs, thanks!
Sorry for the lame question, what's the meaning of yellow circles plotted around S11 & S22 traced shown at Advanced Tab for Stability?
Edited :-DD
I take it you found the problem. The Texan's software shows both MS and MAX. You have to look careful to see the MAX. Of course when K<1, GMAX will become NaN. If you look in the manual, you will see I ran into some problems with GMAX where two papers I found both had different errors in their equations. I had to turn to a text book to find the correct equation.
-
I did finding their site where you can DL the manual for the new LiteVNA. Maybe someone will benchmark it against the others.
https://zeenko.tech/litevna?spm=a2g0o.detail.1000023.1.b5a97ff8tHYEOr
Yellow are the mapping circles.
Some preliminary info about nev SAA-2 from Hugen here.
https://groups.io/g/nanovna-beta-test/topic/new_v2_version_hardware/83829273
BPF compared against R&,S measurements
-
Looks like its an invite only. Too bad they didn't make it viewable.
-
DR for S21 BPF & f<3 GHz is better than 80 dB, for f>3GHz it's about 70 dB.
I shall ask for permission to make a repost here.
-
Is that with any averaging?
***
Looking at the data I took with no averaging, the claim is it would out perform your VNA as well as the V2+4 I have above 3GHz. They also claim it is faster than the V2Plus4 (>550 points/s ). And, half the price.
If they use the old ASCII interface, my software may work but I have my doubts. A while back I had a discussion with Dislord about the problems I was seeing with their firmware. One thing they were pushing was to not use the command set I have been using as it was obsolete. It may no long support these early commands. Then there is the whole stability issues I see with the firmware.
-
LiteVNA use V2 exchange protocol
For compare perfomance better use last LiteVNA hardware (i have only first test board)
I run and connect NanoVNA_r10 to LiteVNA all work, data exchange ok
-
LiteVNA use V2 exchange protocol
For compare perfomance better use last LiteVNA hardware (i have only first test board)
I run and connect NanoVNA_r10 to LiteVNA all work, data exchange ok
I am curious if you get the same update rate with NanoVNA_r10 as with other software.
Alex,
If I plot the GMS with GMAX, you will see the two programs match. I do not currently plot this data but can certainly add it if you like.
-
if set 10x AVG, SweepTime 3088
If set 2x AVG, SweepTime 675
For 1x avg show strange value 1 - 35 (for 1x avg sweep speed ~570 points/sec)
-
if set 10x AVG, SweepTime 3088
If set 2x AVG, SweepTime 675
For 1x avg show strange value 1 - 35 (for 1x avg sweep speed ~570 points/sec)
I should have been more clear what I was asking. I have no way to support averages so set the VNA to none.
Connect and set the date points to 101 and the start/stop to 1MHz/300MHz. Leave it in Smith chart.
Goto the setup/Diagnostic tab and select the NanoVNA Raw Data tab. CH1_Z should not be updating and the Freq(Hz) should be as shown. If not, the range or number of points is not set right.
What does the Response Time show? This is the time from when I request data to when I actually receive it. My original will bounce around from 600 - 800ms.
You could lower the Refresh from 200ms to 50ms and throttle the trigger by increasing the PgmTimeout to 2000ms but it shouldn't matter.
-
LiteVNA use V2 protocol (and use NanoVNA V2+4 software), as i see screenshot you show NanoVNA-H exchange protocol and software
V2 protocol not allow ask only one channel data, always send all
I connect to LiteVNA and made screensots
-
Very nice. You're using the install software. You may want to try it with the current version.
I never wrote a regression test for the new protocol as that V2+4 pretty much worked out of the box. The problems I have seen with the V2P are it locks up at random. This can be anywhere from a half hour to six hours. When it locks, it requires a power cycle to recover. It did turn out to be firmware, or at least I found a version that I have ran over 48 hours without a single glitch. I tried one of their latest releases and the problem was back.
-
Autoscale still has a bit of a problem. All three antennas from my demos.
-
Alex,
If I plot the GMS with GMAX, you will see the two programs match. I do not currently plot this data but can certainly add it if you like.
Thanks, leave it as You like)
....
I don't know whether it's possible or not to do in LabView (in *.exe files), but it might be good to provide the end user with an opportunity to scale the size of the app's main window at the screen.
While I am comfortable with the present settings, others might like to change them, depending on the screen resolution, etc.
-
I never wrote a regression test for the new protocol as that V2+4 pretty much worked out of the box. The problems I have seen with the V2P are it locks up at random. This can be anywhere from a half hour to six hours. When it locks, it requires a power cycle to recover. It did turn out to be firmware, or at least I found a version that I have ran over 48 hours without a single glitch. I tried one of their latest releases and the problem was back.
I update software to last, and run sweep on LiteVNA, at this moment it work more then 10 hour (201 points and 10 to 300MHz sweep)
As i remember you use my firmware for stable work (in it i made lot of fixes), LiteVNA also use part of this firmware (better say my V2Plus/Plus4 fw use LiteVNA code)
-
Alex,
If I plot the GMS with GMAX, you will see the two programs match. I do not currently plot this data but can certainly add it if you like.
Thanks, leave it as You like)
....
I don't know whether it's possible or not to do in LabView (in *.exe files), but it might be good to provide the end user with an opportunity to scale the size of the app's main window at the screen.
While I am comfortable with the present settings, others might like to change them, depending on the screen resolution, etc.
I'll add it to the next release to avoid future questions on why they differ. Also, I will add an easy way to select log or linear scale.
For scale see the following posts and those near them:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/#msg3617154 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/#msg3617154)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621182/#msg3621182 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621182/#msg3621182)
I have no plans to change this.
-
I never wrote a regression test for the new protocol as that V2+4 pretty much worked out of the box. The problems I have seen with the V2P are it locks up at random. This can be anywhere from a half hour to six hours. When it locks, it requires a power cycle to recover. It did turn out to be firmware, or at least I found a version that I have ran over 48 hours without a single glitch. I tried one of their latest releases and the problem was back.
I update software to last, and run sweep on LiteVNA, at this moment it work more then 10 hour (201 points and 10 to 300MHz sweep)
As i remember you use my firmware for stable work (in it i made lot of fixes), LiteVNA also use part of this firmware (better say my V2Plus/Plus4 fw use LiteVNA code)
Thanks for checking my latest software. I know you said your LiteVNA was an older revision but it would still be interesting have the data for it. I wrote a simple procedure for the two measurements. If you could upload the TS files, I would add them.
https://nanorfe.com/forum/VNA-output-level.html (https://nanorfe.com/forum/VNA-output-level.html)
I don't think they ever sorted out why the V2P hangs. The firmware I am using is not even listed on OWOs page, so I archived it with my software. I have not changed the firmware in the V2+4. That firmware is also not shown on their site and is a couple of days older than their stable version. Guessing there was some bugs they fixed that do no effect me. I only run them with the PC so most of the features added to the firmware are wasted on me.
Yes, we had a discussion about using your firmware with the H4.
Starting:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3584301/#msg3584301 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3584301/#msg3584301)
Last post:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3586208/#msg3586208 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3586208/#msg3586208)
I have not used the H4 since except to measure it's system dynamic range and noise floor. That old communications interface was poor. I am really glad you and Hugen adopted the newer interface. It's robust, fast, reliable and very easy to implement.
-
Hello I am new here, congratulations for this great software.
I have a SAA-2N here and work with vna-qt SW.
Is it possible to use your SW also for the SAA-2N ?
PC with WIN7 Prof. is available.
Unfortunately I do not get along with the installation description yet.
Is there a step by step instruction to install your software ?
I have read that a "Main" SW is required. Where can I download this?
Many questions, please ask for info if possible.
Greetings
Translated with www.DeepL.com/Translator (http://www.DeepL.com/Translator) (free version)
-
I have a SAA-2N here and work with vna-qt SW.
Is it possible to use your SW also for the SAA-2N ?
PC with WIN7 Prof. is available.
Yes, it's possible, but is not recommended if You are not fluent with LabView-based apps.
It's a steep learning curve to start from.
Unfortunately I do not get along with the installation description yet.
Is there a step by step instruction to install your software ?
I have read that a "Main" SW is required. Where can I download this?
Translated with www.DeepL.com/Translator (http://www.DeepL.com/Translator) (free version)
1) Download & install the "Main" installer package from this link:
https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10 (https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10)
2) Unzip, install.
3) For the latest version of SW, at Github, download the .zip file from this link:
https://github.com/joeqsmith/NanoVNA_Software/blob/NanoVNA_V2Plus/NanoVNA_V2Plus_2p08.zip (https://github.com/joeqsmith/NanoVNA_Software/blob/NanoVNA_V2Plus/NanoVNA_V2Plus_2p08.zip)
Unpack it to the path at C:/program files (x86)/... where the original SW (NanoVNA_V2Plus.exe) is located.
Replace the existing *.exe file with the current version file.
-
[attach=2]
Thanks for checking my latest software. I know you said your LiteVNA was an older revision but it would still be interesting have the data for it.
https://nanorfe.com/forum/VNA-output-level.html (https://nanorfe.com/forum/VNA-output-level.html)
My firmware for V2/V2Plus/V2plus4/LiteVNA support this registers (allow control output power and average settings)
// -- 40: average setting
// -- 41: si5351 power
// -- 42: adf4350 power
registers[0x40] = current_props._avg;
registers[0x41] = current_props._si5351_txPower;
registers[0x42] = current_props._adf4350_txPower;
I wrote a simple procedure for the two measurements. If you could upload the TS files, I would add them.
How i can measure this data? Need measure open ports after calibration?
Here Hugen screenshots: 6dB attenuator on S11 port (S21 port open) and 60dB between ports, after ~3.8GHz possible see dynamic lost
-
I wrote a simple procedure for the two measurements. If you could upload the TS files, I would add them.
How i can measure this data? Need measure open ports after calibration?
Here Hugen screenshots: 6dB attenuator on S11 port (S21 port open) and 60dB between ports, after ~3.8GHz possible see dynamic lost
To measure the S11 noise floor, I used the standard cal kit that was provided with the V2. The standards were connected directly to the VNA's ports (no cables or adapters were used). Standards were properly torqued. Three different bands were used, 1MHz - 1.5GHz, 1.5GHz-3GHz and 3GHz - 4.4GHz, calibrating for each band.
For the new VNA, add another band from 4.4GHz to 6GHz. Cal the instrument for one of the bands using the supplied SOL standards, then with the load installed, measure S11 and save it to a Touchstone file. Do that for all four bands.
The specs for the System dynamic range for the V2P is 60dB < 3GHz and 70dB < 3GHz, without averaging. I will assume System mean no amplification. As before, the standard cal kit that was provided with the V2 was used. The standards were connected directly to the VNA's ports. For the thru, a single cable was attached from port 1 to 2. I used one of the blue cables supplied with the V2P. A;; connections were properly torqued. Three different bands were used, 1MHz - 1.5GHz, 1.5GHz-3GHz and 3GHz - 4.4GHz, calibrating for each band. Both ports were terminated to 50 ohms when making the measurement.
I used my software to make all of these measurements. The ideal model was used in all cases. My software supports the leakage term. When measuring above 3GHz, I show it with and without the leakage term.
So, again cal the unit and theninstall a load on each port and measure S21. Save that data to a Touchstone file. Do this for all four bands. Zip up all 8 Touchstone files and upload them here.
My software I think uses the 0x42 address for the ADF4350 power. You can find that setting under the Setup/Diagnostics tab, Filters/Attenuators. Once you enter a new number it should send it to the VNA. You should be able to cal the unit, or just normalize with a cable shorting port 1&2 together. Look at S21 after changing it. You should be able to see the change. Of course, you need to be in the range that it's using the ADF4350.
-
If you want to just run a single sweep like Hugen shows from 1MHz to 6GHz, that would be fine. I was running in smaller bands but no reasons you couldn't do this.
-
Thanks for the quick information, the installation was successful.
Now I have to learn to work with it.
greetings Georg :-+ :-+
-
Made SOLT calibration and after single sweep, both ports open 10MHz to 6400GHz on 1001 points, save result to SD card
After add 50Om load on both ports (use different 50Om load (not calibration) on S11) and save again
-
Thanks for taking the time to run these. Both ports loaded is fine. This will get us both and save's you time. Would have been better to keep the cal standard on port 1 for the noise floor, but not a big deal. I was just looking to get an idea where it was.
Sounds like you ran it standalone (no PC). For the higher frequencies (>3GHz) are you using the leakage term?
Did you use any sort of smoothing on the single sweep?
The dynamic range is impressive.
-
Yes, i run standalone (prevent noise from external power)
I have V2, and can see leakage between ports if put fingers between RF connetors (near buttons)
On LiteVNA i see small noise level drop after ~3GHz if add 50Om load on S11 measure port, also need warm device near ~5min
No any smooth used, only avg = 10x, this option increase measure data size for one point and give better quality, but slow measure time.
-
Then actually 10 sweeps averaged, not one sweep smoothed. This makes a lot more sense when looking at your data. Your single sweep comment threw me off. As I said, I took all my data with a single sweep, no average. If there is a problem with the USB connection causing noise, I want to know about it. I think what you have provided is good enough. I wouldn't repeat the test unless you're bored. We have the new hardware on order. I'll let you know how it performs in a few months.
If you copied the V2Plus4 firmware as a starting point, I expect the calibration accounts for the leakage term. OWO had brought the need for it to my attention after I started porting my software over to it.
-
Then actually 10 sweeps averaged, not one sweep smoothed. This makes a lot more sense when looking at your data.
VNA measure by ADC for example 100 samples, then multiplie on 100 sin/cos values table (made FFT for IF) for calculate IF IQ data
But possible get 200 samples or 300 or more.
This look like i try grab more data for FFT bin, but for get more data need more time.
This process not fully average (as i made measure, made another measure and average results), but result look same
This option on H/H4 named bandwidth, H/H4 use fixed IF and possible calculate IF bandwidth.
If you copied the V2Plus4 firmware as a starting point, I expect the calibration accounts for the leakage term. OWO had brought the need for it to my attention after I started porting my software over to it.
Yes LiteVNA use same calibration alghoritm as V2 (i only add real time interpolation for calibration data, this allow get good measured results if calibration range not same as measured range)
-
I have a V2P as well from OWO that I do not use. Now that I know that the hardware is good, if your firmware supports it, I could load what ever version you like into it and provide you with feedback.
-
Hi Joe, is it possible to run or scale your software ( NanoVna) in full screen as well?
Great program!
-
Hi Joe, is it possible to run or scale your software ( NanoVna) in full screen as well?
Great program!
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813893/#msg3813893 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813893/#msg3813893)
-
Its easy enough to add average to my software. Rather than having the VNA perform it, I just add a simple FIFO to hold all the sweeps. As it acquires data, then plots update at the normal rate. There is an Avgs counter that keeps track of the accumulations. Once it reaches the target is starts tossing out the oldest sweep and adding the new. So it's always the average of the last N sweeps. The PC is basically unlimited compared with the little embedded micro, so this really poses no problem.
Shown with a GHz interdigital filter with no averaging and with it set to 100.
****
Also shown with 1000 averages including phase.
****
Looking at S21 for the original NanoVNA with both ports terminated (system dynamic range) after calibration. Yellow is the raw data. Violet is the average of 100 sweeps. Red is using the smooth filter but really stepping on the signal. Normally, I would rather see the raw data.
-
For calibration data good if use big averaged measure (in my firmware for H/H4 i use 100Hz bandwidth = ~40x avg on calibration measure as minimum, user can select less bw if need)
This allow get less noise calibration data, and as result less noise measure later after calibration apply
-
I have the 2.2 and its quite handy for 2.4 GHz antenna evaluation. But not the higher wifi bands. The absolute top for it is 4.4 GHz and above 3 GHz its not flat. But its not super peaky, either. Still useful, IMHO, for relative measurement.
I use the nanovna2 for 2.4 Ghz a fair bit actually
Antennae for 2.4 G are so conveniently small, and easy/fun to build. But without a VNA, not so much.
-
While looking over OWOs projected specs for the V3,
https://nanorfe.com/nanovna-v3.html (https://nanorfe.com/nanovna-v3.html)
I noticed they are planning to support unknown thru. I doubt they are planning on producing a four receiver VNA.
From:
https://www.picotech.com/vector-network-analyzer/picovna/picovna-features (https://www.picotech.com/vector-network-analyzer/picovna/picovna-features)
In a VNA a swept sine-wave signal source is used to sequentially stimulate the ports of the interconnect or device under test. The amplitude and phase of the resultant transmitted and reflected signals appearing at both VNA ports are then received and measured. To wholly characterize a 2-port device under test (DUT), six pairs of measurements need to be made: the amplitude and phase of the signal that was emitted from both ports, and the amplitude and phase of the signal that was received at both ports for each source. In practice this can be achieved with a reasonable degree of accuracy with a single source, a transfer switch and two receivers; the latter inputs being switched through a further pair of transfer switches. Alternatively three receivers can be used with an additional input transfer switch or, as in the PicoVNA, four receivers can be used.
Using four receivers eliminates the receiver input transfer switch errors (chiefly leakage and crosstalk) that cannot be corrected. These residual errors are always present in two- and three-receiver architectures and lead to lower accuracy than that of the Quad RX design.
I've never tried it with these low cost VNAs.
-
Using my homemade standards to calibrate the V2Plus4. Next I measured an SMA to SMA adapter, short section of semi-rigid and a longer section of RG400/U to simulate an unknown thru. Then wrote a simple program to determine the Unknown and feed the data back through with corrections. Plots show the raw data in green and violet after correction.
-
Which values for SMA Calibration Standards did you use?
Hereby the data that I use for my SMA calibration standards.
-
Which values for SMA Calibration Standards did you use?
When making the videos for these low cost VNAs, I've used the ideal model for both my home made FR4 standard as well as the ones supplied. I've also presented data without calibrating the V2Plus4 at all or just normalizing the data as with the following example:
https://www.eevblog.com/forum/rf-microwave/shunt-capacitance-of-1206-smd-resistors-jeroen-belleman-december-2010/ (https://www.eevblog.com/forum/rf-microwave/shunt-capacitance-of-1206-smd-resistors-jeroen-belleman-december-2010/)
In that case, just a quick visual was good enough to see the trend. If you read that entire 2-pages, a gentleman here had helped me to characterize a set of home made N and SMA standards that I use with my vintage Agilent PNA. I posted a little more detail about that here:
https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg2987982/#msg2987982 (https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg2987982/#msg2987982)
Below is a review I made for OWO's V2Plus4. If you take the time to watch it, you will see just how loose I am when it comes to calibration.
https://www.youtube.com/watch?v=XaYBpPCo1qk (https://www.youtube.com/watch?v=XaYBpPCo1qk)
-
Joe, with your help I found the instructive home page of Mario Hellmich relating to the characterizing of a SMA calibration kit.
Very interesting, recommended for a VNA user.
-
If you're looking for a low cost, ready made solution, you may want to consider:
https://appliedeminnovations.com/index.php/product/vna-calibration-kit/
They appear to be a decent quality but I don't see where they spec the number of mate cycles. I would hope the plating is better than what you will find with the parts supplied with these low cost VNAs.
-
Can someone help me with the definitions/coefficients for this SMA Wiltron calibration sets.
See attachment.
[attach=1]
It concerns the standards type 22S50 and 22SF50.
I searched the internet with no results. I can't find a detailed data sheet.
Thanks in advance.
Guido
-
Can someone help me with the definitions/coefficients for this SMA Wiltron calibration sets.
See attachment.
(Attachment Link)
It concerns the standards type 22S50 and 22SF50.
I searched the internet with no results. I can't find a detailed data sheet.
Thanks in advance.
Guido
Guessing you have a similar story as this person:
https://www.eevblog.com/forum/testgear/a-general-question-about-vna-calibration-kit-definitionsconstants/ (https://www.eevblog.com/forum/testgear/a-general-question-about-vna-calibration-kit-definitionsconstants/)
Maybe you will find some useful advice there.
-
State of the software.....
I corrected the autoscale for the antenna scanning feature, added averaging and fixed a few other minor problems. I decided against releasing this version as I started to give some thought to more complex calibrations.
While looking over OWOs projected specs for the V3,
https://nanorfe.com/nanovna-v3.html (https://nanorfe.com/nanovna-v3.html)
I noticed they are planning to support unknown thru. I doubt they are planning on producing a four receiver VNA.
From:
https://www.picotech.com/vector-network-analyzer/picovna/picovna-features (https://www.picotech.com/vector-network-analyzer/picovna/picovna-features)
In a VNA a swept sine-wave signal source is used to sequentially stimulate the ports of the interconnect or device under test. The amplitude and phase of the resultant transmitted and reflected signals appearing at both VNA ports are then received and measured. To wholly characterize a 2-port device under test (DUT), six pairs of measurements need to be made: the amplitude and phase of the signal that was emitted from both ports, and the amplitude and phase of the signal that was received at both ports for each source. In practice this can be achieved with a reasonable degree of accuracy with a single source, a transfer switch and two receivers; the latter inputs being switched through a further pair of transfer switches. Alternatively three receivers can be used with an additional input transfer switch or, as in the PicoVNA, four receivers can be used.
Using four receivers eliminates the receiver input transfer switch errors (chiefly leakage and crosstalk) that cannot be corrected. These residual errors are always present in two- and three-receiver architectures and lead to lower accuracy than that of the Quad RX design.
I've never tried it with these low cost VNAs.
Using my homemade standards to calibrate the V2Plus4. Next I measured an SMA to SMA adapter, short section of semi-rigid and a longer section of RG400/U to simulate an unknown thru. Then wrote a simple program to determine the Unknown and feed the data back through with corrections. Plots show the raw data in green and violet after correction.
OWO was recently posting about the V3 and they were requesting feedback on features.
https://www.eevblog.com/forum/testgear/nanovna-v3-(6ghz)/msg3847832/#msg3847832 (https://www.eevblog.com/forum/testgear/nanovna-v3-(6ghz)/msg3847832/#msg3847832)
With the squarewave drive, I don't see a lot of value in a full 2-port system. We may be stuck with using a external transfer relay. Which gets back the the topic of calibration. For the couple of you actually trying to use my software, I am sure you realized that the calibration is pretty limited. The main reason for this is because of pure laziness and the lack of performance on these low cost VNAs. Because the original NanoVNA worked much like my old
HP8754A, I stayed with the same software structure. The calibration for the NanoVNA is actually a bit more advanced than what I wrote for the HP8754A which isn't saying much. Consider the 8754A at best could normalize the data where my software allowed me to run a SOL on it.
My software normally applies the error correction as soon as it sees a valid sweep. This works fine for the 1-port VNAs but as we add the transfer relay, the software has to make multiple requests to read all 4 four S-parameters. This means a change to how the software was structured. All doable but I doubt the gains are worth it.
As I continue to ponder my software for the low cost VNAs, the first problem I see is we need to ditch the current calibration file format. This means the new software will not be compatible with the old files. If the transfer relay was selected when a calibration was performed, the software prompts the user to run an SOL on both ports. The new software would work the same way, however when selecting the 2PSwp (2 port sweep) it will test the state of the transfer relay and that the unit was calibrated. It will then enable the full SOLT or SOLR (unknown thru) model. This would only be useful when using the Advanced, 2-Port Plot tab. When only S11/21 are required, the software will continue to normalize the thru but will use the 12-term model if SOLT is selected with the transfer relay.
If I get something that I think may be useful to users, I will release it. Going forward, I don't intend to put any more effort into supporting the original NanoVNA outside of correcting problems. We have the LiteVNAs on order and are expecting them soon. Looking forward to seeing how their performance compares with the V2Plus4.
Attached screen shots of version 3.0.
-
I'm looking for a reference book that covers the unknown thru in detail (along with other techniques).
-
We received the LiteVNAs and ran a few tests on them. Within a few minutes of testing we ran into a small snag with the firmware but the hardware appears like it was worth the wait. I should have mine in the next few days.
-
I'm looking for a reference book that covers the unknown thru in detail (along with other techniques).
You have Dunsmore, right? See 3.4.3.1 in the newer edition.
-
I'm looking for a reference book that covers the unknown thru in detail (along with other techniques).
You have Dunsmore, right? See 3.4.3.1 in the newer edition.
I was just discussing that book with another member. I am not of fan of his mixing terms, for example 3.35 the use of E11 in place of ESF. Why not make it as clear as possible? 3.4.3.1, it is summed up nicely with "... of which is beyond the scope of this book..."
Don't get me wrong. I think it is a very good book and recommended for anyone interested in the topic but I am really looking for a book dedicated to calibration that keeps it on a practical level for my aging brain. It's a fun topic but as I mentioned to the other member, with the software I have written and as much as I have used VNAs, where I stand today, I know very little about them.
-
The LiteVNA arrived.
-
The claim 50kHz to 6.3GHz. My software doesn't care so I set it to 6.6GHz. Looks like 6.47GHz is the upper end. Setting it to 6.4GHz, it seems fairly accurate. The counter is GPS referenced.
-
I was really interested in seeing how low it would run. My friend Flipper and I had ran some simple remote tests with this exact unit a few days ago and I suspected there may have been a firmware problem when running at the lower end. Now that I have the unit, I can see it was a timeout in my software that needed to be increased to handle the slower rates.
***
9kHz is the lower limit of the SA. I think when we ran it with the scope, we were down below 10kHz before it fell off. We did not try to collect data down this low.
-
Similar results when looking at a 3.68MHz crystal as the V2Plus4, both poor. No surprise. OWO had mentioned a version of firmware that would allow the V2Plus4 to make narrow band measurements. I never looked into it.
-
OWO had asked about using a short length of coax and looking at linearity. Here I am using a M-M attached to a F-F to create a small extension, calibrating at the end, then removing the extension. Using the same settings, I repeated the test with the V2Plus4.
-
I was curious how the LiteVNA would handle the PDN measurements. Shown with the homemade wideband common mode transformer measuring a 100mOhm, 25mOhm and 1mOhm resistor. I will admit, I was concerned about the firmware causing a very poor low end response. Keep in mind they only spec it to 50kHz.
-
We had ran the unit much lower. Here I have it set to 2kHz. I then attach the 1mOhm and swept from 2kHz to 1MHz.
I had looked at the noise floor and system dynamic range all the low cost VNAs I have. I plan to repeat that with this unit and will post the results. OWO was also asking about temperature stability so I'll drag out the meat packing box.
-
Looking at the noise floor, once we get beyond 100MHz the LiteVNA is worse than the V2Plus4. As we get closer to 1.2GHz, the two are similar.
The system dynamic range for the V2Plus4 is better than the LiteVNA. Jan's VNA offers further improvements.
-
Sweeping from 1.5GHz to 3GHz, the noise is comparable. The V2Plus4 seems to have better dynamic range. Again, Jan's VNA offers further gains.
-
Sweeping from 3GHz to 4.4GHz, the V2Plus4's noise is very comparable with the LiteVNA.
The LiteVNAs system dynamic range is better as we get beyond 3.3GHz or so. Note, data for the V2Plus4 was collected two ways. One with the VNA powered from the PC, the other with it running from the internal battery. I had ran a few tests and found any time I use any external power source with the V2Plus4, the noise goes up. Even with a highly filtered linear supply. I doesn't seem to matter and am guessing it is a problem with the design. The LiteVNA does not appear to have this same problem.
-
Hi, Joe,
Thanks for sharing this results, very interesting!
Just a short remark concerning Jan's VNA port isolation tests, they are not up-to-date.
There had been found a workaround solution for the port isolation improvement at higher frequencies.
Also, there's a new discussion group, and actual info is posted there.
https://groups.io/g/LibreVNA-support
-
Jan had announced here when they had moved the group and about the problems they had with the account. Seemed like a really bad business choice (using an unknown account if that's really what happen) but at least they now have it sorted. I never joined the group after reading of all the shortcomings (no direct way to control the VNA without their software layer, new hardware announced, higher cost, low frequency performance...).
When we bought the two LiteVNA's, they were $130/ea on sale. I think that's what I paid for the V2Plus4 when it first came out. The price for the V2Plus4 was $200 last I checked. I would assume the price for the LiteVNA will also increase over the next year.
After running the LiteVNA for about 4 hours last night, I did not experience a single problem with it. I was really concerned with Dislord's firmware. I noticed they advertise for donations in the version menu for those wanting to help them out. The version of firmware in this VNA is 1.0.70.
I was unable to change the attenuator and assume it still doesn't have support for it which does seem a bit odd after Dislord's comment about adding it. I'm guessing the problem is with my software and lack of documentation on how to implement it.
-
Jan had announced here when they had moved the group and about the problems they had with the account
I never joined the group after reading of all the shortcomings (no direct way to control the VNA without their software layer, new hardware announced, higher cost, low frequency performance...).
Ok, understood.
How do you think,
In case I ask Jan to add support for standard V.2 command protocol to his SW, would You consider it possible to add it in Your SW?
-
Jan had announced here when they had moved the group and about the problems they had with the account
I never joined the group after reading of all the shortcomings (no direct way to control the VNA without their software layer, new hardware announced, higher cost, low frequency performance...).
Ok, understood.
How do you think,
In case I ask Jan to add support for standard V.2 command protocol to his SW, would You consider it possible to add it in Your SW?
As long as the interface is well documented, then yes. Obviously, it would require the hardware.
-
>I was unable to change the attenuator and assume it still doesn't have support for it which does seem a bit odd after Dislord's comment about adding it
You mean output power? This my temp V2 protocol format description:
V2 Binary protocol:
V2 contain 256 registers for read/write
On write to registers data put to reg[address] and V2 grab data and process (depend from address)
All values after in hex format!!!!
Commands for read/write
0x0D - read version (return "2")
0x10 - read byte
0x11 - read word
0x12 - read dword
0x13 - read qword
0x18 - read measured data (use 30 address for count)
0x20 - write byte
0x21 - write word
0x22 - write dword
0x23 - write qword
28 - write buffer (next byte data size, and data)
address:
0x00 - (qword) start frequency
0x10 - (qword) frequency step
0x20 - (word) points count
0x22 - (word) values pre frequency (need set to 1,
0x26 - (byte) mode (0 - USB mode, 1 - send raw data, 2 - normal mode)
0x30 - (byte) points for measure, or up to (measured values)
0x40 - (byte) average
0x41 - (byte) si power
0x42 - (byte) adf power
0x50 - (dword) color value
0x54 - (byte) color index (use H/H4 indexes)
0xee - (byte) any value, on write V2 send screenshot
0xD0 - (dword) SN[0] (serial number 0)
0xD4 - (dword) SN[1] (serial number 1)
0xD8 - (dword) SN[2] (serial number 2)
0xF0 - (byte) device variant (2 vor V2)
0xF1 - (byte) protocol version (1 vor V2)
0xF2 - (byte) board revision (2 vor V2, 3 - V2Plus, 4 - V2Plus4)
0xF3 - (byte) firmware major
0xF4 - (byte) firmware minor
Example:
Set average = 5 command:
0x20 - write byte
0x40 - address (average)
0x05 - value
Need send : 204005
Example:
Set SI5351 (<140MHz) power = 2 command:
0x20 - write byte
0x41 - address (Si power)
0x02 - value (0 - 3 value range avaible)
Need send : 204102
Example:
Set ADF/MAX(>=140MHz) power = 1 command:
0x20 - write byte
0x42 - address (ADF/MAX power)
0x01 - value (0 - 3 value range avaible)
Need send : 204201 (in hex bytes)
-
>I was unable to change the attenuator and assume it still doesn't have support for it which does seem a bit odd after Dislord's comment about adding it
You mean output power? This my temp V2 protocol format description:
V2 Binary protocol:
V2 contain 256 registers for read/write
....
Example:
Set SI5351 (<140MHz) power = 2 command:
0x20 - write byte
0x41 - address (Si power)
0x02 - value (0 - 3 value range avaible)
Need send : 204102
Example:
Set ADF/MAX(>=140MHz) power = 1 command:
0x20 - write byte
0x42 - address (ADF/MAX power)
0x01 - value (0 - 3 value range avaible)
Need send : 204201 (in hex bytes)
Yes, these both appear correct. The version of your firmware supplied with the LiteVNA is 1.0.70.
Are there other steps beyond having the frequency set that are required to change it? Have you verified it works?
-
I not change V2 protocol in LiteVNA (only extend it) for allow existing software work.
I think about use NanoVNA v1 protocol, but not ready do this
-
That's fine. Does the two examples shown actually work with the LiteVNA? Have you tested them?
-
I test LiteVNA control in NanoVNA-App software (add this feature to this app) all work. Avg setting / power for Si5351 (LiteVNA use MS5351 analog) and MAX2871
PS LiteVNA in < 400k work slow, it use less IF and need more time wait (i try think how possible improve this).
-
Thanks for confirming you have tested it. I will have another look at my code and see if I can sort out where the problem is.
-
I test LiteVNA control in NanoVNA-App software (add this feature to this app) all work. Avg setting / power for Si5351 (LiteVNA use MS5351 analog) and MAX2871
PS LiteVNA in < 400k work slow, it use less IF and need more time wait (i try think how possible improve this).
Set the start frequency to 200MHz followed by setting the step to 0 (200MHz CW). Now try and change the ADF's power level. Repeat this at 100MHz with the SI's power level. Now try repeating the above with the step of 1MHz rather than 0 to force the sweep.
It seems that the power may only be set if the VNA is sweeping. Let me know if you can replicate this.
-
Looking at the home made 70mm stepped airline with a sweep range of 1M-6.4GHz.
Not sure of a good way to benchmark the temperature stability of the LiteVNA compared with the V2Plus4. We want the contribution of the VNAs, not the loads and cables. Seems like we would want to include both ports.
-
>It seems that the power may only be set if the VNA is sweeping. Let me know if you can replicate this.
Yes, if nano not change frequency, new power setting not apply (i fix this in future fw update). So this command not work in CW mode.
-
It appears that the 23 +/-5C may be a common range they are tested over.
For testing the two VNAs, I am thinking to place them together in the meat packing box, run two instances of the software and collect the data with a short section of Teflon coax between the two ports. Maybe average the data down enough so we can see something. This was a request from OWO so maybe they will chime in.
***
They are suggesting S11 with a high return load (open or short) as they suspect there would be little error in S21. We loose the other circuit. I may have a look both ways.
https://www.testforce.com/pub/media/sparsh/product_attachment/anritsu-MS2036C-datasheet_compressed.pdf (https://www.testforce.com/pub/media/sparsh/product_attachment/anritsu-MS2036C-datasheet_compressed.pdf)
-
Sweeping from 1.5GHz to 3GHz, the noise is comparable. The V2Plus4 seems to have better dynamic range.
One obvious difference with the V2plus4 is the addition of a metal case which should reduce external noise floor somewhat, but would also increase internal reflection of noise from components within the VNA. The V2plus4 combats this by adding a layer of Radio Absorbing Material (RAM) to the entire back of the unit. In researching possible improvements in the LiteVNA to achieve system dynamic range parity with the V2plus4, I found this paper detailing the use of very common carbon fiber-filled 3D printer FFF filament for absorbing energy but at much higher frequencies that present in our VNAs, namely 63GHz-215GHz and observed in the neighborhood of -20db difference:
https://arxiv.org/pdf/1808.00820.pdf
Does anyone have a 3D printable case design that they would consider modifying with treatment similar to the paper (they used an open Hilbert curve infill, but I suspect even no infill but just using a 3D printable case with the appropriate CF-filled FFF filament should be enough to vet the idea).
Thoughts ? If this is not on topic, I can start a new thread, but I'm really most interested in finding out if the LiteVNA can be made as good as the V2plus4 in the ranges the V2plus4 supports.
Thanks !
-=dave
-
Sweeping from 1.5GHz to 3GHz, the noise is comparable. The V2Plus4 seems to have better dynamic range.
One obvious difference with the V2plus4 is the addition of a metal case which should reduce external noise floor somewhat, but would also increase internal reflection of noise from components within the VNA. The V2plus4 combats this by adding a layer of Radio Absorbing Material (RAM) to the entire back of the unit. In researching possible improvements in the LiteVNA to achieve system dynamic range parity with the V2plus4, I found this paper detailing the use of very common carbon fiber-filled 3D printer FFF filament for absorbing energy but at much higher frequencies that present in our VNAs, namely 63GHz-215GHz and observed in the neighborhood of -20db difference:
https://arxiv.org/pdf/1808.00820.pdf
Does anyone have a 3D printable case design that they would consider modifying with treatment similar to the paper (they used an open Hilbert curve infill, but I suspect even no infill but just using a 3D printable case with the appropriate CF-filled FFF filament should be enough to vet the idea).
Thoughts ? If this is not on topic, I can start a new thread, but I'm really most interested in finding out if the LiteVNA can be made as good as the V2plus4 in the ranges the V2plus4 supports.
Thanks !
-=dave
OWO had thought the performance of the LiteVNA would be worse in this region. While I agree that the LiteVNA should have performed at least as well as the V2Plus4, I thought that the V2Plus4 should have at least performed as well as the original NanoVNA. They had asked for a few photos as well and eventually I plan to pull both apart for them. As of today, I have not had them apart outside of inserting a battery in the V2Plus4.
-
The LiteVNA is boxed up and heading to 18C. SOL cal with Open inserted. I'll let it set for an hour at each temperature (18 & 28).
***
The meat packing box has added insulation and an RTD that I use for feedback. Temperatures are fairly stable.
-
The LiteVNA, swept from 18 to 28C. Looking at S11 after SOL with open attached.
-
Data for the V2Plus4 zoomed in to get some idea how the drift looks. The LiteVNA appears much more stable as we get above 3GHz.
-
I had also captured a Touchstone file for each VNA at the both temperatures just prior to changing temperatures. No cables were used during this test. The open was attached directly to the VNA's port1.
-
OWO had suggested that the USB cable supplied with my V2P4 may have enough loss to be causing the increased noise I see when not running off the internal battery.
I took the unit apart and attached some leads to the large bulk cap they have across the USB power leads. I wanted to know what it measures inside the unit. With my extension cable plus the supplied blue one, I measure 4.61V. With the supplied cable plugged directly into the USB port, I measured 4.865V.
Again to be clear, I had made a test cable to try and identify the problem as well. My last attempt had used a linear power supply driving a linear regulator powering the V2Plus4. This also caused the increased noise. Basically, as I had said, if don't run it from the internal battery, the noise goes up. Measuring the voltage with this cable, I get 5.014V
-
Testing in the 3-4GHz range is not the most fair comparison because the V2 Plus4 only has guaranteed performance specifications up to 3GHz.
Your custom cable has too much resistance, and operating at 4.6V is way too low for the mixer.
The LiteVNA copies my design without permission and only substituted some parts to extend the frequency range.
-
I suggest reviewing the Arinst VNA-DL or VNA-PR1. Both reach 6GHz at low cost, have better performance, and are designed from scratch by people that know what they are doing who don't need to rip off other's designs.
-
I suggest reviewing the Arinst VNA-DL or VNA-PR1. Both reach 6GHz at low cost, have better performance, and are designed from scratch by people that know what they are doing who don't need to rip off other's designs.
Hi Owo,
Just a short comment about the design of the
Arinst VNAs You've mentioned.
In their manuals, they show a functional block diagram for both VNAs, which seems to replicate the classical NanoVNA design from Eddy555 with some modifications for frequency band expansion.
Basically, the core of the design is the same audio-codec chip with build-in high-resolution -sigma-delta ADC, which helps to get high DR.
Both VNA are not cheap, though.
-
I suggest reviewing the Arinst VNA-DL or VNA-PR1. Both reach 6GHz at low cost, have better performance, and are designed from scratch by people that know what they are doing who don't need to rip off other's designs.
yes apart from higher price as Alex mentioned, i suspect they have different protocol that made them incompatible to NanoVNA-Qt, and also possibly NanoVNA-App and Joe's LabView App here. they have their own SWs. i know Hugen did copy your design illegally through our PM, and now you publicly mentioned it here, but few days ago i made order LiteVNA from AliExpress @ $126 incl shipping, not because i have personal problem with you, but because i desperately need it in quick time ASAP. your upcoming version will be the next interesting upgrade, if the figure you showed me in PM is true, your VNA will be very close to professional grade VNA anyone should be looking for... but since its ETA unknown, thats the problem i cant consider for the time being.. member Dislord informed me in PM that the LiteVNA can be used with NanoVNA-QT only up to 4.4GHz, and i suspect its the NVNA-QT limitation in the code. so i asked Zeenko Store to forward my request to Hugen to recompile NVNA-QT to increase limit to 6.3GHz because i dont have linux to make compilation, and surprisingly he did it for me after few days of PM back and forth.. so i lose in shame and have to make the order. cheers.
-
Testing in the 3-4GHz range is not the most fair comparison because the V2 Plus4 only has guaranteed performance specifications up to 3GHz.
Limit the design if you don't want customers to run beyond 3GHz.
Again to be clear, I had made a test cable to try and identify the problem as well. My last attempt had used a linear power supply driving a linear regulator powering the V2Plus4. This also caused the increased noise. Basically, as I had said, if don't run it from the internal battery, the noise goes up. Measuring the voltage with this cable, I get 5.014V
Your custom cable has too much resistance, and operating at 4.6V is way too low for the mixer.
I don't have the standards in front of me but first hit from Google:
According to the USB spec, and illustrated in Figure 1, the minimum available voltage from a USB host or powered hub at the peripheral end of the cable is 4.5V, while the minimum voltage from a USB bus-powered hub is 4.35V.
I would have assumed you would design the product to meet the USB minimum voltage requirements. You mention my cables high resistance. The cable drops 21.5mV @ 398mA or 8.6mOhm or so. Even with the 5.014V measured internal of the V2Plus4, the noise is poor. Blame the cable if you like.
I suggest reviewing the Arinst VNA-DL or VNA-PR1. Both reach 6GHz at low cost, have better performance, and are designed from scratch by people that know what they are doing who don't need to rip off other's designs.
I would not waste my time with that device. Similar to Jan's, they did not document the communications requiring the use of their software. The hardware could rival the best VNAs on the market today but without good firmware and software, they have little value to me. Of course, you are welcome to procure what ever VNAs you like to create your own reviews. You could even cherry pick the parameters to skew the data.
The LiteVNA copies my design without permission and only substituted some parts to extend the frequency range.
I've asked you several times for proof that any laws were broken in your country, so far all I have received is a constant stream of lecturing from you. It comes across rather rude, childish and unprofessional. And while you may feel you have some say in how I conduct my reviews, you don't.
If I wanted to create something novel and planned to turn it into a product to capitalize on it, I may patent the IP or I may hold it as a trade secrete. I would NEVER make it open source!
Once the product is designed, social media seems like a good choice for advertising to the hobbyist market. I setup a mail group to attract potential customers. I would never consider is locking the group to potential customers! You have stated that was a mistake. That is what Jan stated as well. Really bad choices.
I decide to reinvest some of my earnings into my next product and make an announcement to stir up some interest. The one thing I would never do is make a public announcement that I am walking away from it unless I plan to walk away from it! It's the story of the boy and his ball walking off the playground. It shows a lack of maturity on your part.
It's just a hobby project at this point since all I've seen indicates the market is so small that you shouldn't take it too seriously. Or I may just go and take the 6 figure job at a big technology company doing cutting edge R&D and be gone with this race to the bottom crap, maybe I'll decide that's where I want to be in life instead.
https://www.eevblog.com/forum/testgear/nanovna-v3-(6ghz)/msg3847775/#msg3847775 (https://www.eevblog.com/forum/testgear/nanovna-v3-(6ghz)/msg3847775/#msg3847775)
Let's assume I had placed my design in the public domain and someone improves the idea and capitalizes on it. These changes were obvious to one skilled in the art. I would ask myself, I had the design done and all I needed to do was make these simple changes to obsolete my own product or add to my product line and increase my market share. Why didn't I?
From my perspective the problems you are having are a reflection of the poor choices you have made. I'm responsible for the choices I make. If there is something I don't like, I change and move on. You seem unable to learn from your mistakes and change course. It's not the competition you need to be concerned with.
-
The attached slide showing the worse case analysis was from a workshop I attended put on by one of the creators of the USB standards.
-
Pictures of the LiteVNA. It seems well made.
-
i know Hugen did copy your design illegally through our PM, and now you publicly mentioned it here,
Project was released under GPL license ...
-
I'd rather not start this argument on the forum again, but you misunderstand why I have a problem with Hugen's actions.
It is not simply that he is using my design, as many others have done legally (for example sysjoint with their NanoVNA-F V2, or all the other shenzhen cloners that I have no problem with). That was my original intention with open sourcing the design, which is to allow a broad range of players to get a head start and enter the market. It is that he is playing the monopoly playbook and using every possible tactic (such as dumping) to squeeze everyone else out, when he already has over 80% market share. Since it is my design that enabled him to do this, I'm the only one in any position to do anything about it. It is truly regretful that my original intentions with open source has enabled a monopoly player, and since then I have never open sourced anything.
That's why I'm urging everyone not to support this vendor, and I'm not saying support me instead. We are #2 and will do just fine, so I recommend giving more attention to the smaller players instead like Arinst, deepelec, etc.
-
This project is only a hobby for me, please don't assume I'm trying to run and grow a business just because we happen to sell stuff. I'm making enough (and if I didn't, it wouldn't be hard to find a well paying job). You are right that if I wanted to, I could use my technical advantage (and the same tactics) to overtake the #1 spot (and also use patents and design secrecy to maintain it), but I have no desire to do that. Exchanging one monopoly player for another doesn't achieve anything, and ultimately will just result in a collapse just like the PCB market in China. Like the PCB market, they are operating on unsustainable margins to try to dominate and eventually become the only player, just like some PCB vendors are now offering free PCB prototypes in China which I also view as an anticompetitive move. I simply want there to be healthy competition, not cutthroat competition or a monopoly.
If I can go back and redo, the only thing I would do different is use a revocable open source license, so that everyone else would still be allowed to use my design but anyone attempting a monopoly can have their license revoked.
-
I'd rather not start this argument on the forum again, but you misunderstand why I have a problem with Hugen's actions.
..
Starts argument, proceeds to suggest they would rather not. What were you expecting would be the end result? Change your business practices if your are not happy with them but don't try and suggest that the problem is with everyone else.
-
I did say I have no problem with everyone else, only one particular vendor...
-
You are still misunderstanding.
What you think my position is: I'm salty about my design being copied by everyone and that is why I'm complaining.
What my position actually is: I'm happy with what almost everyone are doing with my design, just as I intended when I open sourced it. However one vendor is now using anticompetitive tactics to corner the market, and after realizing it is my design that enabled them to do so, I no longer have any enthusiasm for open source anymore. Regardless of whether it has any legal standing, I made a gesture of revoking permission to use my design by this vendor as a symbol that the original developer denounces his products that are based on my design. I urge everyone to give more attention to the smaller players instead of this vendor.
What you assume: we are trying to grow a business and we aren't maximizing our chances and perfecting our execution because we're incompetent.
What's actually going on: this is only a hobby for us. The fact that my earlier efforts only helped a monopoly gain more power is highly demotivating, so V3 is only worked on when I have the motivation, and I don't want to get people's hopes up so I tell them the truth that they shouldn't anticipate it too much. This is not announcing that we are walking away from the project, only the reality that they should not depend on it becoming available.
The other implicit assumption you made is that people only care about maximizing their own material interests/financial interests. There are more things I can get ticked off about, such as I can feel resentment towards someone that is trying to screw me over. Therefore I may care more about stopping this monopoly than simply making maximum money myself.
-
Exchanging one monopoly player for another doesn't achieve anything, and ultimately will just result in a collapse just like the PCB market in China. Like the PCB market, they are operating on unsustainable margins to try to dominate and eventually become the only player, just like some PCB vendors are now offering free PCB prototypes in China which I also view as an anticompetitive move. I simply want there to be healthy competition, not cutthroat competition or a monopoly.
now i got your point. about Hugen tries to monopolized the market thats the problem, not that he copied your design... but i guess similar happened to outsides countries such as US with China. US businesses have become unsustainable due to competition and low production cost of China, i cant imagine how many businesses in US have to close or scaled down due to this. now the fight has become domestic within China itself ;D how about bring this kind discussion to the NanoVNA 6GHz thread i have no problem with you over there and leave this thread to its original intention ;) and i'm sorry to say you wont be able to stop people from buying what they want. like me for example, i need cross compatibility with NanoVNA-QT i told you, and LiteVNA is the only option for me now and no other else afaik. cheers.
-
I will express my opinion:
I was doing the firmware for LiteVNA. For her, I implemented everything that I would like to see in the device (Possibility to save data to the card, external USART, brightness control, the ability to see the battery charge), everything features that was on H / H4.
I did not deal with the hardware part (there is not only replacement of the generator and switches, there is a completely redone part of the power supply, and another piping of the generators, since SI5351 was replaced by MS5351, ADF4350 by MAX2871). Different layout on the board (and this is also a significant alteration, since it does have a huge impact on the result), different CPU. There may be other changes that I do not know about. Therefore, it is impossible to say that everything is simply copied.
The firmware has been almost completely rewritten (only the protocol code remained from the original one, and a part for the ability to assemble for V2/V2Plus/V2Plus4). And in the part of the firmware, I used only board/protocol code from V2Plus / V2Plus4 and not depend from hardware H/H4, write all hardware-dependent code (you can even see this by the significantly reduced firmware size and 2 times more points (up to 401 on any V2, and up to 1001 on LiteVNA), and I note these points are not interpolation, as you indicate in your website, I just use the available processor resources more economically)
You did not develop the firmware from V2 after hardware release (and close sources), and its further development was mainly due to donations and Hugen's initiative. The firmware code is not protected from copying in any way (although I do not have plans to open it, since all manufacturers use my developments from open source code for H/H4 although it is released under the GPL3 license, they prefer to close their own). Therefore, I don’t think that your code has been illegally used in the programmatic part.
-
I did not deal with the hardware part (there is not only replacement of the generator and switches, there is a completely redone part of the power supply, and another piping of the generators, since SI5351 was replaced by MS5351, ADF4350 by MAX2871). Different layout on the board (and this is also a significant alteration, since it does have a huge impact on the result), different CPU. There may be other changes that I do not know about. Therefore, it is impossible to say that everything is simply copied.
I also reviewed the V2 hardware. E.g. the impedance mismatch will limit the performance above GHz. Especially, the S11 will be degraded above -10db by the mismatching around SMA connectors. This problem could not be totally solved by the calibration.
According to the internal photos of LiteVNA, It seems it used a better type of connectors which may improve the performance.
-
You are still misunderstanding.
Most certainly I am. This is why I continue to ask you for proof that a law was broken and have received no evidence. Rather you continue to claim that your design was stolen from you.
It does seem from your comment "Your custom cable has too much resistance, and operating at 4.6V is way too low for the mixer." that you did not design to the USB standard.
What you think my position is: I'm salty about my design being copied by everyone and that is why I'm complaining.
I have followed your actions, read your posts and played them back.
What you assume: we are trying to grow a business and we aren't maximizing our chances and perfecting our execution because we're incompetent.
I have outlined choices you have made that I wouldn't. I would say the market share is the best indicator of your performance.
The other implicit assumption you made is that people only care about maximizing their own material interests/financial interests. There are more things I can get ticked off about, such as I can feel resentment towards someone that is trying to screw me over. Therefore I may care more about stopping this monopoly than simply making maximum money myself.
I won't attempt to speak for the masses, only myself. When I talk of people, its based on metrics like the 80% market share you keep bringing up. I would have no way to know what the market share is or what motivates people to buy a particular product.
As I suggested earlier, looking at the number of posts in groups as a metric, the low cost VNAs (excuse me, antenna analyzers) seem to have ran their course. Based on some of the comments, projects and videos, I would say that the original lowcost NanoVNA did a fine job raising the general awareness and education of the masses on a fairly large scale.
-
What you assume: we are trying to grow a business and we aren't maximizing our chances and perfecting our execution because we're incompetent.
I would say the market share is the best indicator of your performance.
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1358396;image)
https://www.washingtonpost.com/technology/2021/09/21/us-china-tech-competition/ (https://www.washingtonpost.com/technology/2021/09/21/us-china-tech-competition/)
-
Seems OWO was not happy with the temperature tests I ran. I am planning to repeat the test at 1MHz to 2.9GHz. I will again run at 18 & 28C, using the open. The temperature is starting to settle at 18C.
-
https://www.washingtonpost.com/technology/2021/09/21/us-china-tech-competition/ (https://www.washingtonpost.com/technology/2021/09/21/us-china-tech-competition/)
AFAIK OWOs complaints of theft and monopolies don't involve the USA. Outside of her attempting to bias my reviews (which won't happen), I have little involvement.
As a consumer, I will say the LiteVNA is pretty impressive for the price. I wonder if Dislord will investigate the narrow band problems and attempt to solve them. Maybe they will try to improve the dynamic range.
-
We are doing fine and I simply don't have the motivation to try to grab more market share by reducing prices or selling higher cost designs at the low prices. If we were to sell a product like the LiteVNA, we would have to price it above $500 because we are simply not interested in maximum market share and prefer to make a comfortable living selling to a smaller niche market at higher margins. In fact, our profit share is very close to Zeenko's, and if I do decide to go forward with V3 it wouldn't be hard to beat them (although that isn't my goal). I'm in no hurry though, because the more time I spend optimizing my designs the further it will be in the cost/performance ladder and the higher margin we will have.
The issue is that no one else can compete with them because they are operating on unsustainable margins to try to monopolize everything. Do you really want a market with only us and Zeenko left, and everyone else gone? You might think Arinst, deepelec, sysjoint, PocketVNA, MiniVNA, and VNWA are all uncompetitive and don't need to exist, but each bring a unique set of features and software, and I think it would be a bad state of affairs if there is only one VNA protocol to choose from and one type of architecture to choose from (with all of its limitations).
-
I think the user is interested in quality and functionality. Give it to him and he will choose your device. Offer him more functions or capabilities, give him convenient and intuitive control, and most likely he will choose you. The price often does not affect that much (I know that many people choose F and F2 precisely because of the metal case, the larger display, despite the significantly higher price).
-
... If we were to sell a product like the LiteVNA, we would have to price it above $500 ...
A very good deal indeed while they keep their prices so low. It's slightly more than I paid for the H4 but the firmware appears much more stable.
You might think Arinst, deepelec, sysjoint, PocketVNA, MiniVNA, and VNWA are all uncompetitive and don't need to exist, .....
You are correct. I do not "need" any of my equipment. As for the low cost VNAs I have looked it, I've been pretty clear from the start that it's been a matter of trying to help educate a few friends on their possible use. It should be obvious that I'm not attempting to capitalize on it in any way.
-
The issue is that no one else can compete with them because they are operating on unsustainable margins to try to monopolize everything.
good for us :P
Do you really want a market with only us and Zeenko left, and everyone else gone?
no, not really. but in fact, we dont care, this is not our battle.
You might think Arinst, deepelec, sysjoint, PocketVNA, MiniVNA, and VNWA are all uncompetitive and don't need to exist, but each bring a unique set of features and software, and I think it would be a bad state of affairs if there is only one VNA protocol to choose from and one type of architecture to choose from (with all of its limitations).
they must provide something special not available in other brands, but i cant find any, except the higher price. Joe needs compatibility because he doesnt have time to reverse engineer protocol of another device (i've been there when upgrading Rigol 1052E to 1054Z). i otoh, as i become more and more familiar with VNA features, figured out s-parm/characterized calibration kit is the golden standard available in modern pro level VNA that i really required, thanks to NVNA-QT and its programmer(s) than opened my eyes on this. trust me when you come up with your V3 with -200dB noise floor at $50 but doesnt support NVNA-QT or doesnt have built it characterized calibration kit setting, i'll find that less interesting or less usefull atm. as for others potential buyers/newcomers, i guess they will do like how most of us do.. compare features, look at the prices and then look in their pocket and imagine which features are most important to them and buy that brand. the best will win. as others said, being the cheapest not necessarily wins, too much expensive with very little extra features that not really important to us will not win too, thats why each brand has their own share. in case the monopolizer wins and become the only one, so be it. when they increase the price, other brands will sneak in and win again, the market will balance itself out, a simple supply and demand rule.. like it will and what happened among countries now (i linked earlier) and anywhere else. ymmv cheers.
-
Sweeping from 18 to 28C, from the paper I previously attached we would expect to see less than 0.1db and 1degree of change. While we could cherry pick some frequencies, it seems both are very stable with temperature.
-
trust me when you come up with your V3 with -200dB noise floor at $50 but doesnt support NVNA-QT or doesnt have built it characterized calibration kit setting, i'll find that less interesting or less usefull atm.
I still doubt about the performance of V3. 500 USD is more than reasonable if V3 has thus kind of performance.
The only problem is when I could place the order. No ETA for V3 for a long long period. Thus, I just placed an LiteVNA order for digging in its RF design, maybe its Noise Figure could be improved by user community...Refining the PCB and SMT becomes far easier than before.
-
trust me when you come up with your V3 with -200dB noise floor at $50 but doesnt support NVNA-QT or doesnt have built it characterized calibration kit setting, i'll find that less interesting or less useful atm.
I still doubt about the performance of V3. 500 USD is more than reasonable if V3 has thus kind of performance.
that is just my too optimistic exaggerated guess but in real life impossible to achieve even by #1 brand... for eq Keysight FieldFox is -100dB dynamic, Siglent is -120dB iirc... i've been shown the result of prototype board thats on par or very close to those but i'm not allowed to post it in public. cheers.
-
OWO shared some preliminary data from the prototype with me as well. We discussed making a review comparing the V3 prototype with the LiteVNA to help stir up some interest in the product. Once she made the comment:
Or I may just go and take the 6 figure job at a big technology company doing cutting edge R&D and be gone with this race to the bottom crap, maybe I'll decide that's where I want to be in life instead.
, I felt the risk was too high that they wouldn't follow through and it made no sense to continue down that path. Her constant lecturing me of business practices further cemented my concerns. I hope I am wrong.
I have added support for setting the output power to support the LiteVNA and also increased the timeout to handle the very slow data transfers when it is set to low frequencies. The power settings will be stored into the defaults. This means that both the defaults and calibration files are not compatible with the 2.x software.
-
Alright, thanks for sharing your points of view.
About V3, as I said it's a hobby project and please do not take it too seriously. I have no intention of trying to compete with them for market share and I don't necessarily want to "stir up interest". I didn't start that thread and only ended up posting in it because too many people were emailing me and giving me time pressure that I really do not need. V3 will happen when it happens, and in the mean time look at other alternatives too. EuroVNA is another one possibly worth following.
-
0xF0 - (byte) device variant (2 vor V2)
0xF1 - (byte) protocol version (1 vor V2)
0xF2 - (byte) board revision (2 vor V2, 3 - V2Plus, 4 - V2Plus4)
0xF3 - (byte) firmware major
0xF4 - (byte) firmware minor
Was there a reason for not using a unique board revision for the LiteVNA?
Or do you consider the 2, the lite?
-
>Was there a reason for not using a unique board revision for the LiteVNA?
I leave this values
#define BOARD_NAME "LiteVNA 6G"
#define BOARD_REVISION (2)
#define FIRMWARE_MAJOR_VERSION 2 <--- Change only this for Lite (V2/V2Plus/V2Plus4 = 1)
#define FIRMWARE_MINOR_VERSION 2
For compatibility with programs on the CPU side (i tried to change everything about the protocol to a minimum). Software like NanoVNA-App detect device type from this registers.
PS LiteVNA as V2Plus4 can provide up to 65535 points in one sweep
For my fw version i use LiteVNA code for compile V2 fw, this allow me get more measure and calibration points (up to 401) and all features from H / H4 devices (also if need V2 can modded for add SD card support)
-
>Was there a reason for not using a unique board revision for the LiteVNA?
I leave this values
#define BOARD_NAME "LiteVNA 6G"
#define BOARD_REVISION (2)
#define FIRMWARE_MAJOR_VERSION 2 <--- Change only this for Lite (V2/V2Plus/V2Plus4 = 1)
#define FIRMWARE_MINOR_VERSION 2
For compatibility with programs on the CPU side (i tried to change everything about the protocol to a minimum). Software like NanoVNA-App detect device type from this registers.
PS LiteVNA as V2Plus4 can provide up to 65535 points in one sweep
For my fw version i use LiteVNA code for compile V2 fw, this allow me get more measure and calibration points (up to 401) and all features from H / H4 devices (also if need V2 can modded for add SD card support)
Other firmware could end up with the same Major Version as the Lite. Device variant or board revision may be a better choice to make a unique ID for the Lite.
https://nanorfe.com/nanovna-v2.html
They advertise 1024 points with the external software. Maybe you are suggesting with your firmware that the V2Plus4 could be increased?
-
>Maybe you are suggesting with your firmware that the V2Plus4 could be increased?
Strange, i remember for V2Plus4 on this site write 65535 (original fw also V2Plus4 allow send this points count)
Question not owerflow input buffer:
Example for get N points need write in 8 bit register N (8 bit limit 255)
So for read 1024 points need write 255 again 255 again 255 again 255 and 4
For 65535 points need lot of writes (and possible owerflow)
I allow write 0 in this register one time and then Nano return all sweep points (as i remember this fix also present in official firmware)
For LiteVNA and V2Plus4 possible set up to 65535 points
PS my fw variant for V2Plus4 not work on new V2Plus4 revisions (used different LCD module? i dont`t know details, only know CPU connection work)
-
>Maybe you are suggesting with your firmware that the V2Plus4 could be increased?
Strange, i remember for V2Plus4 on this site write 65535 (original fw also V2Plus4 allow send this points count)
I'm just going by their document. Today I limit my software to 1600 points but it's one number change to open it up.
Question not owerflow input buffer:
Example for get N points need write in 8 bit register N (8 bit limit 255)
So for read 1024 points need write 255 again 255 again 255 again 255 and 4
For 65535 points need lot of writes (and possible owerflow)
Sorry you lost me. I have no idea what 8-bit register you are referring to.
I allow write 0 in this register one time and then Nano return all sweep points (as i remember this fix also present in official firmware)
Sorry, again I have no idea what register you are referring to.
From: https://nanorfe.com/nanovna-v2-user-manual.html , Sweep points is a 16-bit register. I just set that to what ever I need and the device returns that number.
For LiteVNA and V2Plus4 possible set up to 65535 points
PS my fw variant for V2Plus4 not work on new V2Plus4 revisions (used different LCD module? i dont`t know details, only know CPU connection work)
Yes, its a 16-bit register but from their specs, I am not sure what they actually support. I can make a quick change to my software and try to see what the limits are of the V2Plus4 (with what ever firmware I have installed). I've never upgraded it.
-
> Sorry you lost me. I have no idea what 8-bit register you are referring to.
https://nanorfe.com/nanovna-v2-user-manual.html
See: Host to device command list
READFIFO - for read data from V2
18 (AA) (NN)
How you ask V2 for read data? (NN) - 8 bit value
-
I set it to read one value at a time (32 bytes).
Both seem to support 16-bits. V2Plus4 is much slower. However, I can't think of a need for it off hand. I may go ahead and open it up on the next release.
-
>I set it to read one value at a time (32 bytes).
You can set up to 255 values (can be faster)
Or set 0 then get all sweep points
>V2Plus4 is much slower.
Possible this related to your read procedure? 65535 points must read in near 3 min on default avg setting (400 points/sec for V2Plus4 and 550 points/sec for Lite).
You can try ask 255 data point in one time (or try use 0 value for get all sweep points data, last firmwares for V2Plus4 should support this)
Example read 1020 points (by 255 points in one ask):
Send: 0x18 0x30 0xFF 0x18 0x30 0xFF 0x18 0x30 0xFF 0x18 0x30 0xFF
And wait 1020 data points
Can try this
Send: 0x18 0x30 0x00
And wait all sweep points
-
>I set it to read one value at a time (32 bytes).
You can set up to 255 values (can be faster)
Or set 0 then get all sweep points
>V2Plus4 is much slower.
Possible this related to your read procedure? 65535 points must read in near 3 min on default avg setting (400 points/sec for V2Plus4 and 550 points/sec for Lite).
You can try ask 255 data point in one time (or try use 0 value for get all sweep points data, last firmwares for V2Plus4 should support this)
Example read 1020 points (by 255 points in one ask):
Send: 0x18 0x30 0xFF 0x18 0x30 0xFF 0x18 0x30 0xFF 0x18 0x30 0xFF
And wait 1020 data points
Can try this
Send: 0x18 0x30 0x00
And wait all sweep points
For the V2Plus4, the sweep time is what dominates, not the USB communications. I've ran several tests collecting large data sets and the software easily will keep up, even asking for a single value.
Yes, they are very close to the 400Hz, or 2.5ms per value. Of course, you need to be using the higher frequency range. Looking at the attached, we are sweeping from 500MHz to 900MHz with 4000 points. The software is measuring 10 seconds per sweep as expected.
I wouldn't mind being able to pull down 4000 points in a second but again, I can't think of a case where I needed this much data from a linear sweep.
***
Some time back, a member was attempting to use the V2Plus4 to measure human vitals which required running CW at a fixed sweep rate. They were able to get it working. It's a few pages back if you are interested in having a look.
-
Based on
550 points/sec for Lite
, 4000points would require 7.3 seconds. Oddly, it is very slow. I tried it at 400 data points and it is about 10X faster but no where near what I would expect. The V2Plus4 is much faster.
-
LiteVNA use 2x avg as default, this give ~300 points/sec
You can control this by write avg value in 0x40 register:
Set average = 5x command:
0x20 - write byte
0x40 - address (average)
0x05 - value
Need send : 0x20 0x40 0x05
High avg setting slowdown measure speed, but increase quality. You can also do average inside your software.
-
LiteVNA use 2x avg as default, this give ~300 points/sec
You can control this by write avg value in 0x40 register:
Set average = 5x command:
0x20 - write byte
0x40 - address (average)
0x05 - value
Need send : 0x20 0x40 0x05
High avg setting slowdown measure speed, but increase quality. You can also do average inside your software.
Doing a running average in software, I maintain the VNAs data rates. So for 101 points and 10 averages, I would have a 101 X 10 array that maintain.
It would have been nice to see it backwards compatible with the V2P4 so no software changes were required. It seems like in this case, it seems like you could have used different defaults. Odd is until now, you did not mention it and there was nothing in that short document you provided that mentioned the defaults. I get to stumble into it. :-DD
I'll add the new command and try it.
***
What does your firmware do when I set this to 0?
Does writing to this register instantly reset the sweep and average?
Set it to say 4000 points, 100 avg. Switch it back to one, does it hang? Mine does. I can disconnect and reconnect and yet can not get the VNA to start sweeping again. Is this expected by design?
Does the firmware require that you stop sending data before changing the average (or some other requirement)? Is it similar to the power selection that requires a sweep rather than CW to update?
-
>It would have been nice to see it backwards compatible with the V2P4 so no software changes were required.
Just use default, result just little less sweep speed 300 points / sec
This just additional option (my fw for V2Plus4 also support this, but not remember about official)
>What does your firmware do when I set this to 0?
I check limits, min value = 1
>Does writing to this register instantly reset the sweep and average?
Yes, sweep reset after last asked data send to CPU.
V2 protocol parse input commands and put in FIFO buffer, then commands executed
So if you ask data Nano start send it, received command put in FIFO and wait, after send complete executed next command. FIFO have limited depth so can overflow (in this case Nano not accept new commans while old executed and free buffer)
PS I check this option work vs NanoVNA-App application, and not see any problems. And repeat - use can use this default settings, it will not affect the work in any way.
PS Also i fix output power change in CW mode (and additional fix update XTAIL correction, this allows you to set the output frequency up to 140 MHz with an accuracy of 1-5 Hz), need some tests.
Change power not apply in CW mode - i cache generator setting, and not update if no frequency change, as result no power settings update. Now i reset cache after receive this command.
-
>Does writing to this register instantly reset the sweep and average?
Yes, sweep reset after last asked data send to CPU.
With a 100 averages, that could take a VERY long time. You need to have a way to abort and recover.
Setting the average with the firmware included with my V2Plus4 has no effect.
What about the lockup I mentioned? Can you replicate it? Seems like I can easy enough. Maybe it's unique to this firmware.
I really don't know what the implications are of averageing to everyone else. Personally, if something isn't stable, I want to see the peak heights. I want the raw data.
Changing the sample rate, hard to say what the effects are.
-
I think I already wrote here what averaging is on the nana side. Perhaps the wrong term here is averaging.
This value affects the bandwidth in which the measurement is performed (this is not exactly what you do in your program, but it looks like)
Let’s be more specific, nana digitizes the signal for say 10 periods, this data is sent for processing for calculation. But if you take not 10 periods but 20, then the value will be calculated more accurately. If we consider this as a spectrum analyzer, then the analogy is a decrease in RBW during measurement, this reduces the noise level, but unfortunately more samples need to be taken.
So in any cases you get RAW data
>Can you replicate it?
I can test only in NanoVNA-App.
If i set 1000 points and x100 avg, then run sweep and disconnect - then Nano not hang, after reconnect i can run.
As i see nanoVNA-App reset sweep before disconnect and on sweep start (by send 18 30 00)
Here program log in this case:
10.159 tx: setting scan parameters
10.163 tx: 00 00 00 00 00 00 00 00 23 00 80 D1 F0 08 00 00 00 00 23 10 CB 41 57 00 00 00 00 00 21 20 00 04 21 22 01 00
10.166 tx: requesting 1024 points ..
10.168 tx: 18 30 00 <- Here i disconnect
11.966 tx: clearing FIFO buffer
11.969 tx: 00 00 00 00 00 00 00 00
11.972 tx: leave USB data mode
11.975 tx: 20 26 02
11.978 tx: polling - requesting hw-revision and fw-version
11.981 tx: 10 F2 10 F3 10 F4
11.984 disconnect: serial port disconnected
15.305 connect: serial port connecting ..
15.308 connect: serial port connected <-- reconnect
15.337 tx: leave USB data mode
15.340 tx: 00 00 00 00 00 00 00 00 20 26 02
15.343 tx: are you a V2 ?
15.346 tx: 0D
15.349 rx: 32 .. ACK OK
15.352 tx: requesting device variant
15.354 tx: 10 F0
15.357 rx: 02 .. DEVICE VARIANT OK
15.360 tx: requesting serial protocol version
15.363 tx: 10 F1
15.399 rx: 01 .. PROTOCOL VERSION OK
15.402 tx: requesting hw-revision and fw-version
15.405 tx: 10 F2 10 F3 10 F4
15.460 rx: 02 ..... HARDWARE REVISION
15.463 rx: 02 02 .. FIRMWARE VERSION
15.466 rx: [connected to a V2]
>Maybe it's unique to this firmware.
No i nothing change in fw related to protocol (command and data processing equal as on any V2, just added additional commands).
Test on Current version of your software, i manually set on Lite avg = 80x, run sweep on software, then disconnect (remove cable), connect cable back and reconnect, after i can run sweep as before
But if i run sweep stop it, restart. In some cases sweep not start. Also i see after restart sweep point counter (point index) not start from 0 after sweep resume after stop on 50 for example after resum it can start from 120 (not sended reset sweep?) But if disconnect in software and reconnect, sweep start from 0.
PS But then test USART connection to LiteVNA (connect to Lite over Bluetooth and WiFi), i found bugs - on low speed connection V2 does not have time to send data, and fills its buffer for measurements, as a result, it overflows and data is lost, as it is overwritten with new ones. I fixed this by pausing measurements while filling.
-
Plotting the sweep time for the two VNAs. Both set to 401 points, 150-300MHz. I would imagine the stability and averaging are not very important to the antenna analyzer group. For our friend attempting to do their radar experiments, maybe its a bit more critical.
I did try changing the process to realtime but as expected, no effect.
So I set the average back to 2 and the system is stable. It could be a problem with my software. Hard to say.
Where are you storing the firmware? I would be willing to have a look at the new version that supports the narrow band measurements.
-
I made firmware for self (but send last code to Hugen, he additionally checks it on his devices and assembles the firmware)
I don't have the latest hardware revision, just a couple of engineering samples (2.8 inch version and very old 4 inch board)
Official page here:
https://zeenko.tech/litevna
I can build my last code
LiteVNA 62 for 2.8 inch devices (i test it on my sample)
LiteVNA 64 for 4 inch devices (must work but not test)
Fixed update power setting in CW mode for both SI and MAX
Added more trace/marker types
Added USART connection support
>narrow band measurements
If i correct calculate 1xavg give 2kHz bandwidth on > 400kHz frequency (
On < 400kHz used 12k IF on less 20k use 6k IF so measure on this range slow (very slow).
Min frequency = 1.6k but in this range Lite have very bad dynamic (i allow use it only for tests LiteVNA Specifications 50kHz ~ 6.3GHz).
All V2 (and LiteVNA) on ~ < 1Mhz not good.
H4 up to ~100MHz work more better then any V2 variant include LiteVNA
-
I have the 4 inch version. No problems installing the firmware. The only thing I had to do was calibrate the touch screen (so I could check the version). Measuring a crystal, I get the same values as I did with the previous firmware. Yes, very slow at lower frequencies. I'll try out the power level settings.
-
On serial crystal measure i get better results if select x5 or x10 avg
LiteVNA (as H/H4) have crystal measure calculator (see MEASURE->SERIES XTAL)
I use Phase Shift Measurement https://www.mikrocontroller.net/attachment/473317/Crystal_Motional_Parameters.pdf (https://www.mikrocontroller.net/attachment/473317/Crystal_Motional_Parameters.pdf) method for calculate
For get better results on limited points count i use bilinear interpolation on search
Here it results for 10MHz serial xtal connection
NanoVNA-H (101 points)
[attach=1]
Here some measure on LiteVNA (1001 points allow better search resonances and phase shifts):
[attach=2]
V2Plus4 not allow made this measure (it use additional processing for get better dynamic, so results look strange):
[attach=3]
But any V2 not good in XTAL measure, due to used measure mode (first measure reference, second refflect, second thru), H/H4 measure (reference / reflect and reference / thru in some time, and this allow see correct XTAL responce)
Lower frequency XTAL better measure on bigger avg settings (results look better)
-
I've not tried to use any of the built-in features for the NanoVNAs. It may be of interest to compare the LiteVNA against my original NanoVNA.
What do you require for a test fixture? I see the paper you provide has a few. I made a few different fixtures but didn't obtain very good results. The last fixture I constructed seemed to get me very close results when compared with other methods:
https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3076877/#msg3076877 (https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3076877/#msg3076877)
I have a couple of crystals that I had collected data for but was never able to get my hands on a reference standard.
-
I use cheap fixture like this, just for test
For this fixture need set Rl = 50 Om
[attach=1]
Also i see this variant:
For this need set Rl = 12.5 Om
https://www.ph2lb.nl/blog/index.php?page=xtal-adapter-for-nanovna (https://www.ph2lb.nl/blog/index.php?page=xtal-adapter-for-nanovna)
I have H / H4 / V2Plus4 / LiteVNA / modded V2Plus from V2 / LibreVNA
Also have v3.6 board H variant (last board revision show very good results)
PS i try add in firmware all features as on CPU side, for stand alone use
-
I tried it but was lost. For starts, the terms you use do no match the paper you provided. I'm not sure what equations you use. Q for example could mean different things. If I used the simple fixture, cal the VNA, the software will not detect the crystal. I have to manually zoom in. Eventually it starts to show some numbers. As I continue to zoom in, these change a fair amount. I would need some sort of written procedure before I could evaluate it.
-
Yes, need manually (this measures semi automatic) select range for good see both resonances on screen (on calculation i search resonances/phase shifts on current measured data), i use bilinear interpolation for get data between poins so bigger points count reduce errors (also selecting good range allow get more closest results)
Also better select bigger avg settings (Display->AVG = 10 for example)
w2aew made video:
https://www.youtube.com/watch?v=G9zZRNzhsEE (https://www.youtube.com/watch?v=G9zZRNzhsEE)
How i made calculations:
I search Max linear value in S21 (k = |S21| at this point) value and get Fs frequency
k - linear value (not in dB, for dB value Rs = 2*Rl * (10^((S21 in dB)/20) - 1)
Rs = 2*Rl * (1/k - 1)
Reff = 2*Rl + Rs
Next i search pase shift -45 degree and get frequency f2 and pase shift +45 degree and get f1
After i correct measured Fs frequency by made geometry average
Fs =sqrtf(f2*f1)
dF = f2 - f1
Ls = Reff / (2 * Pi * dF)
Cs = dF / (2 * Pi * Fs * Fs * Reff)
Q = 2 * pi * Fs * Ls / Rs not remember why, need search (look like Need use Reff? not Rs, in this case Q = Fs / dF)
After i search min linear value in S21 and get Fp frequency
Cp = (C0 + Cstray)
There C0 is the holder capacitance, Cstray - shunting capacitance of the test fixture
Cp = Cs * Fs / (2*(Fp - Fs))
PS SHUNT LC measure allow measure XTAL connected as shunt, need also manually select range for see peak (this measure critical to good calibration)
[attach=1]
PS need rename Rs to Rm, Ls to Lm and Cs to Cm
PS you store calibration in 0 slot (better use DONE in RAM for temporary calibrations, calibration reset after power off, if you change range calibration data interpolated), this slot loaded on startup and apply to sended to CPU data. After all experiments better clear all calibrations by CONFIG->EXPERT SETTINGS->CLEAR CONFIG. This reset device to default state.
I made this (apply internal calibration on sended to CPU data) as option on next.
-
>PS need rename Rs to Rm, Ls to Lm and Cs to Cm
Right, I wasn't sure if you had used the paper you linked because of this.
> (look like Need use Reff? not Rs, in this case Q = Fs / dF)
According to the paper you linked yes. I used Chris Bowick RF Circuit Design.
>... this slot loaded on startup and apply to sended to CPU data.
Good to know. Normally, I would just leave them calibrations blank and assumed the CPU would just send the raw no matter if I used them or not.
-
Rs = 2*Rl * (1/k - 1)
Reff = 2*Rl + Rs
Q = 2 * pi * Fs * Ls / Rs not remember why, need search (look like Need use Reff? not Rs, in this case Q = Fs / dF)
Looking at my software, I also use Rs for Q. I warn people about my software possibly not being correct. I find a lot of errors in published papers and sometimes it is difficult to determine which are correct. We could both be wrong! This was one reason I tried to procure a standard crystal to perform some sort of sanity test.
-
From another paper, again confirming your calculation. I suspect it's just a mistake in the paper you linked.
-
When looking at my software, I saw that I had names it Serial Freq. WTF is serial? The person who had first asked me about using the NanoVNA to make a crystal filter was planning to use the DISHAL software. I ended up using that software to double check my software (not that it is right).
To try and make it easier for that person to follow along, I used the same name.
-
now i got your point. about Hugen tries to monopolized the market thats the problem, not that he copied your design... but i guess similar happened to outsides countries such as US with China. US businesses have become unsustainable due to competition and low production cost of China, i cant imagine how many businesses in US have to close or scaled down due to this. now the fight has become domestic within China itself ;D how about bring this kind discussion to the NanoVNA 6GHz thread i have no problem with you over there and leave this thread to its original intention ;) and i'm sorry to say you wont be able to stop people from buying what they want. like me for example, i need cross compatibility with NanoVNA-QT i told you, and LiteVNA is the only option for me now and no other else afaik. cheers.
No one put a gun to USA manufacturers and forced them to move to China.
The rest is a claim, repeated a thousand times, by a single person without any evidence.
-
For the few of you who come to EEVBLOG for the tech rather than the politics...
https://www.youtube.com/watch?v=y6iOTEU6Zzo (https://www.youtube.com/watch?v=y6iOTEU6Zzo)
-
V2Plus4 not have CW output mode as i remember.
Output switch for measure reference signal, in this case output off.
You can see this on oscilloscope as output switch on/off
In last V2 firmware added special cw mode, in this case output not switch (can enabled in sweep settings).
LiteVNA also have this mode (auto enabled on user select cw)
About square output, for measure used IF frequency (use mixer for switch F to IF frequency, value depend from device and measure range, anyway IF < 150kHz), and filter IF from harmonics after go to ADC and made DSP.
-
V2Plus4 not have CW output mode as i remember.
Output switch for measure reference signal, in this case output off.
You can see this on oscilloscope as output switch on/off
Yes, you can see it in this video and we have discussed it here a few times.
In last V2 firmware added special cw mode, in this case output not switch (can enabled in sweep settings).
LiteVNA also have this mode (auto enabled on user select cw)
I noticed that and was going to ask you if the firmware you created for the V2+4 also works this way?
About square output, for measure used IF frequency (use mixer for switch F to IF frequency, value depend from device and measure range, anyway IF < 150kHz), and filter IF from harmonics after go to ADC and made DSP.
Yes, I remember the poor performance of the H4 at lower frequencies. When we purchased the LiteVNA, this was my biggest concern. I have not gone back to look at the low frequency performance after installing the firmware you linked above. The original firmware supplied (sadly not archived from what I see and I blew it away) seems to perform well. Actually, overall the firmware for that product has worked well.
After making that video, someone commented about problems with the square wave drive. I wonder if any of the members who have access to a commercial grade VNA have experienced problems when using it due to the square wave drive.
-
Looking at the LiteVNA P1 with my vintage LeCroy 5GHz WaveMaster (w/ SSD that was going to fail after a few weeks and added Ethernet that wasn't going to improve data rates. As I said, lots of misinformation). Lite first set to swept mode, then to CW. Finally, setting the VNA to 500MHz and looking at the edges.
-
Showing the V2Plus4 set to 500MHz CW.
-
Sorry. In last code i add power change option in cw mode, and made typo - apply power option for max/adf synthenizer for si5351. I found and fix it later.
I work on use calibration standart coefficients on LiteVNA calibration. This can improve measure quality if use known standarts.
Main problem, how made this calculation more simple for allow real time calculations on device (need calculate 3 complex variables for calibrations, and use additional 3 measured data in huge size formulas).
-
Is the new version released on the official site?
If you find a good book on calibration, let me know. Outside of learning how little I know, I haven't made much progress.
I blew the dust off of my old 7200.
-
I work on use calibration standart coefficients on LiteVNA calibration. This can improve measure quality if use known standarts.
Main problem, how made this calculation more simple for allow real time calculations on device (need calculate 3 complex variables for calibrations, and use additional 3 measured data in huge size formulas).
Even if the known S parameters of the calibration standards are not specified directly, but in parametric form, isn't it still possible to pre-calculate the 12 (?) error terms for each frequency point, and apply the pre-calculated error terms as usual to the measurements? Then only the pre-calculation of the error terms is affected by the higher computational complexity (whenever start freqency, stop freqeuncy, or #ponts are changed).
Edit: Or do you also have a memory shortage, so that you can't afford a pre-calculated table?
[ I remember, when I compiled the NanoVNA V2 firmware from github for a V2.2 device, there was not too much RAM free. I have not yet tried your firmware variant. I think I need to try when I find some free time. ]
-
If you find a good book on calibration, let me know. Outside of learning how little I know, I haven't made much progress.
A helpful resource for implementing VNA calibration is IMO scikit-rf. It supports various VNA calibration methods.
This toolkit is written in Python, but it should not be too difficult to transcribe the NumPy stuff to Matlab.
Edit: Sorry, I think I mixed it up -- you are using LabView, not Matlab, right?
Anyway, I guess it should be possible to transcribe the implemented algorithms.
Docs for the calibration module:
https://scikit-rf.readthedocs.io/en/latest/tutorials/Calibration.html
Edit: More details are in the API docs:
https://scikit-rf.readthedocs.io/en/latest/api/calibration/index.html
Git repository:
https://github.com/scikit-rf/scikit-rf
The core of the calibration-related stuff is located in this module:
https://github.com/scikit-rf/scikit-rf/blob/master/skrf/calibration/calibration.py
-
The last book I purchased was not helpful. While Dunsmore's book dedicates a chapter to calibration and error correction, Bonaguide & Jarvis have only a few pages. Both books would make a very good reference and I wish I had them when I was first introduced to a VNA.
-
The last book I purchased was not helpful. While Dunsmore's book dedicates a chapter to calibration and error correction, Bonaguide & Jarvis have only a few pages. Both books would make a very good reference and I wish I had them when I was first introduced to a VNA.
Hi, Joe,
Wish You Happy New Year!
Trying a very basic search with the "Unknown Through Calibration" gives some hits
http://www.microwave.fr/publications/149.pdf (http://www.microwave.fr/publications/149.pdf)
http://coppermountaintech.com/wp-content/uploads/2018/05/Conducting-Calibration-with-the-SOLR-Unknown-Thru-Method.pdf (http://coppermountaintech.com/wp-content/uploads/2018/05/Conducting-Calibration-with-the-SOLR-Unknown-Thru-Method.pdf)
https://m.youtube.com/watch?v=sMYwFdxyF9o (https://m.youtube.com/watch?v=sMYwFdxyF9o)
There's much more, of course
-
Hello Alex. Most of my searches didn't yield very useful information (at least for me). Some of the better papers will talk about the need for different approaches depending on the hardware. Dunsmore's book glosses over this and you may find equations during your searches not covered. You can try terms like "VNA delta match" to narrow your search. The best resource I have found have been patents. Sadly, what is obvious to one skilled in the art is not so obvious to me.
I've contacted others who have wrtiten their own software but have not ran across anyone who has implemented anything beyond the 12-term model on something like the NanoVNA.
The only reason I started to look into it was OWO had mentioned the V3 supporting it along with other advanced calibration techniques. This made me wonder if it could even be done with the hardware and if so, would there be any advantage. My old PNA supports unknown thru and TRL but it's a four receiver system. While I use them, I know very little about how they work. Even if these were well documented, the Nano's hardware isn't the same.
https://nanorfe.com/nanovna-v3.html
Its been an interesting rabbit hole.
-
My understanding is that "unknown thru" is based on the 8-term error model for a full two-port VNA. So I have doubts, that it can be used with the 1.5 port NanoVNA (whose 2nd port cannot transmit and has no directional coupler). OTOH, the V3 was initially announced as full two-port VNA, in this case "unknwon thru" were an option. But in the meantime the actual features of the V3 seem to be not so clear any more.
With the NanoVNA as is, your options for S21 calibration are basically response normalization (suffers from both, source and load mismatch - both are not corrected), or Enhanced Response Calibration (which corrects source mismatch, but still cannot correct load mismatch). Enhanced Response Calibration is obviously supported by the NanoVNA V2 firmware and can be enabled in the menu.
I'm unsure whether Two Port One Path Calibration can be used with the NanoVNA. This calibration model enables full S11,S21,S12,S22 measurement and full error correction with a 1.5 port 3-receiver VNA, but the DUT needs to be flipped and measured twice. Therefore the DUT must have either two male, or two female connectors of the same type, in order that you can still insert the flipped DUT w/o additional adapters. My doubts regarding usability of this model is the switched receiver of the NanoVNA V2 (it does not have 3 receivers).
-
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3853994/#msg3853994 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3853994/#msg3853994)
-
My understanding is that "unknown thru" is based on the 8-term error model for a full two-port VNA. So I have doubts, that it can be used with the 1.5 port NanoVNA (whose 2nd port cannot transmit and has no directional coupler).
For true SOLR (aka "unknown thru") you do not only need a fully bidirectional two-port test set that can measure the full S-matrix (i.e. S11, S21, S12, S22), but actually a four receiver VNA.
There is no way around these hardware requirements. However, on a three receiver VNA, you can do a full two-port calibration (i.e. by a SOLT cal), and then determine certain parameters from the calibration data, the so-called switch terms. With the assumption that the switch terms are constant (this is usually a very good assumption), you can use them subsequently to do SOLR calibrations, even on a three receiver VNA. If I'm not mistaken this approach essentially is what Keysight calls "delta match method" which is available on their older or lower cost VNAs without four receivers.
A four receiver VNA has the ability to measure the switch terms directly. It does not need to assume that they are constant, and does not need to measure additional cal standards in a previous step to determine them.
Some more background about this: As you correctly say, SOLR is defined in terms of the 8-term error model. This model consists of two so-called error boxes at each port that correct for all imperfections. That means that it is assumed that the impedance of the physical VNA port does not change if it is switched from source to load configuration (the error boxes are constant and thus are unaware of the current port mode). The quantification of this model can be done in terms of measuring short, open, and load at each port, together with an unknown reciprocal thru. All that remains is a sign ambiguity, which essentially is due to the phase ambiguity in the thru of unknown length. Also, this step does not need a four receiver VNA. All of this is laid out in the original paper by Ferrero and Pisani which introduced the method ("Two-port network analyzer calibration using an unknown 'thru'", IEEE Microwave and Guided Wave Letters Volume 2, Issue 12, 1992).
To get rid of the assumption of a constant port match, commercial VNAs then transform the 8-term model to the conventional 12-term model (which is usually only a 10-term model by neglecting the crosstalk error terms which also do not exist in the 8-term model). The 12-term model has separate source and load port match errors for each direction. This of course, due to the larger number of unknowns, requires additional measurements: the switch terms.
The switch terms are defined as the ratio of outgoing wave and the incident wave at one port, while the other port is configured as a source. Notice that a three receiver VNA has no way of measuring them. On four receiver VNAs they are usually measured along with the thru.
An implementation of SOLR will therefore consist of several steps: First quantify the 8-term error model by measuring SOL at each port as well as the unknown reciprocal thru. Then measure the switch terms (or recall them from memory if unable to measure them on a three receiver unit). Finally convert everything to the 12-term error model. Then the DUT can then be corrected in the usual way. Unfortunately this requires a bit more implementation effort than just using a single formula.
The switch terms only depend on the test set and should not vary much over time, at least in commercial lab grade VNAs. I have checked that with my VNA, they seem to be indeed very stable.
-
The last book I purchased was not helpful. While Dunsmore's book dedicates a chapter to calibration and error correction, Bonaguide & Jarvis have only a few pages. Both books would make a very good reference and I wish I had them when I was first introduced to a VNA.
As I already said in a private mail, I have it on my to do list to check Michael Hiebel's book ("Fundamentals of Vector Network Analysis", the German version from 2006 is titled "Grundlagen der vektoriellen Netzwerkanalyse").
Unfortunately, the most comprehensive and mathematically complete exposition on VNA calibration in textbook form that I know is in "Grundlagen der Hochfrequenz-Messtechnik" by Burkhard Schiek, and there is only the German original, with no English translation.
-
Hope you had a nice trip. Outside of looking at that book I mention, I have not done anymore with the project. I am hoping that walking away from it for a while will help. You were correct about that particular book.
-
The last book I purchased was not helpful. While Dunsmore's book dedicates a chapter to calibration and error correction, Bonaguide & Jarvis have only a few pages. Both books would make a very good reference and I wish I had them when I was first introduced to a VNA.
As I already said in a private mail, I have it on my to do list to check Michael Hiebel's book ("Fundamentals of Vector Network Analysis", the German version from 2006 is titled "Grundlagen der vektoriellen Netzwerkanalyse").
This book does not cover the Unknown Thru method in details, as well.
Only basic information is provided
-
The last book I purchased was not helpful. While Dunsmore's book dedicates a chapter to calibration and error correction, Bonaguide & Jarvis have only a few pages. Both books would make a very good reference and I wish I had them when I was first introduced to a VNA.
As I already said in a private mail, I have it on my to do list to check Michael Hiebel's book ("Fundamentals of Vector Network Analysis", the German version from 2006 is titled "Grundlagen der vektoriellen Netzwerkanalyse").
This book does not cover the Unknown Thru method in details, as well.
Only basic information is provided
I suspect rf-messkopf was spot on when they wrote me about there being a market gap and it only being important to a handful of vendors and researchers. I certainly fall into that category of just using the functions implemented in the VNA firmware. The only tiny difference is that from starting out with such an old relic as the 8754A, there was no firmware which forced me to learn some of the basics.
For the square wave drive, from W2AEW's comment "They do appear more and more sinusoidal above 1GHz. ", using my old 1989, 68000 VME chassis LeCroy 7200, I dug out a 720k floppy and sneaker net the data to the PC using CERNs software. I wasn't sure if my USB floppy drive would read it, but no problem. Shown is the output from the LiteVNA at 1.2GHz. Not bad for a 32 year old scope. :-DD
https://service-hpglview.web.cern.ch/service-hpglview/
-
...
To get rid of the assumption of a constant port match, commercial VNAs then transform the 8-term model to the conventional 12-term model (which is usually only a 10-term model by neglecting the crosstalk error terms which also do not exist in the 8-term model). The 12-term model has separate source and load port match errors for each direction. This of course, due to the larger number of unknowns, requires additional measurements: the switch terms.
The switch terms are defined as the ratio of outgoing wave and the incident wave at one port, while the other port is configured as a source. Notice that a three receiver VNA has no way of measuring them. On four receiver VNAs they are usually measured along with the thru.
...
The switch terms only depend on the test set and should not vary much over time, at least in commercial lab grade VNAs. I have checked that with my VNA, they seem to be indeed very stable.
I have included a snip from Agilent's patent 7,019,536 B1 which talks about the switch errors.
To start, I have attached the transfer relay to the LiteVNA. I then calibrated the unit over a range of 1-300MHz using the ideal standards and 12-term model. After which I inserted the T-check and saved the Touchstone and calibration files. Next I made a simple wrapper for the LabView files I sent you allowing me to run some basic checks without the VNA. I have included a the snip of the switch error terms.
Also shown is a plot of the two switch terms.
Again, I am totally clueless and there could be a lot of errors in what I have shown and the path I took for this first step.
****
It may not be clear but the reason for collecting the data for the T-Check is I expect to be able to switch from the 12-term error model to the unknown thru and get roughly the same result with it inserted.
-
Two different Agilent patents vs Dunsmore's book.
-
nanoVNA-QT use libxavna
inside i found:
if(matchedThru)
return "Unknown thru calibration using 3 fully known one port standards"
" and a reciprocal thru standard. Thru standard must have "
"an electrical delay between -90 and 90 degrees, should be "
"well matched (or as short as possible), and have less than 10dB of loss. "
"Matching error of the two instrument ports is fully removed.";
So you can try research used Unknown thru calibration
https://github.com/xaxaxa-dev/vna/blob/master/libxavna/calibration.C
-
Using my test code, I tried to isolate where my problem/s are. I suspect at least one of my problems is this one sentence from that patent. If I use the ETF/R from the 12-term model, I get something close to what I would expect.
Not being skilled in the art or understanding it, coupled with errors in the various papers.... It's not all between the keyboard and chair.
-
Two different Agilent patents vs Dunsmore's book.
I've only been briefly looking again at Section 3.2.3 in Dunsmore's book, but the notation there seems to be consistent, and I cannot spot an obvious error in the equations.
The E00, E01, E12, E11 are the error terms of the error box at port 1 of the 8-term error model, and E22,, E23, E32, E33 of the error box at port 2, see Figure 3.3. When you want to convert from the 8-term model to the 10/12-term model, the load match errors are
\[
\begin{align*}
ELR&=E_{11}+\frac{E_{10}E_{01}\Gamma_R}{1-E_{00}\Gamma_R}=E_{11}+\frac{ERF\cdot\Gamma_R}{1-EDF\cdot\Gamma_R},\\
ELF&=E_{22}+\frac{E_{32}E_{23}\Gamma_F}{1-E_{33}\Gamma_F}=E_{22}+\frac{ERR\cdot\Gamma_F}{1-EDR\cdot\Gamma_F}.
\end{align*}
\]
That is simply equations (3.8 ) together with equation (3.11) and (3.12). So it is all there in Section (3.2.3) to convert between the 8-term and the 10/12-term model. Also, the conversion from the 10/12-term model to the 8-term model is spelled out explicitly, see equations (3.13) to (3.16).
The only notational glitch I see in that section is that Dunsmore switches between, e.g., \$E_{LF}\$ and \$ELF\$, etc., in equations (3.14) to (3.16).
Edit: I should have pointed out that \$E_{11}\$ of the 8-term error model actually is equal to \$ESF\$ of the 10/12-term model. But that is a result, not just a notational oversight. Similarly, \$E_{22}=ESR\$. See equations (3.8 ).
-
Attached are plots of the two switch terms of my VNA. Directly measured, and not calculated from the 12-term model after a full two-port calibration.
No idea what they would look like on a nanoVNA or similar kit.
-
Perhaps this Agilent paper can corroborate the Equations? Paper also details a 16-term correction. Is that a useful improvement here?
-
Two different Agilent patents vs Dunsmore's book.
I've only been briefly looking again at Section 3.2.3 in Dunsmore's book, but the notation there seems to be consistent, and I cannot spot an obvious error in the equations.
The E00, E01, E12, E11 are the error terms of the error box at port 1 of the 8-term error model, and E22,, E23, E32, E33 of the error box at port 2, see Figure 3.3. When you want to convert from the 8-term model to the 10/12-term model, the load match errors are
\[
\begin{align*}
ELR&=E_{11}+\frac{E_{10}E_{01}\Gamma_R}{1-E_{00}\Gamma_R}=E_{11}+\frac{ERF\cdot\Gamma_R}{1-EDF\cdot\Gamma_R},\\
ELF&=E_{22}+\frac{E_{32}E_{23}\Gamma_F}{1-E_{33}\Gamma_F}=E_{22}+\frac{ERR\cdot\Gamma_F}{1-EDR\cdot\Gamma_F}.
\end{align*}
\]
That is simply equations (3.8 ) together with equation (3.11) and (3.12). So it is all there in Section (3.2.3) to convert between the 8-term and the 10/12-term model. Also, the conversion from the 10/12-term model to the 8-term model is spelled out explicitly, see equations (3.13) to (3.16).
The only notational glitch I see in that section is that Dunsmore switches between, e.g., \$E_{LF}\$ and \$ELF\$, etc., in equations (3.14) to (3.16).
Edit: I should have pointed out that \$E_{11}\$ of the 8-term error model actually is equal to \$ESF\$ of the 10/12-term model. But that is a result, not just a notational oversight. Similarly, \$E_{22}=ESR\$. See equations (3.8 ).
I suspect the sprinkling of dots is an oversight but the use of terms changes for each revision. I tend to agree that Agilent had at least two patents that have errors.
Maybe today I can figure out some of the art not covered by the book or the patents....
***
Actually, looking at the page you sent, your equation 3.31 is 3.36 from my copy (second edition).
-
Yes with the new firmware Dislord has improved a lot the LiteVNA, I hope John resolve this important equation for the calibration on V3 software.
If test the new FW the noise is reduced successfully in the HI part of the frequency range.
-
Sorry but I've had no luck getting the unknown thru to work. I've thought about writing out the steps I took in layman's terms but based on the lack of responses, I doubt it would be helpful. I've reviewed the patents and code with a few friends but it's the blind leading the blind. The attached shows the latest software used to exorcise the calibration algorithms. The software imports the calibration and uncalibrated touchstone files. We can then run them through the 12-term or the unknown thru and compare the results.
I have not done any more with the Lite's new firmware as I wasn't sure where Dislord was storing it. Now that we know that it defaults to a average where the V2Plus4 does not, it explains why it is slower and the noise may look better than what it is. If you wanted to compare the two, you would need to consider these differences. I also never figured out where the official archive was located. So if I wanted to reinstall the firmware that was shipped with the unit, today, I can't.
-
Last official soft here (contain last official soft and fw):
https://zeenko.tech/litevna
My test blog on:
https://groups.io/g/nanovna-beta-test/topics
last week i also work under calibrations. Add calibration standard support (for OPEN C0,C1,C2,C3, delay, for SHORT L0,L1,L2,L3, delay, for LOAD Z0, L and C, delay, for THRU delay), not added only offset loss (due to difficult calculation for device, need use sqrt and lot of calculations) i think this not critical. I good optimize calculation and now all work in realtime.
Interesting know how you calibrate thru (i add ISOLN measure for correction, this give more good results)
Here my 70dB measure in Lite to 6.4GHz after changed calibtration alghoritm (look not bad i think, measure ~linear)
Also now i can see difference 90 (red) and 100dB (blue) attenuators on measure to 3GHz
Added work on harmonic, allow see to ~8-9GHz (yes dynamic on 8GHz not good, but possible see something)
One user test hi freq filters (see attach)
-
Last official soft here:
https://zeenko.tech/litevna
You already provided that link. I was asking about where the archive (older releases) and the code you are working on (pre-release) are stored. The official release has no documentation to tell users what has changed. When you suggest you have corrected a problem, I would have no way to know if it was released or not.
***
My test blog on:
https://groups.io/g/nanovna-beta-test/topics
Thanks for adding that link.
-
Last official soft here:
https://zeenko.tech/litevna (https://zeenko.tech/litevna)
still using peculiar BMP format.. i still read BMz and BGR tag in hex editor... i've provided standard format if its compatible to you in that thread... i'll be happy if you can still make it compatible to me, but i understand its not a compulsion to fulfill my request, thanks to you anyway. https://www.eevblog.com/forum/testgear/hugen-litevna-64-6-3ghz/msg3928667/#msg3928667 (https://www.eevblog.com/forum/testgear/hugen-litevna-64-6-3ghz/msg3928667/#msg3928667)
-
This test FW works well on PC software (the averaging slow the process but work)
Dislord test blog on:
https://groups.io/g/nanovna-beta-test/topics
-
This test FW works well on PC software (the averaging slow the process but work)
Dislord test blog on:
https://groups.io/g/nanovna-beta-test/topics
It appears they kept the list private for some reason. I'll pass. Hopefully they will improve the official release area to inform customers of the changes.
-
Hello Jhon, Dislord sends you the list of addresses you can join to the beta tester, seam to me one person with your experience is beneficial for all.
Best regards.
Francesco.
-
My changelog for NanoVNA code.
LiteVNA use some code as H / H4 (not depended from hardware) after v1.0.69
Last v1.2 not finished (all work under calibrations) - so no change log yet
Also my github contain all changes for H/H4 (i also use this code for build fw for V2 / V2Plus / V2Plus4 / LiteVNA)
https://github.com/DiSlord/NanoVNA-D
PS thanks HA3HZ
-
Hello Jhon, Dislord sends you the list of addresses you can join to the beta tester, seam to me one person with your experience is beneficial for all.
Best regards.
Francesco.
I never wrote a regression test to support this protocol. Unlike the firmware supplied with my original NanoVNA, the firmware for the V2Plus4 was stable enough to use from the start.
Because I use the PC to control the VNAs, I have little use for the majority of the features being added to the firmware. I don't have a need for the display, buttons, switches and CF card. As long as the firmware is stable and able to send raw data, that's really about all I need. I view any changes that break the backward compatibility with the V2Plus4 a detriment. Today the Lite is slower than the V2Plus4 are requires I increase my timeouts. This may have been from the added averaging that is enable by default. Turning off the average may increases the data rate but I am not sure if that causes other problems where a user may be expecting the V2Plus4's sample rate. Certainly none of this is a problem for the antenna analyzer group.
If I ever sort out my calibration problems, I will download the latest firmware for the Lite and test it with my software before I make a release.
-
Thank you for the explication. :-+
-
I attempted to carve out a simple bandpass stub filter with a center freq of 6.4GHz just to see if the Lite would show anything reasonable. Shown without any calibration or normalization. Looks almost too good.
-
On the V.3, there is the possibility of averaging? I see it on the screenshot. I use the Lite-VNA with PC, my interest is to get maximum function on the computer, portability is not in my interest. The main interest characterizes filters, stub, and passive components.
I get some line Stretcher from Hirose I like to learn to use I don't find a lot of information on the application, they sed can use for impedance adapter, phase shift etc. but not practical examples of application.
-
I mentioned the average feature here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3895409/#msg3895409 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3895409/#msg3895409)
Asking a practical use for a phase trimmer may be like asking a practical use for a resistor or any other component. I did show one in a recent video:
https://youtu.be/dI2LjW_joXA?t=41 (https://youtu.be/dI2LjW_joXA?t=41)
Here I am using one as part of my jitter measurements:
https://www.youtube.com/watch?v=4rJcEVj8OYo (https://www.youtube.com/watch?v=4rJcEVj8OYo)
-
Another phase trimmer in use.
https://youtu.be/XaYBpPCo1qk?list=PLZSS2ajxhiQD2gftdurGQoyGpUM_HobNI&t=4247
-
Wanted to get an idea how the V2+4 filter compares with the Lites. Using the same narrow band setup on both VNAs. Changing the Lite's averages from 1,2 & 3.
-
Your conclusion is? :)
-
LiteVNA copy V2Plus4?
-
Your conclusion is? :)
Phase trimmers have a use and VNAs are fun.
-
Is good I got 4 line stretchers from Hirose and one 21cm Airline the airline is calibrated HP/Agilent 11566A AIR LINE 10 CM. The Airlane is god for the TDR test?
I need to learn to use with the VNA the line stretchers.
The Lite-VNA work flawlessly, Dislord make good work to put a lot for use portable but I use the lite only with PC.
-
There was that person posting about using 18 data points to increase their TDR edge rates. They were also using a metrology grade Beatty standard that was 10cm. I really have no idea what their or your goals are for buying them.
For the phase trimmer, I am not sure what you are trying to learn. Imagine a section of coax that you can adjust the length. As you do, the phase changes. Are you expecting some sort of magic? You may want to post what your thoughts.
-
I found this PDF for Unknown THRU (also known as SOLR) calibration
-
Wanted to get an idea how the V2+4 filter compares with the Lites. Using the same narrow band setup on both VNAs. Changing the Lite's averages from 1,2 & 3.
At least with the original NanoVNA V2 firmware (https://github.com/nanovna-v2/NanoVNA2-firmware), the exact shape near the center is not so important, since the IF freqency resulting from mixing stimulus with LO always hits the peak at the center of the filter exactly (+/- phase noise) once the PLLs are locked, due to the chosen frequency plan 1). An important property of the filter 2) are however the zeros at fcenter +/- N * fIF, where N is an integer >= 1, in order to cancel IF harmonics completely, which emerge as mixing products of the the (square wave) harmonics of stimulus and LO. These zeros are therefore important in order to deal with the square wave drive.
1) Stimulus, LO, and ADC clock are derived from the same oscillator and are therefore frequency locked to each other. Stimulus and LO frequency are always integral multiples of the minimum frequency step, IF frequency is an integral multiple of the minimum frequency step, too, and ADC clock is an integral multiple of the IF frequency. Since the ADC clock is frequency locked, too, and an integral multiple of the IF frequency, the IF frequency can't miss the center of the digital filter once the PLLs are locked.
2) The IF filter is not a filter in the traditional sense, but the frequency response is eventually an implied property of the (digital) synchronous detector (mathematically the detector is equivalent to a windowed DFT, but calculated only for a single frequency bin). In addition to the synchronous detector, there is just an analog lowpass pre-filter between mixer and ADC, obviously acting as anti-aliasing filter.
Vector averaging of multiple acquisitions inevitably changes the effective frequency response of the detector, since the effective window (over which the DFT is accumulated) becomes a repetition of the primary window function then (possibly even with zero-valued gaps between the repetitions if there happen to be time gaps between the acquisitions which are averaged). Your screenshot did nicely visualize the change of the frequency response :). The averaging strategy of the Nano and the Lite obviously deviate from each other. The peak at the center and the zeros at fcenter +/- N * fIF (which are the properties of importance) are not affected by averaging and still retained, though.
-
>Vector averaging of multiple acquisitions
Lite not use vector average. It continue put to DFT bin xN periods (example for AVGx1 use 30 IF periods, for x2 used 60 and so on). Value named as average - different freq range use different IF, and as result have different RBW for some periods.
Lite use int64 for collect measure (V2Plus4 use int32 and if use big avg can overflow, by this reason i limit max AVG count to 20 in my fw for V2Plus4, original fw use vector average and not have this limit)
-
Lite not use vector average. It continue put to DFT bin xN periods (example for AVGx1 use 30 IF periods, for x2 used 60 and so on). Value named as average - different freq range use different IF, and as result have different RBW for some periods.
My feeling (according to the screenshot posted by Joe) is also that the Lite uses a rectangular window, and not a specific window function (as the original NanoVNA V2 firmware does), is this correct?
-
Use gaussian window (as do it original fw on V2, V2Plus4 sources closed and i not have any information)
But for faster calculation/small code, gaussian window apply on sin/cos table (table size 2 IF period) for x1 avg used 15x2 periods. So if set span more you can see modulation from multiplie windows.
I have plans rewrite this part.
-
V2Plus4 sources closed and i not have any information
Is the V2plus4 firmware source not included here (https://github.com/nanovna-v2/NanoVNA2-firmware) (i.e. mostly common code with the other V2 models)?
-
>Is the V2plus4 firmware source not included here (i.e. mostly common code with the other V2 models)?
Yes V2Plus and V2Plus4 init and measure code hided in bootloader part. This github contain only V2 sources. But you can build from it V2Plus and V2Plus4 fw, bootloader on startup change interrupt table and do all work for measure.
-
I found this PDF for Unknown THRU (also known as SOLR) calibration
This link had been already posted here
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3911030/#msg3911030 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3911030/#msg3911030)
There exists another textbook, which covers calibration in brief within a dedicated chapter, written by the author of the method, A. Ferrero:
Cambridge isbn 9781107036413.
But once again, very little info is provided from the practical point of view.
-
I doubt there are too many papers on the internet I have not looked at by now. Google is pretty good for rooting out the sources. I tried to contact one of the persons involved with a few of the patents but had no luck. It's possible they are no longer alive. I also ran a few more experiments but the results like always, were less than positive and not worth posting.
My personal ignorance on the subject and lack of education
Lack of material to learn from
Low cost VNAs may not be suited for it (other error sources dominate and nothing/little to gain)
Publications have errors which can waste time
Publications seldom consider the hardware available and look it the problem from a generic view
Publications like to mix terminology which aids in clouding the topic
-
nanoVNA-QT use libxavna
inside i found:
if(matchedThru)
return "Unknown thru calibration using 3 fully known one port standards"
" and a reciprocal thru standard. Thru standard must-have "
"an electrical delay between -90 and 90 degrees, should be "
"well-matched (or as short as possible), and have less than 10dB of loss. "
"Matching error of the two instrument ports is fully removed.";
So you can try research using Unknown thru calibration
https://github.com/xaxaxa-dev/vna/blob/master/libxavna/calibration.C
This Unknown thru calibration doesn't work?
If work there is a need to reinvent the wheel?
There is some problem with originality?
This came from my personal ignorance on the subject.
-
...
nanoVNA-QT use libxavna
...
This Unknown thru calibration doesn't work?
If work there is a need to reinvent the wheel?
There is some problem with originality?
This came from my personal ignorance on the subject.
I have not tried the QT software since I attempted to use it to demo the VNA. It sounds like you have it working so there is nothing that prevents you from conducting some experiments to demonstrate the unknown thru. Looking forward to seeing your findings.
I did notice they have a new firmware release for the Lite but I really have no idea what changed. Maybe download that along with their latest QT and use that for your testing.
https://zeenko.tech/litevna?spm=a2g0o.detail.1000023.1.b5a97ff8tHYEOr
-
Hello, my questions are rhetoric I'm not sufficiently educated on software, I stated before they came from my ignorance on the subject.
This is the Lite-VNA screen shoot.
-
I would guess there is a manual for the QT software and you are able to read. You should be able to setup the unknown thru method and try it. Looking at the screen shot you provided, I would just select the calibration type. Total guess on my part but I would expect that pulldown? allows you to select it. I'm not sure how it will work with your transfer relay but I assume they support something. I would start by reading the manual for it. Post your findings here. I'm interested in seeing what you come up with.
-
Changes for LiteVNA in last fw:
I add calibration standard correction (allow input all OPEN/SHORT/LOAD/THRU corrections L/C/delay/Z ..) for calibration
Fixed work in CW mode (correct apply power settings)
Always send not calibrated data to CPU (calibrated only if ask)
Added RAW sample show (for debug and ~SA mode)
Enable Harmonic mode, now Lite can work up to ~9G (yes after 6.3G have limits, but usable)
Max points now 1024 (default 1001 for better steps)
For THRU calibration also used ISOLN measure (allow get more linear results)
Allow save 4 trace image
More traces formats
-
Always send not calibrated data to CPU (calibrated only if ask)
:-+
Enable Harmonic mode, now Lite can work up to ~9G (yes after 6.3G have limits, but usable)
wow! am i listening right? 9GHz? can you ask Hugen or yourself update the NanoVNA-QT to limit up to 10GHz? i asked Zeenko that but Hugen only updated to 6.3GHz limit. i believe its just one line constant edit in QT's code. i dont have Linux to compile. i think xavna's NanoVNA-QT is the most mathematically complete app among all other PC app options. please?
Max points now 1024 (default 1001 for better steps)
can you increase again next time a little bit to 1601 points? because HP and i believe de facto standard by pro grade VNA is saving 1601 points. i dont mind if its slow, i think the LiteVNA is quick enough already if plotting 1001 points.
thanks for your effort on this.
-
Changes for LiteVNA in last fw:
Thanks. You may want to consider adding a simple text file like this to the releases.
I add calibration standard correction (allow input all OPEN/SHORT/LOAD/THRU corrections L/C/delay/Z ..) for calibration
Fixed work in CW mode (correct apply power settings)
Always send not calibrated data to CPU (calibrated only if ask)
I doubt I will do anything to test the calibration but will certainly try the power settings and uncal data.
Added RAW sample show (for debug and ~SA mode)
Enable Harmonic mode, now Lite can work up to ~9G (yes after 6.3G have limits, but usable)
I've been reading some of the emails about this in the public forums. Last one, someone was attempting to change the hardware with additional shielding. I suspect with me running it from the USB, it will be worse. Look forward to trying this out, although I don't have a way to verify results. I'll try that home made bandpass filter.
Max points now 1024 (default 1001 for better steps)
For THRU calibration also used ISOLN measure (allow get more linear results)
Allow save 4 trace image
More traces formats
Max points and defaults for me isn't too much of a problem. The leakage terms made a significant improvement with the V2+4 above 3GHz.
-
Hello, my questions are rhetoric I'm not sufficiently educated on software, I stated before they came from my ignorance on the subject.
This is the Lite-VNA screen shoot.
My simple question is direct not to the Nano-QT software but to the original xaVNA-QT software this whose used for one VNA project about 5 years ago this software claim the Unknown thru calibration using 3 fully known one port standards and a reciprocal thru standard. Thru standard must have an electrical delay between -90 and 90 degrees, should be well matched (or as short as possible), and have less than 10dB of loss. The matching error of the two instrument ports is fully removed..
https://github.com/xaxaxa-dev/vna
My first question is this calibration system work?
I don't try to teach anything I stated in my message to be ignorant on the subject.
I'm NOT able to read or writing any software.
-
Hello, my questions are rhetoric I'm not sufficiently educated on software, I stated before they came from my ignorance on the subject.
This is the Lite-VNA screen shoot.
My simple question is direct not to the Nano-QT software but to the original xaVNA-QT software this whose used for one VNA project about 5 years ago this software claim the Unknown thru calibration using 3 fully known one port standards and a reciprocal thru standard. Thru standard must have an electrical delay between -90 and 90 degrees, should be well matched (or as short as possible), and have less than 10dB of loss. The matching error of the two instrument ports is fully removed..
https://github.com/xaxaxa-dev/vna
My first question is this calibration system work?
I don't try to teach anything I stated in my message to be ignorant on the subject.
I'm NOT able to read or writing any software.
I tried to do a search but didn't see where it was ever tested, or even implemented. I assume with you asking, you did your own search and found something. From below, it seems the Nano QT was spun off from it, so you should be able to run the unknown through with your lite, assuming it was not stripped out. You may have a hard time finding the old hardware from the kickstart but at least for me, the goal would be to target the Lite (and V2Plus4) anyway.
https://groups.io/g/xaVNA/topics
-
Briefly skimming the source code I cannot see that NanoVNA-QT supports anything else than "SOL (1 port)" and "SOLT (T/R)" calibration, i.e. 1-port and 1.5-port. No full 2-port emulation via DUT flipping. No external relay. The libxavna obviously includes some unknown thru stuff, but this part of the library seems not to be used by the NanoVNA-QT app.
-
Yes, the Nano-QT does not use the unknown thru only the SOL and the SOLT.
The xaVNA software seam to use the unknown thru possibly on the library their some information for it, I'm NOT able to read or write any software.
-
Dislord,
I had no problems with the install. I started by testing the power level settings with both synthesizers in swept and CW modes (4 tests total). This appears to now work as I would expect.
Next I tried loading a very bad cal into memory 0 and rebooted the VNA. Then connected using the PC. I now get the raw data as I would expect.
Next I tried sweeping my home made band pass filter. The Lite was not calibrated for this test. The data seems in the ball park as I would expect but again, I can't verify the results. Just for fun I checked and it seems to lock it at 9.3GHz. I normalized with the supplied cables and ran 7.8GHz HP filter. Yellow is the normalized thru, purple the HP filter and red with the ports terminated. Just a quick sanity test but again, it all seems expected.
I did try to collect some data down at 9kHz. Appears the same.
Looks good. Again, thanks!
-
Without having the old kickstart hardware, it would be difficult for me to say if it works or not then. Of course, anymore I would need you do define "works" as that particular word carries little weight with me anymore. The software guy will tell me
my code built without errors. See, it works!
I would want to see the performance gains before I would suggested it worked.
-
I went over the Lite VNA with a friend today. They are well versed in the world of RF. After showing them the specs and hardware , I spent some time going over my software. They wanted to know how to measure group delay with it. So I took 15 minutes and added it. Then explained the power of LabView. :-DD
Shown looking at the 12MHz lowpass I made for one of the demos.
-
Midwest Microwave 10 & 20dB attenuators using leakage error. I have not tried it running from batteries or that linear supply I made to try and tame the V2Plus4.
-
Using my home made 70mm Beatty standard, 101 data points, SOL with no average (software or firmware).
-
I hope to get the V.3 software with the news feature to test the Lite-VNA whit it, I don't get any substantial difference with the T/R relay on the HP test set with two relays getting good isolation considering the Lite-VNA spec.
The screenshot uses the leakage correction for testing one 50homs load.
Not averaging
-
Good to see another person playing with the Lite. The only features added to 3 are:
*Automatic collection of antenna radiation pattern
*Average sweeps
*Group delay
*Increased timeouts to support the Lite
*Allows setting the Lite's power levels
*Allow larger data sets (more points) to support the Lite in unsegmented sweeps
*Allows setting the Lite's internal average (or what ever Dislord decides to call it in the future)
*Maybe one day, new error models
Most of these changes would have very limited use. For example, measuring radiation patterns requires a fairly expensive motor and would need the user to develop the gear drive. Like smoothing, averaging is not very useful IMO and can mask problems. The timeouts are only a problem when using the Lite at very low frequencies. I was surprised that not one person had asked me about adding group delay but it also tells me that most users would have no use for it. Error correction hasn't shown to have any use yet. The documentation also is lacking but many people seem unable to read anyway so this may be of little concern. Want some entertainment and drama, read the last issue posted on Git. I had no idea that the NanoVNA had anything to do with the spread of the virus until recently.
In a nutshell, there's no benefit to the antenna analyzer group.
Dislord,
What are the default settings for your firmware's average and power levels? Will these be user settable and made sticky so they are saved as part of the calibration? If so, when using USB, will these settings reflect what the user has set of be some other default? Is there a way to query the Lite (using USB) to know what they are set to? I wonder if I need to consider initializing the Lite to some known defaults when connecting to it. If so, maybe store them in the defaults file to allow my software to make them sticky. Curious of your plans.
I suspect there may be a small problem with your average feature. I believe I have seen it not change in some cases but I will need to test it. Is it similar to how the power setting was locked out in CW, where maybe you can't just change it in some modes? If so, can you provide these requirements so I can automate the change. If you are not aware of a problem, I will try and sort the cause and get back with you.
-
Hello, I'm glad you added this feature my plan is to learn to use one VNA, I haven't the money to buy one professional one, on the market there is vintage but the working one hare expensive. The portability for me is not interesting, what is important is to use it with PC all possible VNA features.
The calibration system if there is a possibility to improve in the future.
The philosophy of the mobile phone is to put everything on.
Testing Minicircuit VAT-15+ attenuator very close to specs.
Touchstone file for VAT-15+
-
nanoVNA also have Group delay trace
Lite use inernal AVG setting for send to CPUm but you can always send need value before sweep start. You can read current avg settings by read 0x40 register (or set this valuse if write in it)
Read - need send 0x10 0x40 and read answer byte
Also for power levels, send on sweep start, or read current from register
0x40 - (byte) average
0x41 - (byte) si power
0x42 - (byte) adf power
PS soon i hope increase S11 (and others) dynamic range, i add AGC for all measures (AGC auto gain change, allow select best gain for every measure data). Before AGC have limited functional only in S21 measures (for > 140M)
-
... value before sweep start.
I think that this may be tied to what I saw. I would have been trying to change it after or during. I'll double check it.
I'll go ahead and add the power and average to my defaults file and auto set them when connecting to the VNA. It will be interesting to see how these effect the dynamic range. Are you posting this data in that beta test area? I may need to join up.
-
(quote from joeqsmith)" Most of these changes would have very limited use. For example, measuring radiation patterns requires a fairly expensive motor and would need the user to develop the gear drive. Like smoothing, averaging is not very useful IMO and can mask problems. The timeouts are only a problem when using the Lite at very low frequencies. I was surprised that not one person had asked me about adding group delay but it also tells me that most users would have no use for it. Error correction hasn't shown to have any use yet. The documentation also is lacking but many people seem unable to read anyway so this may be of little concern. Want some entertainment and drama, read the last issue posted on Git. I had no idea that the NanoVNA had anything to do with the spread of the virus until recently."
Online, there is a lack of teaching to use the VNA with your video people learning a different way to use VNA not only "antenna analyzer" if not have request from people is for the lack "knowledge" (this is my case) I thank you for your effort to teach me many think to use the VNA with your video.
Question: Is possible doing a T-Check on a wide range of frequencies from 10Mhz to 6.4 GHz?
-
Question: Is possible doing a T-Check on a wide range of frequencies from 10Mhz to 6.4 GHz?
I suspect what you are asking is if under the best conditions, could the LiteVNA achieve acceptable results over this range. I don't know.
On a more practical side, I think I made a demo showing a home made transfer relay with the original NanoVNA working up to 50MHz. I don't know if I ever demo'ed the OEM relay. Still, it would have been with home made FR4 standards which are not going to be near good enough.
I attempted to make a better T-check standard and ran it on my vintage 4 x receiver PNA. Good cables, properly torqued, home made standards I had characterize against some Agilent standards using Mario's scripts and SOLR correction. About as good as I could do. The performance was poor.
That paper I showed during the demo from RS had an example at 4GHz or so. But that standard was nothing home made. I guess you would need to try it and report back.
-
... value before sweep start.
I think that this may be tied to what I saw. I would have been trying to change it after or during. I'll double check it.
I'll go ahead and add the power and average to my defaults file and auto set them when connecting to the VNA. It will be interesting to see how these effect the dynamic range. Are you posting this data in that beta test area? I may need to join up.
There was a problem with my software. I can change it in all modes as I would expect.
-
Testing Minicircuit VAT-15+ attenuator very close to specs.
Your measurement appears worse than I would have expected. I tried using a more stable set of cables and again torqued everything. Shown with the the leakage term enabled (I gain about 10dB with it) and Midwest Microwave attenuators at 20,30 and 40dB. I would expect your VAT device to be much flatter.
I tried the same settings using a very low cost 20dB attenuator like the ones listed below. Its within 1dB over the range. I would expect you to have similar results.
https://www.amazon.com/Nooelec-SMA-Attenuator-Kit-Line/dp/B07YYMT65T (https://www.amazon.com/Nooelec-SMA-Attenuator-Kit-Line/dp/B07YYMT65T)
-
Question: Is possible doing a T-Check on a wide range of frequencies from 10Mhz to 6.4 GHz?
I suspect what you are asking is if under the best conditions, could the LiteVNA achieve acceptable results over this range. I don't know.
On a more practical side, I think I made a demo showing a home made transfer relay with the original NanoVNA working up to 50MHz. I don't know if I ever demo'ed the OEM relay. Still, it would have been with home made FR4 standards which are not going to be near good enough.
I attempted to make a better T-check standard and ran it on my vintage 4 x receiver PNA. Good cables, properly torqued, home made standards I had characterize against some Agilent standards using Mario's scripts and SOLR correction. About as good as I could do. The performance was poor.
That paper I showed during the demo from RS had an example at 4GHz or so. But that standard was nothing home made. I guess you would need to try it and report back.
From the RS paper:
This parameter should be exactly 1, i.e. 100%, in the ideal case. Any deviation from 100% indicates inaccuracies of the network analyzer. Deviations of up to ±10% are considered as minor (green range). Deviations between 10% and 15% are still acceptable (yellow range) and those more than 15% should not occur in a good vector network analyzer after careful system error calibration (red alert).
V2Plus4 shown with my home made PCB standards and transfer relay. Full 2-port cal was performed and sweeping from 1MHz to 1GHz. The Transco part far exceeds my home made transfer relays. At a GHz, its well within the +/10%. I've used the FR4 standards to about 1.5GHz but that's about their limit.
The home made standards I made for the PNA are coaxial and give fair performance to several GHz but I am using an OEM load that I had sorted. The T-Check is standard resistors and it's just not good enough. At 2GHz, its within 15% but not impressive at all.
-
I have not tried it running from batteries or that linear supply I made to try and tame the V2Plus4.
External linear might help but ferrite loop on stock LiteVNA USBC cable didn't seem to make a big improvment for me.
[attach=1]
-=dave
-
I'm not too surprised. Using the linear supply with the V2+4 had no effect. As soon as I run it off external power, the noise goes up. Someone had recommended going right to the battery pack. This would of course work. Or, in my case, I just turn off the liner supply (basically cut the USB cables power pin only). The Lite was not nearly as bad as the V2+4. Easiest way to check for possible gains it just try it with and without external power using the firmware.
Every time I try to use the firmware I waste time trying to get what I want on the screen. Most of it, I find very easy. For the Lite, I turn off everything but S21. Turning off the traces requires double taps. You can't select what you want to display with each trace. Viewing S21 requires the second trace. There's no autoscale and that reference position seems to be in some alien units. Assuming you set the stop freq to 6.3GHz, you would think you want -50dB or maybe 50dB ref. Of course, that drives the trace off screen. Maybe 0 resets it. Nope. Set the reference to 9. Once you have it all set up the way you want, save the configuration. Surely it saves everything to NVRAM. Power cycle the unit. Oops. All your work was lost. Start over...
I obviously never took the time to learn to use it as I just don't run it this way.
Anyway, once you have it setup. Try plugging in the unit to the PC. Don't connect with the software. Just watch the LCD and see if it changes. The Lite I have, using 10dB/div shows no difference. If I do this with the V2Plus4, the noise goes up a fair amount. OWO claimed the cables but really, it seems they screwed the pooch on the USB interface was all.
-
Yes, the whole VNA base FW it all started from is a bit of a UX disaster, but then so are many commercial VNAs (it’s just that you’ve grown used to them over the years :) ). DiSlord had made some improvments over the V2P4 atrocity but there’s only so many shades of lipstick that look good on a pig. And that the LiteVNA manual exists only in Chinese makes even learning how this “settings stored in 50 different procedural logic traps that aren’t documented in English” even more frustrating. But unlike you, I no longer have access to equipment that I can occasionally use for this purpose, so learning the parts I need to make it work for me I’m more motivated to endure. The portability of the device is also unparalleled (which, again, is moot for you, so I understand your dismissal of it because a lot of these idiosyncrasies).
Regardless, we persevere :)
Btw- as you’ve undoubtedly noticed, there’s 2 main settings groups under the hood: the “config” and the cal data stored in cal slot 0. Unfortunately it’s still not fully known to me all of the various ways data is saved (and more importantly jettisoned) from the config nvram but I’ve learned the few parts that seem safe to touch in order to keep the “config” from changing over a power cycle. However, even now I occasionally stumble into doing something only to find the config changed (and as you’ve noticed, only after frustratingly finding out only because of getting impossible results after a lengthy setup process, then having to start fully from scratch [insert table flip here]). Yes, it’s all a UX hot mess nuclear disaster.
For most of these community based “designed by engineer” projects I just rely on the benefit of reading the code when something doesn’t make sense, but that’s not an option here. Regardless the fact that it is available for such a low cost is it’s only saving grace that makes hitting ourselves upside the head with a hammer getting it to at least work for the few things we need it for an overall net positive.
-=dave
-
With the early firmware, less options = easier to setup but it was clear with fragments on the display and other oddities it was going to need a better UI. Of course, I was never able to get the software that was supplied to work well enough to be used. The solution seemed obvious. With the software no longer an issue and limiting the the requirements for the firmware, it gets down to the hardware which has it's own limitations (square wave drive....). I've shown in the right hands they can throw up some pretty decent numbers. I've never had a problem saving/using the internal calibration, until the Lite was changed to send corrected data. The latest firmware seems to work well. I've put a few hours on the Lite now and not had any major problems.
All of them I have looked at have been under $200. At that price point I'm not expecting much. I continue to be impressed with what has been achieved.
-
Yes, the whole VNA base FW it all started from is a bit of a UX disaster, but then so are many commercial VNAs (it’s just that you’ve grown used to them over the years :) ). DiSlord had made some improvments over the V2P4 atrocity but there’s only so many shades of lipstick that look good on a pig. And that the LiteVNA manual exists only in Chinese makes even learning how this “settings stored in 50 different procedural logic traps that aren’t an overall net positive.
-=dave
English version of Lite,s manual here,:
https://static.eleshop.nl/mage/media/downloads/LiteVNA_User-Guide.pdf
-
Yes, the whole VNA base FW it all started from is a bit of a UX disaster, but then so are many commercial VNAs (it’s just that you’ve grown used to them over the years :) ). DiSlord had made some improvments over the V2P4 atrocity but there’s only so many shades of lipstick that look good on a pig. And that the LiteVNA manual exists only in Chinese makes even learning how this “settings stored in 50 different procedural logic traps that aren’t an overall net positive.
-=dave
English version of Lite,s manual here,:
https://static.eleshop.nl/mage/media/downloads/LiteVNA_User-Guide.pdf
4. Calibration status
Displays the saved slot number of the calibration being used and the error correction applied.
C0 C1...: Each indicates that the corresponding calibration data is loaded.
5. Reference position
Indicates the reference position of the corresponding trace. You can change the position with:
DISPLAY →SCALE →REFERENCE POSITION.
6. Marker status
Displays the selected marker points and the frequency of the marker p...
Notice, not even a comment about the alien units used.
7 Device settings
The CONFIG menu contains general settings for the device:
Saving device settings
Select CONFIG →SAVE to save general instrument settings. General device settings are data
that includes the following information:
• Touch screen calibration information
• Brightness
The CONFIG →SAVE command does not apply to calibration setting
Maybe it saves the trace settings, maybe it doesn't. This manual leaves everything up to your imagination but I'm not Willy Wonka or playing with everlasting gobstoppers.
***
Thinking about the poor results with the VAT attenuator and T-check. Don't underestimate the importance the cables play. You can't magically fix a bad cable with calibration and the higher up you go the more critical they become. Same for proper torque.
I played a bit with the cables supplied with the V2Plus4. They were fairly stable and flexible. I used them during my review of it. I didn't try the ones that came with my Lite. The ones that came with my original Nano I never even bothered with. I have used this type of coax for the majority of what I have shown.
-
... the alien units used.
IIRC, in the NanoVNA V2 firmware there was at least one parameter whose unit were screen divisions.
Don't remember which one, but could have been the reference level (eventually it is just a vertical offset for the trace).
EDIT: I.e. at say 10dB/div, three units means that the origin is shifted by of 30dB then (or at 20 Ohm/div, three units mean 60 Ohm).
I also don't remember whether the origin was at the top or bottom of the screen when the offset is 0.
-
IIRC, in the NanoVNA V2 firmware there was at least one parameter whose unit were screen divisions.
Don't remember which one, but could have been the reference level (eventually it is just a vertical offset for the trace).
Even yourself seem unsure and it sounds like you use it. That's not good. Once it goes off screen you can guess how many alien units to try to get it to display something again. There's no undo, autoscale or even a full range button. In my example, I selected a different trace function, then re-selected S21 log to start over and guess some more.
-
Reference = N ean shift trace 0 position to to N*Scale from bottom screen, yes not good :)
you can change reference / scale position of current selected trace by tap on left side (see attachement)
Scale factor change from middle of screen
-
Reference = N ean shift trace 0 position to to N*Scale from bottom screen, yes not good :)
Thanks, so it is from the bottom of the screen. That's the detail I did not remember anymore (at the moment my NanoVNA is out of reach for a while, so I cannot verify).
Honestly, when I needed to use it for the first time, I was initially confused either.
-
Of course, its not really from the bottom of the screen. Say you enter 1 and things more up 1 unit. Now you enter 1 again. It does not use the new bottom of the screen and more up 1 more unit. It stays the same. You would need to enter 2. So its from some fixed location, not related to the current screen. Where's that in the manual? If you change the scale, better be ready to try and find your new reference. I would have guessed there was a way to change the view with the touchscreen or jog switch but if there is, I couldn't figure it out.
Still, IMO usable. Just not the most intuitive or well documented product I have ever seen.
-
An example of some very poor cables. All I am doing is moving them slightly. With the error you are seeing, I would be checking to make sure that there are no problems with your setup.
-
I tried a some short cables made from RG223 and noted little difference above 8GHz. Its a bit too stiff.
https://www.pasternack.com/flexible-0.216-rg223-50-ohm-coax-cable-pvc-jacket-rg223-u-p.aspx (https://www.pasternack.com/flexible-0.216-rg223-50-ohm-coax-cable-pvc-jacket-rg223-u-p.aspx)
You may have seen me use this cable as well. It's much more flexible than the other double shielded cable I had been using. Using this cable with all the adapters shown and careful calibratio, the cheap 20dB attenuator is still within a half dB sweeping from 1MHz to 6GHz. Once we get into the harmonic mode, things fall apart but still useful.
https://www.pasternack.com/flexible-0.122-rg188-ds-50-ohm-coax-cable-ptfe-jacket-rg188-ds-p.aspx (https://www.pasternack.com/flexible-0.122-rg188-ds-50-ohm-coax-cable-ptfe-jacket-rg188-ds-p.aspx)
*** Note the two short RG223 cables to left
*** Letting the Lite run for a bit with the attenuator, seems stable.
-
The mode of operation on harmonics is not the standard mode of Lite, the 3rd and 5th harmonics are used for measurement, because of which the dynamic range suffers (this mode just optional, but can be useful for example in TDR measures for get better resolution). It is better to calibrate at these frequencies at high AVG values, this will reduce the noise in the calibration data, as well as in the measured data).
In general, you can get ~ 50dB in these modes, but there is a very long calibration
My 40 and 50dB measures
-
Hi, Joe,
Do You use a SMA fixed-torque wrench to attach the cables & DUTs every time or fix them by hand?
-
The mode of operation on harmonics is not the standard mode of Lite, the 3rd and 5th harmonics are used for measurement, because of which the dynamic range suffers (this mode just optional, but can be useful for example in TDR measures for get better resolution).
:-+ if i buy a tool expecting to behave as in spec, and then the seller offers me a broken toy as a gift, i will happily accept that. i bought LiteVNA because 6.3GHz, now you offer 9GHz i will gladly accept that as bonus however broken it is. some application i can use eyeball or PC regression/averaging app to predict dut's behavior beyond 6.3GHz.. if you hear complaint from mourners you can ignore them. if they dont want the gift, they can always set stimulus to maximum of 6.3GHz.. btw i just asked Zeenko Store to ask Hugen to upgrade again NanoVNA-QT to support 9-10GHz, i hope they will listen.
-
Hi, Joe,
Do You use a SMA fixed-torque wrench to attach the cables & DUTs every time or fix them by hand?
Normally, I try to leave the cables attaches to avoid wear. For the Lite, I did install a couple of extensions to try and further minimize the wear.
https://www.digikey.com/en/products/detail/amphenol-rf/132171RP/1011924 (https://www.digikey.com/en/products/detail/amphenol-rf/132171RP/1011924)
The adapters and cables are all torqued properly. As for torquing the DUT and cal standards, it depends. Notice the cables I show that I claim are bad. If you were using them below a few hundred MHz, you may find you get very good results with them. Again, the lower the frequency, the less critical the mechanics which includes proper torque. So to answer your question, it depends on what I am doing. Just like calibration, a lot of times I won't do it or it's about the last thing I do. Again, depends what I am after.
-
The mode of operation on harmonics is not the standard mode of Lite, the 3rd and 5th harmonics are used for measurement, because of which the dynamic range suffers (this mode just optional, but can be useful for example in TDR measures for get better resolution). It is better to calibrate at these frequencies at high AVG values, this will reduce the noise in the calibration data, as well as in the measured data).
In general, you can get ~ 50dB in these modes, but there is a very long calibration
My 40 and 50dB measures
I had someone recently write me about using one of these low cost VNAs to tune some filters. These would have a fairly steep skirts and I would expect very low gains in the stop band. Communications... They were telling me how they were planning to use the average. I was thinking to myself, if I were trying to tune a filter like this I would want the screen to be updating several times a second. It will be interesting to see if they decide the one they bought was good enough for their application.
-
Pulsing S21 asynchronously with one and two firmware averages. Maybe in the future we can have a trigger in and out.
-
Just for the fun of it, here's some sort of an attempt to use the Lite beyond 10GHz. My software for the original 8754A supported using external mixers. I built a test set back then that allowed me to experiment beyond 2.5GHz but even 20 years or so later, I would say I'm still just generating garbage.
Shown looking at a S21 normalized with a 20dB MWM. Then inserting an SMA T adapter (some sort of stubish notch filter).
No cal standards along with poor cables, connectors and components. I don't put any stock in it. Fun but not useful.
-
I hope rev.3 of the software full integrate the Lite-VNA inclusive of the harmonic mode.
What is the setup on the Lite? Rev. 3 does not use the calibration on the FW.
-
I hope rev.3 of the software full integrate the Lite-VNA inclusive of the harmonic mode.
What is the setup on the Lite? Rev. 3 does not use the calibration on the FW.
None of the software I have released to the public for these low cost VNAs allows you to select the internal calibration. Nor do I support any feature that requires the touchscreen, buttons, jog switch or card readers. I also only support a very small subset of the commands. Just enough to get the data out of the unit.
Obviously, the Lite was not sending the raw data but this has been corrected. I'm not sure if they have support. Read Dislord's firmware interface document:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3888317/#msg3888317 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3888317/#msg3888317)
-
Yes, version 2.08 take is the measurement on. Thank you for the information, I use only with the PC.
Hope to get the rev.3 with the new feature.
Best regards.
Frank.
-
Yes, version 2.08 take is the measurement on.
Every version including 3 will display what ever the VNA sends up. If the VNA sends calibrated data, my software uses it. It does not know if the VNA was calibrated or not.
For the original NanoVNA, I support the Recal function (allowed me to load any of the internal calibrations). When I decided to open it to the public, I knew leaving a feature like this was going to confuse users, so I moved it off the main page to try and save the antenna analyzer group the grief. The manual warns about it. I'm sure it's caused problems for a few people.
-
I see on V.3 there is the averaging function that is good to use when required, the possibility to use on harmonic mode is one other possibility if the bridge permit.
One question: use one external mixer and directional coupler HPF filter like one of your videos suggests? will be too complicate?
-
2 X mixers were used, one mixer to up convert and one to bring it back down. There is also HP, LP, splitter, LO and directional coupler, depending what you are trying to do. Mixer losses are 7dBish each, so a wideband amplifier is used. In my example with the Lite looking at S21, no directional coupler was used. For the old HP8754A looking at S11, a directional coupler was used.
In concept, it's not too complicated and putting something together wouldn't be too difficult. When playing around with some wire and transistors on a breadboard, I made this video showing a basic software model I wrote to demonstrate LeCroy's Digital Bandwidth Interleaving. Roger Delbue of LeCroy chimed in. The reason I mention this is it shows the basic concepts.
https://www.youtube.com/watch?v=D33lCZAYmMM&list=PLZSS2ajxhiQBXX-hLFPNWD_GAECi6BOZC&index=2 (https://www.youtube.com/watch?v=D33lCZAYmMM&list=PLZSS2ajxhiQBXX-hLFPNWD_GAECi6BOZC&index=2)
-
Thank you for the very good video. :-+
-
Glad you enjoyed it.
-
FYI: a discussion about VNA calibration error models goes here:
https://groups.io/g/nanovna-users/topic/34237712 (https://groups.io/g/nanovna-users/topic/34237712)
This paper seems directly related to the Unknown Through Calibration error model, as I understand:
https://www.researchgate.net/publication/358164808_Measurement_Uncertainty_in_Network_Analyzers_Differential_Error_Analysis_of_Error_Models_Part_4_Non-Zero_Length_Through_in_Full_Two-Port_SLOT_Calibration (https://www.researchgate.net/publication/358164808_Measurement_Uncertainty_in_Network_Analyzers_Differential_Error_Analysis_of_Error_Models_Part_4_Non-Zero_Length_Through_in_Full_Two-Port_SLOT_Calibration)
-
Thanks. I had read that email chain and was talking with a friend about it the other day. The translation makes it difficult for me to follow. It will require I spend a lot of time to try and make sense of it. I did not download the tools and source code to try and replicate their tests. I also didn't read their final report. There were some other nuggets I found in that mail chain but again, it takes time to research. Did you read it and attempt to follow? Were you able to rebuild their code as well?
-
The Lite's internal averages compared with my software average and smoothing filter.
https://www.youtube.com/watch?v=M60Qalyx-r0 (https://www.youtube.com/watch?v=M60Qalyx-r0)
https://www.microwaves101.com/encyclopedias/smoothing-is-cheating (https://www.microwaves101.com/encyclopedias/smoothing-is-cheating)
-
I can suggest made calibration on big avg settings, this allow get less noise calibration data -> and as result less noise measured data after calibration.
I use minimum x10 avg on calibration.
Also 1001 points and 1x avg by sweep time equal 101 points and x10 avg. So if need more fast update better use less points.
PS sweep speed after 6.3G decreased, need more wait generator ready.
-
I show the VNA without calibration for a reason. No doubt that reducing the noise in general is a good thing as long as there is no loss of information.
Because I don't tune a lot of filters, I'm not sure what people would generally consider an acceptable update rate. I would imagine instant feedback is desired but maybe once every few seconds is good enough for a few. Personally, I couldn't use something that slow to make several adjustments. Giving up data points for faster feedback is certainly something users would consider when trying to use it to tune a filter.
PS sweep speed after 6.3G decreased, need more wait generator ready.
Also, the SNR improves as we move below that. Its less of a problem.
As I mentioned, the one person who wrote was planning to average to increase the dynamic range. The one thing they never mention is what they required. It was a communications application so I would assume that they would need something better.
I was thinking I could take a filter and run it on the Lite using the firmware calibration (what ever parameters/procedure you recommend) and store the Touchstone data to the SD card. Then run it with my software. Repeat it with the V2Plus4 and maybe my old VNAs. So I pull out a SD card go to slide it into the slot and it disappears into the unit. :-DD I remove the 4 screws to recover my card and then make sure I fits. No problem. I then put the case back together and try to insert the card but discover the card is too short and I need to use something to push it in deeper than the case allows to get it to lock. :-DD The experiment was doomed before it got started.
-
You can get the card to lock with the stylist. I attempted to use a 64G SD card but was presented with a write error. Lucky for me, the 121GW DMM Dave offers uses a small card which worked fine.
We can try to look at the difference of the dynamic range of the Lite using the firmware's calibration. Anyone could repeat that test compared with some filter I have laying around.
-
Same procedure, 401 data points, 1.5G to 3GHz range. I was going to try with the average set to 80 but was starting to fall asleep waiting for the thru. :-DD So I set the average to 10. Because we were saving the data to the SD card, I ran the Lite off battery to give it the best chance possible.
Shown comparing the above setup (red) with the my software running the Lite the way I would normally use it (dark brown). We gain about 10dB but it does slow things down.
Also shown is the V2Plus4(tan) connected to the PC, no average and running off the PCs power. Sadly, I know using the external power degrades the performance.
Also shown is data another member had taken for the Jankae LibreVNA (black).
Feel free to repeat this little experiment and see if your results show any major improvements.
-
I changed to 80X average and repeated the calibration and measurement. No other changes were made. Data was normalized to the original, non averaged data set. There appears to be some gains at 80 but it takes a very long time to run through it.
-
I ran the V2Plus4 (brown) from it's internal battery and used the software to average 10X for calibration and collection. I then compared this with the Lite (black) with the firmware 80X average for calibration and collection (also running from battery).
-
I wait for the release of rev.3 to test all these new software features with the LiteVNA, my use is with PC this possibility hare very usefully for it. :-+
-
I try compare LiteVNA / V2Plus4 / LibreVNA in S11 measures
I use 6dB attenuator on port and 30cm cable, calibrate all devices by one calibraion kit.
30cm cable:
Red - LibreVNA
Green Lite
Purple V2Plus4
Lite and V2Plus4 show ~equal results (on V2Plus4 strange spike at begin on > 0dB)
Next measure 6dB attenuator:
Red - LibreVNA
Brown - Lite
Green - V2Plus4
LibreVNA now have strange spike at begin. Lite and V2Plus4 ~equal, V2Plus4 little more noise
All measures made on 1xAVG
-
What was the DUT in the first test? (Seems to be something with almost 100% reflexion?)
And if the DUT in the 2nd test was a 6dB attenuator, how was its 2nd port terminated?
An you wrote "S11 measures", but in the diagram the red trace is labeled "S21"? :-//
-
What was the DUT in the first test? (Seems to be something with almost 100% reflexion?)
Hmm let me see how i write...
I use 6dB attenuator on port and 30cm cable, calibrate all devices by one calibraion kit.
30cm cable:
Red - LibreVNA
Green Lite
Purple V2Plus4
At first i measure 30cm cable cable not terminated. I must see 2xLOGMAG value of cable lost (as long as the wavelength fits on the way back and forth, then beats should already be visible due to attenuation in the cable and not pure 50Om or calibration kit or cable)
For attenuator i must see ~ 2 x LOGMAG of attenuator value (12dB line and small errors)
Colors for stored traces all colors as i write, all measures S11 reflect LOGMAG, at top show colors for live traces (not visible).
-
OK, so the test set was port1 -> 3dB attenuator -> calibration plane, and the DUT was the open-ended cable (or alternatively an open-ended 6dB attenuator for the 2nd test)?
-
First test open ended cable
Second test 6dB attenuator (i also use 3dB attenuator, but not store results, so made mistake)
Most strange results i see from LibreVNA (for cable as i write must be line ~600M, for attenuator strange spike at begin and on 3.2-3.4G)
For V2Plus4 also on cable i see strange up to > 0dB (and also small spikes on measure)
For Lite also exist small error on < 100MHz
-
Agreement of V2plus4 and Lite is not that bad :)
Another question is of course, what cal kit was used, and whether the standards were simply assumed to be ideal (although they are not), or whether their known/measured impedances were honored for the calibration.
-
Hello Dislord, my 4 mounts hold V2plus4 not give me the possibility to upgrade with your FW. there is a possibility to erase everything? And put the new firmware?
-
Another question is of course, what cal kit was used, and whether the standards were simply assumed to be ideal (although they are not), or whether their known/measured impedances were honored for the calibration.
Since purchasing the V2Plus4, I have used the standards supplied with it except for the load, which was sorted from a batch of Mini-Circuits terminators I purchased. I am not aware if the firmware for any of the low cost VNAs I have support anything beyond the ideal model. The data I collected for the dynamic range and noise was taken with the ideal model.
-
I wait for the release of rev.3 to test all these new software features with the LiteVNA, my use is with PC this possibility hare very usefully for it. :-+
Sorry but no news on a release. You thought you were confused with 2.x, 3.x isn't going to make things easier. :-DD
-
Not sure what you will learn from this but Lite with 1024 points (max firmware allows), 10Xaverge for cal and collect and measuring a cheap 6dB attenuator. Again, running off battery and saving the data to the SD card. PC was not used as I assume this is what you were doing. I used 10X average as you stated this was the minimum you use now. I have attached the Touchstone file if you want it.
Thinking of your glitches, I assume you inserted the female to female adapter into the open end of the cable you tested to keep it stable.
***
It's winter here and the house is dry. ESD may be another possible cause if what you are seeing is random.
-
Thank you for your great software :-+
-
Any calibration You make is only valid for the calibration plane (and compensates for the errors only there) .
You can change the reference plane after calibration.
Looks like there have been a few changes to the Lite's firmware. They still don't appear to provide any details about what they changed or why. Any details about the new release would helpful.
-
As i know
Only toch screen problems fixed (not work top left corner for 4 inch devices), no any additional fixes.
-
You can change the reference plane after calibration.
how? afaik the term is de-embedding, and its a math intensive procedure and requires full 2-port VNA, which i believe you havent demonstrated it. neither did i.
-
afaik the term is de-embedding, and its a math intensive procedure and requires full 2-port VNA, which i believe you havent demonstrated it. neither did i.
A noteworthy trivial special case of de-embedding is "port extension" which assumes that the network to be de-embedded is a piece of ideal 50 Ohm transmission line. This can serve as a good enough approximation for things like (say) a short female-female adapter between calibration plane and DUT, or similar.
-
You can change the reference plane after calibration.
how? afaik the term is de-embedding, and its a math intensive procedure and requires full 2-port VNA, which i believe you havent demonstrated it. neither did i.
The newer firmware for these low cost VNAs supports adding a delay (port extension). I demo'ed it with my software. You can certainly use it with a 1-port VNA looking at S11.
(and compensates for the errors only there)
I was going to say that we are really correcting errors before the reference plane but felt I was being pedantic. We are correcting for connectors, cables, delay, loss, reflections..... The VNA measures from the reference plane. The way it was worded, it seemed like it was suggesting that you had to measure the device right at that magic spot or all bets were off. Of course, the device we are measuring may be a 1000' of coax, extending far beyond the reference plane.
-
One problem with Electrical Delay in the v2 firmware is that it subtracts the SAME delay from S11 and S21. But S11 is round trip, while S21 is one way. So if you set an electrical delay in order to extend port1, then it can be either correct for S11, or for S21, but not for both at the same time.
-
Imo it were better if I could set separate port extension delays for ports 1 and 2, where the former is subtracted 2x from S11 and 1x from S21, and the latter is subtracted 1x from S21.
-
afaik the term is de-embedding, and its a math intensive procedure and requires full 2-port VNA, which i believe you havent demonstrated it. neither did i.
A noteworthy trivial special case of de-embedding is "port extension" which assumes that the network to be de-embedded is a piece of ideal 50 Ohm transmission line. This can serve as a good enough approximation for things like (say) a short female-female adapter between calibration plane and DUT, or similar.
only that (bolded line), but can we get ideal 50ohm TL at cheap? are we sure the hunglow pigtail M or F connectors/through are really ideal? its ok if we can only "assume" thats fine with me >:D, but in academic world i dont find it that simple. and characterized/ideal port extender can cost 10x of LiteVNA i guess, unless china manufacturing and QC has figured out something. if only want to extend port/plane for insertable dut.. i can only think of, why we dont just recalibrate at new extended plane? if we have both female and male cal kit? (i have ;D), so we can let the internal math of VNA FW do the job. the difficult part of extending plane is because the DUT is not insertable such as on PCB. i'm not sure though what the reason we want to test an open coaxial cable with reflections everywhere along the line as dislord did and then get into hassle try to extend (or even backward) the ref plane as we like. ymmv.
-
One problem with Electrical Delay in the v2 firmware is that it subtracts the SAME delay from S11 and S21. But S11 is round trip, while S21 is one way. So if you set an electrical delay in order to extend port1, then it can be either correct for S11, or for S21, but not for both at the same time.
Imo it were better if I could set separate port extension delays for ports 1 and 2, where the former is subtracted 2x from S11 and 1x from S21, and the latter is subtracted 1x from S21.
My released software only trims the delay for S11/S22. The newer version supports S11/S21 (/2 for S21) but currently does not support the transfer relay. That section of code is the main reason for the change and is still work in progress.
-
The software average work fantastic fast, this for the tuning filter is important.
I get a little confused with the TDR I tray to test my LINE stretcher, I need to learn to use it (not a lot of information for coax line stretcher)
When I did 2 port calibrations with the Transfer relay on, I get the same image for both ports works very good.
-
It's a round robin average. While you are always getting the averaged data at what ever rate the VNA is sending it, if it's 10 deep and the Nano sends data once a second, it will take 10 seconds to rifle through (think step response). If you are tuning a filter (or anything else with trimmers) I would imagine you want instant feedback. You may be able to reduce the number of data points to obtain acceptable feedback but I doubt it. You may also be able to give up the average features but if you are working with communications, again I doubt it. Even with average, I doubt they are good enough for this kind of work. I think its a case where you would need something better than the Nano. This is something the CB and amateur radio hobbyist would need to chime in on.
I do not understand what you are trying to do with these delay lines you keep mentioning which is why I had asked you once to explain it. It should be obvious that the more you extend them, TDR would show a longer time of flight. Maybe just post a short video clip of your setup and what it is doing. Then explain in text what you feel it should be doing.
-
DH7DN had posted an article about using the V2Plus4 with my software.
https://physik.co-i60.com/2022/01/new-addition-to-the-lab-nanovna-v2-plus4/
First steps
Buy NanoVNA, plug in the USB cable and turn it on. If you’re using Windows 10, the device should be recognized as USB CDC (Communications Device Class) on a virtual serial port (e. g. COM6). Next steps will be a little bit annoying: create an account on the National Instruments (NI) homepage, download and install the NI LabVIEW Runtime Engine (Version 2011 SP1 32-bit, size ca. 215 MB) and NI VISA. I have installed VISA v17.0 which is a 750 MB chonker. It contains drivers for USB/Serial communications any many others (also some important drivers for my obsolete GPIB test equipment which aren’t supported in the newer versions anymore). Install VISA and the Runtime Engine and spend your precious life with many reboots. I highly recommend to read Joe Smith’s User Manual, otherwise you may run into problems.
Word of advice, take the time to read the README file. I'm impressed that they were able to get it all working.
-
Dislord,
I am planning to add the ability to reprogram the VNA from my software. Looked simple enough...
What are the userArguments e8..eb that passed to the program upon soft reset?
When programming the device, what is the flashwritestart set to?
I attempted to program the device using a start address of 0. F0 - F4 appear correct. Minor revision reports 0. I see the ASCII 2 for the indicate commands and am able to jump after the file has been loaded. However, when I check the version in the menu it has not been updated.
-
Sniffing the bus, the address doesn't appear to be 0 as I guessed. I changed my start address to match but still no luck.
***
Sniffing when their software is sending the programming file, they appear to always append the array with 0x0d. None of these basics appear to be covered in the documentation. I don't see any other problems with my software and suspect this is the last problem.
***
:palm: After some sleep, the 0x0d is the Indicate command... :-DD
-
This will be great!!! Especially the reset if it's possible to change de firmware from the PC without pushing the jog button on it.
This is for the people using Nano/Lite with the PC is very useful (for people with sigth problem like me great).
There is a possibility to enlarge the screen size to fit on the monitor?
Thank you for all your improvement on the software. :-+ :clap:
-
Firmware start address (uint32_t register 0xe0): V2/Lite = 0x8004000, for V2Plus4 = 0x800C000 !! this value changed in Bootloader!! need write as for V2 = 0x8004000 (bootloader ignore less values for prevent write in it, this allow reduce chance erase bootloader code)
At device startup bootloader check pressed button (Right for V2 or Center on Lite) if pressed enter to firmware upload mode
In fw upload mode set this settings in Version registers:
// set version registers (accessed through usb serial)
registers[0xf0] = 2; // device variant (NanoVNA V2)
registers[0xf1] = 1; // protocol version
registers[0xf2] = 0; // board revision (always 0 in bootload mode)
registers[0xf3] = 0xff; // firmware major version (0xff in bootload mode)
registers[0xf4] = 0; // firmware minor version
So you can read it and detect V2/Lite in firmware upload mode.
Write in 0xE4 register - write in flash
For exit booload mode (reset devide) need write in registers[0xef] = 0x5e
-
Dislord,
Thanks for saving me some time. I wouldn't have guessed these would all require a different address. Why doesn't the boot loader handle it? Is there a way to query the address to make it more generic? I have no idea what the V2 is. Does it use the same protocol as the Lite and V2Plus4?
As realfran asked, is there a command in the application to drop to boot? It would make sense to automate the whole process.
Programmer is now working well (I tried 10 reloads, toggling versions with no errors).
***
Wait... are you telling me I have to run the application first to determine what hardware is installed, then drop to the boot? It sure looks like the Lite and V2Plus4 manuals are showing the same values for F0-F4 when the bootloader is running. Surely with 5 locations we could sort that out.
-
thank you. :-+
-
V2 - any NanoVNA V2.2 devices:
https://nanorfe.com/nanovna-versions.html (https://nanorfe.com/nanovna-versions.html)
V2Plus4 bootloader contain all close source part for measure and DSP processing, this need more bigger size for it 48k for V2Plus4, and 16k For other), but for allow write by old software use 0x8004000 address. I can`t detail answer about V2Plus/Plus4 bootloader structure.
Rewrite bootloader - more difficult part, need use STLink. Used in V2/V2Plus/V2Plus4 GD32F303 MCU not contain DFU mode (not allow easy programm it over USB). So change bootloader/fix it more difficult.
Additional V2Plus/Plus4 boorloaders depend from MCU serial number - used for protect it from copy.
In LiteVNA used AT32F403
https://www.arterychip.com/en/product/AT32F403.jsp (https://www.arterychip.com/en/product/AT32F403.jsp)
Allow use DFU mode, but need ATlink software
https://www.arterychip.com/download/AT_Link_EN_20210427.zip (https://www.arterychip.com/download/AT_Link_EN_20210427.zip)
For enter in DFU mode need connect bootpins on board and power on.
You can`t detect hardware version in bootloader mode (all devices answer as i write)
I can add command for enter in booloaded mode in next version firmware, example write in registers[0xef] = 0x5e, but only on next firmware version.
-
There is a possibility to enlarge the screen size to fit on the monitor?
Using the search in the upper right of the screen and leaving the topic set to "This topic", I used "resolution" and got the following hits:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/?topicseen#msg3617154 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3617154/?topicseen#msg3617154)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813608/?topicseen#msg3813608 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813608/?topicseen#msg3813608)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621361/?topicseen#msg3621361 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3621361/?topicseen#msg3621361)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3616560/?topicseen#msg3616560 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3616560/?topicseen#msg3616560)
-
Thank you for providing these details. That's too bad about the system architecture. I'll just add a selection for the target device.
I used the QT software to load your application code and every time, I cringe. :-DD I think it's safe now to get rid of it.
If you do decide to provide a unique ID within those 5 fields, let me know. I still have that ST-link for programming the original NanoVNA.
***
If you have any concerns about adding the drop to boot command, don't. It would be nice to have but the V2Plus4 doesn't support it and I can imagine that it may be too confusing for the users.
-
FYI: a discussion about VNA calibration error models goes here:
https://groups.io/g/nanovna-users/topic/34237712 (https://groups.io/g/nanovna-users/topic/34237712)
This paper seems directly related to the Unknown Through Calibration error model, as I understand:
https://www.researchgate.net/publication/358164808_Measurement_Uncertainty_in_Network_Analyzers_Differential_Error_Analysis_of_Error_Models_Part_4_Non-Zero_Length_Through_in_Full_Two-Port_SLOT_Calibration (https://www.researchgate.net/publication/358164808_Measurement_Uncertainty_in_Network_Analyzers_Differential_Error_Analysis_of_Error_Models_Part_4_Non-Zero_Length_Through_in_Full_Two-Port_SLOT_Calibration)
Thanks. I had read that email chain and was talking with a friend about it the other day. The translation makes it difficult for me to follow. It will require I spend a lot of time to try and make sense of it. I did not download the tools and source code to try and replicate their tests. I also didn't read their final report. There were some other nuggets I found in that mail chain but again, it takes time to research. Did you read it and attempt to follow? Were you able to rebuild their code as well?
I've read up to where they had started to post their BASIC programs. I attempted to run some of what they have shown but I have not tried to feed in my own data. So far, everything is a one port but I skipped to the end and see they also discuss a 2-port system. While they mention the NanoVNA throughout the thread, I have not seen where they added their algorithms to the open source software.
Dislord, have you tried to port any of their work into the firmware?
-
I've read up to where they had started to post their BASIC programs. I attempted to run some of what they have shown but I have not tried to feed in my own data. So far, everything is a one port but I skipped to the end and see they also discuss a 2-port system. While they mention the NanoVNA throughout the thread, I have not seen where they added their algorithms to the open source software.
It appears to be more a theoretical work, as far as they had published several scientific papers on the topic. I doubt it may have any practical implementation in low-cost VNA FW code.
Their last paper about 2-port systems analysis might trigger some discussion on the topic, but the subject seems too complicated to dive deep into details
-
I use this as base for calibrations.
Also add calibration standard suport, for this part i use various sources.
I had to deduce some formulas myself and optimize the calculations. Since initially they were very cumbersome for calculations (a large number of calculations in complex numbers is quite resource-intensive for the microcontroller, especially since hardware support for floating point numbers is disabled in V2/V2Plus/V2Plus4, since not all GD32F303 processors have this module. The processor in Lite is faster and there support is always on).
For thru calibtaiton most good result show ISOLN/THRU calibration as on H/H4. It allow good remove leakage from measured data.
-
It appears to be more a theoretical work, as far as they had published several scientific papers on the topic. I doubt it may have any practical implementation in low-cost VNA FW code.
Their last paper about 2-port systems analysis might trigger some discussion on the topic, but the subject seems too complicated to dive deep into details
I tend to agree with some of the comments posted in that chain. It would have been very helpful had they started with a clear description of the problem they are trying to solve. This should have been able to be boiled down to a paragraph.
Minimize the errors introduced by existing known models. Provide an approach that allows the error model to run more efficiently. Decouple the error model from the hardware used. As an example. I'm not suggesting these align with their goals.
One person was attempting to follow along which has helped me. Several pages into it, they still seem unsure what the goals are, which is my take when reading it.
With their emphasis on the NanoVNA, I would assume the are suggesting their models offer some benefits. At least for the single port error model they presented, it would be easy enough to experiment with.
I use this as base for calibrations.
Also add calibration standard suport, for this part i use various sources.
I had to deduce some formulas myself and optimize the calculations. Since initially they were very cumbersome for calculations (a large number of calculations in complex numbers is quite resource-intensive for the microcontroller, especially since hardware support for floating point numbers is disabled in V2/V2Plus/V2Plus4, since not all GD32F303 processors have this module. The processor in Lite is faster and there support is always on).
For thru calibtaiton most good result show ISOLN/THRU calibration as on H/H4. It allow good remove leakage from measured data.
Thanks for the post. Did you choose to follow their work because of it requiring less resources (memory, CPU...), or did it provide a more accurate result? Both? If you tried other methods when making the choice what model to use, I would be very interested in seeing any metrics you collected along the way.
-
I am curious if anyone else with the Lite had noticed a random shift problem? It seems to be bimodal, or always recovers. I've seen it when running various tests but it's been rare.
***
Looking at other times I have seen it, the amount it shifts may be constant.
-
S11 or S21 measures? Frequency?
I never see phase shifts, on device or on NanoVNA-App.
I see amplitude shift on my test AGC variant (The problem is that the gain depends slightly on the frequency and it is difficult to correctly connect different levels, it runs up to 0.1dB of error)
PS i possibly know source of problem, but not sure. You see this on device stanalone?
-
That was S21, 100MHz. I don't normally use these devices standalone and have not seen it. Again, it's rare and appears random. After that post, I let it run that same configuration for about a half hour and never saw it.
Anytime I have noticed it, it was a downward shift. I think it is always the same width and height but am not sure. I've been ignoring it.
Of course, it is very possible it's my software but I am not sure what the cause would be. My software checks each packet and it seem fine. This last example was without any calibration or normalization. It's about as close as I can get to the raw data from the Lite.
If there is something you would like me to try in order to isolate the problem, let me know.
***
Also, this was with firmware LiteVNA64-220127. I had tried the touchscreen test before and after this install and indeed, it works MUCH better now near the edges.
-
On 100MHz device switch generator mode, so i think know source of problem.
In V2.2 / V2Plus / V2Plus4 used 2 generators
Si5351 - cover 2 bands:
< 100MHz use fixed PLL and variable multiplier for set frequency
>= 100MHz and < 140MHz use fixed divider and various PLL
On switch generator mode possible unstable work.
For >= 140MHz used ADF4350 (or MAX2871 in Lite)
In future for Lite i move switch to MAX generator to 100MHz (ADF not allow work on less 140MHz, MAX allow work from 26MHz)
-
I tried several tests at 900MHz and could not reproduce the step. Over the last few weeks, for the most part I have been testing below 100MHz. I can believe it is somehow related to that.
-
I continued testing the entire day (12 or so hours, using the PC only) above 200MHz without a single problem. Even with that rare step, the Lite with this version of firmware has been very stable.
-
NanoVNA V2 Plus5 $329.00 difference:Max sweep rate: Specifications:
Frequency range: 50kHz - 4GHz
System dynamic range:
90dB up to 1GHz (V2 Plus4, AVG=20)
90dB up to 1GHz (V2 Plus5, BW=1.6kHz, AVG=5)
80dB up to 3GHz (V2 Plus4, AVG=5)
80dB up to 3GHz (V2 Plus5, BW=1.6kHz, NO AVG)
S11 noise floor (calibrated): -50dB (up to 1.5GHz), -40dB (up to 3GHz)
600 points/s (V2 Plus5)
:-DD god business
-
There is no mention of supporting the power setting, solving or improving the noise when running from an external power supply. Maybe its a firmware change. I have no plans to purchase one. If they made ANY changes that requires additional software updates, I will not be supporting it.
Dislord,
When running CW, why isn't the data rate faster than with swept mode? Is it throttled for a reason?
-
When running CW, why isn't the data rate faster than with swept mode? Is it throttled for a reason?
By default point measure look like this:
1 - set frequency, disconnect output, connect reference trace to ADC
2 - wait lock time
3 - measure reference (in this measure output disconnected)
4 - connect output, and connect reflect trace to ADC
5 - wait N*IF period time (N - integer, need for phase sync)
6 - measure Reflect
7 - connect thru trace to ADC
8 - wait N*IF period time (N - integer, need for phase sync)
9 - measure Thru
.........
repeat
In CW mode step 1-4 made only for first point.
After need hope all switch for step 5-9 good phase sync, not lost any data. On device measure i can grab data and not lost sync. On usb, possible situation then buffer full, and need wait then CPU software grab data, at this moment possible lost it, and as result get wrong phase, so CW mode disabled for USB.
Anyway, at this moment i rewrite all DSP part (i add auto gain select for all measure phases), i hope this allow little faster sweep/more dynamic range in reflect measure, and solve some more problems. But need test it more.
-
After our friend had posted about monitoring their heart rate and breathing, I had wondered why it would not be faster. With you working on the firmware for the Lite, maybe you could improve it.
It's odd that the software can not keep up. Are you using my software or something else?
For their heart rate experiment, it seems it was good enough but I have wanted to run similar experiments that would require a higher sample rate. If you wanted to try sending the data up 2X, 4X, or even higher, I would certainly be willing to see if my software could keep up.
Similar if you wanted to try and resolve the dip I see at the lower frequencies, I would certainly be willing to test it.
***
For example showing MFSK and two chirp wave forms in sequence. It's not a lot of data, 401 * 500 or 200,000 samples but software keeps up just fine.
-
You can increase sweep rate by use my debug registers.
0xE0 - for Si5351 (< 140MHz range)
0xE1 - for MAX (>140MHz)
This regisers by default = 15, set IF periods count for one measure
This mean for one point measure use 300 samples (for frequency > 400Hz, in this case one period = 20 samples, for less frequency one period 100 samples)
Average multiplie this value, so on 2xavg use 2x300 = 600 samples and so on
You can use any non zero value. !!! this registers i use for debug, so not check for 0)!!!
Use 1 allow get high sweep rate, but more noise (in this case sweep time limit only USB bus speed and wait/sync delays)
PS try use USB 2.0 port on CPU, as i see it allow get more sample rate then USB3.0
-
Thanks. I will add the ability to change this setting and let you know how it works.
My newer software supports sending the demodulated signals to the sound card. Maybe we can do some audio.
***
spelling
-
I added manual control to these two registers. Changing from 1 to 15 seems to have no effect on the data rate to the PC. I tried both synthesizers at 10MHz and 200MHz. No change (except the slower sweep rate for the lower frequency).
I still have LiteVNA64-220127.bin firmware installed. Does the released code support it? Do I need to be in a certain state before changing the registers for them to take effect?
-
Hmm, i write to E0 (send 0x20 0xE0 0x01)
And get ~660 samples/sec sweep on 1xavg in < 400k range
Here is my last beta, in it i rewrite DSP part, now for all measures select best gain (before only for thru).
Also must get little less noise floor and more linear thru measure on hi frequency, but this still beta, i want add more fixes.
-
It's very possible it's on our side. At 10MHz, I was seeing an update rate of 1000ms for 401 data points, 1 avg at 10MHz. Writing a one to E0, I still see 1000ms. I'll try your current firmware.
-
With the new firmware installed, it seems to speed it up about 100ms.
If you turn off S11 and only send the S21 data, could you then skip all the delays? Do you have have another debug register to select what data comes back?
-
Yes, this is one of the features that I would like to add (for version H / H4 this feature is available), this allow near x1.5 faster sweep.
-
That would be a worthwhile change. 50% increase but half the data, hard to believe any of the existing software would have a problem. Let me know if you want to try it.
-
This is as fast as the Lite will run with your test code and my software seems to have no problem keeping up. It seems there is a bit of phase error in the sampling as well.
-
I see onboard speed increase (visually) but max speed i can get in CPU software ~800 points/sec (in theory by timings i must get near 2000-3000).
I see x1.5 increase on one data measure (S11 or S21), but as before limit near 700-800 (not depend from internal measure speed, limits in current USB exchange format).
You can try this:
write in 0x44 register 1 allow get only S11 data (exchange protocol not change, S21 data conatain garbage)
write in 0x44 register 2 allow get only S21 data (exchange protocol not change, S11 data conatain garbage)
Current settings (not need use debug registers 0xE0 and 0xE1) allow get max speed in only S11 or S21 measure on 1xAVG, as i can see near 800 points/sec (1.2ms for one point in your software)
-
Thanks for the update. I tried it and it seems to work as suggested. Not stated but setting to 0 will reset the mode to S11 and S21 data.
I tried comparing USB 3 and 2 ports but saw no difference. My PC seems a fair bit slower than yours so I suspect there is a way I could further speed up my software by using the read FIFO command (0x18,AA,NN). Since getting the V2+4, I have always set NN to 1. Each call the index will increment as expected. Setting NN to 2 for example, I will get the two packets but they are identical. Not just the same index but the same payload. I always assumed this was a bug and just ignored it but suspect if this were to work, I could reduce the overhead a fair amount.
I send 0x18, 0x30, 0x01 for every data point. I would expect I could send 0x18, 0x30, 0x02 and receive two data points but it doesn't appear to work this way.
***
That was a problem on my end. I forgot to index the array... :palm:
Anyway, seems to work fine but sadly, no gains. With USB 3.1, 800 points, 200MHz CW, 1 Avg, S21 only, it takes about 1.23 seconds (1.53ms/point or 650Hz sample rate). Sending both S21 and S11 requires 1.36 seconds. I can disable all the features except the showing the raw data and the time is not improved. Sending both with USB 2.0 requires 1.46 seconds.
It's only 167kbps sustained. In your case, a couple hundred kbps, but I am not sure why. You have a faster Lite? Hardly seems like the PC is the bottleneck.
***
Using NN > 1 does seem to deduce the phase error. Shown is about an hour of data.
***
If I throttle the PC read thread. This is the thread sending the read FIFO commands, the index will start to skip. So, if the software can't keep up, we will not see incrementing indexes.
(not true, always seems to increment regardless. Breakpoint in wrong spot)
At these low data rates, I could use a couple of USB / TTL or RS232 adaptors and write a simple Lite simulator. Maybe send test patterns. From this we could sort out at what speed LabView can't not keep up.
On the firmware side, you could also try making a simple debug version that just sends up a pattern. Even a simple counter with checksum should be good enough. If the problem is getting the data out of the Lite, what do you think about only sending the data that is being requested?
I'm only considering CW.
-
Looking at the USB comm port adapters I have, none are very fast. I could achieve maybe 5X faster but I suspect not enough to stress the software.
It's not really an apples to apples compare but I own a Signal Hound BB60C spectrum analyzer that uses USB 3. They offer an API that allows access to the IQ data. I made a demo video where I used LabView to collect the signal from a 900MHz radio (a DMM I own) and convert it to the meter's readings.
https://signalhound.com/products/bb60c/ (https://signalhound.com/products/bb60c/)
https://www.youtube.com/watch?v=f1UtLpSZ2W0 (https://www.youtube.com/watch?v=f1UtLpSZ2W0)
I don't own any other equipment that uses USB but I have used LabView to interface with some Ethernet devices also at much higher data rates without any problems.
-
Found problem, now you can get max speed (i can get ~2600 points/sec if use E0/E1 = 1, avg = 1, and get only S11 data 0x44 = 1, this speed close to current limit)
Also now on device calibrate i use only one channel measure (S11 for SOL, and S21 for ISOLN/THRU) - so calibrate sweep ~x1.5 faster.
But need understand use E0/E1 change measure RBW - so use less value increase noise, increase this value reduce it.
Final RBW depend from E0/E1 * AVG, bigger value reduce RBW and decrease noise, but increase sweep speed.
PS i see only 1000 points/sec on USB3 port and 2600 points/sec on USB2, look like USB3 ask for data only every 1ms
-
:clap:
That's fast! 800 data points is about 160ms or roughly 5KHz on USB3.x port. Screen shot showing me running Flippers Lite a couple thousand miles away. Their PC only has 3.x ports. I tried enabling both VNA ports and it made little difference on the data rates.
I'll play around with it using my setup but this is very much what I was expecting. Thanks for taking the time to look into this.
-
0xE0 - for Si5351 (< 140MHz range)
0xE1 - for MAX (>140MHz)
This regisers by default = 15, set IF periods count for one measure
This mean for one point measure use 300 samples (for frequency > 400Hz, in this case one period = 20 samples, for less frequency one period 100 samples)
Average multiplie this value, so on 2xavg use 2x300 = 600 samples and so on
Can you maybe reword the above or provide more details about where these number come from and what they mean?
-
This related to DSP processing
VNA measure IF data after mixer
Use ADC for this, on LiteVNA used 600k sample rate (V2Plus/V2Plus4 use 1.5M sample rate, but after decimate?)
After used sin/cos table for calculate signal I/Q data
Table period depend from used IF
For signal >400k used 60k IF and 10 samples for one period table (if use 60k on less frequency you start see artefacts on IF harmoincs)
For signals > 20k and less 400k used 12k IF, but use bigger table - and this reduce sweep speed (you can see artefacts on 24k, 36k and so on)
For signals < 20k used 6k IF, and this more slowdown
More IF periods pass in DSP - result less RBW in measure, less noise, but need more time.
E0 - periods count for Si generator ( < 100MHz) for one measure, after this multiplie by AVG settings
E1 for MAX generator ( > 100 MHz)
You can see how this work, connect generator to CH1, set 30MHz output, and measure S21 logmag in 30MHz and span 30k, change AVG or E0 settings and see filter width
E0 = 6 and AVG = 1 give RBW = 10k (60k IF / (6 * 1))
E0 = 60 and AVG = 1 give RBW = 1k (60k IF / (60 * 1))
And so on
Default E0/E1 = 15, this give on 1xAVG RBW = 60k/15 = 4k
-
Here's Dislord's latest rocket powered firmware in action .... so fast!!
https://www.youtube.com/watch?v=qYgo4qoadZY (https://www.youtube.com/watch?v=qYgo4qoadZY)
It will be interesting to see if any of it makes it into the release code. If it does, I will go ahead and clean up my software to support it.
Thanks for all your help.
-
I sed before Joe; you can make with your software one gadget to one instrument:-+
Thank you Dislord@ to share your precious information from your great work on this firmware.
I hope to get the V.3 I'm very anxious about it.
-
I hope to get the V.3 I'm very anxious about it.
You're not alone. Its been a while since I've received any colorful emails but an radio hobbyist PMed the other day. They felt the need to need to let me know they are upset about my not releasing it. They did make me aware of how important their time was. Apparently they didn't like the "tone" of my responses. :-DD
-
I don't flatter person but appreciate your work and when you release the software version I go to use, for the ""tone" of your response same time luck sarcastic or dray but is your character possible is your sense of humour this not change the fact I appreciate your labour and the experience of it. :-DD
-
While one viewed may have droned on about my choice of music, failing to see notice the forest for the trees, I have been playing with the new firmware a fair bit and its impressive. I believe I hung the firmware once and had to power cycle it but for a test version of code it's proven to be very stable.
If you were to add this to the release, would you keep the same register address or add new ones? Would the manual be updated to include the new map?
I have not dug into the hardware at all but another question I have is about the narrow band. It seems I had used the CW mode to see how fine I could control the frequency, using a counter to monitor the frequency. It seems that it had the resolution but something was amuck with the receiver not being able to resolve to the same resolution. I'll repeat this test and give you some numbers but like the limited sample rates, I wonder if this isn't also a limitation of the newer firmware rather than the hardware.
-
I leave this registers (E0 and E1 exist in official firmware, i use this for debug), added 0x44 register, i set use it only for USB connection (at this moment set 0x44 register also apply on device internal measure)
If set CW mode over USB you not see CW output on CH0 port (i not complete this part, CW mode work only if set on device), if i made this - then get more faster sampling (~1.5-2x more, not need measure reference for every point, but can get USB bus limit, as i can see on my CPU new limit ~6k samples in CW mode, you can get it if set CW mode on device and after ask CW mode over USB at this moment)
I hope complete code on next 1-2 week, as i can see new DSP processing more fast, and stable (also allow do more things).
-
Take your time. I'm in no rush and more just curious if the register mapping will remain the same.
On the narrow band, I setup the same experiment. Using my scope's counter to monitor port1 and triggering on the dead time, then stepping the VNAs frequency it seems the resolution isn't a problem.
Connecting my RF generator to a series 4MHz crystal then trimming the frequency for peak and applying on port2. Basically, I want to simulate running the crystal without the effects of port 1 dropping out. With a span of 500kHz, I would expect to see a very narrow peak at 4MHz but instead see two peaks.
Setting E0 to 1 to try and remove some of the filtering, the shape changes but we clearly see the two peaks with a 120kHz separation.
Can you explain the cause?
-
You connect external generator to ch1 port?
You see 60k IF mirror (at 4MHz - 2*60k = 3.88M).
-
Can you explain the cause?
The receiver/mixer has of course no image rejection. Unlike a SA, a network analyzer does not need that, since the stimulus is not wide-band, but only a single freqency at a time (as long it is granted that no foreign signal is present). It is important, though, that the IF filter rejects harmonics of the IF significantly1), since both, stimulus and LO are suqare waves, therefore harmonics of the IF are expected at the mixer output, but we are only interested at the IF fundamental (or alternatively only in a single particular harmonic, when harmonic mode is used at high frequencies).
It were also interesting how well f+540kHz (9th IF harmonic) is suppressed, since 540kHz folds (aliases) back to 60kHz when sampled @600kSa/s, and 60kHz is exactly the IF frequency. So it cannot (must not) be eliminated by the digital filter, but already the analog lowpass in front of the ADC needs to do that. How well does it do its job? The same applies to the 11th, 19th, 21th,... IF harmonics as well, but the 9th is the first (and strongest) one folding back to 60kHz.
1) Either it notches them out, or alternatively it generally needs a high stop band rejection.
EDIT: The bizarre shape in the first image is the (expected) result of averaging. Since the window function of the coherent detector spans only a fraction of the measured samples, it effectively get repeated over the total measurement window, which leads to the depiced frequency response then. In the second image, the window function obviously spans all measured samples.
-
You connect external generator to ch1 port?
You see 60k IF mirror (at 4MHz - 2*60k = 3.88M).
Scope was on port1 to monitor VNA's frequency and CW generator in series with crystal was on port2.
Shown with the same 500kHz span and hardware setup using the original NanoVNA. Note span of two peaks now only at 10k.
-
If we set the span to 5kHz and compare the original NanoVNA with the Lite.
With the same setup, I program the Lite's E0 register to 0x1E and see a similar shape.
My question is the problem with the Lite's narrow band measurement the firmware's filter settings?
-
It's not clear to me what you want to measure in this way.
You send to CH1 port CW frequency 4MHz. Lite sweep in span 500kHz.
Measure result - this CW frequency go to mixer and mix vs sweep signal. And output IF sweep in range 500kHz.
So on display you see internal digital filter around 60k (additional you see mirror IF then on -60k)
Change AVG / E0 settings you change this filter width
NanoVNA Eddy v0.5 firmware use 5k IF (my fw for H/H4 use 12k IF) and not allow change filter width (my firmware allow select it), so you also see 2 peaks (additional mirror IF at -10kHz) on H.
For measure crystal need connect it between NanoVNA ports. Then main frequency correct sweep in measure range, pass thru crystal, and measured. Main problem on measure low width filters like crystal need use less width internal filter.
This my measure series connection 4MHz XTAL between ports, as can see exist strange result - this from wide RBW on measure, but i can reduce it (by increase AVG), as can see 5x avg better, but not good, select 10xAVG and get good result.
If you want use VNA like SA, need use step depend from internal measure filter width.
Additional Lite allow (in last fw) measure and show raw data (CONFIG->EXPERT SETTINGS-> DISPLAY SAMPLES)
in this mode channel data contain raw data samples, and you allow see on diaplay it:
I send to 1 port 30MHz (and stay on 30MHz CW in raw samples mode) and see IF samples on port (in linear format).
Additional i can enable FFT and see spectre (DISPLAY->TRANSFORM->TRANSFORM ON) in Logmag
Now i can see signal SA in frist 512 points
This mode also used for debug, and not friendly use.
PS gf correct answer how all work
-
I wanted to remove the effects of the output being chopped. End goal is to use the Lite for narrow band measurements. Data from the original NanoVNA is very similar to what I see with my vintage VNAs. The Lite is not even close. I want to know if this is because of how the filters are implemented or is it a limitation of the hardware?
-
Sure enough, if I increase the averages to 10, the results are greatly improved. Shown compared with data taken from original NanoVNA from 2020.
-
Can you show how V2Plus4 measure this filter?
-
Do you have firmware that will run on it that you want me to try? I need to test firmware programming function for it anyway so no problem. It's an early version of the hardware.
Attached is with the original firmware.
-
V2Plus4 have close source code (DSP and measure part).
I can provide only UI, points count, calibration changes. But can't change any related to measure.
PS H/H4 better work on low frequency < 10MHz (and have little less noise on < 100MHz, in this range i can get up to -100dB noise floor in S21 measures on my H4, but need use low RBW)
In Lite if remove DC block capacitor and ESD protection diode possible get better results on low frequency range < 10M (but this huge increase chance burn rf switch)
-
I wanted to remove the effects of the output being chopped. End goal is to use the Lite for narrow band measurements. Data from the original NanoVNA is very similar to what I see with my vintage VNAs. The Lite is not even close. I want to know if this is because of how the filters are implemented or is it a limitation of the hardware?
This might be a consequence of RF signal processing chain differences between original NanoVNA and V.2 mods. All V.2 mods need to switch RF signal between output and internal paths to perform measurements.
-
All V.2 mods need to switch RF signal between output and internal paths to perform measurements.
But is this really a problem if you grant enough settling time between switching and taking the measurements?
Sure, a large settling time does not make the sweep faster, of course. But speed vs. narrow-band is always a trade-off.
Does the Lite actually have 3 receivers, or does it switch the receiver as well?
-
All V.2 mods need to switch RF signal between output and internal paths to perform measurements.
Does the Lite actually have 3 receivers, or does it switch the receiver as well?
Yes, the Lite switches the receivers.
There had been 2 main problems with the narrowband filter measurements before.
First came from RF switching,
the second from DFT (FFT) IF signal processing.
But the latest FW for the LiteVNA solves both of them and is well suited for narrowband measurements.
-
I've never used the H4 due to firmware. Maybe your later firmware has improved but going forward, I have no plan to support the original protocol. The released software for the original NanoVNA and the H4 will most likely not change.
It's a shame they locked down the firmware for the V2+4. My experience with the firmware for both the original NanoVNA and H4 wasn't pleasant. Even the V2+ (not the +4) had a major problem where it would hang at random. I suspect the narrow band limitations with the V2+4 are also with the firmware. From what I have seen with the LiteVNA, even your unreleased firmware is proving to be very stable and I greatly appreciate your efforts.
I have not considered modifying the hardware. If you have benchmark data for the front end mods you mention, please post them.
I've been cleaning up my software and working on making it a bit more child proof. Normally, I wouldn't waste any time on it but with your new firmware for the Lite it was very easy to get into trouble and have to kill the application with task manager.
Currently I use LabView 2011. Flipper and I have been testing a 64-bit version of the software. NI offers the community edition free of charge now. This includes the application builder (supports EXEs). However they are 32-bit only and I would need to upgrade my license. $$$
***
It appears that Community 2021 is 64-bit. I will need to read their license contract but it may be an option. I doubt they would give me a price brake to upgrade.
-
Last night I installed the 64-bit runtime engine and built the software with the latest 64-bit version of LabView. It may provide some advantages when using the Lite. It seems to require less processing and screen update rates are a blur. Looking over the license for the community version,
As a condition to the License, and unless and only to the extent that this Agreement expressly permits otherwise, you must not
(iv) publicly perform or display the Software;
LabVIEW Community Edition and LabVIEW NXG Community Edition
You may distribute or transfer applications you create with Software, but only if you comply with the terms of the Agreement regarding distribution of Authorized Applications and such distribution of the Deliverables is for non-commercial, non-industrial, and if you are a degree-granting educational institution non-teaching and non-research, purposes only.
Except for the limited distribution rights set forth in this license, in no event may you distribute any software or code created with the Software.
When I finally get around to making a full demo of the software, I may compare the 32 and 64 bit versions. If users feel it's something they want, I may start a Patreon account to cover the cost of the upgrade.
-
Getting back to the narrow band measurement using Dislord's pre-release firmware, I thought would take the time to run one last filter across multiple VNAs. This was from back in Aug 2020, so a long time coming (sorry for the delay Grandchuck):
https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3180002/#msg3180002 (https://www.eevblog.com/forum/rf-microwave/fun-with-crystal-filters/msg3180002/#msg3180002)
Shown with the latest 64-bit software without any calibration using 10 averages (register 0x44 0x40= 0x0a).
-
Using METAS so show how the V2Plus4 compares with my original NanoVNA. Notice how the gain is also off. This data was taken with both VNAs calibrated. I can install a wideband device like an attenuator on the V2Plus4 and do not see this level of error in the gain.
-
Comparing the original NanoVNA with the Lite.
-
Shown comparing my original NanoVNA and LiteVNA with my two old systems. To make this measurement with the HP8754A, requires an external source so I didn't bother.
-
METAS allows normalizing. Here I am using my old Agilent PNA as a reference. Shown is both the LiteVNA's linear and log mag relative to the PNA. Once the firmware is released and I will most likely add a simple button to set these registers automatically.
-
Hello,
Regarding the NI clauses: You could demonstrate with the bought 32-bit and distribute the 64-bit home version. Seriously, getting users to pony up some support is very reasonable.
Regarding your firmware support: Which platforms/authors will you continue to support operability with your software?
Primary reason for posting: I thought I understood from the first comparison graph that v2+4 was doing much better than the original at that ~3Mhz frequency. The further comparisons showed the original doing very well in comparison to the other machines.
Why did the original do poorly in comparison to v2+4 and then do well against others?
I'll rewatch your original posting. Would be interesting to see what frequency range the original's performance drops below the v2+4 (i recall the issue of harmonics applying).
Thanks.
-
LabView is old and very expensive. As the user base dies off and people search for lower cost and license friendly solutions, I assume they came out with the community version in an attempt to try and recapture future sales. IMO, NI would have been better off summing that lawyer speak into 5 sentences or less in layman's terms. I'm not sure I can ethically distribute my software using the community version without hiring a lawyer to interpret their license agreement. I'm sure some sales or marketing director at NI has it all figured out.
Cost I would imagine by the time I cover the income taxes, sales takes and cost of the license, we are upwards of three.
Regarding your firmware support: Which platforms/authors will you continue to support operability with your software?
Interesting that you would ask as LabView now appears to support the Mac and LINUX under a single license. This was never the case before. If you wanted to target a different OS, you bought a separate license. Still I have no use for LINUX or the Mac and doubt I would invest anything to support them. I did try using LabView on LINUX when NI first released it. It was a total time waste. Pretty much my experience with LINUX throughout the years which is why I will not support it.
I have no plans to develop software for any devices using the original protocol. I have no idea which of these low cost VNAs are compatible. If your VNA is backward compatible with the V2+, V2+4 or Lite, then it should work. Any testing I do will be with the V2Plus4 and the LiteVNA64.
Primary reason for posting: I thought I understood from the first comparison graph that v2+4 was doing much better than the original at that ~3Mhz frequency. The further comparisons showed the original doing very well in comparison to the other machines.
Why did the original do poorly in comparison to v2+4 and then do well against others?
Sorry but I am not sure I follow. When you ask why something did poorly by comparison, it tells me very little without disclosing what metrics you are using. My V2Plus4 has never been able to make narrow band measurements. I've stated that several times and talked about it during my review of the V2+4. I've said if you work below 300MHz and plan to make narrow band measurements, stay with the original NanoVNA. If you want to experiment with PDN measurements, the original NanoVNA still out performs the others. According to Dislord, the H4 does a better job at the lower frequencies. That may be true today but the last time we had that discussion, I posted a fair bit of data showing otherwise. I suspect the problems were caused by firmware. The whole VNA has to work, firmware needs to be stable .... for me to spend any time with it.
Since buying the Lite, I have not done much with the other products. I am interested in seeing what Dislord comes up with for benchmark data at lower frequencies with the DC block and transient protection removed. IMO, that's it's only weak spot. Still, for the cost, who can complain? All of these products have been well worth their price.
-
Good evening, The graph comparing the original to the v2+4 had a line for the v2+4 which showed the multiple crystal effects while the original's line was a weak hump. Perhaps the labels got switched?
We hobbiests are benefitting from the NI home license and your efforts. It's right give back some and update your version. Labview and everything else is expensive. I read these poor opinions about Labview, but I can't think of a better prototyping or research platform. Creating tools with graphical programming environment of Labview has to be faster/easier than python.
Thanks.
-
Good evening, The graph comparing the original to the v2+4 had a line for the v2+4 which showed the multiple crystal effects while the original's line was a weak hump. Perhaps the labels got switched?
We hobbiests are benefitting from the NI home license and your efforts. It's right give back some and update your version. Labview and everything else is expensive. I read these poor opinions about Labview, but I can't think of a better prototyping or research platform. Creating tools with graphical programming environment of Labview has to be faster/easier than python.
Thanks.
I am guessing you're referring to: METAS_NanoVNA_V2P4_magphase.PNG
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4018888/#msg4018888 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4018888/#msg4018888)
I don't know what is meant by a weak hump. The labels are not switched. If anything, I would call the V2+4 the weak hump as it shows more attenuation than it should. I also show how the original compares with my other VNAs. I don't show the V2+4 in the other comparison plots because it is so poor. Maybe copy the graph you are referring to into paint and add some circles or something to indicate what you are calling a weak hump. To me, it couldn't be more clear but when your the one doing the work, everything seems clear.
Yes, I do see a lot of negative comments and misinformation on LabView. It's not a big deal. I just assume they are ignorant about it is all. A lot of my time working on this software has not been coding. That's the easy part. A fair amount is spent doing research.
Git doesn't provide many metrics to estimate the number of users but I doubt my software is very popular. Also, based on feedback, I estimate the majority of the people who have tried the software to be radio hobbyists. There may not be any advantage for this group to move to a 64-bit platform. It may take some time to accrue enough to cover the cost.
Because it seems very few people took advantage of the manual, I doubt I will put any effort into a new one. Its a lot of work just to have people asking basic questions that are covered in it. Most likely I will make a demo video for the LiteVNA similar to what I did for the original NanoVNA and V2+4 and call it good.
-
I'll review your original video about the crystals and study on it some more. Thanks for extra details.
Thanks for writing the manual. Real manuals seem to have gone out of style. It's all online forums, posting/searching questions and reading faqs. I prefer a good reference. Let the community figure it out is the new support.
-
I prefer not do hardware mods (use for firmware tests only original hardware)
Last H/H4 hardware (v3.6) show more good perfomance in noise floor. But i compare old H and H4 and V2Plus4 (one year ago) in impedance measures vs Agilent 4294A in 2-30MHz measures.
My H4 can see max 7-8k and give bigger error on measure < 1Om, V2Plus4 allow see near 12k (but also exist errors on < 1Om).
Last beta Lite firmware contain AGC mode for S11 measures, it allow get more dynamic range (but exist small 0.04dB shifts due not linear opamp? on measure gain level change)
V2/Lite/V2Plus4 use one measure channel and switch for Reference/Reflect/Thru. On crystal measures this of course affects, but setting a larger delay does not solve the problem.
Reduce measures RBW (set device AVG or E0/E1 registers) allow get correct results (but use external sotware AVG not reduce RBW and not allow get it) i think need show/select measure RBW value (not AVG as now)
PS as i see main problem for Lite noise level on S21 measures near 85-95dB (but for cheap device all good, i hope Hugen can improve this in future), S11 measures show very good results.
-
Shown with the latest 64-bit software without any calibration using 10 averages (register 0x44 = 0x0a).
You mean 0x40 register (set average) ?
0x44 = 1 get only S11 measure
0x44 = 2 get only S21.
-
V2/Lite/V2Plus4 use one measure channel and switch for Reference/Reflect/Thru. On crystal measures this of course affects, but setting a larger delay does not solve the problem.
Reduce measures RBW (set device AVG or E0/E1 registers) allow get correct results (but use external sotware AVG not reduce RBW and not allow get it) i think need show/select measure RBW value (not AVG as now)
I still struggle to understand what happed in Joe's V2Plus4 measurements (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1419265).
How did the V2Plus4 achieve the 4-fold repetition of the filter shape at about +/- 4kHz and +/- 2kHz offset?
Do you have an idea why exactly this happens, or is it simply a bug?
(Do you happen to know the IF frequency of the V2Plus4? I wonder if the ~N*2kHz offsets are possibly related to it.)
Does the same repetition effect also happen with the Lite if RBW is not reduced? (my guess were, it does not - but I may be wrong)
0x44 = 2 get only S21.
But is reflection still measured then?
My understanding is that reflection is also required for the error correction of S21, if Enhanced Reponse calibration is used.
If reflection measurement is skipped, then these S21 readings were limited to simple response normalization calibration, right?
-
>If reflection measurement is skipped, then these S21 readings were limited to simple response normalization calibration, right?
Yes, but as i can see ER calibration not allow solve problems, just add more errors.
On V2Plus4 - i think related to internal DSP filter:
And how look narrowband measure
If use 10xAVG you also get this
Yes on Lite if not use RBW you see ~problems (less but see) on image red 2xAVG and blue on 10x
-
The last screenshot from LiteVNA shows a classical spectrum leakage from a DFT transform with rectangular windowing function, just an ordinary DSP filter artifacts.
-
Here my fw for V2Plus4, use all not related to measure functions as on Lite
Limits:
Not work power control in CW (registers 0x41 for SI and 0x42 for ADF)
If use big avg settings (register 0x40) possible get overflow on measures (and not correct results, max avg near 20-25)
Not work 0x44 register for control send channel data.
And main warning: new V2Plus4 hardware use different LCD modules, not supported by this firmware. As sources closed (and i not have this devices), i can`t add it.
On this devices work only CPU control, LCD display black. Install last firmware from official page in this case
Allow 401 measure/calibration points, calibration standard support, and all things added in Lite/H4 devices.
-
Shown with the latest 64-bit software without any calibration using 10 averages (register 0x44 = 0x0a).
You mean 0x40 register (set average) ?
0x44 = 1 get only S11 measure
0x44 = 2 get only S21.
I have E0, E1 & 44 on the brain... Yes, 0x40 set to 0x0A, nothing to do with 0x44.
-
I'll review your original video about the crystals and study on it some more. Thanks for extra details.
Thanks for writing the manual. Real manuals seem to have gone out of style. It's all online forums, posting/searching questions and reading faqs. I prefer a good reference. Let the community figure it out is the new support.
It's a bandpass filter, so we expect it to pass frequencies in the 3.68M and reject everything else. This particular filter was designed to have a 1.5kHz passband. My software will automatically place the cursors 3dB down (I'm lazy). You can see from that first uncal screen shot, it's close. See:
https://www.minicircuits.com/WebStore/RF-Filters.html (https://www.minicircuits.com/WebStore/RF-Filters.html)
I programming the Lite with 1.1.01, and then ran the same 3.68M filter after calibration. Shown comparing with the V2+4 and the original NanoVNA. Only one of the three VNAs is even close and it happens to be the least costly and oldest. Good to finally know this was not a limitation of the hardware.
-
I programming the Lite with 1.1.01, and then ran the same 3.68M filter after calibration. Shown comparing with the V2+4 and the original NanoVNA. Only one of the three VNAs is even close and it happens to be the least costly and oldest. Good to finally know this was not a limitation of the hardware.
But here (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1419283) the Lite was much better. Very close to the Agilent and HP traces (only a higher noise floor). What is different now? Only other firmware, or also other E0/E1 and AVG parameters?
-
Here my fw for V2Plus4, use all not related to measure functions as on Lite
...
Mine was supplied with "git-20201010-86c7055" which I was unable to locate. There was mention of using ST-Link but looking at the PCB, there appears to be no test points to connect in. Maybe the pads under the USB port. It's not documented that I could find.
Finding working firmware for the V2Plus was random luck. I would be concerned that installing the last "stable" version would cause it to become unstable. So unless I am able to locate the original image or a way to back it up, I will not attempt to run it.
-
>Finding working firmware for the V2Plus was random luck
As i remember, you use my firmware version for this.
On V2Plus4 exist pads under USB connector
center left is SWDIO
center right is SWCLK
leftmost and rightmost are ground
Power must be from USB
-
I programming the Lite with 1.1.01, and then ran the same 3.68M filter after calibration. Shown comparing with the V2+4 and the original NanoVNA. Only one of the three VNAs is even close and it happens to be the least costly and oldest. Good to finally know this was not a limitation of the hardware.
But here (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1419283) the Lite was much better.
Very close to the Agilent and HP traces (only a higher noise floor). What is different now? Only other firmware, or also other E0/E1 and AVG parameters?
That is correct. You lost the context was all. That post was an attempt to demonstrate to jspencerg that the setup will make a big difference for this measurement and it's not documented. Its up to the user to somehow know what settings to use and the defaults are not what you want.
My original software for the V2+ did not support changing any of these registers, including the firmware average. It was up to the developers to make their firmware behave like the original NanoVNA to keep it backward compatible (thats assuming they want my software to work with it). In other words, you can not use my released software to make these measurements with the Lite. (that assumes the Lite's firmware defaults remain the same)
My latest software loads the number of averages from the Defaults file (currently set to 1) but the other registers are set from a byte write function which will go away in the final version. Once these are included in the released firmware, I will decide how best to support them.
****
Attached showing latest test firmware for the Lite with Avg set to 10, 1.1.01 firmware with average set to 1 and finally 1.1.01 firmware with defaults using my released software for the V2Plus4.
I assume the defaults were chosen for some other metric besides narrow band performance. I am not sure what but it shouldn't pose a problem in the future.
-
>Finding working firmware for the V2Plus was random luck
As i remember, you use my firmware version for this.
I would have no way to know. It could very well be. I posted about it here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3615392/#msg3615392 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3615392/#msg3615392)
They released a newer version after this and the problem returned. I went back to that one hand picked version I stumbled onto.
On V2Plus4 exist pads under USB connector
center left is SWDIO
center right is SWCLK
leftmost and rightmost are ground
Power must be from USB
Can you write up a procedure to back up FLASH?
-
Larry Rothman made pdf from all interesting info from beta-test forum
I also write how restore V2 device on brick (and dump firmware) on page 13
-
On page 14, was about the only thing close. Is the size for the V2Plus4 still 0x40000? So 0x8000000 to 0x8040000 would capture the entire contents?
Should I also create an partial image from 0x8008000 to 0x8040000 to recover the application?
I also note that the ST-Link is defaulting to 8-bit, should this be changed to 32-bit and will the binary file that generates be compatible with the QT software to reload it?
-
Need dump fw from 0x8004000 (for V2/V2Plus) and 128k size or 0x08008000 and 96k size (for V2Plus4) you can upload it by any software.
Better also made full dump from 0x08000000 (include bootloader) but restore only from ST-Link
Save it as bin file.
For Lite you can dump current firmware to SD card from CONFIG->EXPERT SETTINGS->DUMP FIRMWARE (this also dump all settings/calibrations)
-
Tried to get the software installed on Windows7 but the NI software won't install. Tried 4 different versions; I'm giving up. It would be so much easier if the NI software is included / bundled into the .exe file.
-
Tried to get the software installed on Windows7 but the NI software won't install. Tried 4 different versions; I'm giving up. It would be so much easier if the NI software is included / bundled into the .exe file.
It is included/bundled. You just failed to read the instructions. It's a common problem and one I don't have a solution for. While I have ran it on 7, that's as old as I support with that installer.
****
Read the attached, or don't.
-
I added a header and was able to backup and verify the images. I then used my software to load your new image. I also tried restoring the original with no problems.
That said, increasing the average using your firmware had no effect on the narrow band measurements. (other than slowing them down)
I took a few pictures along the way.
-
Tried to get the software installed on Windows7 but the NI software won't install. Tried 4 different versions; I'm giving up. It would be so much easier if the NI software is included / bundled into the .exe file.
It is included/bundled. You just failed to read the instructions. It's a common problem and one I don't have a solution for. While I have ran it on 7, that's as old as I support with that installer.
I have read the manual! I went to the NI site, downloaded the 2011 SP1 (64 bit) installer, installed it and yet NanoVNA.exe tells me to install the 2011 NI runtime. Just for good measure I tried a few newer versions of the NI runtime but that didn't work either.
The manual says to get the runtime from NI and start the executable. That is what I did.
-
I have read the manual! I went to the NI site, downloaded the 2011 SP1 (64 bit) installer, installed it and yet NanoVNA.exe tells me to install the 2011 NI runtime.
I think you need the 2011 SP1 32 bit Version
-
Tried to get the software installed on Windows7 but the NI software won't install. Tried 4 different versions; I'm giving up. It would be so much easier if the NI software is included / bundled into the .exe file.
It is included/bundled. You just failed to read the instructions. It's a common problem and one I don't have a solution for. While I have ran it on 7, that's as old as I support with that installer.
I have read the manual! I went to the NI site, downloaded the 2011 SP1 (64 bit) installer, installed it and yet NanoVNA.exe tells me to install the 2011 NI runtime. Just for good measure I tried a few newer versions of the NI runtime but that didn't work either.
The manual says to get the runtime from NI and start the executable. That is what I did.
Read the manual?
10. Installation
The software will include an installer which contains the runtime engine only. No drivers will be included beyond NIVISA.
As of version 1.0 there are now two separate programs. One supports the original NanoVNA
and the other supports the new V2+. The installer, .INI, runtime engine and VISA drivers will
no longer be included. You may download these directly from NI, or just install the original
release of the V2+ software. Once these are installed, copy the executable files to your
directory.
10.3 Troubleshooting
Most of the problems seem to stem from user’s inability to follow the basic instruction. Some
of the more common problems are:
Installing the EXEs and then randomly guess at which runtime is required. If they
manage to find the correct one, they are unable to get the software to communicate with
the device because they have not installed the correct VISA.
Using the wrong software for the device.
Downloading the installer and assuming the included 1.0 software is the latest available.
Attempting to use different regional settings without changing the INI file. The
NanoVNA fails to respond when the comma separator is selected.
Trying to use an unsupported hardware / firmware combination. If you like to fiddle
around reprogramming your VNA, the software is not well suited for you.
Do yourself a favor and read the readme file and manual. Of course, if you are reading this, I
doubt you ran into one of above problems.
I have read the manual! I went to the NI site, downloaded the 2011 SP1 (64 bit) installer, installed it and yet NanoVNA.exe tells me to install the 2011 NI runtime.
I think you need the 2011 SP1 32 bit Version
While the manual talks about running on XP (which it will) as I mentioned in the last few posts that I am looking into moving to 64-bit. The older versions of LabView were too crippled to make any use of the 64-bit versions.
While the power user may attempt to install the correct runtime from NI to get the software working on other flavors, I don't recommend it. As nctnico has discovered, unless you are familiar with LabView, that can present it's own set of problems.
-
To be honest there is a bit of an information overflow here. The github page isn't exactly layed out in a way that makes sense for releasing software so for me it is easier to just grab the exe and get the NI runtime.
But needs the program the 64 bit or 32 bit runtime? It would be extremely helpful to know (from the already extensive manual) to get the right NI runtime. I know that a lot of work went into documenting everything but missing this tiny bit of information just trips me up.
-
To be honest there is a bit of an information overflow here. The github page isn't exactly layed out in a way that makes sense for releasing software so for me it is easier to just grab the exe and get the NI runtime.
But needs the program the 64 bit or 32 bit runtime? It would be extremely helpful to know (from the already extensive manual) to get the right NI runtime. I know that a lot of work went into documenting everything but missing this tiny bit of information just trips me up.
You may have felt at the time your way was easier. Funny that you post that having it all packaged would have helped.
You are certainly not alone in your struggles. There's a reason I bundled everything up and included an installer. But as the manual says, you can certainly do it your way.
Git isn't really made to release EXEs. It limits the file sizes which is the reason for the spanned ZIP.
2011 is more than 10 years old and I would expect most people would have guessed its 32-bits just because of the age. The fact the manual talks about running on XP (common) vs XP 64 which was rare and short lived should have been another clue.
My guess is it will continue to be an uphill battle for you. You may want to consider using one of the other open sourced programs. These have several people working on them and I expect have much better support and documentation. The software may also be a lot easier to learn. Mine was really written for the EEs and it's far from user friendly.
If you really want to use it, I suggest you start by following the instructions and use the installer.
***
I'm guessing you will still have a question on which to use, 32 or 64. Again, read the attached from Github, or not.
The few people who follow my channel also may have seen the following where I talk about how to install it.
https://youtu.be/scZ3kZ4Q2sQ?t=1045
Having this level of detail and still having problems with the install is not uncommon. There are people who just can't get past the install. If you feel frustrated, your not alone. Read the last issue posted on Github. I never knew a VNA had anything to do with COVID 19 or who was president of the USA.
-
To be honest there is a bit of an information overflow here. The github page isn't exactly layed out in a way that makes sense for releasing software so for me it is easier to just grab the exe and get the NI runtime.
But needs the program the 64 bit or 32 bit runtime? It would be extremely helpful to know (from the already extensive manual) to get the right NI runtime. I know that a lot of work went into documenting everything but missing this tiny bit of information just trips me up.
You may have felt at the time your way was easier. Funny that you post that having it all packaged would have helped.
I certainly don't want to pick a fight here. I just want to explain my line of thinking in order to offer an insight in how & why I went wrong. We seem to have different views on what is easy. The Github page layout is also not helping me even though there is a releases item. Because the releases box only lists an old version I ignored it; it lead me to believe that the newer versions simply no longer come pre-packaged. Meanwhile I've downloaded & installed the 32 bit version of the 2011 Labview runtime and now the program starts.
And yes, I did try other software. I have a NanoVNA H4 (from nanovna.com ) and I already read that your software likely doesn't support it. No problems there, I just want to try and see how it goes. The other open source software I have tried doesn't seem to run at all without major Linux or Windows OS updates (to get the latest & greatest Python version). The (Windows only) software from nanovna.com does work though. Ultimately I'm researching whether it is worthwhile to get a full fledged VNA or stick with the NanoVNA and control it remotely.
-
To be honest there is a bit of an information overflow here. The github page isn't exactly layed out in a way that makes sense for releasing software so for me it is easier to just grab the exe and get the NI runtime.
But needs the program the 64 bit or 32 bit runtime? It would be extremely helpful to know (from the already extensive manual) to get the right NI runtime. I know that a lot of work went into documenting everything but missing this tiny bit of information just trips me up.
You may have felt at the time your way was easier. Funny that you post that having it all packaged would have helped.
I certainly don't want to pick a fight here. I just want to explain my line of thinking in order to offer an insight in how & why I went wrong. We seem to have different views on what is easy. The Github page layout is also not helping me even though there is a releases item. Because the releases box only lists an old version I ignored it; it lead me to believe that the newer versions simply no longer come pre-packaged. Meanwhile I've downloaded & installed the 32 bit version of the 2011 Labview runtime and now the program starts.
And yes, I did try other software. I have a NanoVNA H4 (from nanovna.com ) and I already read that your software likely doesn't support it. No problems there, I just want to try and see how it goes. The other open source software I have tried doesn't seem to run at all without major Linux or Windows OS updates (to get the latest & greatest Python version). The (Windows only) software from nanovna.com does work though. Ultimately I'm researching whether it is worthwhile to get a full fledged VNA or stick with the NanoVNA and control it remotely.
From my previous post where I quoted the manuals troubleshooting section: Installing the EXEs and then randomly guess at which runtime is required. If they manage to find the correct one, they are unable to get the software to communicate with the device because they have not installed the correct VISA.
Maybe you made it past that second part and actually have it communicating.
There's no fight. Your original post:
Tried to get the software installed on Windows7 but the NI software won't install. Tried 4 different versions; I'm giving up. It would be so much easier if the NI software is included / bundled into the .exe file.
suggests there is a problem. You were giving up and you never asked for help. This can leave people with the wrong impression. So, I provided quotes from the manual and from the on-line help and even a video clip explaining it. All three were of no help to you. Had you followed the instructions, or even bothered to read them, you would have seen it required the 32-bit runtime and VISA. Even after linking the online help here, you were still asking if it was 32 or 64 bits. I'm just pointing out the obvious. Don't take offense to it. Maybe consider what you are posting next time.
Believe me, I will be the first to admit that this software is not an easy tool to use or learn. There's a reason I made these videos and wrote that manual. You read the manual, so I would have thought that the follow would have made that very clear:
Additionally, there have been ongoing efforts to create other software for the NanoVNAs. I
have not been following their development but understand these programs have been largely
adopted by the radio community. My software was not written for this group. It was designed
as an engineering tool for the RF experimenter.
This manual assumes the reader is PC literate and has some basic understanding of how a VNA
works. It is not a learner’s guide on using a VNA and offers no assistance into solving basic
computer related problems.
This software can be viewed as an engineering tool at best. Its primary use was to extend the
author's understanding of NanoVNA V2 Plus. It was never intended to be used as a general tool
for radio hobbyists to tune their antennas. The software is buggy and not very robust. Even
under normal conditions, expect to run into several problems if attempting to use this software.
It is a very poor choice for the beginner.
As for supporting the H4 (or any other VNAs), it's hard to say really. The manual talks about the H4 and so does this thread, even recently. If the firmware is written such that it is backward compatible with the original NanoVNA and the firmware is stable then there is no reason my software would not support it. I ran several tests with the H4 some time ago and it was not to the level I was expecting. Still, others are using my software with it. Of course, it does require you use the correct software which was covered in that video, manual and on-line help. Or, you can just guess.
Old firmware was so bad, I ended up writing my own test code to test their code. Having a stable, automated test was the only way I could keep up with the firmware of the week. I could try loading in Dislords latest firmware for the H4 and repeat the regression test. The last time I played with it, we were working on using the VNA to measure a PDN. Then again, if you are the typical radio hobbyist and just want to look at SWR, then you may be just fine. It's free anyway so you're not out anything.
-
In Lite if remove DC block capacitor and ESD protection diode possible get better results on low frequency range < 10M (but this huge increase chance burn rf switch)
...
I prefer not do hardware mods (use for firmware tests only original hardware)
No problem. Did you see this data published somewhere that you can provide a link to it?
-
The last time I played with it, we were working on using the VNA to measure a PDN. Then again, if you are the typical radio hobbyist and just want to look at SWR, then you may be just fine. It's free anyway so you're not out anything.
My use for a VNA is more likely doing PDN measurements and looking at component behaviour at high frequencies. I already have a network analyser but that only goes to 300MHz which is just not high enough. As a test I measured an elliptic microstripline 1GHz low pass filter I designed / build a about a decade ago with my NanoVNA h4. The measurement shows the filter does something but it is nowhere near accurate (compared to the simulation and measurements -using a swept RF generator + spectrum analyser- I did back then). The noise floor on the NanoVNA h4 is not stellar. So yes, the NanoVNA h4 is good to see if the impedance / SWR isn't much off and get some very coarse measurements on filters.
-
I don't recommend using the original NanoVNA or any derivatives above 300MHz. The software/firmware can't overcome the limitations of the hardware.
To show the difference between the harmonic mode and the direct mode the V2Plus4 uses, I had demonstrated a GHz interdigital filter and compared the data with my vintage Agilent PNA. The same video also shows various hacked up circuits made from copper foil tape on FR4 to demonstrate the V2Plus4 working above 1GHz.
Of course, these low cost VNAs are missing some key features. I recently watched an YT video where a person was giving a training class on these low cost VNAs. They talked about some of them having a sinewave drive which of course they don't. They mentioned the possibility of problems when using a squarewave drive but provided no further details. So I made a quick video showing one such potential problem.
Of course there are many other missing features but for educational use, who cares. They are very inexpensive. With Dislord's efforts in developing the firmware for the LiteVNA, I would say that one in particular is the most flexible. Once Dislord releases his latest firmware, I will most likely make a review for it.
https://youtu.be/XaYBpPCo1qk?list=PLZSS2ajxhiQD2gftdurGQoyGpUM_HobNI&t=2732
-
You can calculate it from IF / Periods count for one AVG / AVG like this:
IF = 60k (for > 400kHz measures, at current firmware)
Periods count for one AVG = 15 (at current firmware)
RBW = 60k / (15 * AVG)
For AVG = 1, RBW = 4k
For AVG = 10, RBW = 60k / (15 * 10) = 400Hz
0xE0 - for Si5351 (< 140MHz range)
0xE1 - for MAX (>140MHz)
Are both E0 and E1 defaults 15?
For RBW is the switch point 400kHz or 140MHz?
Is E1 then used above 400kHz and E0 <= 400kHz?
Is the 60kHz fixed or can divider be set as well?
-
E0 used for < 100MHz now (i move thie threshold to 100MHz, MAX2871 allow do this. This reduce generator mode change count in sweep)
E1 for >=100MHz
For < 400kHz used different IF (not 60k), used 12k
For < 20kHz used 6k IF
Default E0/E1 = 15
IF frequency depend from ADC samplerate, and used in DSP sin/cos table size and periods count in it.
IF can`t be any. MAX2871 generate F second MAX2871 generate F + IF, this must be very accurate. Generators not allow set any frequecncy, exist minimum step. This step additional depend from reference TCXO (24M at this moment).
Current step = 24M / 4000 = 6k
-
When you calculate RBW (IFBW?) is everything below 100MHz using E0?
So, < 20kHz
RBW=6k/(E0 * AVG)
20k - 400k
RBW=12k/(E0 * AVG)
400k - 100M
RBW=60k/(E0 * AVG)
> 100M
RBW=60k/(E1 * AVG)
-
Yes, you can measure it as in
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4013407/#msg4013407 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4013407/#msg4013407)
RBW - central lobe width in Hz
-
I ask because you may find RBW is acronym mostly associated with spectrum analyzers. For example:
https://coppermountaintech.com/optimizing-vna-measurement-speed/
I am trying to think about how you would tackle the filter from a user perspective. I would expect for most VNAs, the user just sets the IFBW they want. It's independent from frequency. The software can set the sweep range which could cover all four bands you currently have defined. It's not in control of E0,E1 & 40 real time during the sweep so it can't dynamically change them. I also doubt the user will want to poke values into these registers after they calculate what filter they want. The other problem I see is that you have not yet locked them down and I wonder when you release the firmware, if they would still be prone to changing. This is why I asked about setting the divisor for the 6k-60kHz. At least the software would have some control to keep it consistent.
Maybe I'm not understanding it.
-
Yes better name it as IFBW
register 0x40 (avg setting) present in all LiteVNA firmwares
registers E0/E1 also present in all, but better not use it, only if need very fast sweep (use only 0x40), i leave it for debug use in all fw
Power setting 0x41 and 0x42 registers also present in all firmwares (just fix apply in CW mode in last official fw)
0x44 - (S11 or S21 data select) added only in last beta, and i plan leave it for future use
PS It is quite difficult for me to operate with technological terms, English is not my native language
-
Google translate has made it a smaller world. Without it, you and I would not be working together and that would be a shame.
VNAs I have used IFBW is constant across the entire sweep range. With Lite, presented with a selection of four bands (maybe more depending on what you settle on) . The data for the IFBW pull-down is populated when changing E0 and/or E1.
I can hear the screams of the poor users now. :-DD Give it some thought.
-
The low price of NanoVNA/V2/LiteVNA allowed many users to get it, and lowered the entry threshold. Many users with little skill have started to use the instrument and have many questions.
This little device has a lot of options available on professional devices, but there is no good description.
-
I suspect most users are CB and amateur radio hobbyist who were sold on it being an antenna analyzer. It seems to be the one area that they generally still enjoy constructing their own. Most features would never be utilized by that group and I suspect just further confuses them. Most are going from a simple SWR meter and now placing the VNA in-line with their PA and antenna. :-DD
Using a PC can make it easier and more flexible. It also provides a system with basically unlimited resources compared with the embedded system. Still, there is only so much the software can do. It's at the mercy of how the firmware is designed.
My experience based on feedback from users, there is little benefit from investing in documentation.
-
Hello, I have realized the source of my confusion about the graphs showing crystal filters in different vna's. My ignorance and not paying attention. Need I say more?
I appreciate getting to watch your conversation as you work on firmware and software to eke or as much performance as possible from the hardware. I've always admired the concept of continual improvement.
I went ahead and bought the nanovna-h and the v2plus. I did my best to get instrument that were not clones and which ran in Dislord's firmware. I appreciate things will change, but my hope is that your collaboration will see continued functionality with Joe's software (Does the program have a proper name?)
Joe, perhaps the day will come when you have to specify the specific hardware and firmware which will be compatable with your program? Maintaining and testing compatability with the variations is a job which you have not signed up for!
I know I'm ignorant, but I am learning. I've decided to use program SimSmith and videos from WOQE along with a text to learn about Smith charts. I hope to understand and implement features of Joe's program in the future. Joe's presentation and explanations of his experiments are helpful and inspire me to better understand.
Thank you Joe and Dislord for your work and for sharing the process.
-
Stand-alone device portability is useful making the habit of (mobile phone gadget)
"Using a PC can make it easier and more flexible. It also provides a system with basically unlimited resources compared with the embedded system. Still, there is only so much the software can do. It's at the mercy of how the firmware is designed.
Using the PC resource can make one powerful software to use with this low-cost VNA.
Personally, I learned much and want to learn more to use the VNA, not only one gadget but like a real instrument (with is on limitation).
-
...proper name
I've never given it any thought. They are typically named after the instruments they support. HP3589A.EXE for example. Let me know if you have something in mind.
I went ahead and bought the nanovna-h and the v2plus.
I have no plans to further support the older units and many of the new features we are discussing here are only supported by the Lite.
..want to learn more..
I've been reading "The VNA Applications Handbook". The first couple of chapters are available free on-line. It covers many of the basics. You may want to have a look.
Lite with firmware avg set to 10 and 20, with common mode transformer and 100uohm resistor attached. Compared with the original NanoVNA. Don't ask how long the Lite took to run those sweeps.
-
I'm computer illiterate hope someone gives one simple way to get the possibility and freedom to install the Dislord firmware or other on the NanoVNA 2V plus4 :box: :-+
-
Really odd problem with Flipper's Lite. We are not sure if it came this way or if this is a problem that has happened over time.
We were testing with nothing attached to the Lite, except the end caps. We had programmed in your latest test firmware and looking at the noise of S21 in the 9KHz to 1MHz range. There is a 20dB step in the noise at 400kHz where it jumps from 80dB to 60dB. There is no calibrations applied. We rolled it back to the last released firmware and it had no effect. If we change the sweep range to 1M to 100M, its roughly 60dB.
If we run it standalone disconnected from the PC, S21 drops to 80dB. Plugging in the USB cable (but not running any software), it jumps back up to 60dB with the step at 400kHz.
***
We tried different ports on the PC as well as used a powered hub and different cables, no effect.
Taking the unit apart, it appears the same as my Lite. We removed the battery and ran it from the PC, noise still present. Totally different from how mine behaves.
***
We tried a few different PCs, again no effect. Shown also is sweeping Flipper's from 1M to 100MHz.
For comparison, my Lite is shown in J1&2. The USB port on mine seems to have no effect.
-
If I run 50 averages on mine, we can see the switch point at 400kHz but mine actually decreases rather than increases like Flippers.
-
By default Ive gotten in the habit of leaving ferrite beads on both pigtails and the USB on my nanovna2. Having an RTLSDR made me strange that way.. lol
Really odd problem with Flipper's Lite. We are not sure if it came this way or if this is a problem that has happened over time.
We were testing with nothing attached to the Lite, except the end caps. We had programmed in your latest test firmware and looking at the noise of S21 in the 9KHz to 1MHz range. There is a 20dB step in the noise at 400kHz where it jumps from 80dB to 60dB. There is no calibrations applied. We rolled it back to the last released firmware and it had no effect. If we change the sweep range to 1M to 100M, its roughly 60dB.
If we run it standalone disconnected from the PC, S21 drops to 80dB. Plugging in the USB cable (but not running any software), it jumps back up to 60dB with the step at 400kHz.
***
We tried different ports on the PC as well as used a powered hub and different cables, no effect.
Taking the unit apart, it appears the same as my Lite. We removed the battery and ran it from the PC, noise still present. Totally different from how mine behaves.
***
We tried a few different PCs, again no effect. Shown also is sweeping Flipper's from 1M to 100MHz.
For comparison, my Lite is shown in J1&2. The USB port on mine seems to have no effect.
-
I suspect this problem is similar to what I see with my V2Plus4. I suspect it uses a SMPS when running off the USB and this is the source of the noise. Sadly the schematics do not appear available. I can use the USB interface with the V2Plus4 without any problems as long as I don't power off it. Even using a linear supply or batteries will not help. The noise source is internal to the V2Plus4. Still, I had Flipper purchase some very lossy cores but doubt it will have any effect. He has another Lite on order in hopes of getting a good one. I'll post an update once we have more information.
-
I have a habit from way back of using a .22 or .33 yellow tantalum capacitor across the USB rails. (used to be common in cheap phone handsets) Not so large that the current draw will cause USB enumeration to glitch but significantly smooths out the DC power. Have never seen any problems from doing this with those low value tants. The original maker of the first nanovna also recommends doing this with USB devices.. (this wasnt referring to nanovna though.. He just, like I always does this.
-
On 400k threshold for switch IF from 12k to 60k
You see power source noise as on V2Plus4.
Hugen post this reccomendation
https://groups.io/g/liteVNA/topic/reduced_interference_from_usb/89382728
-
Since LiteVNA is designed to work without a battery installed, it switches to using USB power directly when connected to USB power. When working with the USB power supply, the voltage of the input DC-DC boost power supply is very close to the voltage of the output, resulting in a very narrow PWM pulse bandwidth of the switching power supply, and these pulses may enter the IF, resulting in a large measurement noise.
Without the schematics, I wonder what the proposed changes do. It seems to claim the voltage is too high when running from USB. Once the changes are in place, will the battery still charge? Will the charger circuit provide enough power to keep the battery charged when running extended times? Why are two VNAs bought at the same time from the same company behaving so different? Bad design? I'm surprised designers wouldn't consider the the worse case as seen in the second link as this problem basically renders the VNA useless. At $130, it's a coin toss so far pr 50:50 chance if it will work or not. Not great odds. I'll let you know how Flippers second Lite behaves.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3891083/#msg3891083 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3891083/#msg3891083)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3891791/#msg3891791 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3891791/#msg3891791)
-
If variable PWM noise spectrum is the cause, it's quite possible to have this problem arise occasionally, depending on the current state of battery charge )
-
This I get with my LiteVNA
-
I had Flipper take a powered hub and replace it's external fixed 5V supply with his bench supply. We then ran it down at 4.5V. Sure enough, the Lite's noise drops to normal. We then tried averaging 50 samples and see the same drop in noise at 400kHz that I see with mine. Finally, we increased the supply voltage and the noise level goes up.
So, this is certainly the issue with the Lite's design. For now, Flipper will just use a diode to drop the hubs voltage. Hub + Lite was drawing less 380mA. We will wait for the second one to arrive.
-
One other thing I noticed was the sweep rate slow from 10Khz to 400Khz passing this limit start fast.
My observation is with the V.2.8
-
One other thing I noticed was the sweep rate slow from 10Khz to 400Khz passing this limit start fast.
My observation is with the V.2.8
Sweep rates are dictated by the firmware, not the software and it's really up to Dislord to decide how he wants it to work.
From the last post, I assume this is what he plans to release:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4024105/#msg4024105 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4024105/#msg4024105)
I can let the firmware try and squeeze every drop out while I wait or I can use the original NanoVNA to collect the data in a few minutes and have even higher performance.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4026451/#msg4026451 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4026451/#msg4026451)
-
Hello,
I suggest you remove the V2plus4 from your program header. Do something to emphasize to new program user that you are in process of tailoring program to the LiteVNA. Previous recommendations of the V2Plus4 should be tempered with your current intentions. You don't owe users anything, but fair warning of future program changes makes some sense.
I'm getting perspective about the nanovna ecosystem as I read through this thread.
-
Hello,
I suggest you remove the V2plus4 from your program header. Do something to emphasize to new program user that you are in process of tailoring program to the LiteVNA. Previous recommendations of the V2Plus4 should be tempered with your current intentions. You don't owe users anything, but fair warning of future program changes makes some sense.
I'm getting perspective about the nanovna ecosystem as I read through this thread.
The header indicates which hardware is supported. For now, this will be the V2Plus4 and the Lite. It's not really tailored to one or the other. It just happens that that V2Plus4 is falling far behind in features. It sounds like from Dislord's comment that could be addressed easy enough if the developers decided to open it up. If they do, it's up to the firmware developers to follow Dislords efforts if they want my software to support them. The same holds true for any future products. It's up to the developers to make their firmware compatible with the software, if they want to leverage it.
Because 3.x is so different from previous versions I have created a new repository for it. I have no plans to do anything more with the original repository. The 32-bit code will remain for those wanting to run on older OSs.
-
I thought I'd seen you running current program version with the original nanovna...
So, version 3 will not support the v2plus4? I guess I'll stop reading about the new features with a sense of anticipation.
Thanks for the details. I realize it's all in the works. I'll stop asking for predictions
-
I thought I'd seen you running current program version with the original nanovna...
I haven't made any updated to the software for the original NanoVNA since the last release.
So, version 3 will not support the v2plus4? I guess I'll stop reading about the new features with a sense of anticipation.
Thanks for the details. I realize it's all in the works. I'll stop asking for predictions
Getting an early start? :-DD
The header indicates which hardware is supported. For now, this will be the V2Plus4 and the Lite.
-
For me, the V2plus4 with the close firmware is a great disappointment no possibility to upgrade it, the Lite with the V.3 software is very interesting, especially for use with PC, I need to find some information for the calibration kit, the way to put Kurt calibration Kit data on the software. To calibrate one instrument need one calibration standard the professional one is very expensive out of my possibility. I hope to find someone nearby in the UK with professional VNA to help me to characterize one kit.
-
Dislord,
Any idea what was changed in LiteVNA64-220225.BIN? If this contains your most recent changes, can you provide where you ended up with the filter settings.
***
Last I knew, this was your proposed settings with E0 & E1 defaulting to 15 decimal:
< 20kHz
RBW=6k/(E0 * AVG)
20k - 400k
RBW=12k/(E0 * AVG)
400k - 100M
RBW=60k/(E0 * AVG)
> 100M
RBW=60k/(E1 * AVG)
-
For me, the V2plus4 with the close firmware is a great disappointment no possibility to upgrade it, the Lite with the V.3 software is very interesting, especially for use with PC, I need to find some information for the calibration kit, the way to put Kurt calibration Kit data on the software. To calibrate one instrument need one calibration standard the professional one is very expensive out of my possibility. I hope to find someone nearby in the UK with professional VNA to help me to characterize one kit.
I have heard of the low cost Kirkby kits but not Kurt.
https://www.kirkbymicrowave.co.uk/Sales-and-Services/Vector-network-analyzer-calibration-kits/SMA-calibration-kit/ (https://www.kirkbymicrowave.co.uk/Sales-and-Services/Vector-network-analyzer-calibration-kits/SMA-calibration-kit/)
As long as they provide the coefficients with the kit, you should be able to just type them in and hit save.
-
Yes this firmware contain all changes as in provided here beta.
Only one 'bug' i fix it today, not stable write on some SD cards (i send fixes to Hugen)
-
For me, the V2plus4 with the close firmware is a great disappointment no possibility to upgrade it, the Lite with the V.3 software is very interesting, especially for use with PC, I need to find some information for the calibration kit, the way to put Kurt calibration Kit data on the software. To calibrate one instrument need one calibration standard the professional one is very expensive out of my possibility. I hope to find someone nearby in the UK with professional VNA to help me to characterize one kit.
https://www.eevblog.com/forum/rf-microwave/diy-short-open-and-load-for-vna-calibration/ (https://www.eevblog.com/forum/rf-microwave/diy-short-open-and-load-for-vna-calibration/)
-
For me, the V2plus4 with the close firmware is a great disappointment no possibility to upgrade it, the Lite with the V.3 software is very interesting, especially for use with PC, I need to find some information for the calibration kit, the way to put Kurt calibration Kit data on the software. To calibrate one instrument need one calibration standard the professional one is very expensive out of my possibility. I hope to find someone nearby in the UK with professional VNA to help me to characterize one kit.
https://www.eevblog.com/forum/rf-microwave/diy-short-open-and-load-for-vna-calibration/ (https://www.eevblog.com/forum/rf-microwave/diy-short-open-and-load-for-vna-calibration/)
IMHO you'd be better off buying an SMA calibrator kit from Ebay instead of making something. For starters the short is right into the connector so it doesn't add any length.
Random hit on Ebay:
https://www.ebay.com/itm/284154775104 (https://www.ebay.com/itm/284154775104)
-
For me, the V2plus4 with the close firmware is a great disappointment no possibility to upgrade it, the Lite with the V.3 software is very interesting, especially for use with PC, I need to find some information for the calibration kit, the way to put Kurt calibration Kit data on the software. To calibrate one instrument need one calibration standard the professional one is very expensive out of my possibility. I hope to find someone nearby in the UK with professional VNA to help me to characterize one kit.
https://www.eevblog.com/forum/rf-microwave/diy-short-open-and-load-for-vna-calibration/ (https://www.eevblog.com/forum/rf-microwave/diy-short-open-and-load-for-vna-calibration/)
IMHO you'd be better off buying an SMA calibrator kit from Ebay instead of making something. For starters the short is right into the connector so it doesn't add any length.
Yes well until you've attempted to make some and compare their results against a commercially available kit how can one know.
In the thread I've linked there is a wealth of info including some good videos that align with my findings on this matter. SMA fittings are dirt cheap and coupled with SMD components and with a little care it's not hard to make Cal kit components far better that those I've checked that come supplied with any of these cheap VNA's.
-
I found that making some other fixtures especially -a 1:1 RF transformer is useful. Still have not found a pair of very small alligator or alligator-like strong CLIPS that I am looking for, though. The transformer is to decouple whatever (practically anything) from the transmission line.
Ive never heard of most of those other VNAs. I can see how the nanovna2 is a hard act to follow.
Wonder what it takes to make a pocket sized ultrasound device like I see being sold now.
-
A DIY calibration kit is one waste of time for two reasons first need one professional VNA with a calibration kit to compare, second many people get some results below 3Ghz.
I think is better to find some good quality of 50homs loads and some clone of short and open (the one that came with the LiteVNA) and play with them, on the end the low-cost VNA got is on limit.
I believe one good software can better use the resources of them using PC power computation.
-
A DIY calibration kit is one waste of time for two reasons first need one professional VNA with a calibration kit to compare, second many people get some results below 3Ghz.
I think is better to find some good quality of 50homs loads and some clone of short and open (the one that came with the LiteVNA) and play with them, on the end the low-cost VNA got is on limit.
I believe one good software can better use the resources of them using PC power computation.
Your previous referring to Kurt must have been someone who characterized a set of the included standards and not a cal kit they sell. If that's true, I suggest you contact them and see if they would be willing to supply you with the coefficients.
Your point about needing to compare the home made set with a known setup is valid. However, I just want to remind you that everything I have shown with the low cost VNAs has been with the included shorts, opens and load(or a hand selected load). Or, in many cases when testing below a GHz and looking at components, a set of standards I made up on FR4 were used. In all cases I have used the ideal model.
I could certainly attempt to characterize these standards and it may even improve my measurements some measurable amount. However, in your case I suspect there are much bigger problems that would mask any gains. You posted some data for an attenuator that showed several dB of error. No cal standard can correct that problem.
Besides myself, someone else had posted a report for you making a similar measurement with their low cost VNA.
https://nanorfe.com/forum/attachments/Calibration/96e7e95e1885-0/VNA_CalCheck_Summary_12-5-2021.pdf (https://nanorfe.com/forum/attachments/Calibration/96e7e95e1885-0/VNA_CalCheck_Summary_12-5-2021.pdf)
I would expect you to get similar results. I've suggested you simplify your setup by removing all your home made bits until you start getting better data but I suspect you think that the calibration is going to fix it all for you. That book I mentioned earlier is a pretty good starting point and covers a lot of basics.
https://www.google.com/books/edition/The_VNA_Applications_Handbook/_VyzDwAAQBAJ?hl=en&gbpv=1&printsec=frontcover (https://www.google.com/books/edition/The_VNA_Applications_Handbook/_VyzDwAAQBAJ?hl=en&gbpv=1&printsec=frontcover)
-
Yes, Kurt Pulsen has characterized a set for the liteVNA- LibraVNA and VNWA and many others.
The name of the software is "NanoVNA-Solver64" is good have it is a proper name :-+
For the calibration, I use to do it first directly on the LiteVNA and after thru the HP switching test set, watching for the different results with and without the switching relay,
the isolation is 100dB and even there is some problem the LiteVNA does not see them. :-DD
-
We kicked around a few names but Solver64 won out as it best described it. Unlike all the previous software I have released for these low cost VNAs, version 3 is a 64-bit application. This means a new runtime engine and VISA.
Its possible you are fighting a cable, connector, relay, attenuator ... problem. There's just no way that an attenutor would be off by as much as you show without there being a major problem.
With the release of Dislord's firmware, I have started to work on a demonstration video for the new software. Because of Dislords added features, the Lite will be used during the demonstration. There's a lot to go over. I plan to revisit the transfer relay and T-Check. Just for you, I'll show a step attenuator.
The data that OWO had presented for the V3 showed 100dB. They were planning to push it further.
-
The story of OWO OWO on the NanoVNA V3 takes time, I don't like the close source FW like the NanoVNA 2 Plus4 and the hysterical version Plus5 with some improvement (on the firmware) to scrub some money with this supposed version $329.00 and now quick disappear and recall Plus4 Pro from the Nanoforte web page.
My question is: what is the reason for Plus5 improvement? get more money? instead to upgrade Plus4 with new firmware.
One other VNA 6Ghz with (supposed 100dB) with squarewave generator for $1300 [full two-port version] on 5-12 mont time is making noise and loss of credibility.
I hope Dislord can get another 10dB more from the LiteVNA and for the hobby, use is good.
-
Most of my test equipment is closed source. It doesn't concern me as long as it does what the manufacture claims. In the case of the V2Plus4, the mail group is not public. The last time I posted I was told to not to bring up the Lite. I then made the choice to leave the group and have no plans to return. We were exchanging PMs for a while but similar to what you saw her posting here a few pages back about business practices.
I assume any successful business is about monetary gains. If they achieve 120dB that's impressive. They claimed to support the unknown thru. I doubt the hardware architecture is at all the same. If they are able to get reasonable performance do to 10kHz and support narrow band measurements, I would buy one. Even with the squarewave drive.
The Lite is very slow and can't out perform even the original NanoVNA in the lower frequencies. Then again, I assume most of their market are CB and amateur radio operators. I once had an electrical worker ask me why would I ever need to measure frequencies above 60Hz. The CB/hams perspective seems to be that the VNA is an antenna analyzer. We all have different perspectives. OWO talked about targeting smaller companies, not the radio hobbyist.
-
Flipper's second Lite arrived. Sadly, same problem as his original. Sounds like the supplied USB cable was also bad. Measuring the voltage at the (HP Z640) USB connector at 5.098V. There is also a rapid charge port which outputs 5.25V. Both are too high for the LiteVNA to work properly but note that there is a difference.
Looks like the diode dropped powered hub is the fix for now. Flipper is sending me the VNA and I will attempt to make the Changes Dislord mentioned and see if we can improve the low frequency performance.
-
LiteVNA64: Remove D1 R7 R1 -Please disconnect the battery and USB power connection when modifying the circuit. The battery must be connected after the modification is completed to work properly.
This is the modification suggested.
Another suggestion is: Calibrate without a USB cable (the reason is on calibration is embedded in the noise).
I calibrate the LiteVNA on battery with USB cable disconnected I started the NanoVNA-Solver V2.8 and I get this.
-
I was referring to the front end modifications Dislord had mentioned:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4015222/#msg4015222 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4015222/#msg4015222)
In Lite if remove DC block capacitor and ESD protection diode possible get better results on low frequency range < 10M (but this huge increase chance burn rf switch)
I have no plans to modify the power supply section. I had asked a few questions to try and understand if these changes would cause other problems but we did not get a response. So for now, Flipper will stay with the low voltage powered hub.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4030855/#msg4030855 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4030855/#msg4030855)
***
Another suggestion is: Calibrate without a USB cable (the reason is on calibration is embedded in the noise).
I calibrate the LiteVNA on battery with USB cable disconnected I started the NanoVNA-Solver V2.8 and I get this.
The data I've presented in regards to the power supply noise has all been without calibration. Calibration isn't a panacea able to overcome such hardware problems.
That said, we always run them with a PC. We expect raw data from the VNA and calibration is handled by the PC. It should be easy enough to replicate.
***
Snip a USB cable and expose the power leads. Power the VNA from an external supply. Flipper's will start to act up with 5.04V applied. I don't know the upper voltage limit before damage but it was plugged into that charge port. Keep it below 5.2V and I suspect you are fine.
Assuming no calibration, I would expect you to measure 50-60dB in the 400kHz to 1MHz range.
Then you can try to calibrate your way out of it. Let me know how it works out for you.
-
On the PC software, I don't perform any calibration of their raw data from the VNA
-
On the PC software, I don't perform any calibration of their raw data from the VNA
I understood that from the photo and what you had wrote.
Another suggestion is: Calibrate without a USB cable (the reason is on calibration is embedded in the noise).
I calibrate the LiteVNA on battery with USB cable disconnected I started the NanoVNA-Solver V2.8 and I get this.
However, you made the suggestion which suggests to me that you do not understand some of the basics.
Run through a calibration on battery (stand alone, no PC), but do not insert any of the standards when doing it. Create a bad calibration. Save it to 0. Reset the unit and it should show a lot of random garbage. Now connect it to the PC and run Solver. If you see the same random garbage, then something is wrong!! Again: We expect raw data from the VNA and calibration is handled by the PC.
I had discussed this with Dislord a few pages back. There was a time where he would not send the raw data but this was corrected:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3947854/#msg3947854 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3947854/#msg3947854)
The data that you show is what I expect.
-
ok, thank you for the explication, so the power supply on the LiteVNA modification is not important to reduce the noise after 400Khz.
-
ok, thank you for the explication, so the power supply on the LiteVNA modification is not important to reduce the noise after 400Khz.
Solving the noise Flipper was seeing is very important! I'm not sure why you would think otherwise. The modifications you posted are not understood and we chose to solve it a different way to avoid potential problems.
Did you run the cal as I suggested and prove it to yourself?
Did you run the VNA off an external supply as I suggested, to force the condition and then try to improve it with calibration?
-
Re: Getting started with hardware. Versions and connection success.
1. Versions
"THIS IS NOT THE LATEST RELEASE AND ONLY SUPPORTS THE V2 PLUS. IT SHOULD BE INSTALLED FIRST!"
I've installed and am running the program. Indicates it is Rev 0.10.
Where is Rev 2.05 & 2.07 as shown in manual?
2. Connection state looking good.
Windows Device manager sees the nanos' connections. As stated in manual, this install(0.10) links with the v2plus4 but not the original nano. I look forward to comparing results from the two.
-
Re: Getting started with hardware. Versions and connection success.
1. Versions
"THIS IS NOT THE LATEST RELEASE AND ONLY SUPPORTS THE V2 PLUS. IT SHOULD BE INSTALLED FIRST!"
I've installed and am running the program. Indicates it is Rev 0.10.
Where is Rev 2.05 & 2.07 as shown in manual?
2. Connection state looking good.
Windows Device manager sees the nanos' connections. As stated in manual, this install(0.10) links with the v2plus4 but not the original nano. I look forward to comparing results from the two.
Make sure you select the correct branch.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021102/#msg4021102 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021102/#msg4021102)
Also
The few people who follow my channel also may have seen the following where I talk about how to install it.
https://youtu.be/scZ3kZ4Q2sQ?t=1045 (https://youtu.be/scZ3kZ4Q2sQ?t=1045)
-
Re: branch choice on install
I never saw a place to make a choice. Was this a file selection or installer option?
-
Re: branch choice on install
I never saw a place to make a choice. Was this a file selection or installer option?
Press the Main button to show the available branches.
-
Once you select the correct branch, you need to select the ZIP file
-
After selecting the ZIP file, you must download it to your PC. It will need to be decompressed before it will run.
-
To save the file to your PC, you will need to select save and then press the OK button.
-
You will need to decompress the file. I use 7-zip.
-
I suggest you also read the following post:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021714/#msg4021714 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021714/#msg4021714)
If you are still having problems, provide details and maybe I can walk you through it.
If you do manage to figure out how to get it running, I am not sure you will get the results you are looking for. The impedance you are targeting could very well be far below what the NanoVNA can measure. You will also have to remove the ground loop between the two ports and you will need a way to block the DC. If you get all of that sorted out, the next problem will be not damaging the VNA when making the measurements! :-DD You should be able to get down below 10mOhms. 20kHz or so is doable.
Out side of Flipper and myself, I am not aware of anyone else attempting to make these measurements (with the NanoVNA). Let me know how it works out.
-
The modification is suggested by Hugen "
Since LiteVNA is designed to work without a battery installed, it switches to using USB power directly when connected to USB power. When working with the USB power supply, the voltage of the input DC-DC boost power supply is very close to the voltage of the output, resulting in a very narrow PWM pulse bandwidth of the switching power supply, and these pulses may enter the IF, resulting in large measurement noise.
To avoid this interference, the power supply circuit can be modified so that the input to the switching power supply always comes from LiteVNA64 circuits are slightly different, with the following modifications.
LiteVNA64: Remove D1 R7 R1
Please disconnect the battery and USB power connection when modifying the circuit. The battery must be connected after the modification is completed to work properly.
"For me is impossible to make this modification for my sight and some shaking hand"
-
Re: Finding installation files
Thanks for the details. GitHub is not intuitive. Installs went fine. Linking successful for both nanoVNA's.
My computer has a 1920x1080 pixel screen. Your program interface has lots of details. Could you enable a larger(stretchable?) VI window?
Thank you!
-
Re: Finding installation files
Thanks for the details. GitHub is not intuitive. Installs went fine. Linking successful for both nanoVNA's.
My computer has a 1920x1080 pixel screen. Your program interface has lots of details. Could you enable a larger(stretchable?) VI window?
Thank you!
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3986420/#msg3986420 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3986420/#msg3986420)
-
My software was released to the public over a year ago. Most of the basic questions have been asked and answered a few times over. In the upper right corner, there is a search button. You can type in what you want to search and the select the search button.
-
Re: VI screen size
I followed link supplied and then followed those links. Reading your replies leads me to think you are aware of the screen real estate issues, like program's current behavior and do not intend to modify the interface options. Correct?
I tried all permutations in the compatibility properties as suggested by ALW on 210805 in this thread. One option made window smaller, but nothing increased the window size.
-
Re: Adjusting VI window size
I found two references to controlling VI window size programmatically. Perhaps one method will work?
https://lavag.org/topic/8691-how-to-scale-ui-for-different-monitors/
https://labviewwiki.org/wiki/VI_class/Front_Panel_Window.Minimum_Size_property
-
Re: VI screen size
I followed link supplied and then followed those links. Reading your replies leads me to think you are aware of the screen real estate issues, like program's current behavior and do not intend to modify the interface options. Correct?
I tried all permutations in the compatibility properties as suggested by ALW on 210805 in this thread. One option made window smaller, but nothing increased the window size.
From:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813893/#msg3813893 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3813893/#msg3813893)
I have no plans to change this.
I didn't realize this was ambiguous statement. You are correct.
While I hadn't planned on a PC 101 course, another options to change the Windows resolution is to right click on the screen and select "display settings". Press "Identify" then select the monitor you want to change the resolution. You need to select the box with the number. Scroll down and select the "Display resolution". It's a pulldown menu and you will need to press the button. Change it to 1280 x 720.
-
Re: 1280x720
LCD screens lose sharpness when displayed at something other than their optimum resolution. I thought the links I found would suggest a solution for different screen sizes. Window size does seem to be a recurring issue for users.
Thanks for your efforts.
-
Re: Adjusting VI window size
I found two references to controlling VI window size programmatically. Perhaps one method will work?
https://lavag.org/topic/8691-how-to-scale-ui-for-different-monitors/
https://labviewwiki.org/wiki/VI_class/Front_Panel_Window.Minimum_Size_property
Re: 1280x720
LCD screens lose sharpness when displayed at something other than their optimum resolution. I thought the links I found would suggest a solution for different screen sizes. Window size does seem to be a recurring issue for users.
Thanks for your efforts.
Indeed. There's a reason they have a recommended setting and why I buy hardware that suits my needs.
Quick background. I was reacquainted with LabView 3 and started using it when 4 was released. I bought it for my own personal use when 5 was released. I'm by no means any sort of expert but I'm familiar with it enough to be able to have a discussion.
I'm certainly open to your ideas about how to improve my software. NI offers LabView free of charge but I expect you already have it. I suggest we start with you coding up how you envision my software should work. Use what version of LabView you are comfortable with. Then we can go over it. I've already mentioned some of the problems but I suspect you have ideas on how to solve them.
-
Using my V2+4, I lowered the supply voltage like we had with the LiteVNA to solve the noise problem. Even with as low as 4.5, there was no improvement.
-
Re: VI window size
First impression indicates newer versions of Labview have ability to adjust window size for monitors of different resolution. I don't know whether those functions are available for Labview 5. I'll look into it.
-
Re: VI window size
First impression indicates newer versions of Labview have ability to adjust window size for monitors of different resolution. I don't know whether those functions are available for Labview 5. I'll look into it.
I haven't used LV5 in I would guess 20 years. For your demo, just use what ever version you have available.
-
What version of Labview are you using to create the program?
-
What version of Labview are you using to create the program?
Re: Getting started with hardware. Versions and connection success.
1. Versions
"THIS IS NOT THE LATEST RELEASE AND ONLY SUPPORTS THE V2 PLUS. IT SHOULD BE INSTALLED FIRST!"
I've installed and am running the program. Indicates it is Rev 0.10.
Where is Rev 2.05 & 2.07 as shown in manual?
2. Connection state looking good.
Windows Device manager sees the nanos' connections. As stated in manual, this install(0.10) links with the v2plus4 but not the original nano. I look forward to comparing results from the two.
Make sure you select the correct branch.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021102/#msg4021102 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021102/#msg4021102)
Of course....
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021555/#msg4021555 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021555/#msg4021555)
-
I knew that LV11 had been used. Your discussion of 64-bit version and the program's new name suggested you were updating program as you develop next version. Correct?
-
I knew that LV11 had been used. Your discussion of 64-bit version and the program's new name suggested you were updating program as you develop next version. Correct?
Correct
-
Flipper's transfer relay is NOS. He cheated with an OTS DC-DC rather than rolling it from scratch. It's a much nicer setup than mine.
-
What version of Labview are you using to create the program?
Re: Getting started with hardware. Versions and connection success.
1. Versions
"THIS IS NOT THE LATEST RELEASE AND ONLY SUPPORTS THE V2 PLUS. IT SHOULD BE INSTALLED FIRST!"
I've installed and am running the program. Indicates it is Rev 0.10.
Where is Rev 2.05 & 2.07 as shown in manual?
2. Connection state looking good.
Windows Device manager sees the nanos' connections. As stated in manual, this install(0.10) links with the v2plus4 but not the original nano. I look forward to comparing results from the two.
Make sure you select the correct branch.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021102/#msg4021102 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021102/#msg4021102)
Of course....
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021555/#msg4021555 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021555/#msg4021555)
But that message is still clear as mud -sorry-. Why not write down some simple steps that people can follow instead of needing to find bits of information in documents, this forum and videos? The problem is that a lot of the installation part is obivous to you but it isn't obvious at all to other people. Someone new to your software needs a single place with a full instruction on how to get your software going without needing to go on a scavenging hunt for information (like it is now).
As far as I understand it right now the installation boils down to the steps below:
- Go to the github page: https://github.com/joeqsmith/NanoVNA_Software (https://github.com/joeqsmith/NanoVNA_Software)
- Look at the right under releases, download all the zip files, extract to a directory and run the installer (setup.exe ?). This will install the NI Visa (version x 32bit) and Labview runtime (version y 32bit)
- Go back to the github main page
- Click on branches in the left top
- Open the branch for your NanoVNA model and download the .exe file onto your computer
- Start using the program
Please amend these steps with missing info and add them to your Github page and manual. I'm 100% sure you'll see a huge drop in questions about installation issues.
Assuming these steps are correct, I would have had your software up & running within 5 minutes.
-
Of course....
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021555/#msg4021555 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021555/#msg4021555)
But that message is still clear as mud. Why not write down some simple steps that people can follow instead of needing to find bits of information in documents, this forum and videos? The problem is that a lot of the installation part is obivous to you but it isn't obvious at all to other people. Someone new to your software needs a single place with a full instruction on how to get your software going without needing to go on a scavenging hunt for information (like it is now).
As far as I understand it right now the installation boils down to the steps below:
- Go to the github page: https://github.com/joeqsmith/NanoVNA_Software (https://github.com/joeqsmith/NanoVNA_Software)
- Look at the right under releases, download all the zip files, extract to a directory and run the installer (setup.exe ?). This will install the NI Visa (version x 32bit) and Labview runtime (version y 32bit)
- Go back to the github main page
- Click on branches in the left top
- Open the branch for your NanoVNA model and download the .exe file onto your computer
- Start using the program
Please amend these steps with missing info and add them to your Github page and manual. I'm 100% sure you'll see a huge drop in questions about installation issues.
Define simple. After providing you a screen shot from Git that answered your question about 32 or 64, you still asked the same question. So even just a few sentences, one which directly answered your question is not simple enough.
Rather than having such expectations of me, what prevents you personally from writing what ever documentation you feel would help other users? You could start a Wiki page for it, make instructional videos and what ever else you feel is a benefit to the community.
I have no plans to do anything more with the original repository.
-
....
Start using the program
....
Assuming these steps are correct, I would have had your software up & running within 5 minutes.
By far most questions were sent in by PM or direct email asking how to use the software. Most have been from CB/amateur radio hobbyist regarding antenna measurements. This group expresses a level of expectation when it comes to supporting them. I delayed the original release by about a year because of the constant complaints and demands. Anymore, I rarely take the time to answer private emails and in some cases block them.
Point being, you are asking about what I consider a trivial problem that again, you personally could help make a difference if you chose to. The bigger problem is educating people on it use.
-
I understand but I still believe that information regarding installation should be contained in as few places as possible. That has made me hesitate for a long time to post my idea on how the installation steps can be made more clear. On the forum it just gets lost in the noise and I don't see how another wiki page adds something of value. Especially given the fact that there are several software packages out there to use one of the many NanoVNA models out there.
As to using your software; the NanoVNA has opened up owning a VNA to a lot of people to whom such a device was out of their budget and/or not worth having. So I'm not surprised you get a lot of questions from people to which the technical terms are not familiar.
-
I understand but I still believe that information regarding installation should be contained in as few places as possible. That has made me hesitate for a long time to post my idea on how the installation steps can be made more clear. On the forum it just gets lost in the noise and I don't see how another wiki page adds something of value. Especially given the fact that there are several software packages out there to use one of the many NanoVNA models out there.
As to using your software; the NanoVNA has opened up owning a VNA to a lot of people to whom such a device was out of their budget and/or not worth having. So I'm not surprised you get a lot of questions from people to which the technical terms are not familiar.
I believe if we look at your specific question where the information was provided in a few sentences was too much to read. I doubt adding a list of instructions would have enticed you to read them. Lack of reading skills is a common problem in general and why I will not invest any time towards documenting new releases.
Git offers very little for metrics to help track the number of users. I suspect my small channel and free software has done little to help the community. I try to steer people away from using my software and to use one of the other open source programs. These have a large user base and I assume much better support.
It should be clear by now that my business model is such that I don't make any money from my attempts to help the next generation of EEs. You don't see me begging for money to fund my efforts.
-
Re: front panel sizing
I realize you've got bigger fish to fry. I'm just trying to make a little contribution. I've only been able to find one way to maintain percentage of front panel coverage with different monitor resolutions. This solution speaks directly to current issue. However, scaling issues with inserted graphics and fonts might be problematic. In any case, trying it couldn't hurt:
https://zone.ni.com/reference/en-XX/help/371361R-01/lvdialog/window_size_properties/
Thanks for your work.
-
Re: front panel sizing
I realize you've got bigger fish to fry. I'm just trying to make a little contribution. I've only been able to find one way to maintain percentage of front panel coverage with different monitor resolutions. This solution speaks directly to current issue. However, scaling issues with inserted graphics and fonts might be problematic. In any case, trying it couldn't hurt:
https://zone.ni.com/reference/en-XX/help/371361R-01/lvdialog/window_size_properties/
Thanks for your work.
True and true. Until you take that first step to learn about what you are suggesting, you're not contributing anything but noise. Maybe ask yourself, Joe's says he's been using Labview for decades. Why doesn't he listen to me... :-DD
Scaling is an interesting problem and I would certainly take the time to show you a few tricks if you decide you want to learn it. As you're discovering, the basics can be found with Google. Use these to build your own understanding of how it works. Maybe start a thread in the programming or test equipment sections to discuss learning LabView. You may find others having something to contribute.
Again:
Who knows what you were expecting. Maybe you expect the graphs to scale. Obviously the font sizes are fixed. There are videos on YT about designing software with LabView using the autoscaling if you are interested in learning about it.
I've run my VNA software on 1280X1024 19", 1920X1080 27" and 1920X1200 24" and its very easy for me to read on them all. It is designed to run on my laptop which has a 17" display.
You should consider running one of the popular open source programs. If you really have some need to run my software and your choice of monitors was poor for your eyesight, just buy a new monitor. They are cheap.
-
Flipper's second LiteVNA arrived today. Using the same USB cable, PC, port, his has very poor performance. The serial number on mine is about 150 higher than the problem unit. I'll ask about the SN# for second Lite he bought as it also shows much worse performance. Looking at the two, I don't see anything major sticking out but maybe they made an improvement with the newer units.
I would think their final test would have caught it but maybe the older ones are just poor and they had changed the design.
-
In Lite if remove DC block capacitor and ESD protection diode possible get better results on low frequency range < 10M (but this huge increase chance burn rf switch)
...
I prefer not do hardware mods (use for firmware tests only original hardware)
No problem. Did you see this data published somewhere that you can provide a link to it?
https://groups.io/g/liteVNA/message/210
When pulling the blocking capacitor, what is the common mode range? Would P1's source have a DC bias?
Would it be better to keep the block but change the value? I don't see a problem pulling the protection diode but find it odd it would improve the low frequency range.
Lack of schematics makes some of this a total guess. Plan is to modify Flipper's one bad unit and see if indeed there are any performance gains.
-
Hello, the flipper is one new device?
-
Hello, the flipper is one new device?
:-DD If you type in Flipper, then select the Search:
My friend Flipper ...
Flipper and I have been testing ....
I bounced it off my friend Flipper ....
-
Hoo! Luck good :-DD For people with software typewriter skills can dump the close NanoVNA V.2Plus4 firmware and open it for different FW?
For me is a problem I'm ignorant of typewriter software.
-
Maybe ask OWO in the mail group. Dislord has already posted about the V2+4 being locked. I suspect OWO's recent updates were firmware changes. I doubt they will be making that available for free. You may not see any further development on the V2+4.
I suspect most new buyers would purchase the Lite rather than the V2+4 because of the higher operating frequency, able to make narrow band measurements, much lower cost and the firmware is being maintained and continues to be stable.
-
the v.2plus4 is the firmware on the screen module is closed, the other can install Dislord fw, if the pc software makes the measurement is a very expensive upgrade from OWO with the same amount of money I buy other two LiteVNA :-DD
-
Hi all,
I am posting here because I am very interested in using Joe's software for PDN measurements.
To this end I have bought what I assumed/thought is/was informed should be an original NanoVNA, however, it appears to be a NanoVNA-H (bought from eleshop.eu which only sells "original" nanoVNA (H)s, according to their website https://eleshop.eu/nanovna-h.html ).
Reading through this thread it seems as if Knuddel in #1155 with some challenges made the NanoVNA-H work with the software ... however, there's no final confirmation of this in the pages following this post #1155 (as far as I can see) ... ?
In any case I am very genuinely interested in using this fine software for PDN measurements and somehow need to find a way either to:
- make the NanoVNA-H that I have bought work with Joe's software (much preferred), or
- find a vendor that sells the genuine "original nanoVNA" ...
Help into either of these possibilities would be very much appreciated ;)
Jesper
-
Hello Jesper, the first thing is to read the manual after downloading the software, watch Joe's Videos on the subject when connecting your NanoVNA start to test it, make the NanoVNA-H that you have bought work with Joe's software.
-
Hi all,
I am posting here because I am very interested in using Joe's software for PDN measurements.
To this end I have bought what I assumed/thought is/was informed should be an original NanoVNA, however, it appears to be a NanoVNA-H (bought from eleshop.eu which only sells "original" nanoVNA (H)s, according to their website https://eleshop.eu/nanovna-h.html ).
Reading through this thread it seems as if Knuddel in #1155 with some challenges made the NanoVNA-H work with the software ... however, there's no final confirmation of this in the pages following this post #1155 (as far as I can see) ... ?
In any case I am very genuinely interested in using this fine software for PDN measurements and somehow need to find a way either to:
- make the NanoVNA-H that I have bought work with Joe's software (much preferred), or
- find a vendor that sells the genuine "original nanoVNA" ...
Help into either of these possibilities would be very much appreciated ;)
Jesper
Jesper,
You and jspencerg have a lot in common. Had you read Knuddel and my posts following #1155, you know that their problem was due to their regional settings which has been covered many times. I suggest you make use of the search feature. It's very easy to use (see attached). I suggest searching "regional" or maybe "comma".
Of course, you never state what problem YOU are having. Only that you need to somehow make it work. Assuming you are running the latest software, the regional settings should be handled automatically so maybe you are having some other problem. Maybe you have the wrong software, wrong VISA, no VISA. Rather than my guessing, how about you provide a few details.
-
Demonstration of Solver64 with the LiteVNA.
https://www.youtube.com/watch?v=G4eLcTC4Ako (https://www.youtube.com/watch?v=G4eLcTC4Ako)
-
Hi All,
@Joeqsmith: Thanks, Joe, for your feedback.
However, I am treading a bit carefully here as - I hasten to add unrelated to your software as such - downloading & trying to install VISA for some unknown reason completely crashed my Win10 installation. And trying to re-install Win10, Microsoft's Win10 downloading interaction GUI did not state that it would fully overwrite all other files on the download drive. Maybe somebody else would know about this - but IME Microsoft products otherwise are very cautious to warn about such things so I didn't consider this an option when I didn't see any information about it.
Anyway, it means that my backup HDD has been erased. Including all photos from some years back and some very important files. I'm currently trying to recover the drive but it is a mess - files all over the place and the original file structure no longer present. So, I am a bit vulnerable right now - and being careful here ...
As to your feedback I can say that I normally do read the documentation I need to read and actually have read your manual (the pages relating to installation & PDN), seen many of your videos, and also read about the compatibility issue and about the regional settings. To this end I may have missed something but following #1155 I did not see Knuddel make a final confirmation that he made the software work with the NanoVNA-H version ...? But he did? That obviously would be the easiest solution since I already have bought the NanoVNA-H.
In any case I am fully aware that you provide this software for free - and I actually always do my best to respect other people's time (as much as I can). I know it is not "my time" and thus should be respected and appreciated when given!
I will send you a PM.
@realfran: Thank you also for considering and replying. I think I replied to your comments in the above ...
Cheers,
Jesper
-
Jesperl,
... downloading & trying to install VISA for some unknown reason completely crashed my Win10 installation. And trying to re-install Win10, Microsoft's Win10 downloading interaction GUI did not state that it would fully overwrite all other files on the download drive.
I've never had LabView crash a PC like you describe. What VISA were you installing? Where did you get it from?
...Anyway, it means that my backup HDD has been erased. Including all photos from some years back and some very important files. I'm currently trying to recover the drive but it is a mess - files all over the place and the original file structure no longer present. So, I am a bit vulnerable right now - and being careful here ...
I never understand how people put so much trust into their computers that they do not feel any need to back them up. It's always the same story of lost photos and business records. They spend hours trying to recover what may have taken minutes and a couple of FLASH drives to back up.
... I may have missed something but following #1155 I did not see Knuddel make a final confirmation that he made the software work with the NanoVNA-H version ...? But he did? That obviously would be the easiest solution since I already have bought the NanoVNA-H.
I doubt there was any sort of followup. People rarely post unless there is a problem. My guess is they went away once they had no more questions which is typical.
I will send you a PM.
I have no interest in using the PM as it does nothing to help others with the same problem. From your PM, I do not take donations or payments. When it comes to my software, I've had many people express their expectations. I can only imagine how the general population behaves when you go down this path. "I donated a dollar and demand you do what I say!!" Pretty much how many behave today without any donations.
-
Jesperl,
Searching with Google to see if there was some sort of trend, I found one hit that may be related.
https://forums.ni.com/t5/LabVIEW/Windows-crash-after-NI-VISA-driver-installation/td-p/4184355
-
Following Dislord's recommendation to remove the DC blocking capacitors, I ran a few tests today.
The two blocking caps appear to be 1uF. at 50 ohms, the 3dB cutoff would be 3200Hz. I decided to replace both with a 4.7uF and see what effects lowering it to 680Hz had. Again, both protection diodes had been removed. First, I reinserted the 2 X resistors and diode to bring the power supply circuit back to stock. I saw no difference in performance.
I then replaced both blocking caps with a zero ohm jumper. Again, I saw no improvements. I then tried using the firmware's average set to 4. Very slow but data overlays with the original NanoVNA. Note, mylite is my original LiteVNA, unmodified.
The little dips and notches are still present like was shown during the video demonstration of the Lite. Compared with the original NanoVNA which is again, very smooth.
I would be VERY skeptical of any suggestions to change the Lite's hardware. From my perspective, there are no gains to be had removing the front end block and protection diode. The noise problems with the USB power supply are also solved with a simple series diode and bulk cap added to a USB cable.
***
poor wording
-
Hi Joe,
& thanks for considering & replying ... I think I will just consider what to do ...
Wishing you a pleasant day.
Jesper M
-
Hi Joe,
& thanks for considering & replying ... I think I will just consider what to do ...
Wishing you a pleasant day.
Jesper M
Jesper,
... downloading & trying to install VISA for some unknown reason completely crashed my Win10 installation. And trying to re-install Win10, Microsoft's Win10 downloading interaction GUI did not state that it would fully overwrite all other files on the download drive.
I've never had LabView crash a PC like you describe. What VISA were you installing? Where did you get it from?
I would have just started out answering the simple questions I asked you. It sounds like you may have tried to manually install the runtime and NIVISA rather than using the supplied installer. Which of course, can be done if you know what you are doing.
-
Now here's an interesting post about LabView:
Joe Smith has released a LabVIEW program to the public which supports the LiteVNA and may better suit you than VNA-QT, including the ability to control a transfer relay. LabVIEW is too resource intensive for my system, so I have not tried Joe's program yet.
Thinking of what PCs were around at the time Labview 2011 was released and what this poor person must have that LabView is too resource intensive for it.
Just for fun, showing the LiteVNA linked up and talking with my Lenovo MIIx2 8. Running it from MicroSD card. Not even using a mouse. Note the custom cable. This allows me to run the tablet off external power and maintain access to the USB port.
Almost forgot, yes, that's Windows 8.
Review says short on features but this unit has a GPS receiver built in. You can even run Microsoft Maps with it (old).
https://www.pcworld.com/article/444045/lenovo-miix-2-8-review-a-fast-tablet-thats-short-on-features.html (https://www.pcworld.com/article/444045/lenovo-miix-2-8-review-a-fast-tablet-thats-short-on-features.html)
https://groups.io/g/liteVNA/topic/recommended_windows_sw_to_use/89406609?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,89406609,previd=1646818766347533994,nextid=1642626865287766864&previd=1646818766347533994&nextid=1642626865287766864 (https://groups.io/g/liteVNA/topic/recommended_windows_sw_to_use/89406609?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,89406609,previd=1646818766347533994,nextid=1642626865287766864&previd=1646818766347533994&nextid=1642626865287766864)
-
Thinking of what PCs were around at the time Labview 2011 was released and what this poor person must have that LabView is too resource intensive for it.
That "poor person" has a i7 system with 16GB of ram but is lacking the space resource for adding another program when he generally only uses a PC to conveniently grab a screen shot, update the firmware or plot numerous traces. Please note I did say "my system". Each user should judge for themselves whether their system has similar space resource limitations or whether your program offers them a feature that is more important to them than the LiteVNA software they are currently using.
Herb
-
Thinking of what PCs were around at the time Labview 2011 was released and what this poor person must have that LabView is too resource intensive for it.
That "poor person" has a i7 system with 16GB of ram but is lacking the space resource for adding another program when he generally only uses a PC to conveniently grab a screen shot, update the firmware or plot numerous traces. Please note I did say "my system". Each user should judge for themselves whether their system has similar space resource limitations or whether your program offers them a feature that is more important to them than the LiteVNA software they are currently using.
Herb
I certainly understood this was your system and because you did not provide any details, people may be left with the idea that LabView will only run on the latest high end hardware. In contrast to your statement I wanted to show in detail what I consider to be a system with very limited resources available running my software. Up to 2016, I was running LabView 2011 on a P4 with Windows XP. Of course the new 64-bit software would not run on it but the released code certainly will and I had demonstrated that in the past.
It sounds like you're lacking the drive space to store it which in todays low cost large drives, it a fringe case. That old tablet has 32G built in. The OS takes up a fair chunk of that. 2011 doesn't require much for drive space compared with modern applications. The runtime and VISA are installed local. I think I have a 32G SDcard installed in that tablet to store my applications.
***
The older versions of LabView, like 2011 obviously require less resources than the latest version. To get some idea on the requirements to run Solver64, here is a link from 2021 showing the current version (most likely will release with this).
Disk Space: 620 MB
RAM: 256 MB
The program is about 16 MB.
https://www.ni.com/en-us/support/documentation/supplemental/17/system-requirements-for-labview-development-systems-and-modules.html (https://www.ni.com/en-us/support/documentation/supplemental/17/system-requirements-for-labview-development-systems-and-modules.html)
For fun, I searched "modern games PC requirements" and get this for my first hit:
Cyberpunk 2077
OS: Windows 10 (64-bit)
CPU: Intel® Core™ i7-4790 processor or better
RAM: 12GB
Graphics Card: NVIDIA GeForce GTX 1060 or AMD Radeon R9 Fury
Storage: At least 70 GB of available space
:-DD :-DD My old PC is showing it's age.
-
Hello, Solver64 with the LiteVNA demonstration is amazing, the software will be released in the coming day?
My V.2.8 setup works with the NanoVNA V2 SSA and the V2 Plus4, for the LiteVNA "Solver64 is best suitable. :-+
-
"... It sounds like you're lacking the drive space to store it which in todays low cost large drives, it a fringe case."
In my post on the other group, I suggested your program to a user interested in controlling a transfer relay. I could have been more detailed in explaining why I was suggesting a program that I hadn't used myself. A better explanation would have been that my current software needs are not very demanding and are met by the software I already use.
You are certainly correct that if I had a compelling reason to try your LabVIEW program, I could easily free up the necessary space resources to do so.
Herb
-
Hello, Solver64 with the LiteVNA demonstration is amazing, the software will be released in the coming day?
My V.2.8 setup works with the NanoVNA V2 SSA and the V2 Plus4, for the LiteVNA "Solver64 is best suitable. :-+
Running the software local vs watching it after capture, it looks slow. I have not played with the 64-bit versions of LabView until now because they were too limited. With 2022, they have dropped all support for 32-bits which tells me that it's time to finally upgrade. It makes better use of the PCs hardware and is noticeably faster on my old PC.
I have been testing with LabView 2020 rather than 2021 and will need to get a new license first and then test it. I did uncover a couple of bugs since making the demo which have now been addressed.
***
typo
-
"... It sounds like you're lacking the drive space to store it which in todays low cost large drives, it a fringe case."
In my post on the other group, I suggested your program to a user interested in controlling a transfer relay. I could have been more detailed in explaining why I was suggesting a program that I hadn't used myself. A better explanation would have been that my current software needs are not very demanding and are met by the software I already use.
You are certainly correct that if I had a compelling reason to try your LabVIEW program, I could easily free up the necessary space resources to do so.
Herb
I trust you know what resources your PC has and if it can run LabView or not. You say its too resource intensive and I believe you but I want to make it clear to others what the system requirements actually are. I suspect for most of us our PCs would not pose a problem.
I try to steer people away from using my software. Not because the system requirement for LabView but rather other free programs should have better support and be much easier to learn for the CB and radio hobbyist.
-
Hi Joe,
Before writing about the NanoVNA related topics I would just say that I have sent you another PM. Not intending to do this onwards - but in this context I found it to be more appropriate.
And then in relation to the NanoVNA, with hopefully the right details, and would appreciate your feedback:
Yesterday I downloaded the previous version of the software for the V2 Plus from this weblink:
https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10 (https://github.com/joeqsmith/NanoVNA_Software/releases/tag/0.10)
I downloaded all files (except the tar.gz file) and had 7-Zip do the unzipping of the files to a specific folder.
As I understand from the manual (r23 version), p.18, the .INI, runtime engine (labview runtime engine), and VISA drivers should be included in this original release (I assume it is this one I downloaded?):
The installer, .INI, runtime engine and VISA drivers will no longer be included. You may download these directly from NI, or just install the originalrelease of the V2+ software.
Unzipping created a folder sequence named "NanoVNA_V2Plus_Installer"->Volume->bin->dp and p0 to p34 folders. I went into the "dp" folder and clicked the "install" icon.
The installation started up, however, before the actual installation began there was an error message saying something like "that the installation needed Labview Runtime version 2011 SP1 to continue" (I am writing this from another harddisk than the harddisk I would like to install the NanoVNA software onto - and I do not exactly remember what the dialog box said).
Anyway, I went to NI labview runtime's download webpage and setup the dropboxes to be "Windows OS, 2011 version, 32 bits" and started download. However, for some reason NI labview runtime download doesn't work - what happens is that the NI webpages switch to a new webpage but "hangs" on this new webpage. There's a small circular clock-like icon that keeps rotating but nothing more happens.
I did this several times (and actually also the day before), and the same happens. I have contacted NI about this but they do not answer their phones here in Denmark (really unusual!) - and I couldn't find another email than their web feedback email which I have sent an email about this So no success yet wrt this. Anyone else here have the correct labview runtime, VISA driver, and maybe INI file to use? Would be very helpful ...
Regarding your question:
What VISA were you installing? Where did you get it from?
I can say that when my Win10 installation crashed I used a VISA driver that I had downloaded from this NI webpage:
https://www.ni.com/da-dk/support/downloads/drivers/download.ni-visa.html#442805 (https://www.ni.com/da-dk/support/downloads/drivers/download.ni-visa.html#442805)
I do not remember which version I downloaded but I likely would have chosen the newest one. It may also be relevant to say that the Win10 was installed on an older laptop of mine - a Lenovo T61 (4 GB RAM) which I normally use for my CNC mill. It usuall works fine - but this PC has been dedicated to the CNC mill use and overall has not been used for anything else.
I normally use Win7 Pro 64 bits - this OS goes well with other programs I use, and if possible I would much appreciate advice on how to setup the NanoVNA software on this OS. The computer used with the Win7 OS is a Dell Latitude E6420, I3 processor, with 8 GB RAM and Samsung 850 SSD HDD. But I can/will install the Win10 on this computer as well (Win10 Pro, Samsung 830 SSD).
I would appreciate help as to what I may be doing incorrectly - and also if others are able to download the NI labview runtime ...? I even tried to download it on my smartphone :o but that didn't work either ...
:palm: Jesper
-
Jesper,
It seems you fell into the trap of not reading the instructions in the README and then randomly downloading files. It's a common theme.
I downloaded all files (except the tar.gz file) and had 7-Zip do the unzipping of the files to a specific folder.
Ok
Unzipping created a folder sequence named "NanoVNA_V2Plus_Installer"->Volume->bin->dp and p0 to p34 folders. I went into the "dp" folder and clicked the "install" icon.
Wrong
The installation started up, however, before the actual installation began there was an error message saying something like "that the installation needed Labview Runtime version 2011 SP1 to continue" (I am writing this from another harddisk than the harddisk I would
like to install the NanoVNA software onto - and I do not exactly remember what the dialog box said).
The installation installs the runtime engine. This isn't Catch 22. See attached if you need help saving files and using 7-zip.
Considering you need to construct a transformer, DC blocks, learn the software..... If the project is for work, I would just buy a commercial system. There are many options to choose from depending on your specific requirements. You may end up having to do that anyway depending on your goals. It is after all a $50 device.
***
https://www.omicron-lab.com/products/vector-network-analysis/bode-100# (https://www.omicron-lab.com/products/vector-network-analysis/bode-100#)
https://www.picotest.com/products_PI_Station.html (https://www.picotest.com/products_PI_Station.html)
Brian from Copper Mountain Tech is also a member. You may want to contact him as well.
-
I spent some time today comparing the V2_2 schematic with the LiteVNA. Oddly enough they had used 10uF for the two blocks in place of the 1uF Flipper's had. There are also several other 10uF parts they has swapped for 1uF. Really strange is one part that I was ecpecting to be a 1uF on Flippers had a 0603 10uF. I wonder if that was a mistake in the Lite. I removed my two zero ohm jumpers that I had used to replace the blocks then inserted all 4.7uF parts just to see if it had any effect. I would need to order 10uF parts.
Shown in black was Flipper's stock Like, brown was adding a series diode with the USB power and red is with the two protection diodes pulled and all of the 1uFs in the signal path replaced with 4.7uF.
-
It's still not as good as the original NanoVNA but if I allow the firmware to average 2X and then average 10X and 20X in software, we can bring it well below. Not a good solution.
-
100uOhm shunt thru load. Original NanoVNA compared with Flipper's after capacitor mod and 10X software filter.
-
Hi Joe,
Thanks for your detailed & helpful reply & illustrations ;) ... I installed the software yesterday and it appears to have worked although I do not yet have a contact with the nanoVNA-H. Will look into it tomorrow.
Cheers & thanks,
Jesper
-
Jesper,
I installed the software yesterday and it appears to have worked although I do not yet have a contact with the nanoVNA-H.
I would have to guess at why it doesn't communicate. I have no idea which OS you ended up installing it on but it will make a difference. Let's guess and say you used the unsupported Windows 7. When I installed my software on that old Lenovo tablet which runs Windows 8, it did not include a compatible driver like 10 does. Did you install the driver? Did you then verify the PC assigned the comm port number using Device Manager? Then did you actually install the correct software for your VNA? Did you select the comm port that Device Manager shows in my software and save that to create the defaults file?
As I mentioned, you have a lot in common with jspencerg. You may not know how to pull the latest software for your H. I suggest you read the following several posts starting with:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4037986/#msg4037986 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4037986/#msg4037986)
Jspencerg never followed up so I can't say if they made it any further. Getting the software installed is trivial. If you follow the thread, you may think everyone is having problems. But I suspect it's more the only people who post are the ones having problems. Most will just install it and we will never hear from them.
I'll be very impressed if you manage to construct the peripherals and get any meaningful data. Somehow you will need to validate the setup.
-
Hello, considering the new feature of Solver64 with the possibility to upload firmware from it, I wonder if is possible to upload the @Dislord firmware on the V.2Plus4, I use with the PC and Solver64 the display module I don't use. ( I'm computer illiterate not possible for me to dump the closed source display FW)
-
Hello, considering the new feature of Solver64 with the possibility to upload firmware from it, I wonder if is possible to upload the @Dislord firmware on the V.2Plus4, I use with the PC and Solver64 the display module I don't use. ( I'm computer illiterate not possible for me to dump the closed source display FW)
Yes and I demo'ed it with the Lite. Previously to program my V2Plus, I used VNA_QT.EXE. The only reason I used the ST-Link with the V2Plus4 was to backup the original firmware. The reason I used my software rather than VNA_QT to program Dislord's firmware was that feature needed to be tested. If it's not clear, I reverted back to the original firmware.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021114/#msg4021114 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4021114/#msg4021114)
-
Yes is clear I like to test the @Dislord firmware (I don't like to be forced to use only the close source firmware) the one from @Dislord is open and continually improved.
Thank you for the information :-+
-
"... I wonder if is possible to upload the @Dislord firmware on the V.2Plus4"
Please note that the more recent versions of the V2Plus4 use a different display module and DiSlord's firmware will not work with them (display screen goes blank). Back up your firmware before updating if you are not sure which display module your V2Plus4 has installed. It's always a good idea to back-up your FW before upgrading, unless you already have a back-up copy, regardless.
DiSlord cautionary note when using his FW version for the V2Plus is as follows:
" !!!! V2Plus4 firmware work only on old V2Plus4 devices, new V2Plus4 devices have different LCD module not supported by this fw. As last V2Plus4 sources (software and hardware info) closed i not support it. !!! "
Herb
-
I have installed the @dislord firmware on the V2plus4 the only thing the display module does not work, I use PC only for the NanoVNA v.2Plus with the NanoSolver64 software I hope will be OK (eventually I reinstall the native firmware).
-
I have installed the @dislord firmware on the V2plus4 the only thing the display module does not work, I use PC only for the NanoVNA v.2Plus with the NanoSolver64 software I hope will be OK (eventually I reinstall the native firmware).
If the firmware is 100% backward compatible with the original, then it should work. You should be able to run it with the current release. If that does not work, then the new software will not work as well.
-
This is @Dislord !.2.03 FW for V2Plus4 testing one 2Ghz HP Low-Pass-Filter work the only thing the Nano Solver64 got more possibility for use it from the PC
-
It seems to work, so the new version shouldn't be a problem. What OS do you plan to try an run it on?
-
Re: XferRly Err
I release this error has to do with program expectation of a transfer relay, which I do not have. I don't get how to adjust settings so this error light will not occur. Does it matter?
Thanks.
-
Re: S21 and S12
It's my understanding that these NanoVNA cannot do an S12. You have emulated S12 by building in support for xfer relay functionality. Right?
I am not seeing how to select a one port calibration. How?
Selecting the two port calibration without a xfer relay would entail putting the shunt and load on port A when it asks for port B because it thinks there is xfer relay installed. These vna's can't put out a signal through port B, right? (I realize I'm repeating myself. The omission of this in manual seems like a big deal to me). Please set me straight about my understanding.
-
If the software finds a valid comm port for the one you assigned to the transfer relay, it will attempt to talk to it. If the comm port does not have have the proper handshake signal for the transfer relay, it will set the error. I assign the port IDed in Device Manager for the transfer relay and save that as the default. If I remove the transfer relay, Windows no longer reports it being a valid to my software. If I plug it back in, Windows will once again report it is present. Windows 10 does a decent job with the assignment and keeps the same port number.
Odd your PC would behave any different as I would assume all Windows 10 behaves this way. Otherwise it would be a nightmare to have to determine the VNAs port every time the software runs. Then again, it seems someone had posted how they did not use the defaults file and would set it up manually every time.
I can see that a basic computer course is needed. I know an elderly lady who still uses AOL!! :-DD
-
Re: S21 and S12
It's my understanding that these NanoVNA cannot do an S12. You have emulated S12 by building in support for xfer relay functionality. Right?
I am not seeing how to select a one port calibration. How?
Selecting the two port calibration without a xfer relay would entail putting the shunt and load on port A when it asks for port B because it thinks there is xfer relay installed. These vna's can't put out a signal through port B, right? (I realize I'm repeating myself. The omission of this in manual seems like a big deal to me). Please set me straight about my understanding.
Yes, the manual includes details about adding a transfer relay in order to measure all four S-parameters. If you tell the software you have a transfer relay by assigning a valid port number to it, it will attempt to use it. This includes calibration.
I wrote the software this way because I am lazy. I don't want to have to tell the software if I have the relay installed or not. If its there I want Windows to tell me it's there and use it.
***
Also, that last video I posted for the Lite demonstrated how to use the transfer relay.
***
If you are curious why I have an enable selection for the stage controller but not for the transfer relay, the USB adapter I use for the transfer relay is dedicated hardware. The only time it is installed in the PC is when I am using it. The stage uses a USB adapter that I use to interface with other peripherals. In that case, it is very possible that it may be installed at the time start the software.
I could have chose to do something similar for the transfer relay but again, I didn't want to have to select it every time I wanted to use it. Again, lazy.
-
Shown in the upper right are the standards supplied with my Lite compared with parts from the V2Plus4. I looked at the load standard supplied with my Lite and it's not very good but it's better than the remaining parts from Mini-Circuits. I would need to buy another batch and hope for another decent one.
-
Re: USB ports and calibration
I realize I was assigning port when I should not have been. Only needed to assign port for the VNA.
However, I find that not assigning a port for the relay does not seem to change the calibration options. 2-port button still there, but not the SOLT for port A. I'll check to see if it asks for the port B short and load.
Regarding the message "select transfer relay and cross talk" Are they program options? Is it referring to selecting port for transfer relay and for setting cross talk coefficient?
I'm not an old lady and you're not lazy. I know programming for oneself as the primary user leads to "common sense" decisions. There is no such thing.
I just found a used transfer relay for $802 on ebay.
82152-700C70200 - TRANSCO - TRANSFER LATCHING RELAY 28VDC, SWITCH-RFF XMSN LINE
Is that a fair price? Is that general pricing for this functionality?
Thank you.
-
I use Win10/64 the installation I did on one Pentium two core with 8 Ghb ram and 250Ghb SSD hard disk I live in the background the NanoVNA working all day on running the software, other PC I use is one Xenon with 16Gbt memory and 500Ghb SSD hard disk for the OS and 2TB HD for backup.
I'm computer illiterate, I typewriter with two fingers, I don't use Babbuino too hard for me, I tray many times Linux and I get lost on the console.
-
I use Win10/64 the installation I did on one Pentium two core with 8 Ghb ram and 250Ghb SSD hard disk I live in the background the NanoVNA working all day on running the software, other PC I use is one Xenon with 16Gbt memory and 500Ghb SSD hard disk for the OS and 2TB HD for backup.
I just found a used transfer relay for $802 on eBay.
82152-700C70200 - TRANSCO - TRANSFER LATCHING RELAY 28VDC, SWITCH-RFF XMSN LINE
Is that a fair price? Is that general pricing for this functionality?
No is very expensive for $120 VNA gadget, I use one old HP VNA Switching test set, inside 2 switching relays (two relays improve isolation end get very low crosstalk) however the LiteVNA don't notice a big problem for the specs of it.
The transfer relay worked well I integrate the LiteVNA with the T/R relay using a very short semirigid original coax from the HP VNA switching test set to the N connectors.
-
Hi Joe,
Let's guess and say you used the unsupported Windows 7. When I installed my software on that old Lenovo tablet which runs Windows 8, it did not include a compatible driver like 10 does. Did you install the driver? Did you then verify the PC assigned the comm port number using Device Manager?
With reference to your manual Supports Windows 10 (may run on OS’s as early as XP)
I chose to install it on Win7. And, no, I did not know that I would need to install other drivers.
Jspencerg never followed up so I can't say if they made it any further. Getting the software installed is trivial. If you follow the thread, you may think everyone is having problems. But I suspect it's more the only people who post are the ones having problems. Most will just install it and we will never hear from them.
I'll be very impressed if you manage to construct the peripherals and get any meaningful data. Somehow you will need to validate the setup.
I simply just work at my best when the people around me have confidence in me and my abilities to find solutions and engage positively in the personal exchange.
For me it just doesn't work in this context and I have now chosen to accept this.
So I will leave it here.
Be well,
Jesper
-
Re: USB ports and calibration
I realize I was assigning port when I should not have been. Only needed to assign port for the VNA.
However, I find that not assigning a port for the relay does not seem to change the calibration options. 2-port button still there, but not the SOLT for port A.
SOLT Short, Open, Load, Thru
Wouldn't the thru be difficult without a second port?
I'll check to see if it asks for the port B short and load.
From the manual:
This software has the ability to control a transfer relay. If this option was enabled prior to selecting the calibration, you would be prompted to repeat this process for port B (2).
Regarding the message "select transfer relay and cross talk" Are they program options? Is it referring to selecting port for transfer relay and for setting cross talk coefficient?
I'm not an old lady and you're not lazy. I know programming for oneself as the primary user leads to "common sense" decisions. There is no such thing.
I just found a used transfer relay for $802 on ebay.
82152-700C70200 - TRANSCO - TRANSFER LATCHING RELAY 28VDC, SWITCH-RFF XMSN LINE
Is that a fair price? Is that general pricing for this functionality?
Thank you.
Leakage was also covered in the manual.
I think Flipper paid under $100 for a NOS Transco transfer relay. At $800, I expect you could get a new one from Pasternak.
-
I use Win10/64 the installation I did on one Pentium two core with 8 Ghb ram and 250Ghb SSD hard disk I live in the background the NanoVNA working all day on running the software...
Very nice!!
-
Jesper,
Hi Joe,
Let's guess and say you used the unsupported Windows 7. When I installed my software on that old Lenovo tablet which runs Windows 8, it did not include a compatible driver like 10 does. Did you install the driver? Did you then verify the PC assigned the comm port number using Device Manager?
With reference to your manual Supports Windows 10 (may run on OS’s as early as XP)
I chose to install it on Win7. And, no, I did not know that I would need to install other drivers.
Yes the manual states:
Supports Windows 10 (may run on OS’s as early as XP).
While I have shown it running on XP, the only OS that is supported is 10. The use of the word "may" can be better understood from the manual's scope:
This manual assumes the reader is PC literate and has some basic understanding of how a VNA works. It is not a learner’s guide on using a VNA and offers no assistance into solving basic computer related problems.
Also from the manual:
The software will include an installer which contains the runtime engine only. No drivers will be included beyond NIVISA.
...
You will want to have all the drivers installed and make sure your PC is seeing the device before getting started. The software was tested using both the recommended Cypress as well as Microsoft's included drivers. No differences in their performance were noted.
Installing drivers and making sure the OS can ID the your device is pretty much standard practice for any peripheral you install.
Jspencerg never followed up so I can't say if they made it any further. Getting the software installed is trivial. If you follow the thread, you may think everyone is having problems. But I suspect it's more the only people who post are the ones having problems. Most will just install it and we will never hear from them.
I'll be very impressed if you manage to construct the peripherals and get any meaningful data. Somehow you will need to validate the setup.
I simply just work at my best when the people around me have confidence in me and my abilities to find solutions and engage positively in the personal exchange.
For me it just doesn't work in this context and I have now chosen to accept this.
So I will leave it here.
Be well,
Jesper
For myself, I enjoy learning new things but not everyone is wired like that, like my elderly lady friend with her AOL.
From the manual:
My software was not written for this group (radio community). It was designed as an engineering tool for the RF experimenter.
While this forum's owner suggests that anyone who calls themselves an engineer is one, I do not prescribe to that idea. The harsh reality is that while these VNAs can be had for $50, it doesn't mean that just anyone can sit down and be some sort of expert in minutes. The fact you are having problems reading the manual and not knowing some of the basics on how to use your PC tells me this will be a very difficult task for you. Your willingness to give up may have saved you a lot a headache.
-
:palm: Does it really not dawn to you that the installation problems people have originate from your end? And on top of that you belittle people that get lost along your breadcrumb trail. Quoting over and over again from an incomplete manual isn't going to help; just fix the manual. I admire the effort that you put into your software but your belittling tone towards people is putting me off big time. Just like Jesper I have lost all interest in even trying to get your software to work. There are tons of other tools around for the NanoVNA so there is no need to put up with such abuse.
-
Re: A real "two-port" calibration
What do you call a SOLT calibration that is done where port 2 can only receive? I wouldn't think that would be a 2-port calibration.
-
Re: Using a transfer relay
Thanks for comments regarding the $800 relay I saw on ebay. Pricing there often needs serious reality check.
I was also seeing pricing for relays, claiming to be new, for under $100.
https://www.ebay.com/itm/255349680593?epid=28052016567&hash=item3b7406e9d1:g:hBEAAOSwmX5hgWGc (https://www.ebay.com/itm/255349680593?epid=28052016567&hash=item3b7406e9d1:g:hBEAAOSwmX5hgWGc)
My question is what specifications are necessary for the relay to work with the software?
-
:palm: Does it really not dawn to you that the installation problems people have originate from your end? And on top of that you belittle people that get lost along your breadcrumb trail. Quoting over and over again from an incomplete manual isn't going to help; just fix the manual. I admire the effort that you put into your software but your belittling tone towards people is putting me off big time. Just like Jesper I have lost all interest in even trying to get your software to work. There are tons of other tools around for the NanoVNA so there is no need to put up with such abuse.
I have made my software available for free to those that want to use it but that does not mean it comes with unlimited support or for that matter any support. I have no desire to try and educate people on the basics of how to use a PC. Especially if you are asking questions that have already been covered. In your case, even when I handed you the answer, you couldn't be bothered to read it and asked the same question yet again. You may feel your time is too valuable or maybe just need an excuse. As I have already explained to you, I will not be making any updates to the old repository. This includes the documentation.
-
My 2 cents:
Mr. Smith has reluctantly made available a software tool that he wrote for himself. It is obvious, as he has often said, that he does not want to promote it or put much effort into teaching others to use it. I am surprised he bothers to answer my ignorant, incompetent questions. I am still glad he does.
-
Re: A real "two-port" calibration
What do you call a SOLT calibration that is done where port 2 can only receive? I wouldn't think that would be a 2-port calibration.
Single path two port. With the transfer relay, a full two port.
See one path two port:
https://coppermountaintech.com/help-s2/one-path-two-port-calibration2.html (https://coppermountaintech.com/help-s2/one-path-two-port-calibration2.html)
Re: Using a transfer relay
Thanks for comments regarding the $800 relay I saw on ebay. Pricing there often needs serious reality check.
I was also seeing pricing for relays, claiming to be new, for under $100.
https://www.ebay.com/itm/255349680593?epid=28052016567&hash=item3b7406e9d1:g:hBEAAOSwmX5hgWGc (https://www.ebay.com/itm/255349680593?epid=28052016567&hash=item3b7406e9d1:g:hBEAAOSwmX5hgWGc)
My question is what specifications are necessary for the relay to work with the software?
The software will use one handshake pin to control the relays two states. The software checks the status of one of the handshake pins and will set an error flag but it does not do anything else with it. So, there really are no other requirements outside of having the one pin select the state.
From a hardware standpoint, you would need to design what ever interface to control your specific relay. Because there are many devices available, that's really up to the designer to sort out.
I had used realfran's data as an example in the last video to demonstrate the transfer relay. Looking at what realfran recently posted:
I use one old HP VNA Switching test set, inside 2 switching relays (two relays improve isolation end get very low crosstalk) however the LiteVNA don't notice a big problem for the specs of it.
The transfer relay worked well I integrate the LiteVNA with the T/R relay using a very short semirigid original coax from the HP VNA switching test set to the N connectors.
I now suspect this is the cause of their problem. I have seen others talk about using 2 VNAs in place of a transfer relay to save cost as well as use two separate switches. The 2 X switches would require some sort of T and extra stubs. Not a great solution. *** But better than the 2 X VNA proposal.
-
My 2 cents:
Mr. Smith has reluctantly made available a software tool that he wrote for himself. It is obvious, as he has often said, that he does not want to promote it or put much effort into teaching others to use it. I am surprised he bothers to answer my ignorant, incompetent questions. I am still glad he does.
I dare say I have spent a fair amount of effort attempting to teach others to use my software (and general use of a VNA). Putting the manual together and creating the videos was a major effort when you consider I give it all away free of charge.
***
I would like to add that being incompetent or ignorant on a subject is not a problem. I am very ignorant on most subjects. For subjects where I am interested, I may invest the time to educate myself. Normally by reading and experimenting.
Expecting anything from me will not go over well but asking me for help when I can clearly see you are trying to better yourself is typically not a problem.
-
Please read the manual step by step (I'm computer illiterate)
The transfer relay is controlled by the state of the RTS pin. When RTS is de-asserted, Port 1
and 2 of the VNA will route to Ports 1 and 2 of the transfer relay. When RTS is asserted, Port
1 and 2 of the VNA will route to Ports 2 and 1 of the transfer relay. The software expects the
transfer relay to always assert the CTS pin, or it will set the transfer relay error (XferRly Err).
The software really doesn’t care what type of transfer relay is attached. It uses a common USB
– TTL adapter from FTDI. The RTS signal is used to select the state of the relay and the CTS
is used to monitor it’s status. The communications port is selected in the Setup/Diagnostics
page using the XferPort. Again, the BAUD rate has no effect. The selected port is saved as part
of the defaults. Shown is the FTDI cable attached to the Transco controller.
After this, I go online to study the serial port connection and the FTDI converter to USB (I'm totally ignorant of digital) I built one transistor NPN one diode two resistors
and one small relay to driver the T/R relay.
-
Re: Transfer Relay
I found a new unit that appears identical to the Transco relay Joe recommended in the manual. Bought it. I'm willing to give it a go though I'm not sure how to connect everything(anything).
-
Re: Transco relays
Joe's relay has different activation wiring. Unit I ordered has only two wires. No sign of Transco, absorbed by another company? Dow-Key microwave appears to make similar units. Identified likely schematic for my unit. There are several units with 3+ control wires. Attached catalogue of coaxial relays.
[attachmini=1]
-
The manual provided the part number for the relay I used but again the software will not care.
-
The relay activation methods seem to be only difference between models. I don't know why or when one switching activation would be preferred. My two-wire input is simplest of them all.
Creating this port- switching arrangement is a rabbit hole I had not planned on.
-
Your relay will require a constant supply for one state vs my latching type that only requires a small pulse to change the state. My average current draw is basically 0 off the USB port. You could use a simple RC diode circuit to reduce the hold current after it switches if that is a concern for you. They may not spec the hold current but easy enough to swag.
Do you have a clear goal in mind or just wanting to play? Just curious. Obviously you are adding variables and as we saw from realfrans, it can cause some problems. If the goal is to measure active circuits, keep in mind that square wave drive. If you just want to play with it, maybe build a T-Check to go with it. In the last video I made, I show the home made T-Check and transfer relay giving some decent results to a GHz or so.
-
The transfer relay on my set-up is one design from HP there is two really switches on H the 141T" semirigid from the relays to the N connectors hare the original length. The only thing I change is the relay drives, the connection from LiteVNA port and the relays are connected directly.
The LiteVNA for is limited specs don't notice a big problem of crosstalk or isolation on the end of all is hobby instrument, not metrology grade device.
The calibration on the software helps a lot to minimize the difference.
-
Re: My goals
I'm interested in the science. I'm studying the theories and applications of EE. Waves were always central to my engineering and science. Learning about, measuring and controlling EM wave behavior fascinates me. As a hands-on person I've always considered that being able to measure something is a core endeavor.
I'm having fun with it.
-
The HP8711A seems to have had an upper end of 1.3G. This makes sense that the data you posted for your Mini-Circuits attenuator was so poor at 6GHz. I imagine the extra stubs are a problem. I had no luck finding a clear photo of what it looks like inside.
I'm studying the theories and applications of EE.
I've been in that same boat for many decades and still know very little about electronics. There's just not enough time. :-DD
-
Re: Learning EE et. al.
The amount to learn just keeps growing too. Plasmonics... Where will this field lead to?
The great thing for me is the availability of learning resources and hands- on experiments I can do while learning.
Having so many experts, or at least very competent people, on YouTube, etc sharing and teaching is a huge boost for me.
I'm going to recreate your power circuit for relay using Microcap and then modify for my relay. It'll be a big learning process all the way.
Do you use RG58 with stranded core for your instrumental connections?
-
Mostly I use RG223, RG400/U, RG188
https://www.pasternack.com/flexible-0.122-rg188-ds-50-ohm-coax-cable-ptfe-jacket-rg188-ds-p.aspx (https://www.pasternack.com/flexible-0.122-rg188-ds-50-ohm-coax-cable-ptfe-jacket-rg188-ds-p.aspx)
Link shows a photo of the custom blue cables I use in a fair number of videos.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3954551/#msg3954551 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3954551/#msg3954551)
-
Re: Meaning of vat-15 scan?
I'm thinking the v2plus4 did good job of measuring the gain. Shows loss of functionality at +5GHz because attenuator data sheet says attenuation should be going down as frequency increases.
Unknown is how dependable the units are to follow spec's. Have to verify attenuator on another VNA.
How's that for reading results?
Looking at cable specs: I see the double- shielded cables have higher operating frequencies.
Thanks.
-
I wouldn't expect to see that much ripple, even when using the ideal models.
Yes, the cable I use will normally outperform RG58.
-
Re: ripple in attenuation level
Would the ripple decrease if measurement taken over narrower frequency range?
Is there good rule for samples/Mhz where not expecting filter or resonant effects?
-
That's a good question for you and realfran to sort out.
-
I set up v2plus4 as shown in screen shot. Calibrated it. I'm getting nothing when I sweep. Seems locked up.
Restarted all. Ran without calibration. Normalized with a thru. Connected 2W 20db attenuator from aliexp. Obtained screen shot.
v2plus4 clearly breaks down about 4.5GHz. Results lower than that look really good.
This locking up after calibration always occurs. My nanovna-h does not have that problem. Is there something to check or fix for this issue?
-
Re: lockup
You would need to provide more details beyond suggesting it locked up. I suggest you look at the specs for your V2Plus4:
https://nanorfe.com/nanovna-v2.html
Someone else once told me how my software was locking up after calibration. They too provided no details. In the end, after they provided screen shots, I could see they had entered their own coefficients for the standards. They had zero'ed out C0 which then caused a divide by zero and the software was showing NAN (not a number). I talked about that specific problem in the last video I made.
I don't typically limit the software to try and protect the user from themselves. If you want to program your V2+4 for 20GHz, the software will gladly attempt it. As I said during that last video, I now add a small offset to C0 to avoid diving by zero. I also talked about someone who was attempting to set the number of data points to something very small (as this apparently improves the distance resolution in TDR mode), which would put a very high demand on the CPU to the point where the OS may become non-responsive. The new software attempts to throttle the system. So there are a few things that I added in an attempt to prevent users from shooting themselves in the foot. We also now handle the regional settings for much the same reason.
-
Maybe this will help:
https://nanorfe.com/forum/Preview-of-my-latest-software-updates.html
scroll down to:
Guido ON7CH 2021/11/19 13:57
Guido,
If you want to try and solve it, as I have wrote many times, you need to provide enough detail for me to replicate the problem. I don't have enough time to guess at what you are doing. Post a screen shot of the Calibration terms you have entered and AFTER you calibrate, post a picture of the coefficients. Are you saving the settings, if so, upload the defaults file you have created. I wonder what you are actually seeing when you suggest CH0_Z freezes. Again, a screen shot would have helped.
I have not actually used more than the first entry in the standards with the V2Plus4 but I have used more than 10 with the other VNAs and they pull from the same code base. CH0_Z should never freeze and there is nothing magic about the tenth entry. Maybe post a photo of the data supplied with your calibration standards. I think with all of this information, we should see the problem rather quickly.
-
I have not adjusted any values you mentioned prior to or after calibration. I'll study on this, see if I can find pattern of failure or success.
-
That's one clue. I have not tried to run the V2Plus4 outside of it's operating range like you are and I am not sure how my firmware responds compared with yours. You could provide screen shots like the other person did. That would certainly help me understand what is happening.
-
This is not something I would normally do but again, the software will certainly allow you to. Don't expect it to somehow magically increase the upper range of your equipment.
-
Re: vat-15+ results and documenting programs
I now divine you ran that test with the litevna rather than v2plus4. That is why you ran it to 6.4Ghz. Yes, I know that is outside the v2plus4 range. My assumption based on program version you ran, would have thought you'd run litevna on the new solver64 software. Did not understand hardware ID at top of page.
I'm reading suggested posts. Realizing the depth and breadth of responses you've made. For me, repeating myself and continually referring back to past answers would be tiresome and frustrating. Would compiling and sorting question/answers into a searchable FAQ style page create a user reference akin to a manual? I understand you're not writing another manual. Your postings have created an unapproachable(big) archive of advice and details for us newbies.
Thanks for your help.
-
Yes, realfran had ran their VAT15 on their LiteVNA. I assume they used their transfer relay to collect that data. I suspect they ran it at 6.4GHz to show how well it worked but they show a lot of ripple. There was a reason I suggested you work with them to answer your question about the ripple.
Because the newer LiteVNA is somewhat backwards compatible with the V2Plus4, the software I wrote for the V2Plus4 does indeed support it to some extent.
Answering questions, especially repeated ones can also be tiresome and frustrating. You certainly could create a FAQ if you want to just like nctnico could also write an installation manual. Don't expect me to create any new documentation. People will not read it. In the future I will most likely stop attempting to answer the more basic questions.
-
Re: answering questions
"In the future I will most likely stop attempting to answer the more basic questions."
I expect anyone would grow tired of repeating themselves. Regrettable you don't want to organize the help you've already provided. I don't have to understanding necessary to transform your conversations into a categorized FAQ.
-
Re: v2plus4 locking up
Attempted calibration after first reading of postings with Guido. Same behavior. Program not displaying same errors as his. Don't know where to go from here. Attaching screen shots.
PS Reset all. Attempted calibration between 10M and 300M with 401 pts. Same results. Calibration terms identical.
-
Another pic
-
One more. Attaching all three to same post was not working.
-
Re: Regrettable you don't want to organize the help you've already provided.
People will not read it which is indeed regrettable.
Notice how every picture you show the sweep is turned off. Surely you don't expect it to sweep when you are telling it not to. We can see in the last screen shot that the VNA is not sending any data which I would expect when the sweeps are turned off.
Lets assume this is not the problem. For me to look into it, you need write a detailed procedure that I can use to replicate the problem. Document every step from the time you turn on the VNA. If you can do this, there is a good chance that if there is a problem, I could fix it or at least tell you where the problem is. Consider that I used the V2Plus4 a fair amount with this software and had no problems like you describe.
***
Make sure you include the firmware information as well. Every detail is important.
-
Looking at the code, the only thing that make sense is not enabling the sweep. You could run through the calibration process with sweep turned off. The software will not care and happy do it. Of course, it will be very fast as its not collecting any data. The coefficients will not be created like you show as there was no data collected to create them. The cal LED will be active as it made it through the calibration.
However, you wrote:
I'm getting nothing when I sweep. Seems locked up.
I suspect you actually do press the sweep after you have ran through a cal without the sweep enabled. The software being cal'ed is of course calculating the display values based on these nulled coefficients. It's going to display a lot of nothing just like you asked. You then turn off the calibration and like magic, it starts displaying data because it no longer uses the nulled coefficients.
12.5 Displaying Data
The software will default to a center frequency of 10MHz with a 2MHz span and 201 data points (Frequency spectrum shown in Figure 11). The V2+ was programmed with these defaults when the connection was made. The V2+ is actually sweeping at this time. Select the Sweep button and the software will begin collecting data from the V2+.
Maybe there is actually a problem but you have not provided any details on how to replicate it. I suspect like many, it's easier for you to post on the forums than to use that time to try and understand what is going on. Most of the basics were covered during the videos and the manual.
-
I'll retry and document procedure today.
-
Re: "freezing up"
Realized as soon as I read your comments: I was not enabling sweep BEFORE calibrating. Works fine. Duh. Newbie mistake.
Calibrated 1001 points from 1M to 4.5G. Connected said same 20db attenuator. Lots of jitter at higher frequencies, but looks as though average would be fine till around 3.25G. Shown is results using normalization. Not appreciable difference without normalization.
Thanks for your help!
I've been salvaging components. Interesting in characterizing Inductors and common mode transformers. Lots of approaches from you and others. Going to build holder(s) to test. Fun stuff!
Parts for transfer relay arriving within week. Need to study up on circuit build to power and connection details for usb. I'm so ignorant.
-
It looks like you may have the leakage term disabled. OWO mentioned the problem with the V2Plus4 when I first received mine. I would just save that waveform to memory then enable the leakage and see how much it changes....
You seem to failed to read my post so I will repeat myself, I suggest you look at the specs for your V2Plus4: https://nanorfe.com/nanovna-v2.html
And again, READ the attached.
Surely you understand that 4.5GHz is > 4.4GHz??
***
It also appears that you calibrate the system and then use the normalize after the cal.
-
Re: Your feedback
1. Thanks for reminder about leakage. I'll study that and incorporate.
2. I know I'm exceeding freq. limits. I'm pushing beyond to see if the published limit is accurate for my unit. No harm there. Will not try that with dbm limit!
3. Yes. I calibrated before trying normalizing. I did not realize that would be a mistake.
Thanks.
-
I assume you ran your V2Plus4 standalone, setting the range to 4.5GHz and it allowed it. From that you feel there may be something to gain. My software wouldn't care and assumes you know what you are doing. The reason I mention it is I think the firmware I have for the V2+4 will coerce the data to stay within the limits. Obviously, if that were the case you are just fooling yourself. One way to get more BW is to go with the LiteVNA. It's about half the cost and offers a lot more bang for the buck anyway. I'm surprised that you wouldn't have gone with it.
I don't consider attempting to run your equipment outside of the specified range, normalizing after cal or even running a calibration with the data collection turned off a mistake. Again, I try to keep the software as open and flexible as possible as it is an engineering tool after all and not recommended for the beginner. Your mistake comes when you suggested the software locks up when it's just doing what you told it. One way to avoid that would be to read the manual.
For the leakage, just turn it on. There is no need to recal or change your setup.
***
I just checked my V2+4 with the original firmware (20201010-86c7055) installed and indeed mine will coerce the setting to keep it in range. If I enter 4.5GHz, mine will coerce to 4.4GHz. So you must have newer firmware than mine. Or you believe my software somehow overcomes this limitation, which of course, it does not.
-
Solver64 is now available.
-
SOLVED ( ini.file) :-+
-
Solver64 is now available.
Works perfect, no problems so far.
Many thanks!
-
Hello Joe,
"the LiteVNA. It's about half the cost and offers a lot more bang for the buck anyway. I'm surprised that you wouldn't have gone with it."
I asked you which version of the vna's to get. You said either the original or the v2plus4 would be good for learning.
"read the manual" I did. I still make mistakes. This is all new I did not have the common sense that the calibration session was going too fast (without first activating the sweep). Details, details. Still working on the details.
I found a good reference for calculating the Z (and other associated) parameters. Studying the math of it. I don't suppose I could look at the code you settled on for your calculations?
-
JoeQSmith:
https://www.ni.com/en-us/shop/labview/select-edition/labview-community-edition.html (https://www.ni.com/en-us/shop/labview/select-edition/labview-community-edition.html)
https://www.ni.com/en-us/support/documentation/supplemental/20/labview-community-edition-usage-details.html (https://www.ni.com/en-us/support/documentation/supplemental/20/labview-community-edition-usage-details.html)
In general, non-commercial and non-industrial references any use case that is not intended to make a profit. The LabVIEW Community Edition is intended for personal projects. Here are some examples:
Home hobbyist projects
Making free, open-source projects or add-ons for the community to reuse
Using LabVIEW to study for an upcoming certification
Using LabVIEW at home to keep skills sharp or try out new ideas outside of work
[/b]
I'm not particularly sure how restricted (if at all) the community edition is, but you certainly do fit at least one of those. 'add-ons for community use'. I'm one of those weird people who reads through the whole EULA, and it doesn't have anything about redistribution of software, but based on what's specifically stricted by the EULA, you're definitely fine on that end. I'd feel safe using it if I were in your position.
But other than that, you should start doing things along the lines of "Marco Reps" but someone with +25 years. The content is technical yet diverse, funny delivery and good content. He manages to make the concept of guarding against current loops on test equipment funny. A feat most people would think impossible. He made his own milling machine and got like 10 videos out of that-- testing different controller setups and things like their acceleration profiles, different ballscrews to see how linear they are, spindles and their run-out, and then finally showing the project & it's performance.
I think he got reliability works down to the mid-nanometers. Sure, Edmunds would build you something with the same numbers but enjoy paying a few million for it. He got way past metal machining numbers, competing with optical numbers (where you break out optical test flats under HeNe(600ish nm?) with eh, 8 interference fringe patterns gets you into the double digit nanometers. (He obviously can't *do* optical because it's not equipped with the necessary spindles, vibration damping, tooling to avoid subsurface fracturing, etc, and he was definitely hitting those numbers against standard cold rolled steel.)
Wow that went off topic.
Again, for 22000 subs (crazy), you've tested like...them all. Except the Euro version of the UT61E. I forgot where I heard this mentioned, but they're supposed to be hardened up. I think using an actual HRC fuse and some such? If you do test it, and it turns out to be a good buy, PM me 24 hours before you post the video, so I can buy one before the rush hits.
Testing components too would be really interesting. Get a bag of GDTs from different manufacturers, and compare them. Maybe from different lots, and see how much conservative they play with their spec sheet numbers. There are some vendors (TDK? Epcos? Vishay almost certainly..) that have the MOV/PTC in one package and see what they can handle, their failure modes etc. Educational for the community and blowing things up is always fun.
And to test them, maybe design a unit that will meet the official UL test standards. That'd probably be one of the most interesting series you could possibly do. Have an 8 part series where 10 minutes of the content is the theory injected at arbitrary spots in the dialogue, with the remainder being "most people would do this, but they're idiots: do this instead". Or the famous issue of: One or two people put out an app note, everyone reads that app note, then 20 years down the line people are talking about 45 degrees at DC. "they're idiots, ..." Or just mentioning shit that most people don't really think about. The first chapter of Hall, Hall and McCall did this really well. with dispelling the rumors on where the energy is actually passing through (the dielectric, not ON), along with how the EM fields develop and *why*. Though I'd be reluctant to walk through something like that on YouTube. Judging by the emails you seem to get...well...
-
Hello, I start the test of the program, the graphics line on the monitor screen hare too thick on v.3.
I put some screenshots to see the difference on v.2.08 the line got better definition and better readability on V.3 some go to mixup.
-
LabView allows you to change the line colors and thickness. I have added the ability to save the main graphs settings to the defaults file.
-
Hello Joe,
"the LiteVNA. It's about half the cost and offers a lot more bang for the buck anyway. I'm surprised that you wouldn't have gone with it."
I asked you which version of the vna's to get. You said either the original or the v2plus4 would be good for learning.
Perhaps a case of SISO? You didn't provide a reference. If you would like less vague answers, learn to ask more detailed questions.
-
LabView allows you to change the line colors and thickness. I have added the ability to save the main graphs settings to the defaults file.
Is only one comment for the difference from V.2.08 to V.3.0 for the better readability of V.2.08.
I'm computer illiterate :D
-
Comparing a BP filter on my PNA vs the Lite. Different standards, cables and method were used.
-
Hello, is that default LiteVNA or with the capacitor mod you mentioned previously ?
-
Unmodified LiteVNA with custom diode dropping USB cable.
-
Sure do wish I knew how to solve this problem... does lvsound2.dll have to b 8) 8)e in a specific location?
-
[attachimg=1]
-
Sure do wish I knew how to solve this problem... does lvsound2.dll have to b 8) 8)e in a specific location?
This sound DLL seems to be a bit of a bastard child. Normally, I would expect it to be included as part of the runtime like everything else. For what ever reason, the sound is a special snowflake. When building the EXE, LabView places the DLL into the Data directory. The proper directory structure is shown with Github.
Again, you need the correct VISA and runtime for it to run and communicate with the VNA. It's a 64-bit app and tested on Windows 10 only.
-
I have been using the correct versions of VISA and the Labview-runtime (64bit). Actually, I have a complete install of LabView. But nontheless, no matter what I have tried in terms of placing the lvsound2.dll I can't get past the program complaining that it can't find the DLL I assume that there is no way to option out the sound support. It's so frustrating to be unable to use the app with a NanoVNA because of sound.
-
I have been using the correct versions of VISA and the Labview-runtime (64bit). Actually, I have a complete install of LabView. But nontheless, no matter what I have tried in terms of placing the lvsound2.dll I can't get past the program complaining that it can't find the DLL I assume that there is no way to option out the sound support. It's so frustrating to be unable to use the app with a NanoVNA because of sound.
I haven't seen any problems with the sound posted in the LV forums. Sadly you decided to chop off the screen shot and have supplied very few clues to what you are doing. I can replicate the errors you posted but I really have to go out of my way to screw things up.
Remove the DLL. Launch the program and when it prompts for the location of the DLL, select cancel. Tell it to continue to load anyway. It will show an error but force it to run. I would expect trying to run it this way would be obviously a bad idea but it will reproduce the same results.
If you want to try an solve it, you will need to supply a lot more detail about what you have done. Otherwise, I would just use the open source program.
-
I tried to grab an older 32-bit version of the DLL and place that into the correct directory. They have the same name. I then attempted to load it and it will not prompt for the file location. The error is still set and when I attempt to force it to run, the software once again shows the same errors. Of course, no one in their right mind is going to expect my two examples to work.
Then again, with you having the full blown LV installed, I can believe you tried to run with a DLL you had. I have no way to know without my crystal ball.
-
Well here is my experience:
a) Followed the instructions and installed SPI LabView-Runtime (64 Bit)
b) Installed NI-VISA
c) Setup the directory structure as suggested in Github.
Ran NanoNVA_Solver.exe. Selected Run from the top menu ==> Complains about can' t find lvsound32.dll in muliple instances as indicated in the image file submitted previously.
Then moved to a second windows 10 system and repeated the process and experienced the same results.
Then carried out a full install of LabView 2021. Same results.
Then tried adding lvsound32.dll to the environment path. Same results.
Put a copy of lvsound32.dll in the same directory that NanoVNA_solver.exe is in, same results.
There should not be any conflict with lvsound.dll because these dlls have different file names.
Now one might reasonably ask what possible motivation could there be to have spent so much time trying to get this to work. The answer is simple. I wanted some of my advanced students to use the tool for their senior projects prior to graduating with a BSEE.
-
Well here is my experience:
..
Ran NanoNVA_Solver.exe. Selected Run from the top menu ==> Complains about can' t find lvsound32.dll in muliple instances as indicated in the image file submitted previously.
Notice that the software is looking for lvsound2.dll, not lvsound32.dll.
Then moved to a second windows 10 system and repeated the process and experienced the same results.
I'm not surprised. People often repeat their mistakes.
Then carried out a full install of LabView 2021. Same results.
Not sure why but ok.
Then tried adding lvsound32.dll to the environment path. Same results.
Put a copy of lvsound32.dll in the same directory that NanoVNA_solver.exe is in, same results.
There should not be any conflict with lvsound.dll because these dlls have different file names.
The software is looking for lvsound2.dll not lvsound32.dll or lvsound.dll. There are several versions of lvsound2.dll all with the same name. Based on the symptoms, it seems you are trying to use the wrong one.
-
Well unfortunately I made a typo. I don't think there is a lvsound32.dll. I of course used the lvsound2.dll provided by NI. The lvsound2.dll comes with NI-VISA/SPI LabView-runtime so given that those were explicitly stated as required that doesn't seem likely. It is odd that the app can't find the dll even when it is in the same directory as the application.
-
Before compiling the software, check that file pointer for this file is "C:\Program Files xx\National Instruments\LabVIEW 2020\resource\lvsound2.*"
See my attached picture. No need to move around this file, it will automatically be included in basic compilation package and will be located as above.
Have a local copy at any else location can give problem with properties to call a dll function.
If problem with reaching a local version, can it sometimes help to start the software as administrator.
For my own Labview softwares was it more disadvantages then advantages compiling using 64 bit Labview, so I have reverted back to 32 bit.
Check check correct file location when compiling by open "Sound Output Info.vi" in labview search-function as shown below or whatever sound related *.vi file that is used in the software.
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1454953)
-
For my own Labview softwares was it more disadvantages then advantages compiling using 64 bit Labview, so I have reverted back to 32 bit.
Care to expand on this? I have not ran into any problems with it yet. There are a few programs I have yet to port over.
-
Well unfortunately I made a typo. I don't think there is a lvsound32.dll. I of course used the lvsound2.dll provided by NI. The lvsound2.dll comes with NI-VISA/SPI LabView-runtime so given that those were explicitly stated as required that doesn't seem likely. It is odd that the app can't find the dll even when it is in the same directory as the application.
Ok, so your not using the DLL that was provided on Github. Provide the date and file size for the DLL you are attempting to use.
-
Care to expand on this? I have not ran into any problems with it yet. There are a few programs I have yet to port over.
Nothing specific and mainly some minor problems.
My Labview experience can differ a lot and maybe be less relevant for your software but I am sure you can judge that by yourself.
Main problem I have had was poor compatibility with Keysight IO Libraries VISA software if it also should coexist with NiMax. I as well as some other users of my software had problems with this compatibility that not seldom ended with total breakdown and reinstall of both NI-VISA and Keysight drivers, which in later versions of Labview can take several hours to first remove and then reinstall using by NI provided tools.
Maybe was my problems specific for my NI installation but Keysight VISA driver compatibility have had some compatibility problems, at least since Labview 6.1.
Keysight VISA driver need a rather big software installation of Keysight "IO Libraries" installed because it is a need if using Keysight USB-GPIB adapters. There are possibilities to just include a minor driver library for Keysight VISA adapters but it is driver installation at hacker level.
I remained long time using Labview 8.5. It fulfilled my and my customer needs. Never versions do not add any bells or whistles that not can be created in 8.5 from software view and programming environment is downgraded in some aspects from my view.
Main reason that I switched to newer version was that Labview 8.5 not was compatible with newer version of Nimax and some customer had for other reasons updated to newer version of Labview runtime including Nimax so it was a must to update if i wanted compatibility with newer versions of Labview runtime.
It is else not any absolute must to use Nimax, there are other possibilities to communicate with instruments, but as my software intend to be compatible with all brands and models of VNA as long as they talk GPIB/IEEE-422 is my software self configuring for each type of VNA, is it very practical and comfortable from programming view when Nimax is working properly. One problem less to handle and even if it is problems can that be solved without affecting my software code.
It is then instead a problem for actual VNA manufacturer to provide a NI-VISA-compatible driver and proper IEEE-422 communication but most commercial VNA's have a such interface.
Nimax and windows file properties are the both sources that have cost most problems for my customers as well as needing my support. I have actually done a bit half dirty programing to automatically elevate my software properties during some file operations, such as dynamically saving settings in ini-files located in ordinary program directory or automatically download and replace existing exe-version, which else may need administrator rights.
Since I reverted to Labview 2020-32 from 64-bit have I not had any known problem with Nimax or compatibility with Keysight soft and hardwares.
Porting software between different versions of Labview is seldom any big problem.
As long as you have highest version of Labview installed can that version save for compatibility with lower versions as well as importing older versions. Some functions that have disappeared in never version or can need some cleanup of the code as well as when saving for older versions. It is seldom any problem, both older and newer versions of Labview runtime can coexist and it is possible to include code for both version when writing a new vi.file. Drawback if mixing several runtime versions is that if you distribute that file to others do they also need several runtime versions installed.
One such common case is for example when read/write spreadsheet files which file functions differ between older and newer Labview versions.
Had a minor problem as I had code that was upgraded to 64-bit and afterwards continued developed. Then did I replace 64 bit Labview with 32-bit and couldn't any longer open the 64-bit version of my vi-file. Had to install a virtual 64-bit version just to be able to save this file for older 32 bit version.
Have not tested it but a file compiled for 64 bit Labview environment do probably refuse to run using 32-bit Labview runtime.
It is possible that both 64 bit and 32 bit environment can be installed in parallel as they not use same program directories but have not tried. Do not want to add another possible source to problem.
Have else full environment of several older Labview versions installed. That is not any problem except for that older labview versions not can use newer versions of NI-488 and NI-VISA.
Partly list for which versions that are compatible can be found here: https://www.ni.com/sv-se/support/documentation/compatibility/16/ni-visa-and-labview-version-compatibility.html (https://www.ni.com/sv-se/support/documentation/compatibility/16/ni-visa-and-labview-version-compatibility.html)
I have a list for older labview versions as well, if needed.
-
Thank you for taking the time to write this up. I am currently using the Keysight IO Lib but that is one of the things I have not tried yet with the new LabView. While I have NiMax installed, its nothing I ever use. GPIB was always problematic for me. I have a good story about their tech support and GPIB.
I ran into problems at one point with their PCI, GPIB and serial port interfaces. Also some leaky code they wrote. All in all, not too many problems. I'll try the Keysight libraries next and let you know if I turn anything up.
While the current version of LV will allow you to save down to version 8.0, going from 8 to 6 required 7. I had stayed on 6.1 until 2011 for much the same reason (No advantage). With VISA only supporting 64-bits, it was time to upgrade.
Normally I create an installer when distributing software. I would have done that with Solver64 but enough people had chose to manually install the support files that I decided not to put any effort into it this time around. All of the software I have written with LabView was not for distribution beyond my own use or work related. Rolling out new programs has never been a problem. This VNA application is the only LabView based software I have put into the general public's hands.
It is possible that both 64 bit and 32 bit environment can be installed in parallel as they not use same program directories but have not tried.
I am doing this with 2020 and not having any problems so far. Same for older versions of LV.
-
What triggers the following message "NanoVNA V0Unknown,Protocol 0, FW 0.0 " ???
-
What triggers the following message "NanoVNA V0Unknown,Protocol 0, FW 0.0 " ???
Based on your question, I take it you have downloaded the correct Sound2.dll. Congratulations! You have taken the first step to getting it working! I wonder if you had both the 32 and 64 bit LabView installed and then grabbed the 32-bit DLL. Same name but certainly would have caused what you were seeing.
Next you need to get the software to talk with the VNA. This will require the proper NI-VISA be installed along with the drivers. You will of course need to select the correct comm port. Also because it seems you're a bit of a beginner, let me be very clear that this software ONLY supports the LiteVNA, V2Plus4 and V2Plus.
Assuming you now have the latest 64-bit NI-VISA installed and running on Windows 10, the built-in drivers should be fine. At least this is what Flipper and myself continue to test with. You looked in the device manager and turned on the VNA to identify the comm port so you know that is correct. You then entered that into my software. All the typical basics and I am sure insulting to many people, akin to did you plug it in sort of response. Let's assume your skills are not lacking. Obviously something is still wrong and you are not forthcoming with data. My guess is you have an unsupported VNA or there is a hardware problem. Maybe a bad USB cable. My friend Flipper ran into that with their LiteVNA. It's also possible the VNA itself has a problem. Obviously the PC will chime when a device is connected. Device manager would be my first check. Maybe provide some details and I can help you out.
-
Comparing a 2.46MHz crystal on my LiteVNA, original NanoVNA, PNA and HP3589A. The IFBW of the HP can not be set to 100Hz. Using Dislords equations, we need 20 averages for a 100Hz IFBW. With 401 data points, the LiteVNA requires 24.2 seconds to sweep.
Odd how far off the Lite's frequency is.
This is again, the unmodified Lite with the diode dropping USB cable.
***
Also, all of these program were built using the new 64-bit LabView. The PNA is using the Keysight library. The 3589A is using my old Ethernet GPIB controller with direct calls. No problems to report. The one thing I need to check is my HIL simulator for my bike. This uses the driver development wizard and resides on the PCI bus. If that works, I will say goodbye to 32-bits.
-
Re: The 500Hz width scan using original Nanovna
What scan and data collection/ processing settings did you use? Thanks.
-
At least with the old firmware I use, you can set the sweep range. If newer firmware has additional settings, my software does not support them. It is obvious what the sweep range was set to so I suspect you're trying to ask something about the IFBW but maybe not sure what to ask or how to ask it. I'll take a guess...
My original NanoVNA's IFBW appears to change based on the frequency settings. If for example I change the span from 500Hz to 1kHz(shown in 2).
Comparing the original 500Hz spanned data I collected with the NanoVNA with the HP3589A. The HP's IFBW was adjusted until the two datasets are close. From this, I would guess that the NanoVNA has an IFBW of roughly 2.3kHz in this sweep range (shown in 3). There may be documentation that covers the IFBW by now.
Using Dislord's equation we can set the Lite's averages to 2 (the default) for 2kHz IFBW. Setting the span to 1kHz and comparing with the HP3589A (shown in 4). There's no other averaging being done by the software.
-
Yes, I'm trying to understand the IFBW on the nano. There are 6 frequency choices ranging from 4k to 30Hz found in display->bandwidth. I believe that sets the IFBW
https://groups.io/g/nanovna-users/topic/resolution_bandwidth/84425083?p
-
The firmware I use does appear to have this menu but with it not being documented, I never supported it. Turning on the unit, it defaults to 1kHz but I have no idea what this means. Obviously it changes with the span. Like the Lite, it may also change with the frequency. Maybe it is documented somewhere. Too bad really as I would have added support when I was developing the application. Oh well.
Because you can change the settings while the original NanoVNA is attached to the PC, I set it to 100Hz. Shown compared with my PNA.
***
Added photo of the menu on mine. Note that 4kHz is not an option.
-
I've almost gathered all items necessary to construct transfer relay.
I'm going to make a t-check using sma pcb connectors and paralleled 100ohm 1206 resistors.
Also planning to replicate your test of amplifier using no name amplifier.
I'm using cheap Chinese equipment, piecing together instructions from similar well documented equipment. The low price and language barrier are reasonable reasons the instructions are lacking.
I never had to be a technical writer per se. Making the tool(code) was enjoyable, but writing instructions was when I remembered I was getting paid.
-
The transfer relay is a complicated matter, most people use one relay, the HP switching relay test-set on different frequencies 1.5, 3 and 6 GHz using two relays, if using this relay system you get good isolation and very low cross talk (most of the people luck only on isolation specs, putting two relays on T configuration respecting good quality cable, very short cable connection you can reach an acceptable result, is important the response of the Nano/LiteVNA not perceive the small cross talk on the T/R relay.
If you want one professional result buy one professional instrument. The nano/lite, VNA is sufficient for a hobby, and student.
-
I was looking at the source code to see if I could sort out how to program the IFBW. I was not able to find "bandwidth" in any of the files. Then realized that the firmware I currently have loaded is not the one I had tested with. A quick search for some sort of newer software interface manual also turned up nothing. I guess you just have to manually set it.
Setting the two LiteVNAs to 10MHz CW and comparing with my old NanoVNA, both Lites are off a fair amount. My old VNAs and counter are referenced to the GPS receiver. I may try to install a better reference into the Lite I have been experimenting with.
Model, Reading @ 10MHz CW (Hz), Delta (Hz)
LiteVNA (stock), 9999989.7, 10.3
NanoVNA, 9999998.1, 1.9
LiteVNA (mod), 9999989.6, 10.4
-
I was looking at the source code to see if I could sort out how to program the IFBW. I was not able to find "bandwidth" in any of the files.
At least in the DISlord firmware (https://github.com/DiSlord/NanoVNA-D) for Firmware for NanoVNA, NanoVNA-H, NanoVNA-H4, search for _bandwidth (https://github.com/DiSlord/NanoVNA-D/search?q=_bandwidth) and cmd_bandwidth (https://github.com/DiSlord/NanoVNA-D/search?q=cmd_bandwidth).
VNA_SHELL_FUNCTION(cmd_bandwidth)
{
uint16_t user_bw;
if (argc == 1)
user_bw = my_atoui(argv[0]);
else if (argc == 2){
uint16_t f = my_atoui(argv[0]);
if (f > MAX_BANDWIDTH) user_bw = 0;
else if (f < MIN_BANDWIDTH) user_bw = 511;
else user_bw = ((AUDIO_ADC_FREQ+AUDIO_SAMPLES_COUNT/2)/AUDIO_SAMPLES_COUNT)/f - 1;
}
else
goto result;
set_bandwidth(user_bw);
result:
shell_printf("bandwidth %d (%uHz)\r\n", config._bandwidth, get_bandwidth_frequency(config._bandwidth));
}
Looks like the command were either "bandwidth <divisor_minus_1>", or "bandwidth <bandwidth_in_Hz> <anything>", where <anything> just distinguishes the one-argument from the two-argument variant of the command. The given <bandwidth_in_Hz> is not honored literally, but quantized to an integral fraction of MAX_BANDWIDTH. I.e. the actual bandwidth is MAX_BANDWIDTH/divisor then, where divisor is an integer in the range 1...512.
-
The last source code I downloaded was from 2019 and the word "bandwidth" is not found. When I wrote
I was looking at the source code to see if I could sort out how to program the IFBW.
I was referring to changing the setting using the USB interface.
If the people writing the firmware had made it easy for the software programmers to implement, I may have included it. Like nctnico, I too get lost along the "breadcrumb trail". Of course, you can always change it from the device's menus (assuming the firmware you are using supports it).
-
Thanks Joe for your measurements. Did you calibrate the TCXO with a frequency counter on your Lite (in the expert menu) ? True value may deviate a bit from 26Mhz.
-
Thanks Joe for your measurements. Did you calibrate the TCXO with a frequency counter on your Lite (in the expert menu) ? True value may deviate a bit from 26Mhz.
I rarely run the LiteVNA manually and have never looked into it until now. The Lite's menu shows 24MHz, not 26. A bit odd they don't just have an offset.
If there were a way to set it using USB, most likely I still would not use it. Adding the offset to my software would be trivial and would keep things more uniform across the products. With all of the low cost VNA's being so close, it's not something I have considered. With the Lite's poor narrow band performance, I would be even less inclined to invest any time.
For the average user, I wonder if changing it does more harm than good. As I mentioned, most of my time based equipment is referenced to the GPS. I doubt most users would have a decent reference.
-
Normally I ignore emails about the software but this one is worth going over.
Not that big of a deal because people shouldn't be flashing the incorrect FW to a device, but but in case this bug might be sign of a more sinister bug that could affect a normal FW flash at some point, below is the repro steps:
1) Flash incorrect FW LiteVNA62-220228.bin to LiteVNA64 device using Solver64 (3a84660); observe successful flash and LiteVNA64 screen displays smaller/mirrored screen output due to incorrect FW
2) Attempt to flash correct FW LiteVNA64-220228.bin to the device using the same Solver64; observe progress bar immediately completes but FW is not updated; there is no way to flash the correct FW to the device using Solver64
3) Attempt to flash the device using NanoVNA-App; observe correctly detects device in DFU mode and correctly flashes to the requested appropriate FW
Thanks Joe !
I have added step numbers to the original email. Step 1 is fine. Note that once the firmware is loaded to the VNA it has reset the VNA. It is now no longer connected to my software or running in DFU mode. User fails to power cycle the VNA with the selector pressed to place the VNA back into DFU and then reconnect with the software. Step 2 is fine. They have told the software to program a device that is not connected. The software is happy to proceed and tells you it has programmed your unconnected device.
It should be obvious that the device was not in DFU mode as they talk about what the display looks like. It is running the application just fine.
-
All is well Joe, thanks to your unending patience and kindness. I really admire the many contributions you are making to the rest of us. Gives me hope for our country. Regards Eddie Currie
-
All is well Joe, thanks to your unending patience and kindness. I really admire the many contributions you are making to the rest of us. Gives me hope for our country. Regards Eddie Currie
Good to hear you now have the PC talking to the device. You should consider posting the problems you came across and your solutions. A few of your students may have the same questions. I would expect them to have even more detailed questions about how the software works and how to use it. It places the burden on you to learn it well. You can also point them to the EEVBLOG forum if they really get stuck.
You may also want to consider using one of the open source programs to base your curriculum. One advantage is students could then modify the software to conduct what ever experiments they come up with. If you look at my software, this is basically what it is. As I come up with experiments I want to run, I will add them to the software. I think your using these low cost VNAs to teach the next generation of EEs is brilliant.
-
Joe, you didn't follow the repro steps. If you did, you would have seen that if your assumption were correct, then there is no way I would have completed step 1:
Flash incorrect FW LiteVNA62-220228.bin to LiteVNA64 device using Solver64 (3a84660); observe successful flash and LiteVNA64 screen displays smaller/mirrored screen output due to incorrect FW
As you presume the unit was correctly prepped to "flash" in step 1 , you should also presume that the necessary steps were completed in step 2 which I stated the same process:
"2. Attempt to flash correct FW LiteVNA64-220228.bin to the device using the same Solver64; "
I can assure you Step 1 completed as I stated and Step 2 did so as well using reasonable expectations (cycling into DFU mode, etc).
If however, you are telling me you attempted to perform the steps as written with reasonable assuptions and were successful, I will retry (for the 6th time - I attempted 5 complete separate times without success even after returning to correct FW using Saver each time, before giving up and resolving that there is a bug.
Since Joe wasn't convinced, I thought I should rule out my system so I copied the (HUGE) NI runtime binaries over to my old Win10 laptop and unfortunately (or fortunately, for Solver) could not repro the issue. This would point to a system issue but it didn't make sense why Solver could flash the FW at all on the first system, so I moved from the front USB3 port I had been using (connected to a bridge chip on the MSI mobo I have) and to one of the native USB2 ports direct on the rear of the mobo, and flashing back and forth was successful. I then moved to the rear mobo native USB3.0 ports and flashing back and forth was successful. So I then went back to the bridge-connected front USB3 port and it was successful 3 times, then failed on the 4th. I then moved back to Saver and flashed successfully back and forth 5 times each without failure. So it seems there may be some intermittent/rarish timing issue with the MSI USB3 bridge chip in the B450 based mobo I have. What I can't explain is why it failed 5 times in succession last night but worked 3 times in a row tonight. Perhaps sunspots (I was also very successful with CB skip last night around the same time ;)
Regardless, good to find out this wasn't a bug in Solver. If you encounter any flash problems, obviously ensure you are following the correct steps as Joe states, but try a mobo-direct USB port just in case.
I have not had a failure yet when programming the Lite's firmware using my software. This includes the exact versions listed above (shouldn't matter).
... you should also presume that the necessary steps were completed in step 2 ..
Author did not specifically state the VNA was set back to DFU. Details mater when you are reporting a problem.
-
Adding a simple offset to null out the frequency error is trivial. It's an addition.. :-DD
Shown with the Lite's average set to 40 or an IFBW of 100Hz and a span of 500Hz. Also shown is my PNA with the same settings.
-
Doesn't it look like the PNA has smaller ifbw that the lite? Learning to read these graphs...
-
The Lite's skirts are wider and the peak is attenuated. Put a pulse into a filter and start lowering the cutoff. What happens? You could do this with SPICE.
-
Using the same 2.457MHz crystal, 1kHz span and sweeping the Lite's IFBW from 100Hz (starting at 0) to 4kHz.
-
Nice. Interesting progression and disappearance behavior of side peaks. How many points to that surface?
Need to get back to practicing with mcp. I have too many study topics on my plate. It's all interesting.
Really too bad you didn't get that ifbw functionality incorporated for the original nano. I read some discussions you'd had about similar controls for the V2. Locked out of the code :-(
-
100Hz IFBW = 60k/(15*Avg), Avg = 40. I tried to collect three sweeps per setting. The Lite was set to 401 data points per sweep. So the surface is made up of roughly 3*40*401 = 48k points.
Eventually the side lobes exceed the span and appear to disappear. Had I used a wider span we would see the images even with an IFBW set to 4kHz.
-
Same 100Hz to 4kHz IFBW sweep but with a 3kHz span. 5 sweeps per IFBW step.
-
Sweeping my original NanoVNA at 30Hz, 100Hz, 300Hz and 1kHz.
-
Glad to see you think the original nano is still worth collecting data with (since I don't have the lite). You should keep adding features to version that supports the original :-)
Just noticed the Solver32. Why 32? Does going to 32-bit lose the speed of Solver64?
Looking at these 3-D surfaces brings memories of hand plotting free energy surfaces for phase changes. 3-D plots are trivial now...
-
Re:...keep adding features to version that supports the original :-)
I have no plans to do anything more with devices requiring the old protocol or at least anything I will release to the public. Of course, nothing prevents the firmware for any of these devices from being compatible with the newer protocol.
Re: Why 32?
It's a hobby and I enjoy experimenting.
Re: 3-D plots are trivial now...
Many things are now trivial compared with where we were even a few years ago. Still, I wouldn't want to write a 3D plotting program in assembler.
I thought about running a longer experiment with the Lite's IFBW where we run through more combos. For example, if we set the bounds for the Averages to 1-40 but we also include bounds for E0 or 1-15. This would give us 600 combinations. Of these, we would have 276 unique IFBW settings. This assumes Dislord's firmware works as they claim. In other words, an IFBW of 400Hz could be achieved with Avg/E0 combinations of 10/15, 15/10, 25/6 and 30/5. We would expect all of these would yield the exact same results based on Dislord's statements. Of course, the lower the IFBW, the longer it will take to sweep.
To speed things up we can limit the Average to 1-10. This allows an IFBW between 400Hz and 60kHz, with 74 unique settings. Shown with 2 sweeps per setting.
-
Before anyone asks, the drift in the peak is real. I don't have a calibrated beach towel over the jig and the air temperature will cause the crystal to to drift.
Wrong...
Changing the IFBW settings will change the peak's centroid. Shown at 4kHz and 60kHz.
-
Re: winding torroids
What was the little white jacketed coax you used when making common mode chokes, etc? I've seen twisted pair used in other references. I assume the coaxial has better rf behavior, yes?
-
Re: winding torroids
What was the little white jacketed coax you used when making common mode chokes, etc? I've seen twisted pair used in other references. I assume the coaxial has better rf behavior, yes?
Same coax from the last time you had asked. Those transformers were characterized to 6GHz. You can read about them in the manual or search this thread.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4063153/#msg4063153 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4063153/#msg4063153)
-
Last time you referred to blue jacketed coax while the smaller stuff I saw was white. I'm thinking it was the rg188(from comparing spec's), but that does not seem right. Because: I have some rg316 with similar specified bend radius limit as the rg188. It seemed, from watching video and comparing myself, that the white coax you were wrapping was more flexible than rmin=.5".
So, the rg188 is smallest you use?
Trivial stuff for you, but all new to me.
I am aquiring supplies to make transfer relay connections using rg400u
Thanks for the details.
-
Common sizes I use.
-
900MHz center, 100kHz span, 2 sweeps per setting, sweeping IFBF from 400Hz to 60kHz.
-
Same setup but at 5MHz.
-
Could you replace sweeps with center frequency? Run from 5M to 900M. Still show delta f.
-
Could you replace sweeps with center frequency? Run from 5M to 900M. Still show delta f.
I think I understand. You want to sweep the frequency with some fixed span and fixed frequency step size. If so, yes I can do this. However, think about what you are suggesting. You have not fully considered what you are asking or I am not understanding. There's some missing details, or at least one major one...
-
Just brainstorming: How would peak and lobe profile change as frequency changed?
-
Re: brainstorming: How would peak and lobe profile change as frequency changed?
Well, our ideas of brainstorming differ. Think about it. What causes the peaks and lobes?
-
Haha. Our capacities to constructively brainstorm differ by several orders of magnitude because of difference in referential knowledge. Fancy way of referring to my ignorance.
I realized, after some thought, that even if one had a dut with adjustable frequency response, the resonance (or whatever) would likely not be the same at each frequency. So, that probably would not be a good experiment to investigate the measuring behavior of the VNA.
I discovered why your rg188 seemed so flexible. The ptfe jacket makes it so. That is some fancy wire. I found some mil spec new old stock from 1981 for a good price.
Figuring out wire routing for the transfer relay. Your images help.
-
Re: brainstorming
Bingo. I already sweep the frequency with the span and I also sweep the IFBW. Nothing there changes except we widen the span. But to look at narrow band signals...
We could look at the effects of IFBW on a wideband signal over some very wide freq sweep (basically look at the noise floor) but I don't think we would see anything of interest. If I were for example to run the previous IFBW sweep using that interdigital GHz filter for example, the lobes are going to stay the same but the noise floor will change. Even looking at the crystal filters I made is fine. It's really just when looking at the crystals themselves or a very narrow source.
Your talking to the king of ignorance. Mine knows no bounds and expands each day. lol.
If you are interested in working at these higher frequencies, cable choice is important. RG174 while very flexible by comparison would make a poor choice. Pasternak has most of these cables in stock and will sell it in shorter sections. Digi-key may also carry something you could use.
The jacket on my blue cables that I showed in many videos with the NanoVNA cracked after a few years of use. Just too much flexing when running so many demos.
-
Re: cable choices.
I chose the rg400 for transfer relay connections as effort to make best setup knowing I will have minimal flex and want great quality connection(best I can).
I'm wanting to investigate inductors, chose this high-end rg188 to minimize Impedence changes in wire with frequency. The rg178 I have is stiff. I'll respect bend radius.
Re: Transfer relay
I read proof for using t-check to examine quality of two-port measurement(using transfer relay in my case). More reading seems to say that most circuits are expected to be reciprocal for s12 and s21, which seems to relegate use of full 2-port measurements to checking when dut is well- behaved. Two questions:
1. Are there any non-reciprocal dut's I could study?
2. Do you use full two-port measurements to judge quality of a dut that is supposed to be reciprocal w.re.to s12 and s21?
-
Re: questions
I had wondered why you were attempting to integrate a transfer relay.
1. Are there any non-reciprocal dut's I could study?
Yes, there are non-reciprocal DUTs. Mixers, directional couplers, matching transformers to name a few. You could study them from a text book and then attempt to gain a deeper understanding by experimenting with them. You could even build your own devices. Experimenting with a 4:1 transformer would be simple enough. You would certainly see a difference.
2. Do you use full two-port measurements to judge quality of a dut that is supposed to be reciprocal w.re.to s12 and s21?
No. I do use the reciprocal to judge the quality of my calibration.
I'm wanting to investigate inductors
I made a video where I used the original NanoVNA to make several measurements including Ls, Cs & Rs all without a transfer relay.
Make sure you have a reason to use the transfer relay. Adding one will only add to the error and may create problems.
-
Thanks for suggestions. Perhaps I would not have undertaken the relay project if I'd realized limited applications. I'm invested in getting it together and seeing how well I can do with it.
I've watched a lot of demonstrated activities using inductors. Inductors seem more interesting and varied than behaviors of capacitors. Lots of variables.
Yes, I'm trying to figure out, build and always use setups which will minimize errors. This is a challenge I like to work on using my limited but growing electronics bench.
-
Re: realized limited applications
You may find your time is better spent reading than buying parts. Trying to build something with little understanding of what you are doing or why makes little sense to me. Then again, I rolled two custom xfer relays with zero success along with wrote some software to support them just for the fun of it.
Most of the videos I have watched on VNAs were from CMT, Picotest, RS. These are normally more generic. The last one I watched prompted me to make that rebuttal video. Recently this person commented how their V2Plus4 uses sine wave. It was only the bad clones using square waves. I suggested they post here and show us some data but they pulled their comment.
Most of the test loads I had looked at were standard purchased parts. They come with data sheets. I advice you to start out measuring parts that you know what their specs are before diving into the unknown. For variables, I think it just depends how deep you want to dive in. We had a little contest some time ago about constructing an oscillator on a breadboard for the fun of it. I asked about when the person who started the thread considered a jumper wire an inductor, capacitor, delay line. Some of the demos I made for the V2Plus4 were nothing more than some blank FR4 material and copper foil.
-
Yes, aquiring unnecessary stuff if a waste. I found a 30-year old oscilloscope that is way more than I need, but it's capabilities are there when I learn and think of new ways to use it.
I thought your oscillator solution reflected your experience gained from wire wrapping work. I'd think those constructions were often bumping against frequency limits (complications) due to resonances, etc.
Of course, pursuing the simple questions can lead to elegant insights. I'm not looking beyond getting some personal learning.
Looking forward to your sharing more of your experiments.
-
Hello, for the transfer relay this datasheet help to choose the configuration of it.[attachimg=1]
-
Re: Transfer relay
Thank you but I aquired a new/old transco relay on ebay. I've almost received all ordered parts necessary to put it together. I've got a plan. Time to see if it works!
-
Joe, I truely appreciate the programs you've created and shared. I wish there were a way to entice you to document the features. I'm making efforts to puzzle choices out as I (try) testing new setups. However, measurement returns aren't perfect(nature of rf, connections etc) which really hinders being able to decide whether I'm on the right track. This wandering in the dark likely means I'll never recognize some really important features.
-
This would be a cool experiment. Could this be done with the nanovna's?
https://coppermountaintech.com/determining-resonator-q-factor-from-return-loss-measurement-alone/
-
Re: cool experiment
Again, I am not sure what you are asking. Obviously these low cost VNAs can measure S11 & S21. So I read the paper thinking maybe there was something there that would make you ask. It seemed straightforward enough. Lets spend a few minutes and toss something together.
I don't have a 1uH, so wound up a coil on a chapstick dispenser. For the 113pF, I used a 100pF // with a trimmer. For the 2k, I used a 2k21. For the 12pF coupling caps, I used 22pF.
I have a James Millen Grid-Dip meter model 90651, serial number 16. Released in 1949. Shown with the 6.4-16MHz orange coil. The trimmer was set to provide a dip at 14MHz.
Tank was then attached to the Lite. No calibration was performed. Measuring Q with S11, 13.290M / 980k = 13.56.
Obviously, a swag at best but I see no reason why anyone couldn't follow this paper and replicate the test with the low cost VNAs.
***
Just to give some idea on the error, assuming the RLC meter and resonance frequency of the Lite are close (which they are) 1.055uH @ 13.29MHz gives an XL of 88.1. From this we can calculate C at 136pF. With the 2k2, we should have a Q of 25. We came up with about half that.... Lots of error compared with the paper, but again no calibration and our coupling network is a bit off...
-
Dang, you're fast. Thanks for pic's. Being able to replicate, do calculations and compare results will be good learning experience for me. Will study provided details later.
I was just reading about sample averaging. Recall you stated you used running average of last 100(?) samples. That is a linear weighting scheme? Did you consider using an exponential weighting scheme? Using LV seems a real advantage in implementing signal processing.
Could you also explain the 'smooth' function you have?
Thanks.
-
Ok, so no questions about the cool experiment. I figured you had a reason to ask but guess not.
Smooth uses an FIR. The old software for the original NanoVNA does not support the average feature. The following shows how to calculate an average:
https://www.youtube.com/watch?v=dPmQS4eSsBw (https://www.youtube.com/watch?v=dPmQS4eSsBw)
-
This would be a cool experiment. Could this be done with the nanovna's?
https://coppermountaintech.com/determining-resonator-q-factor-from-return-loss-measurement-alone/
That article is somehow confusing. They are also using S21 for the calculation..
However, I often use the magnetic field probing for determining the Q factor, contactless.
There are many applications where the Q factor is critical. For example I use that probing for testing or fine tuning RFID card readers.
The company I am working for are also producing MRI antennas. I can remember we had some problems with some PIN diodes with too high leakage current in some detuning circuits.
It was not possible to measure in circuit, but the additional resistance of that diodes droped the Q factor of the antennas. So we could finaly sort those "bad apples" out, by checking the Q factor.
The probe basically consists of two small magnetig loops, placed in parallel planes, but slightly shifted. The "challange" is to shift and keep them as near as possible one to another, but keep a high decoupling between them. The probe I am showing in the experiment has > 80dB decoupling. It uses RG178, diameter aprox. 20mm and 18mm spacing between the 2 planes. The Another picture is showing some similar H-Probes made of 0.047" rigid cable.
For this kind of measurments I wrote my own software. I am also not a big fan of the graphical method, thats why I used the group delay.
Q = π𝜏f
For this demo I soldered a resonator consisting of a 39pf C and a few uH L, resonating at aprox. 37.6 MHz
Both methods (graphical and gruopdelay) are practically showing same results: Q= 37570/250 = 150 and Q =152
The 2nd method is faster, but is not working well for low Q factors, when the groupdelay is getting "noisy".
Of corse the results also depend on the loading effect..
-
That article is somehow confusing. They are also using S21 for the calculation..
They are comparing the two methods against calculated values.
Interesting fixture.
-
Lite was calibrated and a second test circuit was made. Coupling caps are a little low now (11pf) which at least partly explains the amplitude difference. C was trimmed to the same center freq in the paper (13.62M). S21 3dB delta now 720k. This gives us a Q of 18.92.
-
If we calculate Q from the S11, the minimum I measured was -1.25dB. This works out to -0.58dB. Using the cursors, to find the delta, 718k. With a center of 13.57MHz, we get a Q of 18.9.
That covers all their math.
-
Re: Experiment
Wow. I've got a lot of catching up to do. Your B-field sensors sound very cool. I want to study on that.
I've been sorting out control of the transfer relay. I've got the rts to control a relay to control switching current for the transco. Used off-the-shelf relay with 3V input. Relay draws .26W, so using external 3V to power the switch(might tap the 5V coming from FTDI).
Not sure what to do with the cts lead coming off the FTDI. It always stays at 3V, is connected to nothing. Program gives the XferRly err light as soon as vna links. Port switching signals/operation work correctly during 2-port calibration. What do I need to do to get rid of the error light?
Thanks.
-
Re: I wish there were a way to entice you to document the features.
...
Not sure what to do with the cts lead coming off the FTDI. It always stays at 3V, is connected to nothing. Program gives the XferRly err light as soon as vna links. Port switching signals/operation work correctly during 2-port calibration. What do I need to do to get rid of the error light?
...
You have just demonstrated why I will no longer invest time on documentation. Read the following from the published documentation, or not.
The transfer relay is controlled by the state of the RTS pin. When RTS is de-asserted, Port 1 and 2 of the VNA will route to Ports 1 and 2 of the transfer relay. When RTS is asserted, Port 1 and 2 of the VNA will route to Ports 2 and 1 of the transfer relay. The software expects the transfer relay to always assert the CTS pin or it will set the transfer relay error (XferRly Err).
-
Re: cts
I've printed out that section and read it many times. I've never used this before, and apparently don't understand w.re.to "asserting". I see the rts change from 3 to 0V, which I assumed was the meaning of (de)asserting. As stated, the cts lead from the FTDI plug stays at 3V, so why does error light come on since program expects it to stay at 3V??
Re: Averaging
You so quickly go from being helpful to being derisive. I know what averaging is. Linear averaging weights all n samples equally. I was asking if you had considered the exponential scheme which weights the newer samples more than the older in the n sample calculation.
-
Re: Checking PIN diodes
This wireless method was what Copper Mountain discussed, but did not use in their experiment. Thanks for showing actual application of wireless measuring. So many questions:
What is point of break in coaxial sheath? Was break location by trial or by principle?
I'll have to study on coupling before I can appreciate other details. Thanks for showing results from both programs.
-
Re: Copper mntn exp
Thanks for posting graphs used to pick data. That's how I imagined it. Demonstration very helpful.
I've seen video of dip meter use. IMHO, the old analog instruments got amazingly good measurements. An instructive elegance in seeing how the results were produced without digital magic.
Read some and perused most of old manual on potentiometer design principles after using some 50+year old wire-wound models I salvaged. They figured how to design and use the devices to full effect before advent of (more) active control. Solid engineering.
-
Re: FIR smoothing
How many terms does the filter use? Please specify algorithm, ie Hanning, after Tompkins&Webster, etc.
-
Re: why does error light come on since program expects it to stay at 3V??
Your suggestion that it expects 3V is something YOU came up with. Read it again then read the FTDI manual.
https://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf (https://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf)
Re: being derisive
I'll take care of it.
-
...
For this demo I soldered a resonator consisting of a 39pf C and a few uH L, resonating at aprox. 37.6 MHz
Both methods (graphical and gruopdelay) are practically showing same results: Q= 37570/250 = 150 and Q =152
The 2nd method is faster, but is not working well for low Q factors, when the groupdelay is getting "noisy".
Of corse the results also depend on the loading effect..
For fun attempting to replicate your test except following the paper. I am using a 39pF ATC capacitor. Your couple of uH makes no sense with the 37.6MHz. Looks like we need something around 450nH. I cut one that measures 509nH. Whole setup seems to resonate around 35MHz. Close enough.
Calibrated the Lite around the peak (34.57MHz) with a 1MHz span. Delta at -3dB is 167.5kHz or a Q of 206.
Looking at the group delay, I get roughly 2us or a Q of 217.
-
Yes, if you mean (any) resonance-finding experiment.
The nanovna 2 excels at this kind of measurement. However its not a "grid dip meter" obviously that is based on ancient technology. But the effect is the same and it has the potential to be much more precise. (if you adjust the stimulus parameters to give you high detail in the range you want to look at.
(The graphs I get when using it thethered - via USB are gorgeous.)
It certainly will show you what frequency any combination of components resonates at. (If it does resonate at any frequency)
The picture of the experiment shows the input and output used to test the resonance as simple short wire probes. In the real world one could couple the RF into the DUT in a great many ways, each having their unique qualities. Yes, one would measure the Q of any kind of filter in that way. Coupling to things like coals with a small loop or similar (choosing the length to be a good impedance match) is what I would expect to work best.
A "shielded loop" of semi-rigid coax is a common inductive RF probe, quite useful for such measurements.
This would be a cool experiment. Could this be done with the nanovna's?
https://coppermountaintech.com/determining-resonator-q-factor-from-return-loss-measurement-alone/
-
Re: FTDI datasheet
I've had that and read it. Just reread relevant section. I'm not getting any clues. It's not a manual. I've referenced some ttl documents in trying to understand your manual. I totally lack experience and context about these signals. I'd appreciate some elementary explanation.
-
Is this a DPDT RF relay like the one described in QXP (the arrl experimenters magazine whose name I might be getting wrong), in or around 2009?
It allows automating the insertion or reversal of the two ports on a two port only VNA.
I am guessing the FTDI chip is likely acting as an arduino running firmata might operate and give you a means to toggle pins via USB in a manner that offers some isolation for and protection of a PC?
Using any of a bunch of different programming languages or scripting you can toggle pins programatically. No relay required but the loss is around 1 db and the response might not be as flat as the little Omron relays.
Still Very useful for doing things like providing RF switches with various short binary codes, for example, my ebay "octopod" sp8T RF switch which activates any of 8 ports depending on what binary numbers are provided by means of cmos compatible voltage on three pins. Very useful.
I hope to use this with a homemade adcock antenna to do RDF at some point soon. Need to make an 8 or 4 antenna antenna for this.
Does anybody else what to also do this with me?
I can find the QEX article about the relay, I have it somewhere, even printed it out because it looked so useful.
-
Last time you referred to blue jacketed coax while the smaller stuff I saw was white. I'm thinking it was the rg188(from comparing spec's), but that does not seem right. Because: I have some rg316 with similar specified bend radius limit as the rg188. It seemed, from watching video and comparing myself, that the white coax you were wrapping was more flexible than rmin=.5".
So, the rg188 is smallest you use?
Trivial stuff for you, but all new to me.
I am aquiring supplies to make transfer relay connections using rg400u
Thanks for the details.
i have two kinds, one is blue and it and the grey stuff i have came to me on pigtails purchased on ebay with u.fl connectors already on them. The coax seems too small for any of the sma connectors that I have too. Its very thin coax. Almost certainly teflon jacketed. Its sold for people to make their own 5GHz wifi antennas for FPV drones, etc. You can buy them in quantity and they are cheap and better made than I could ever make them. Soldering that small stuff is a skill that I don't have and will probably never have.
Also, this might be useful on what CTS and DTR are and when they might be used (i.e "asserted", present..) https://en.wikipedia.org/wiki/Flow_control_(data)#Hardware_flow_control
-
Re: being derisive vs elementary explanations
I've had that and read it. Just reread relevant section. I'm not getting any clues. It's not a manual. I've referenced some ttl documents in trying to understand your manual. I totally lack experience and context about these signals. I'd appreciate some elementary explanation.
It seems you found my simple math average was too elementary and that I was ridiculing you. Enough so you felt the need to call me out for it. Let's see if I answer your question in a way that makes sense but not so derisive. It's a binary system. You only have two states. Even my sister, who has no clue about electronics, would know if I tossed a coin and it didn't come up heads, what it did come up with. Actually she is smart enough I bet she could guess and get it 50% much of the time. So let's see, it's not 3V. What could it possibly be? I mean do you actually need someone to point it out? For the datasheet, what could that CTS# possibly mean on the TTL side...
Now that's derisive.
-
Re: FTDI for relay activation
Hello, I'm using the ftdi cable referenced in Joe's software manual which is
https://www.amazon.com/gp/aw/d/B08BLKCXL4?psc=1&ref=ppx_pop_mob_b_asin_image (https://www.amazon.com/gp/aw/d/B08BLKCXL4?psc=1&ref=ppx_pop_mob_b_asin_image)
Joe's reference to its use is contained in his attached quote(partially in red)
The cts use is supposed to be simple. The crux: I've got that 3V cts wire loose, not telling program that expected hardware(transfer relay) is connected. The rts is successfully toggling 3->0->3V as needed to initiate port switching. I want to get rid of the error light in the program.
Thanks.
-
Joe,
I didn't ask what averaging was. I asked if you used linear averaging and asked if you had considered exponential averaging. You responded with a video explanation of how to average a list of numbers.
Once again, my inability to figure out your manual is met with the assumption that I had not read it. It feels like you harshly decide when a question is not worthy and ademently refuse to add any extra explanation to what you've written in your manual.
I'm trying to figure out your instructions using a circuit device and protocol I've never used before.
Does it seem like I'm not making an effort or did my entreaty to you about documenting your program just piss you off?
-
The cts use is supposed to be simple. The crux: I've got that 3V cts wire loose, not telling program that expected hardware(transfer relay) is connected. The rts is successfully toggling 3->0->3V as needed to initiate port switching. I want to get rid of the error light in the program.
So you do actually need someone to tell you to wire that CTS pin to ground. :palm: Imagine that, a TTL signal that is pulled up to 3V and you ground it to get a different state. Who would have ever guessed that....
That's derisive.
***
Added more detail in case it was not derisive enough!
Note to self.... Learn to spell... :-DD
-
I was suspecting my coupling caps were the primary cause of why my attempt to reproduce the CMT paper was a bit low. Replaced the 4 X 22pF TH coupling caps with 2 X 1pF NPO that were mounted to the fixture. (same caps used to replicate cyp_eev's experiment). Jumpers shown could be about a pF...
Q is now 14.388M / 750k = 19.2 Right on par.
-
I've never experienced or read about the meaning of "asserted" in the context of digital signals.
I would thank you for the detail except it feels like you used the answer as another opportunity to heap scorn.
Considering the words of encouragement you've offered me does not balance these harsh interactions.
No need to deride me further. I will not be back.
-
That article is somehow confusing. They are also using S21 for the calculation..
They are comparing the two methods against calculated values.
Interesting fixture.
Yes, indeed, you are right!
The fixture is 3d printed. I think I have saved some fusion 360 or stl files, if needed.
I've never tried the capacitive coupling method, but great to see it's working. Thanks!
For fun attempting to replicate your test except following the paper. I am using a 39pF ATC capacitor. Your couple of uH makes no sense with the 37.6MHz. Looks like we need something around 450nH. I cut one that measures 509nH. Whole setup seems to resonate around 35MHz. Close enough.
Looking at the group delay, I get roughly 2us or a Q of 217.
Yes, sorry, I have not calculated nor measured that L :-//, just cut a piece of wire and wrote "few uH" , so you are right.
I have also used a high quality cap from EXXELIA (https://www.digikey.com/en/products/detail/exxelia/501CHB390FCLE/14112408 (https://www.digikey.com/en/products/detail/exxelia/501CHB390FCLE/14112408))
Obviously your L has higher Q.
Re: Checking PIN diodes
This wireless method was what Copper Mountain discussed, but did not use in their experiment. Thanks for showing actual application of wireless measuring. So many questions:
What is point of break in coaxial sheath? Was break location by trial or by principle?
I'll have to study on coupling before I can appreciate other details. Thanks for showing results from both programs.
This article describes shielded and unshielded loops and also explaines the gap.
https://incompliancemag.com/article/shielded-vs-unshielded-square-magnetic-field-loops-for-emiesd-design-and-troubleshooting/ (https://incompliancemag.com/article/shielded-vs-unshielded-square-magnetic-field-loops-for-emiesd-design-and-troubleshooting/)
The PIN Diodes I have mentioned, are fast protection diodes, used to protect the MRI receivers from high RF energy fields.
In this case they are used in so called passive detuning circuits.
I try to simplify that.. So imagine the resonator I have used in the experiment as a receiver antenna and solder two diodes antiparallel on top of the capacitor. On low voltages,
under normal receiving conditions, this diodes have a very low conductance (aprox. 50uS). So the Q factor of the loop should be high.
Not so the defective diodes, with a lower resistance that decreased the Q factor.
The diodes should get conductive only when the MRI is transmitting and the voltage is rising. So they are basically clamping the capacitor, detuning the antenna thus protecting the receiver.
Happy Easter everyone!
Cyprian
-
[attach=1]Hello, I think will be simple to put your two-transistor NPN driver diagram with the FTDI cable to drive the transfer relay.
From the manual:The transfer relay is controlled by the state of the RTS pin. When RTS is de-asserted, Port 1
and 2 of the VNA will route to Ports 1 and 2 of the transfer relay. When RTS is asserted, Port
1 and 2 of the VNA will route to Ports 2 and 1 of the transfer relay. The software expects the
transfer relay to always assert the CTS pin, or it will set the transfer relay error (XferRly Err)
Transco PN# 82152-70070200 Driver
The Transco relay requires 24V and is a latching type relay. A simple DC-DC converter was
designed using a 7400 gate that boosts the USB voltage to 24V and charges a large capacitor.
This capacitor holds the charge needed to drive the relay.
Figure 93 shows the DC-DC converter made from a 7404 hex inverter. The two remaining
gates are used to buffer the signals to drive the relay coils. This is not meant as a reference to
base your own design from. Rather this is what I put together with what I had on hand
Reading the manual get some idea from the picture
-
Re: the meaning of "asserted" in the context of digital signals.
RS232 came out long before my time. I remember playing with a UART from Radio Shack in the 70's. The term assert in that context is common.
https://en.wikipedia.org/wiki/RS-232 (https://en.wikipedia.org/wiki/RS-232)
https://www.maximintegrated.com/en/design/technical-documents/tutorials/8/83.html (https://www.maximintegrated.com/en/design/technical-documents/tutorials/8/83.html)
Still, you only have two states to choose from and if the software is telling you that the state of CTS is wrong, common sense should have prevailed and you would have grounded the pin and moved on.
One question begs if software doesn't care about the state beyond setting the error so why use it at all? I still have several serial devices. Having the CTS signal always asserted isn't something common so I use it as a quick check to make sure I have the correct port selected.
... This is not meant as a reference to base your own design from. Rather this is what I put together with what I had on hand...
Reading the manual get some idea from the picture
You have seen my setup. That controller was a quick SPICE and built in a few hours. It sits inside a plastic bag... Nothing is mounted to any sort of structure. Goal was to demonstrate some decent performance with an off the shelf device over my previous attempts at building one from scratch.
I didn't ask what averaging was. I asked if you used linear averaging and asked if you had considered exponential averaging. You responded with a video explanation of how to average a list of numbers.
As we have seen, your questions typically leave me guessing as to what you are actually asking. Sometimes its easier to show things at the child's level and go from there. Sure you took offense to it. Oh well.
Some questions like this one, I left open assuming you would sort it out on your own.
Re: FIR smoothing
How many terms does the filter use? Please specify algorithm, ie Hanning, after Tompkins&Webster, etc.
I would imagine even the random button pushers would have figured it out in a few minutes and it goes something like this:
Wait, a tab titled "Filters". I wonder what that could possibly be.. Let's select it. Smooth Taps, Smooth Cutoff, Smooth Window, Smooth Type. My house and cars have windows. Whats a Smooth Window? Let's select it and see. What on earth is a Blackman Nutall. I just want to measure my antenna's SWR. Why does the Joe Smith guy make things so complex?
-
The fixture is 3d printed. I think I have saved some fusion 360 or stl files, if needed.
I could see that being helpful to a few people. If you wanted to take the time to detail it, I could add a table of contents to the starting post that links to it.
-
...
The nanovna 2 excels at this kind of measurement. However its not a "grid dip meter" obviously that is based on ancient technology. But the effect is the same and it has the potential to be much more precise. (if you adjust the stimulus parameters to give you high detail in the range you want to look at.
(The graphs I get when using it thethered - via USB are gorgeous.)
...
Consider my grid dip meter was most likely from the early 50's. My HP8754A VNA from the 70s. My PNA from the early 2000. We have come a long way in RF tools in a very short time. Much of what I show is just a ballpark. Many times the VNA isn't calibrated. If it is typically I stay with the ideal models.
The following was a recent link from RF cafe, July 1958.
https://www.airplanesandrockets.com/electronics/approxi-meter.htm (https://www.airplanesandrockets.com/electronics/approxi-meter.htm)
Fun site..
https://www.rfcafe.com/ (https://www.rfcafe.com/)
-
Shown with the same ATC 100B390JW 39pF capacitor but place it in parallel with a CoilCraft 0805CS-680X 68nH. The same 1pF NPO coupling capacitors were also used. This should get us just under 100MHz. Data sheet for the inductor shows a Q of about 45 @ 100MHz.
Using the grid dip meter, it seems to resonate around 90MHz. From the datasheet, Q would be around 40. It's difficult to use the grid dip meter to make this measurement.
Measuring with the Lite after calibration, the peak measures 90.29MHz. The 3dB delta is 2.4975MHz giving us a Q of 36.
Looking at the group delay with an average of 10, it's roughly 130ns which gives us a Q of 37.
Should be easy enough to replicate.
-
Noticed some chatter about the H4. Mine has never worked well enough to use it. Similar to my V2Plus, I suspect just poor firmware. I downloaded NanoVNA.H4.v1.1.00.dfu which appears to be the latest.
https://github.com/DiSlord/NanoVNA-D/releases/tag/v1.1.00
After programming this into the H4, it does show the correct version but it no longer sweeps, or rather sweeps VERY slow. Guessing several minutes to run a sweep with what ever the defaults are. Its almost appears likes its default IFBW is below even 30Hz. Rolling back to NanoVNA H4 v1.0.38.dfu and it appears to be back to normal. Reprogram in the latest, again hung. Takes maybe 3 - 5 minutes to show a trace on the screen. Setting BW to 4kHz no effect. Setting number of points to 101, no effect. Clear config and Reset have no effect. Move the center freq to 300MHz and 1MHz span has no effect. There's no software being used and the H4 is not connected to the PC.
As I said, it's never worked very well but seems it's much worse now. Those of you trying to get the H4 to work with my software, or just in general, good luck.
-
My grid dip meter can measure just over 300MHz. Plan was to do one last LC that resonates near the meters upper limit. Rather than the 68nH, a 6.8nH was used with the same 39pF ATC part. This should be a bit over 300MHz except for the parasitics, tolerance.....
Pic1 showing one of the the weak coupling caps. These are a 1pF NPO 06035A1R0CAT2A. See datasheet:
https://datasheets.kyocera-avx.com/C0GNP0-Dielectric.pdf
Pic2 removing mask and adding a small extender tab for the inductor to rest on.
Pic3 showing the 300MHz coil on the grid dip meter along with the new tank.
Pic4 Looks like it resonates just under 300MHz.
Pic5 showing completed tank attached to the LiteVNA
Capture3 Running an uncalibrated wideband sweep to get some idea what it looks like. Looks like it resonates near 295MHz.
Capture4 The LiteVNA has been calibrated. The peaks centroid measures 294.838MHz. The width measures 7.25MHz giving us a Q of 40.7. The data sheet shows it around 30 at 300MHz (Capture2).
Capture5 showing the group delay (50 averages) of 44ns. This gives us a Q of 40.7.
Not sure why the Q is so good. Then again, these are typical numbers.
-
My original NanoVNA does a fair job below 300MHz. The firmware I have will allow 1.5GHz but results are really poor as you go beyond 900MHz.
Shown is using a 3.3nH 0805CS Coil Craft part with the resonance at 800MHz. Just below where the Nano changes bands. Data sheet shows a Q of 40 typical.
First two pictures show the original Nano compared with the Lite with the tank attached after power up, no calibration.
Picture 3 shows the original Nano measuring a Q of roughly 36. Making the same measurement with the Lite gave a Q of 37.
-
The fixture is 3d printed. I think I have saved some fusion 360 or stl files, if needed.
I could see that being helpful to a few people. If you wanted to take the time to detail it, I could add a table of contents to the starting post that links to it.
I've found the stl files for the double H-field probe.
The loop is made of RG178. These connectors seem to be the same type I have used:
https://www.ebay.com/itm/194989969715?hash=item2d664ed133:g:8DUAAOSwTBBiX269 (https://www.ebay.com/itm/194989969715?hash=item2d664ed133:g:8DUAAOSwTBBiX269)
I hope to find some time this weekend and upload a video with more details.
-
The end of Solver64. We hardly knew you.
https://www.youtube.com/watch?v=TAsdr4ypBko (https://www.youtube.com/watch?v=TAsdr4ypBko)
-
I am sorry to hear you will not support the Solver
3264.
Let the market force tell them it may be a smart decision or not.
-
Why does the LiteVNA shift up and down near 750MHz? Both of mine appear to do it. As you can see, it has nothing to do with my software. The switch point has a fair amount of jitter and appears like quantization noise.
-
Plan was to try a higher Q tank above 300MHz and again compare the Lite with the original Nano. Showing group delay with 100 averages.
-
The end of Solver64. We hardly knew you.
https://www.youtube.com/watch?v=TAsdr4ypBko (https://www.youtube.com/watch?v=TAsdr4ypBko)
Would the community edition be an option ?
-
When I looked into it, I thought I read that the community edition required an internet connection and would stop working if one was not provided. There's no way I would invest any time into it based on that. All it would take is for them to pull the plug on it. After them changing their licensing, I have lost all trust in their leadership. Without a perpetual license, I am locked into the versions I own.
That whole NXG SNAFU tells you how disconnected they are from their remaining customers. I wonder how much they had invested into that. Lots of bad choices on their part.
Looking forward, I see no reason for the schools to offer it. I suspect things will start to dry up fairly quickly now. We have already dropped all of our contracts with them. I wonder how many companies are doing the same.
All my opinion. We will see how it plays out over the next few years.
-
Yeah, they want to transition to the software as a service model but they are just not providing anything new or more.
-
They do have their big parties and conferences if that's your thing.
-
And apparently nobody's working during the weekend. Their website is down since yesterday :-DD
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1470253;image)
-
Why does the LiteVNA shift up and down near 750MHz?
I think this related to MAX2871 switch
MAX2871 can generate in 3G-6G range, less frequency get from divide on 2, 4, 8, ....
750M - result 3G / 4 (at this point switch from 6G/8 to 3G/4)
Check 375M, 1.5G, 3G frequency
PS i not see this on my LiteVNA
-
Why does the LiteVNA shift up and down near 750MHz?
I think this related to MAX2871 switch
MAX2871 can generate in 3G-6G range, less frequency get from divide on 2, 4, 8, ....
750M - result 3G / 4 (at this point switch from 6G/8 to 3G/4)
Check 375M, 1.5G, 3G frequency
PS i not see this on my LiteVNA
I'm not sure how I would test it at other frequencies (outside of constructing unique tank test circuits). I'm not surprised you were unable to replicate it. It appears to be a very unique case.
Injecting an RF generator into port2 sweeping the signal looking at the peak, first we cut the problem in half (removing the drive side) but I do not see the step. I tried using a step attenuator to see if I could replicate it on a wider range or just at the 750MHz, no luck.
I can tune the LC tank off that 750MHz (lower to 700MHz) and the step will go away. The problem appears related to that 750MHz and appears to require a changing amplitude signal to replicate it.
I tried to reduce the drive strength one level and the step goes away. I then placed a step attenuator in series with the LC tank and again lowering the signal causes the step to go away.
I wonder if that high Q tank is causing some problem but only at certain frequencies. Really strange. Maybe one of the RF gurus can replicate it.
-
And apparently nobody's working during the weekend. Their website is down since yesterday :-DD
When I tried, it appears it was a planned outage.
-
Testing a tank at 350MHz, we can see the same step. What is interesting is as I reduce the drive, the location of the steps narrows (move closer to the peak).
***
I would show you this without the PC attached but I find it very difficult to scale what is on the screen.
-
Showing a higher Q tank with the same resonance as the last one (yellow trace). As we change the span from 100MHz down to 20MHz, we can clearly see the steps in the phase.
-
Zooming into the step. (Note, I changed the delay slightly to show it is not as some unique phase point).
-
The more I looked into it, it appeared to be tied to the fact it's a high Q rather than the frequency it is running it.
Shown with a Q of around 40 at 225MHz.
The second plot showing the exact same settings and same LC tank circuit. I have removed the two protection diodes on the front end.
Makes sense now.
-
I think you see gain step. V2 models use fixed gain settings for various ranges. This not allow get good resolution.
My last firmware changes - add AGC mode.
Exist one problem - not possible get perfect results on switch step due nonlinearity OpAMP gain. On V2 you also have this errors but not visible (you can see this near 140MHz on V2 most big jump and on 100MHz on Lite).
On start i made gain calibration (you can see it on DMSG screen as GAIN0-GAIN3) on fixed frequency.
How big step you see? My results near 0.01 to 0.05dB i thin this not critical
-
>>How big step you see? My results near 0.01 to 0.05dB i thin this not critical
With last tank, 0.043 dB. About 1 deg of phase error. Of course -1/2pi*dP/dF.. That one degree phase step causes some pretty large spikes in the group delay. I tend to agree. Its a low cost unit and there's nothing really critical. It's more just something to be aware of.
I am still using the same firmware from Feb. If you would like me to try a different version just post a link.
-
No, in this case you must see only amplitude sift (related to errors in gain), phase shift?
I for change AGC need time (near 4 IF periods), possible signal phase change in time? If you reduce IFBW phase shift change?
-
No, in this case you must see only amplitude sift (related to errors in gain), phase shift?
I for change AGC need time (near 4 IF periods), possible signal phase change in time? If you reduce IFBW phase shift change?
The first post, I show the lite stand alone, zoomed in to show the phase shift.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4134577/#msg4134577 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4134577/#msg4134577)
Changing the IFBW from 4k to 400Hz has no effect other than taking longer to acquire.
I posted a 3d plot showing how indeed the reported phase does change with time. However, it's a simple LC tank circuit. So the circuit it self it not changing to cause it.
Things that appear to have an effect:
Q
Loss in the loose coupling
Drive strength
Protection diodes
-
Joe’s software is excellent for interactive bench work. Can it be adapted to work as part of an automated test system? I could probably use an autohotkey script to push buttons and save data files but a direct API or SCPI commands would be more versatile.
One possible use case would be to characterize an LC tuner design over a range of its possible LC combinations; It could then be used for load pull testing (without the VNA). After setting each LC step, trigger the VNA to sweep and then store the S Parameters. A typical autotuner can have up to ½ million possible combinations, so maybe take about 1000 streps. For load pull, set perhaps an 8:1 VSWR and step phases through a full cycle.
-
Joe’s software is excellent for interactive bench work. Can it be adapted to work as part of an automated test system? I could probably use an autohotkey script to push buttons and save data files but a direct API or SCPI commands would be more versatile.
One possible use case would be to characterize an LC tuner design over a range of its possible LC combinations; It could then be used for load pull testing (without the VNA). After setting each LC step, trigger the VNA to sweep and then store the S Parameters. A typical autotuner can have up to ½ million possible combinations, so maybe take about 1000 streps. For load pull, set perhaps an 8:1 VSWR and step phases through a full cycle.
Seeing that it is written using software that was specifically developed for test automation, the answer is yes. I've also demonstrated some experiments where I have integrated other peripherals with the software to automate some of my experiments, for example:
https://youtu.be/XaYBpPCo1qk?t=4251
That said, I am guessing the easiest route would be to start with one of the many open source programs and just tailor it to fit your requirements. I would start by making sure that what ever low cost VNA you plan to use is capable of making your measurements.
-
Showing the raw real and imaginary int32 values of channel 1.
-
I prefer to program with LabView. However, i can likely work with the VNA-qt Python source to expose some controls to LabView.
-
I prefer to program with LabView. However, i can likely work with the VNA-qt Python source to expose some controls to LabView.
Another option would be to just write your own custom application. The interface is a simple serial port so really, not much effort there. Dislord has provided us with a lot of details beyond the basics depending on what you are trying to do. That was a big help for me.
With the downfall of National Instruments, you may want to consider something other than LabView, especially if you start from scratch.
If you do get some sort of load pull working with the NanoVNA, please take the time post about it. Maybe provide a link here. I would be very interested in seeing what you come up with.
-
Dislord,
After much more testing, I now believe this step is indeed a firmware problem. I had looked at the signals with a scope and it just made no sense that removing the diodes would have anything to do with it but lowering the amplitude does. I realized then that I had different firmware in the second unit.
I then upgraded the 2nd Lite to the same firmware and indeed the step shows up. So both VNAs behave the same.
As it turns out, the three released versions of firmware that I have from 220127 and older do not exhibit the step. The version from 220225 does. This was the last version I had downloaded.
I had saved the Beta versions you had uploaded here as well. The one from 220213 exhibits the step. So does the one from 220211.
So it appears what ever the problem is, it happened between Jan 27 and Feb 11. Afraid I can't narrow it down any further for you. Because you are unable to replicate the problem, if you have versions between these two that you would like me to try, just let me know.
***
I noticed a new release 220228. This version also exhibits the step problem.
-
You see gain step change. Older firmware use one gain setting for measure reflect data. Last use auto gain (depend from measured level).
And difficult question where is more correct measure. If use one gain settings you not see step, but error also present (you see smooth data)
Use AGC allow better measure low level signals on reflect.
-
You see gain step change. Older firmware use one gain setting for measure reflect data. Last use auto gain (depend from measured level).
I suspect there may be a language problem. Attached, I am looking at S21 transmitted data. After installing firmware 220224, I will see the step.
No calibration has been performed at this time. The VNA will display the step as I have shown. This step is not the reflected data. Looking at the raw channel 0 integers, I do not see the step in the incident or reflected data.
What is this gain setting you are referring to? How do you calculate it? What are you actually changing? Output power of synthesizers based on frequency?
And difficult question where is more correct measure. If use one gain settings you not see step, but error also present (you see smooth data)
Use AGC allow better measure low level signals on reflect.
Please explain this AGC algorithm in detail. Again, what ever it is you are doing causes a problem when looking at the transmitted S21 data.
When connected to the PC, I expect the VNA to always send raw data.
-
Before the signal is measured, it is amplified by an operational amplifier that has 4 gain levels.
If the level of the measured signal is low, the amplifier switches to a higher gain level. Later this is taken into account in the calculations. But it is rather difficult to connect all gain levels exactly, since the gain is not quite linear.
Using gain switching allows you to measure weak signals with higher resolution.
For example, without amplification, the signal has a level on an 8-bit ADC of 10 out of 2000, and using analog gain it can be raised to 1000 out of 2000
-
That's helpful to know. So the drive level remains constant.
Is this done for all ADC measurements? You mention the reflect but I assume it is for all measurements.
How do you handle glitches in the data? Do you have a fixed switch point and some level of hysteresis? Seeing how the signal looked like it was bouncing between states, it looks like a hard switch point.
Do you have a way that I can override the AGC with one of the debug registers? Maybe an enable bit as well as manual control of the gain stage. If so, I would like to try running a few tests on it.
-
AGC use for reflect and thru measures. Forward use predefined constant level depend from frequency range (AGC not need, forward signal always constant)
Older firmware use limited AGC for thru measures
How i made it:
I measure min/max value in one IFBW period and if i see low signal i switch to more high gain level. If i see overflow i reduce gain. After restart measure. For apply correct gain i need only one period.
Older firmware made full measure and after this apply gain and restart (and only for thru measures).
How this calibrated (on all fw versions):
Used fixed frequency, and measure forward signal in all gain levels. After this data normalised to 0 level.
you can see it in CONFIG->DMSG as GAIN0 to 3
You can manual control gain level by:
0xE8 - reference gain
0xE9 - Reflect gain
0xEA - Thru gain
0 to 3 used this value, 4 use AGC
!! you can get overflow if use high gain settings
-
If I set these registers, how do I tell your firmware not to change them? If there a way to turn off the AGC algorithm?
-
>0 to 3 used this value, 4 use AGC
Set 0 to 3 for thru data (0xEA) and you can see changes in noise level.
-
Could you provide gain values?
Setting a value of:
0 Av=?
1 Av=?
2 Av=?
3 Av=?
4 = AGC enabled
-
This depend from hardware, you can see it in CONGIG->DMSG screen as GAIN0 to GAIN3
Not need recalculate, device do it by self in any case.
-
So there are different revisions of the Lite hardware with different gains? There is some sort of diagnostic menu that displays these gain values?
-
No all Lite have ¬equal gain settings. Difference only from the accuracy of the components used (resistors and capasitors)
Go to CONGIG->DMSG menu (i write this 3 times)
BBGAIN0 to 3 gain levels
-
>>(i write this 3 times)
lol, yes, I know but I do not have the Lite sitting here. I am away right now. Let me get back with you after I have a chance to look at it.
-
This is very interesting. So you add some amount of attenuation.
Power cycling my Lite several times, it will come up with new numbers. So you attempt to calculate these on power up. With you switching these, how is the calibration handled? I would doubt very much that the attenuation is flat over the entire operating range. So when running the SOLT, it would only be for one attenuation setting.
-
Shown with the Lite sweeping from 150M to 2GHz, no calibration was performed, cable attached between the two ports.
Red with 0xEA set to 0, yellow with it set to 2. Note that the attenuator is not perfect. Treating it like it is will cause more problems than good. So, how does your AGC handle these errors?
-
How do 1, 3 and AGC look, for comparison?
Do any of the 5 curves (0,1,2,3,AGC) match with each other? (ignoring noise)
Are you sure that you don't overdrive the IF amp and/or ADC? [ That's of course a potential risk of manual gain. ]
-
Are you sure that you don't overdrive the IF amp and/or ADC? [ That's of course a potential risk of manual gain. ]
I am testing with a section of coax, so yes I am sure I am not overdriving the input.
Do any of the 5 curves (0,1,2,3,AGC) match with each other? (ignoring noise)
Yes. With the coax attached, the AGC appears to use a setting of 0 (no attenuation, no surprise). These two settings match.
How do 1, 3 and AGC look, for comparison?
Shown with all five settings. Again, no cal, coax from port 1 to port 2.
**
Sorry, wrong setting on graph.
-
Same data but attempting to show the difference in the slope at 100MHz.
Again the feature may be useful in some cases. I'll need to give it some thought. Normally I would want the step attenuator right at the front end.
One thing I am not sure about is how these settings effect an LC tank. I'll check that later to make sure that turning off the AGC solves it.
-
The step in the transmission is certainly from the AGC algorithm.
Attached, notice how as the signal starts to rise, they actually reduce the attenuation making the signal even larger, then as the signal starts to drop again it adds attenuation. If its not saturating the ADC, why reduce the signal at all? Leave it at 0dB so we get the most signal through.
Even if we were working in some non-linear region of the ADC, the logic is backwards. Looks like a bug to me but hopefully Dislord can clear things up.
-
Yellow is obviously AGC. What is red and purple?
-
Manually changing gain to match AGC is all. Funny, -15dB down, even with no cal, we are no where near pushing that ADC.
-
The ripple at the top of the purple trace is strange. If it were just noise, I'd rather expect it at lower levels, not at higher ones. What gain is purple?
-
Just for fun, I added an amplifier and step attenuator between the LC tank and port 2. I set 0xEA to 0 and increased the amplitude until I started to detect compression. It's about 20dB higher than the signal we are trying to measure. I must really be missing something basic. Could be lack of sleep.
-
Looking at the schematic for the V2_2, it does appear to be a gain stage. This makes more sense with what Dislord has posted. So I tried setting 0xEA to 3 which I expect to add -20dB of gain but instead it it saturates the ADC. The firmware however reports an even lower gain. So the firmware must be trying to help me.
To I connect a 10MHz -50dBm signal to port 2 and measure the reported amplitude with the 4 different gain settings and sure enough they are all the same. Yep, it's trying to make my life easier by doing some calculations for me. I then set 0XEA to 3 and the input signal to 0dBm. Saturates. As I lower the input signal and then measure where it starts to decompress for the 4 different gain settings, these appear to match up with Dislord's numbers.
So as the signal gets smaller, indeed he attempts to gain it up. It just didn't make sense as the firmware doesn't report the actual raw ADC values.
-
Assuming that's correct, I am back to how do you compensate for the errors the gain stage makes? Does it even make sense to have AGC? I could see some cases where gaining up the signal may make sense assuming we are just not amplifying noise.... We could select the gain we want and just cal out the errors.
Now that its all clear as mud let's try to compare the AGC algorithm against manually setting the gain with a very low level signal. Back to shunt thru PDN measurements with my 100uOhm standard...
Shown with the gain set to 1, 3 and with the ACG enabled. I don't think this is a good use case for it.
-
I guess the reported BBGAINx numbers just have the wrong sign. Or they are meant to be the correction factors (i.e. 1/gain, or 20*log10(1/gain) in dB) to be applied (by the firmware) in order to normalize raw readings with different gain to a common scale. Since different frequency points can be measured with a different gain (when AGC is on), it makes sense to normalize them to a common scale. If I did understand DISlord correctly, then in case of averaging even each of the chunks being averaged could have been acquired with different gain, which also mandates a common scale.
-
I suspect when Dislord calls it gain but uses a negative sign its a language difference. It's not a problem as long as I understand it. I don't look at these menus and when using the PC they are disabled anyway. The problem is what does it mean. A gain setting of 3 for example may indeed represent 20ishdB of gain at 10 MHz but not at 2 or 6GHz.
If they wanted to normalize the gain, then they should characterize it for each gain level over the entire sweep range not just one data point. Maybe it can be done. The PC could certainly do it. Still not sure I want the firmware mucking with it. Measuring group delay is a good example of where AGC can cause problems.
As I said, even power cycling the unit several times, it will show different gain vales due to the noise. If this is a single constant being applies, we are at the mercy of whatever the firmware came up with for a gain value on power up. To get around the warmup, maybe you can reset or something to have it recalculate without power cycling.
IMO when using software, the closer it can get to having the the raw data the better. If makes the firmware easier to code, requires less resources in the embedded system and makes the system more flexible.
Details, details...
-
With all the open source interface software which as I understand it, allows everyone to modify the source. Coupled with how popular these devices are, I'm surprised we don't see more people running such experiments and asking these basic questions. Then again, it's always possible my lack of sleep is not allowing me to clearly think about it.
-
Gain value normalized to Gain0
These are correction factors in order to bring the value to a single value (Gain0 was chosen for it, so I need apply -20dB if use Gain3)
Signal amplitude various in all range, so need use correction.
You can control it from external software (use this debug register), but you can`t know then you get wrong values due to overflow from selected.
You get errors in any case use or not gain due not linear OpAMP (if use AGC you get less error), yes you not see steps (measures look as OpAMP linear, but no - see green line on image)
If use AGC OpAPM range divided by regions, and relative error less. But difficult glue all regions (red lines).
Addition problem: gain values depend from frequency. Most good way - made N GAIN measures in all range and use interpolation, but in less ¬300MHz range not possible calibrate Gain 3 due to overflow in any case.
-
Addition problem: gain values depend from frequency.Most good way - made N GAIN measures in all range and use interpolation
Why does it actually depend on frequency? Isn't the gain always applied to the same 60kHz IF frequency? 1)
Then flatness should not matter. Do you have an explaination?
I wonder, btw, is the gain calibration a vector calibration (complex scaling factor) or just magnitude?
I were not surprised, if the phase response of the amplifier (at the IF frequency) were slightly different for different gain.
1) I can understand it for very low frequencies, since a different (lower) IF is used. But shouldn't one calibration for each IF frequency then suffice?
-
On different freq range i get different base amplitude, so i measure different points on gain curve.
I don`t know real signal amplitude before gain, just after gain
Most this problems fixed by calibration, but calibration can`t fix non linearity.
-
Gain value normalized to Gain0
...
You can control it from external software (use this debug register), but you can`t know then you get wrong values due to overflow from selected.
Are the Gain0-3 values that the firmware calculates exposed to the software? Is there a flag that will turn off the normalized values while still allowing the gain to to be changed?
-
I am not understanding your graph and the criteria you use to change gains.
-
on lower 400kHz always used gain 0 in any case for all (on enabled AGC)
Not remember why i use this (possible need enable, but at this moment i not have free time for tests).
-
on lower 400kHz always used gain 0 in any case for all (on enabled AGC)
Not remember why i use this (possible need enable, but at this moment i not have free time for tests).
I'm surprised that gain 3 is used at all below 300 MHz, if it cannot be calibrated:
... but in less ¬300MHz range not possible calibrate Gain 3 due to overflow in any case.
-
Shown with the 100uOhm and 1mOhm resistors using an average of 10 and gain of 3. I think this is the first time I have been able to discern between these two parts using the Lite.
-
LiteVNA test firmware
I enable AGC in all range for tests
This fw also contain new traces for S21 measures (Series R/X and Shunt R/X and Q)
Small improvements for LCD draw and SD cards
-
Just loaded. It appears to be for the small display. I'll go ahead and run it anyway.
-
Archive contain 2 firmwares LiteVNA 64 for big and LiteVNA 62 for small displays
-
Archive contain 2 firmwares LiteVNA 64 for big and LiteVNA 62 for small displays
I don't think I ever sorted out where you have them archived.
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3928550/#msg3928550 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3928550/#msg3928550)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3928592/#msg3928592 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3928592/#msg3928592)
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3930395/#msg3930395 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg3930395/#msg3930395)
I never joined that groupio mail list for beta testers. Is that the only way to gain access?
Anyway, the new firmware does appear to correct the AGC limitation. Shown with a 1mOhm, 0.1mOhm and short. Graph is S21, not resistance. Not anything useful below 50kHz but certainly improves the lower region.
-
Not anything useful below 50kHz but certainly improves the lower region.
If there is no error in my calculation1), then 1mOhm shunt has S21 of -91dB, and 0.1 mOhm -111dB.
Noise floor is still too high for that use case. Ideally, you'd rather need a noise floor of say -120dB, or even lower.
You could try to increase the averaging further to 100x or 1000x. Rather reduce the number of points, if it becomes too slow.
But even if you can further reduce the noise floor, I wonder whether the gain calibration will be accurate enough at such low levels.
The discontinuity at 400 kHz is quite large, too.
1) https://cds.cern.ch/record/1415639/files/p67.pdf, page 88, "3. shunt admittance", for Y1=Y2=1/50, and Y=1kS and Y=10kS
-
Math seems in the ball park.
Some time ago when I made these two standards and transformer, I used my higher end equipment. I am using them with the Lite only for a fringe case. The original NanoVNA did a much better job of it.
10x average takes a very long time to run. One sweep maybe 6 minutes or so. 100X about an hour per sweep. Compare with a few seconds on my vintage VNA.
-
Working on a rotor to make 3D radiation measurements.
-
5 deg resolution.
-
I was wanting to try something a little more directional on the new 3D mount and decided on putting a simple antenna together with a discarded bean can.
https://jacobsalmela.com/2013/09/07/wi-fi-cantenna-2-4ghz-how-to-make-a-long-range-wi-fi-antenna/
The can I used measures 109mm x 73mm. From their drawing, this can should be good for 2.1GHz, or a wavelength of 143mm. After construction, the Lite showed very poor SWR so I added a few stubs to try and tame it.
-
CAN9
Running the can at 4GHz.
CAN10
Comparing the 4GHz radiation pattern with running the same setup at 5GHz. It looses all directivity.
CAN11
Comparing previous data sets with the same setup at 2GHz (1.94GHz).
CAN12
Looking at the 2GHz data in 3D.
-
CAN13
Moving the bean can further away and running a much higher resolution sweep. Next time I have beans, I'll lengthen the waveguide.
***
This was a paper I had read on making these measurements.
https://www.ets-lindgren.com/WhitePapers/APM.pdf (https://www.ets-lindgren.com/WhitePapers/APM.pdf)
-
Using the newer 3D plotting with the wire frame disabled. This scan was taken at 2 degrees or 16,200 data points. Imagine taking that by hand.
Next step is add some sort of auto align and measurement readouts. Maybe a basic field calculator.
-
Rather than having an auto alignment for the antenna, I just rifle through the data to find the peak and consider that head on. Showing calcs for the half power beam width. Both azimuth and elevation are calculated. For the front-to-back ratio I plan to use the BASTA standard.
Without a chamber and reference antennas, it's more just for the fun of it.
http://www.mobi-antenna.com/uploadfiles/2017/07/201707241212321232.pdf (http://www.mobi-antenna.com/uploadfiles/2017/07/201707241212321232.pdf)
-
Motors for rotor system.
Would you be willing to create a block diagram of your system setup?
-
Motors for rotor system.
Would you be willing to create a block diagram of your system setup?
If you read those few links I had posted and watched the video, it should have been fairly clear but let me try and expand on it for you.
I have the PC tied to the LiteVNA using USB. I have two M-Drive motors as my document describes fitted with a gear drive. These are configured for multi-drop on an RS-485 bus. One motor is used for the azimuth (horizontal) the other for elevation (vertical). There is a separate power supply for the two motors. The RS485 to USB adapter is connected to the PC as well. The LiteVNA has two ports. Port 1 connects to the AUT (antenna under test) and Port 2 to the reference antenna. The LiteVNA sends the signal out Port 1 to the AUT. The signal is then received by the reference antenna on Port 2. The software tracks the signal strength while it moves the antenna.
Currently, the software starts by pointing the AUT downwards and sweeps the azimuth from 0-360 degrees. The elevation is then set to the next angle and the process repeats until the elevation has swept from 0-180 degrees. This gives us our full sphere.
I made a quick block diagram for you but it isn't very helpful as there really isn't much to it. There are lots of papers and videos on this subject if you are interested. Maybe the following videos will help. I hate to guess what that whole setup costs.
****
Block diagram shows PORT1&2 swapped to my current setup.
https://www.youtube.com/watch?v=LVsv26JjcNE (https://www.youtube.com/watch?v=LVsv26JjcNE)
https://www.youtube.com/watch?v=D_2hZZXYtow (https://www.youtube.com/watch?v=D_2hZZXYtow)
-
Thanks Joe
-
Shown is the Vivaldi I attempted to copy from our friend who was experimenting with RADAR. There is also a poorly constructed dipole along with a fresh can of pork and beans. Used the Dremel tool to cut off the bottom of the can and removed the ring from the top of the original can. After that, it was easy enough to solder together. I moved the mounting bracket to center the antenna.
The dipole sort of radiates like we would expect.
-
The Vivaldi compared with the dipole.
-
Showing the new bean can antenna pointing downward compared with the Vivaldi and dipole. Stubs had to be retuned after extending the waveguide.
-
Showing the SWR after extending the waveguide and adjusting the stubs. It seems to improve the side lobes.
-
I'm not able to make work the nanoVNA solver lite/v2 +4 for the liteVNA.
Anyone have it running in windows 11? I really having a bad time trying to understand the issue, no idea if it is the software that just won't run as it is deprecated, it can run but I had something wrong with the National instruments runtimes that Im unable to understand even what they are, what they do , just unable to make it work. Other softwares works. I don't want disturb, sorry if this not proceed.
-
I don't have Windows 11 installed on a PC to try it.
https://forums.ni.com/t5/NI-Package-Manager-NIPM/Does-LabVIEW-software-support-on-windows-11/td-p/4177747
Windows 11 was announced long ago; and there have been many Windows Insider releases to allow companies like NI to port their products such that they would be fully functional by the time Windows 11 started deployment to user systems.
Telling me that NI is "targeting support in 2022 H2" is basically telling me that they failed to support their user base. The majority of software companies worked hard to get Windows 11 support available contemporaneously with the release of Windows 11. Why didn't NI?
Until I actually try it, I wouldn't trust what I read on the internet.
Other softwares works.
Windows ships with a lot of software. When Notepad fails to run with a new release, they have a big problem.
***
Talking with a friend who has ran some basic tests with the 64-bit LabView on 11 and no problems. I would imagine he's done a decent shakedown.
-
I would start by installing the drivers and making sure your PC recognized the VNA. I use the standard drivers with Windows 10. If 11 doesn't find it, you need to locate proper drivers. If that works, then you need to install the latest the National Instruments 2021 SP1 64-bit runtime and NIVISA. Then you will need the 64-bit sound dll. Don't expect anything to work if you are mixing 32-bits and 64. If you still can't get it to work, then I suggest going to one of the open source applications. Actually, you may want to just start there.
-
I don't have Windows 11 installed on a PC to try it.
https://forums.ni.com/t5/NI-Package-Manager-NIPM/Does-LabVIEW-software-support-on-windows-11/td-p/4177747
Windows 11 was announced long ago; and there have been many Windows Insider releases to allow companies like NI to port their products such that they would be fully functional by the time Windows 11 started deployment to user systems.
Telling me that NI is "targeting support in 2022 H2" is basically telling me that they failed to support their user base. The majority of software companies worked hard to get Windows 11 support available contemporaneously with the release of Windows 11. Why didn't NI?
Until I actually try it, I wouldn't trust what I read on the internet.
Other softwares works.
Windows ships with a lot of software. When Notepad fails to run with a new release, they have a big problem.
***
Talking with a friend who has ran some basic tests with the 64-bit LabView on 11 and no problems. I would imagine he's done a decent shakedown.
Just thank you by the extensive answer, I will try everything today.
Just congrats you by your knowledge and thank you by share it.
I hope make it work!!
-
ohh, maybe my problem is NVISIA, as there is a very recent version, there is 20 ,21, 21.5 which of them should I install and that sound file where should be installed? I couldn't see any error of sound. Should I install the firmware included in github?.
-
ohh, maybe my problem is NVISIA, as there is a very recent version, there is 20 ,21, 21.5 which of them should I install and that sound file where should be installed? I couldn't see any error of sound. Should I install the firmware included in github?.
It could be. Without you taking time to detail what you are doing, I can only guess. How many times I have brought up that I do not have a crystal ball.
The last person I attempted to help was suggesting that my software was throwing up bad data. They took the time to create a video showing all the steps they were taking. It was immediately obvious what was wrong. They did not understand the metric system and were entering numbers like 100mHz which is certainly valid. Screen shot can also be helpful. One person was suggesting that the sweep would not show any data. It turned out they had modified the calibration standards coefficients and created a divide by zero. Very easy to spot with a screen shot.
Like many, your stuck on the basic install. As I already mentioned, I would have no way of knowing if your PC sees the VNA or not. It has nothing to do with my software. If that doesn't work, there is no point in installing any of my or NI's software. Take the time to document exactly what you have done or there is little I can do to help.
Also, keep in mind that I have abandoned the 64-bit software due to NI's extortion business practice. I have no way to address any problems you may find with it. IMO, you are wasting your time with it but it's there for those wanting to try it out.
-
Hi, I just want to confirm that your software is working and is wonderful
It is working in Windows 11, with the NI stuff you said, and no issue with the sound dll file.
Thanks a lot by your time. I just reinstalled and worked, no further intervention, maybe ir was a faulty LiteNVA , I made it work with a second unit with same firmware version.
Thanks take this effort, and use you unquestionable talent and knowledge to help help others
-
That is good to know as you are the only person I know of that has tried to run it on 11. My friend flipper's Lite was supplied with a defective USB cable and we ran into that snag with the design not considering the full range of voltage available on the port. Outside of that, I've not had any real problems with the hardware. It's become my favorite of the low cost VNAs. If they ever improve the lower frequency performance, I would certainly order up a new one.
Take care and enjoy your new VNA.
-
It's been several weeks since I last made any changes to the software and consider it stable. I have uploaded revision 3.06 32-bit for the LiteVNA and V2Plus4.
I also updated some of the photos in the README and have included ALW's where he is attempting to measure his heart rate. Also some data from the 2-axis rotor is shown.
-
Hi, @joeqsmith just let you know in case someone ask you, I could install Solver32 LiteVNA that you recently updated in Windows11, keeping the Solver64 Setup.
I could install the old NI and VISA runtimes without conflict.
It is working now I need learn a lot of RF and your software, I just got the stuff required and got set it up, from now will be everything learn, I honestly think your software and Satsagen (6 Ghz SA,TSA,Sig.gen. for ADI Adalm Pluto SDR) will be the most useful tool I have.
I just seen the WIKI with the 3D radiance antenna plots and I almost fall from my chair.
-
If you find the performance of the 32-bit acceptable, you may want to consider removing the 64-bit just to save some space. Any future updates would be with the 32-bit for the LiteVNA and V2+4.
-
I think it just run fine. I only need learn RF and use it! Thanks!
-
Just it know here in liteVNA group.io, someone posted a newer version. It is nice as it can save calibration files in the SD card with names, the pictures can receive a name too.
It looks solved a issue I had that the VNA lose the calibration a lite every day, and in two or three days you need make a calibration.
I guess you need be group member to access to this link
https://groups.io/g/liteVNA/attachment/540/0/LiteVNA64%20v1.3.00.bin
-
If you find there are problems when using my software with it, I'm using Dislord's firmware 1.2 Jan 27 2022.
-
It seems they released a new version of the LiteVNA which may address some of the USB problems I had demonstrated where the did not consider the full voltage range of the standard. You can see that in the video below starting about 49 minutes in. I have no idea if they actually did solve the problem or make any improvements only that they posted about it.
https://groups.io/g/liteVNA/topic/the_new_litevna64_which/93138117?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,93138117,previd%3D1661010961385874549,nextid%3D1649971688251132758&previd=1661010961385874549&nextid=1649971688251132758 (https://groups.io/g/liteVNA/topic/the_new_litevna64_which/93138117?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,93138117,previd%3D1661010961385874549,nextid%3D1649971688251132758&previd=1661010961385874549&nextid=1649971688251132758)
https://www.youtube.com/watch?v=G4eLcTC4Ako (https://www.youtube.com/watch?v=G4eLcTC4Ako)
-
Hello, the new NANO VNA 6000 is on sale, can work with your software?[attachimg=1]
-
Hello, the new NANO VNA 6000 is on sale, can work with your software? (Attachment Link)
Are you spending the $800+ USD to find out?
https://www.tindie.com/products/hcxqsgroup/nanorfe-vna6000/ (https://www.tindie.com/products/hcxqsgroup/nanorfe-vna6000/)
I don't see it being a popular item. The cost is too high for someone wanting to get started learning about VNAs. From a professional view, it really doesn't offer anything new. We have the LiteVNA which my software has been tested with. I do wonder if they actually improved the Lite's hardware but it's hardly worth spending any cash on it to find out.
The most recent software I have released was tested with the V2Plus4, V2Plus and LiteVNA 64. In all cases, this will be highly dependent upon the firmware. I only found one version of firmware that would work with the V2Plus and not cause the VNA to hang. Because the developers do not provide products for me to test, I really can't say how the 6000 behaves. It's really up to the product developers to ensure they adhere to the protocols they came up with to control them. If they make any changes, I would expect it to brake.
-
$789 for the A version and $1499 for the B one. Looks like LibreVNA is better positioned at around $600.
Since I upgraded my NanoVNA V2plus4 last week to the latest 20220814 firmware I see that the "Save" feature is not working anymore, after power off/on again it goes to default settings. On top of this "Recall" presets crash the unit and it needs a power cycle.
VNA6000 is using the same firmware... so I guess it is also inheriting these bugs.
-
$789 for the A version and $1499 for the B one. Looks like LibreVNA is better positioned at around $600.
Note that the thread is about custom software for the NanoVNA, which includes the V2Plus4 and the LiteVNAs. Because the LibreVNA's direct protocol to control it is not documented, I have no plans to ever support it.
The cost for OWOs 6GHz versions along with there's just not enough improvements for me to consider it. If I wanted a higher end VNA, I would purchase a used professional system (which is what I have).
Since I upgraded my NanoVNA V2plus4 last week to the latest 20220814 firmware I see that the "Save" feature is not working anymore, after power off/on again it goes to default settings. On top of this "Recall" presets crash the unit and it needs a power cycle.
I have no use for any firmware features beyond getting the raw data out of the unit as fast as possible and having control over the hardware. The only reason I would use one standalone is for a demonstration. The display, buttons, SD card interfaces for me have no use.
I have posted many times about the problems I have ran into with firmware and software both. There's a reason I don't upgrade firmware and write my own software.
VNA6000 is using the same firmware... so I guess it is also inheriting these bugs.
The V2Plus4 firmware that was supplied with mine was very stable. The firmware for the V2Plus would hang and require the unit be power cycled. After having them for about a year, I tried several versions of firmware for the V2Plus before finding one that was stable. Newer versions would hang as before. I wouldn't suggest any firmware is good or bad without performing extensive tests on it.
The firmware for the original NanoVNA was so poor and was being updated so often I wrote a regression test to help me sort though the mess. The downside to open source, you have people that maybe shouldn't be coding working on it. The version I run is very old and has no features. I could care less as it's stable and throws up some good enough data.
-
Using the LiteVNA to run a few tests on 1Gb Ethernet.
-
Intel paper: 1000BASE-T/100BASE-TX/10BASE-T Physical Layer Compliance Tests Manual
https://community.intel.com/cipcp26785/attachments/cipcp26785/embedded-core-processors/2456/1/1000BASE_T%20100BASE_TX%2010BASE_T%20Physical%20Layer%20Compliance%20Tests%20Manual.pdf (https://community.intel.com/cipcp26785/attachments/cipcp26785/embedded-core-processors/2456/1/1000BASE_T%20100BASE_TX%2010BASE_T%20Physical%20Layer%20Compliance%20Tests%20Manual.pdf)
Section: 1000BASE-T MDI Return Loss
The BALUN uses a Mini-Circuits TC1-1-13M. The paper shows a start frequency of 1MHz where this transformer is spec'ed for 4.5M - 3G. Digikey still offers an evaluation board for this transformer (shown in previous picture). Datasheet may be found here:
https://www.digikey.com/en/products/detail/mini-circuits/TC1-1-13M/13927704 (https://www.digikey.com/en/products/detail/mini-circuits/TC1-1-13M/13927704)
Attached showing the return loss of all four channels on four different boards.
With the newer firmware for the LiteVNA supporting harmonic modes in excess of 9GHz, I attempted to make use of this to look at the trace matching on the PCBs along with looking at a few different cables. One thing I may add now is a way to save some of the TDR data or at least give you a way to measure the change from a reference.
-
It appears CMT recently posted an article about using BALUNs with a VNA. While the article is more generalized and not specifically about Ethernet, they chose to use the same Mini-circuits part.
Online Spotlight: Balun Measurements with a Two-Port Vector Network Analyzer
July 14, 2022 Brian Walker, Copper Mountain Technologies, Indianapolis, Ind.
https://www.microwavejournal.com/articles/38492-balun-measurements-with-a-two-port-vector-network-analyzer?page=3 (https://www.microwavejournal.com/articles/38492-balun-measurements-with-a-two-port-vector-network-analyzer?page=3)
-
Another article from Tektronix (previously Picosecond Pulse Labs) describing their ultra wideband BALUN.
-
Added storage to my software's TDR function. Shown using the LiteVNA to look at the individual wires of a 4' CAT5E cable. The length looks like it varies about 6.8mm. There was no averaging and the IFBW was set to 4k. Sweep range was 100k to 9G.
Also shown is the transition from the coax to the wires. This is of course very stable and my adapter isn't going to add a lot of error. 620mm is roughly 2' which is roughly the length of my coax cables.
For now, rather than having a separate memory button for each location, I just have a single button that increments to the next location.
*** Note that there was no attempt to calibrate the VNA for this particular test.
*** SNAFU
-
Datasheet for the ADT2-1T may be found here:
https://www.minicircuits.com/pdfs/ADT2-1T.pdf (https://www.minicircuits.com/pdfs/ADT2-1T.pdf)
While the TC1_1_13MA was setup as a current BALUN, the ADT2-1T was setup as a voltage BALUN. Attached showing the return loss of the four pairs on our 1Gb Ethernet after calibration.
https://blog.minicircuits.com/demystifying-transformers-baluns-and-ununs/ (https://blog.minicircuits.com/demystifying-transformers-baluns-and-ununs/)
-
My cable length mismatch setup was flawed. The software had a bug and the scales were not even close... These problems have been corrected.
The following was taken from an Anritsu paper:
https://dl.cdn-anritsu.com/en-us/test-measurement/files/Technical-Notes/White-Paper/11410-00988A.pdf
Skew
Extremely high data rate signals can be created by combining multiple parallel paths at lower rates. For
instance, a 40 Gigabit system can utilize four parallel 10 Gigabit paths. Where this is done, care must be
taken to ensure that the propagation time through the various paths is the same. The difference in
propagation time is called skew; skew between traces of a single differential pair is intra-pair skew and
skew between two or more differential pairs is inter-pair skew. If the connecting medium is coaxial
cable, tight control of mechanical length and dielectric tolerances will produce minimal problems with
skew. However, when differential twisted pairs are the conducting medium, the number of turns per
inch is a critical factor in determining propagation time. Commercial CAT5e/6 cable can have as much
as 10 nanoseconds of skew between the paths in a one hundred foot run. This equates to as much as
ten feet of electrical length within the same cable!
Skew is a time/electrical length measurement and is easily determined using the time domain
capabilities of a VNA. Where both ends of the cable are available (prior to installation), it becomes a
straightforward insertion phase measurement. After installation, reflection phase can be used to
measure differences in propagation time. For this measurement, the far end is shorted, so a high
reflection is presented to the instrument. This makes it easy to derive comparisons of roundtrip time.
Roundtrip time must be divided by two, either offline or within the measuring instrument. All Anritsu
VNAs can provide the one-way or round trip times in time domain reflection mode.
We are only looking at a Gb. For this test I am using a 7' length of CAT5E cable.
CAT5E_Matching_Setup:
LiteVNA was set to sweep from 100kHz to 9.3GHz. 601 data points was chosen to allow us to measure the 7' cable + the VNA's interface cable. VF was set to 0.64. Once again, no calibration was performed (we are just looking for a ballpark number)
CAT5E_Matching_Open:
Looking at the VNAs test cable with nothing attached. The cable measures roughly 22" (ruler) or 560mm.
CAT5E_Matching_7ft_pair1:
Measuring the first pair and saving to location 1 (Green trace). I zoomed in vertically to show the 50ohm coax and the 100ohm CAT5E cable. Notice the distance between the two cursors is 2.085 meters or about 6.8 feet. Roughly the length of my test cable.
CAT5E_Matching_7ft_pair1_4:
Collecting all four pairs.
CAT5E_Matching_7ft_pair1_4_delta:
Setting the two cursors during the open transition. It appears we have roughly 42mm of mismatch between pairs. From the Anritsu paper I am guessing this is not unusual.
-
Showing the new transformer and CAT5E test cable.
-
I had posted how my friend Shimp's LiteVNA was very noisy and how I have made up a dropping USB cable to improve it. I have been using Dislords unreleased firmware that he posted here that improved the AGC (V1.2.09). Today I tried out the latest firmware 220228 and at least the AGC is still working. My plan is to transition over to the new firmware (assuming I don't run into any problems with it).
This VNA would get much worse (noise) when the battery was removed. I ended up pulling the 220uF bulk and adding several tant and ceramics to try and improve the noise. Shown even without the USB dropping cable, this VNA is now as low as my other VNA. Removing the battery now has no effect.
-
I had also attempted to bump up the IF gain a small amount. The noise was too high and my first attempt yielded no improvement. I made another attempt and saw a slight improvement.
-
New release is now available. I made a short clip showing how to use the new TDR memory feature.
https://www.youtube.com/watch?v=etTUs8tVjA0 (https://www.youtube.com/watch?v=etTUs8tVjA0)
-
Scratch pad reminders....
https://www.salukitec.com/resource/time-domain-reflection-tdr-impedance-test/ (https://www.salukitec.com/resource/time-domain-reflection-tdr-impedance-test/)
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/pdm/cl_manuals/user_manual/1173_9163_01/ZNB_ZNBT_UserManual_en_62.pdf (https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/pdm/cl_manuals/user_manual/1173_9163_01/ZNB_ZNBT_UserManual_en_62.pdf)
https://www.signalintegrityjournal.com/articles/432-s-parameters-signal-integrity-analysis-in-the-blink-of-an-eye (https://www.signalintegrityjournal.com/articles/432-s-parameters-signal-integrity-analysis-in-the-blink-of-an-eye)
***
http://teledynelecroy.github.io/SignalIntegrity/SignalIntegrity/App/Help/Help.html.LyXconv/Help-Section-1.html#toc-Section-1 (http://teledynelecroy.github.io/SignalIntegrity/SignalIntegrity/App/Help/Help.html.LyXconv/Help-Section-1.html#toc-Section-1)
-
There may already be some add-on software that would allow you to import a Touchstone file and run some of these simulations.
-
A sort of PAM4.
-
Short video showing how the eye diagrams would work.
https://www.youtube.com/watch?v=5bkgglrd-YI (https://www.youtube.com/watch?v=5bkgglrd-YI)
-
I added support to synthesize both PAM-8 and 16 (shown with PAM-8 selected). The time scale was corrected and the bit rate is now programed in Hz (shown with a 5Gb signal).
The code was added to my PNA software. Basically if you are running TDR, the eye is being updated live. It would have been nice to have the newer 64-bit LabView for this but sadly, I can't do anything about it.
While the Bonaguide and Jarvis book I referenced does explain the basic math in a paragraph, the Dunsmore book dedicates a few pages. While he doesn't provide any of the basic details on how it works, he does mention Keysight's Physical Layer Test Solution as being able to create eye diagrams from previously measured data. It doesn't appear Keysight supports this software. They offer a download but when you try and request a trial license, the website it broke.
I have enough of the basics implemented and the next step is to sort out how to validate it.
-
I thought I would search YT for any videos demonstrating the use of eye diagrams with a VNA. Because the videos may cover a lot more than eye diagrams, I used the time link. There doesn't appear to be a lot out there. My short clip I made is coming up first in the search and that's bad. If you are aware of others please provide the links.
Now that I have the software finished up, my plan is to put some sort of demo together showing how it works and looking for ideas.
Rohde Schwarz, Understanding Signal Integrity
https://youtu.be/anX8QZMhVjI?t=677
Anritsu, Signal Integrity testing with the ShockLine MS46524B VNA
https://youtu.be/tbyJdzYECv4?t=159
Keysight, USB Type C Cable Compliance Test with Keysight VNA & Enhanced TDR Application
https://youtu.be/ejRdFSE7HR8?t=123
Keysight, Signal Integrity at 400G and Beyond
https://youtu.be/XwyTtCkUpwA?t=59
-
Demonstration of the Solver32's eye diagram feature with the LiteVNA.
https://www.youtube.com/watch?v=9CwQ5Z7XF0w (https://www.youtube.com/watch?v=9CwQ5Z7XF0w)
-
I decided to add the raw synthesized data to the display. Because the math causes a phase shift, I have added a new button "PhaseTrim" that performs a cross correlation to correct for it. You can also manually change the phase. This has no effect on the measurement but rather is cosmetic allowing easier viewing of the data. Attached showing before and after correcting the phase (cap6&7).
In addition to this I have made a few other changes before the release. I removed the trim fringe feature as there was really was no value added. The software now supports the Tab delimiter when importing Touchstone files. Everything I have used was Space delimited. Both are now supported. It's automatic. Keep in mind, my software is a poor excuse
for a viewer. My only use for this feature has been debugging/validating my software.
I mentioned in the video how I limit the amount of data I process to ease the processing time. I had someone write me once how they were trying to run some very low number of data points to increase their time resolution (ham) and how the software would hang. As the software continues to evolve, I certainly give the users even more rope. Still, I try and prevent some of the more basic conditions that can place a heavy burden on the CPU. Currently I coerce the serial data's period / the step size between 1 and 2000. I further limited the amount of data from 200k (demonstrated during the video) to 100k.
Just an FYI about the 39pF // 10nH tank circuit I ran. In case you were confused about why the software chopped off the settling. I had said the rising edges, third dip was 11ns out and I setup to run it at 50MHz. I set it to 40MHz to show the out of range. This ranging error has nothing to do with why the software could not display it. To measure this amount of time we would have needed to recalibrate the VNA using more data points. This can be seen in Cap 8&9.
As I mentioned, the simulation doesn't consider any parasitics and we don't see the initial spike that we see with the LiteVNA. While we did see this spike with the 30+ year old LeCroy DSO, it's amplitude was much lower. Again, the DSO's pulser has a rise time of roughly 150ps. The slower edge reduces the height of this leading spike. When I synthesize the PRBS in software, it is perfect. So after the convolution, we see a much higher spike.
While I could have synthesized a waveform that was more representative of the DSO's pulser, or any source for that matter, I would rather see only the effects of the circuits I am looking at.
***
Added Solver32 zoomed into initial peak, similar scale as LeCroy DSO (Cap10).
-
YoutTube viewer Chris Scholz provided the following in regards to the eye diagram, signal integrity topic:
Hi Joe, I really enjoyed this video. A few years ago is was very involved in this industry.
May I recommend two more resources in addition to the commercial resources you mentioned in the first part of the video?
First, Packet Micro in San Jose has done quite a bit is interesting work on eye diagrams and associated topics in collaboration with EMStat.
Second AtaiTec, also in San Jose, has done pioneering work in the field of fixture de-embedding,
Keep up the great work, Joe!
https://www.packetmicro.com/ (https://www.packetmicro.com/)
https://ataitec.com/products/adk/ (https://ataitec.com/products/adk/)
-
Anritsu paper with section on gating:
https://dl.cdn-anritsu.com/en-us/test-measurement/files/Application-Notes/Application-Note/11410-00722A.pdf
I added a simple gating feature to Solver. Basically while time domain is selected, you can use the two cursors to define the window. You can use the data within or outside of that window. Attached showing my homemade 70mm air-line Beatty standard. Red is the normal impedance and yellow after placing a window around the 70mm mismatch. It supports both TDR and TDT modes.
-
I was testing using a modern PC and ran into a problem with the Intel Math Kernal Library (MKL) wrapper that is included with the version of LabView I am using. Not a surprise as that version is now over 10 years old. This has been an on going problem as Intel rolls out new hardware. There are a few posts about changing the MKS environment settings but it did not correct the problem.
One work around would be to go with a new version of LabView. Even if National Instruments were to lower the cost (roughly $3000/yr rental fees) to $30/year, I wouldn't go that route. The problem with LabView being and unique bastard child, if anything happens at NI, you are literally fucked. With their new management, I have zero trust in the company and without a perpetual license, I have no plans to consider this as an option.
The second option is not to be concerned. Its only a problem as we start looking at modern processors with several cores. Most commonly posted about is the AMD Ryzen™ Threadripper™ but I ran into it with an i9-10980XE. The software is only used by a small group and there are open sourced programs available. This may be the best option.
The third option is to steal the 32-bit MKL wrappers from a newer revision of LabView. I spent the day testing this and it seems to work fine. This means that most likely I will create a new installer for the next release that has all the correct files. The group who attempts to randomly install 63/32 bit versions of various releases of the runtime and VISA will now have an even more difficult time guessing at how to install it.
-
Gatesetup: Showing poormans Beatty standard with bad connectors and bad layout. We will measure S11 of the resistor attached at the far side.
Gate0: VNA was cale'ed at the cable connector and the Beatty standard inserted with DUT. Yellow trace before adding port extenstion.
Gate1: Converting to time domain, we ca see the roughly 100 ohm followed by the 25 ohm sections and finally our 50 ohm test load. Cursors were used to create a window around the two sections of mismatched line.
Gate2: Setting the windowed area to a perfect line. Red trace showing the raw data, Yellow is after windowing and converting back to frequency domain, Violet is the load measured directly on the cable (without the Beatty standard).
Gate3: Yellow trace is the effect of widening the window to include the hand carved 50 ohm sections of line and connectors.
-
Another example using a low cost 40dB attenuator and our poor man's Beatty standard. This time measuring S21.
gatesetup5_10: Showing the setup with the LiteVNA, attenuator, Beatty standard and a section of semi rigid that is roughly the same length of the Beatty standard.
gate5: LiteVNA was calibrated for 300k - 3GHz. The attenuator was attached using an adapter directly to the test cables (violet). The semi-rigid cable was then added (yellow). Note there is a small difference but I am not taking care to torque anything and am just looking for a ballpark idea of how thing behave. Next the semi-rigid is replaced with the Beatty standard (red).
gate6: With the Beatty standard attached, we change to the time domain mode and display the impulse waveform. The cursors are placed around the reflections and the software then replaces this section with a perfect transmission line.
gate7: We convert from time domain back to the frequency domain and display our corrected data (yellow).
Of course, that Beatty standard would represent a VERY poor test fixture but it should provide some insight how the time gating could be used to correct for these kinds of errors.
-
This example shows using the inverted window where everything outside of it is replaced with a perfect transmission line.
gatesetup10_14: This is our really bad setup showing two Beatty standards on each port with our DUT stuck in the middle. The DUT is one of those really low cost 3dB attenuators.
gate10: LiteVNA was caled and the attenuator was placed between the two ports using an adapter (violet). The two Beatty standards were then added along with a few sections of coax (red).
gate11: Changing to time domain and looking at the reflected step response of the whole mess, we can see the we start out at 50ohms, then step to 100 ohms, then down to 25. This is the first standard off of port 1. We then work our way through the coax to our attenuator and then to the second 25 ohm Beatty standard.
gate12: Changing to the transmission impulse mode, we set the cursors to the area between the two standards where our attenuator is located.
gate13: Converting back to frequency domain, we now see our windowed area (yellow).
-
Calibrating the Lite, and then swapping out the thru standard (violet) for the FR4 standard (red). Attemping to correct it (yellow) we seem to be at the limit. May need to characterize the standards and ditch the ideal model.
-
Checking Dislord's Github account, seems they may have stopped all of their firmware.
Testing this bug, it is easy to reproduce and has been included in the LiteVNA for as early as I have firmware for it. You can produce it with the LiteVNA running stand alone. No PC. It will also replicate on the second unit and I suspect a firmware bug.
To produce it, leave both ports on the Lite open. No need to calibrate it. Display S21 logmag. Sweep from say 1G to 5G by setting the start and stop. You should see some low values. Now set it to CW at say 5G. You should get some same low value. Now set it to CW at 5GHz again. The signal should jump about 6-10dB. You can set the start and stop again to reset it.
It appears that the first time CW is entered, the data is correct. Selecting it again, it's off. It looks like it may have something to do with the IFBW and maybe something to do with if it is sweeping prior to selecting CW. I've just been working around it just by being aware of the problem. If you use my software, you can just select CW twice to see the change.
Attached picture YELLOW showing S21 after selecting CW the first time, and RED after selecting it again. Again, you do NOT need my software or a PC to replicate the problem.
***
Also, I should mention that it doesn't appear to have anything to do with the number of data points selected or the frequency range. It does however appear to shift more the higher in frequency. I have been attempting to use the Lite above 7GHz. At 3GHz, I see maybe 0.4dB shift. At 9GHz, roughly a 10dB shift.
-
Checking Dislord's Github account, seems they may have stopped all of their firmware.
Dmitry* (DiSlord) is from Russia. He seems to have not posted anything here or checked in code to Github for some months. Hoping he is OK.
* his full name and email can be found in the copyright/left messages of his code
-
I sent him a note. Hopefully his absence is temporary. Considering the state of the original NanoVNA's firmware compared with the LiteVNA, I don't see anyone else stepping in and providing that level of stability any time soon.
-
On my device i see small jump near 2dB
In CW mode device work as generator and not switch output for measure (it measure reference one time at set freq and after measure reflect and thru, but not disable output for measure reference).
Look like on second set CW mode on equal frequency in not reset state, and reference data not correct
I try research this problem
-
I hope fix this problem. Now i reset state and remeasure reference on CW mode if set equal frequency again
-
Glad to see you are still with us and doing ok.
I am testing the new firmware now and it does correct the problem I mentioned. As much as I have been using the LiteVNA I would expect to stumble onto a few problems but this is the only one I noticed. I'm very impress with how good both the hardware and firmware has been.
Thank you for your your help and try not to be a stranger.
-
Hey I got a stupid question. I'm trying to connect solver32 to my LiteVNA (FW 1.3.07) and it's not working. So I changed to port number in the "Setup/Diagnostics" tab.
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1688899;image)
When I click on "Link", I got an error
(https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/?action=dlattach;attach=1688905;image)
Is there anything else I should be doing ?
Thanks!
-
...
I'm trying to connect solver32 to my LiteVNA (FW 1.3.07) and it's not working.
...
Obviously the software would have to be setup correctly
You checked control panel, device drivers and are sure you have selected the correct port
You have no other software using this port
You are working with a known good USB cable
You know the PC's port is good
I'm running that last version Dislord uploaded here to fix a small bug. I doubt very much that firmware is the cause.
***
Quick search on Google:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6v9SAC&l=en-US
You don't state what OS or version of VISA you are using and so I assume you used the installer rather than attempted to randomly download tools and are running it on 10.
-
...
I'm trying to connect solver32 to my LiteVNA (FW 1.3.07) and it's not working.
...
Obviously the software would have to be setup correctly
You checked control panel, device drivers and are sure you have selected the correct port
You have no other software using this port
You are working with a known good USB cable
You know the PC's port is good
I'm running that last version Dislord uploaded here to fix a small bug. I doubt very much that firmware is the cause.
***
Quick search on Google:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6v9SAC&l=en-US
You don't state what OS or version of VISA you are using and so I assume you used the installer rather than attempted to randomly download tools and are running it on 10.
Yes the port is good. No other software are running when I try solver32. And other nanovna software are working fine.
Os is windows 10 and got Keysight IO libraries installed for VISA.
-
Look like I have VISA Shared Components 5.8.0 installed
I could try to update Keysight IO libraries. I just realized I have the 2018 version.
-
so I assume you used the installer rather than attempted to randomly download tools and are running it on 10.
You mean for VISA? or your software ?
If you have an installer available please let me know where I can find it. I just saw the binaries on github https://github.com/joeqsmith/Solver32-LiteVNA-V2Plus4/releases/tag/v3.13 (https://github.com/joeqsmith/Solver32-LiteVNA-V2Plus4/releases/tag/v3.13)
-
...
Os is windows 10 and got Keysight IO libraries installed for VISA.
That's fine. I use their IO libraries to interface with my Agilent VNA. Obviously nothing to do with controlling the LiteVNA. What VISA are you using for that?
There are several links in the very first post of this thread. Some cover the basic install. Have you read them?
-
...
Os is windows 10 and got Keysight IO libraries installed for VISA.
That's fine. I use their IO libraries to interface with my Agilent VNA. Obviously nothing to do with controlling the LiteVNA. What VISA are you using for that?
There are several links in the very first post of this thread. Some cover the basic install. Have you read them?
Ok look like I failed to read everything and install the software correctly. My bad, will try again.
-
That's fine. I use their IO libraries to interface with my Agilent VNA. Obviously nothing to do with controlling the LiteVNA. What VISA are you using for that?
IO Libraries include VISA drivers and IVI Fondation drivers. Should be compatible with NI stuff thought.
For my problem with solver32, since I installed the Labview runtime manually, I'm probably missing something.
-
...I'm probably missing something.
Most likely.
There have been a few people who posted that were able to manually get the environment setup successfully. There are several examples of people struggling when using this approach in this thread. My email is filled with them.
...And other nanovna software are working fine. ...
Rather than wasting time on it, I suggest you will be better served staying with the software you have working. My software isn't really a good fit for the amateur radio antenna analyzer group and would require a fair bit of reading and research to use it. Couple that with I no longer invest any time keeping the manual current.
If there is some reason you feel running my software is worth your time, I suggest you start reading and follow the instructions. Getting it running separates the boys from the men. :-DD
-
Actually, there was a member on the LibreVNA groups.io that stated they were going to document the installation procedure and post it on the popular sites. He was asking a lot of questions about my software which was upsetting others so we dropped the conversation and I left the group. You can find it under the subject about converting from time back to frequency. Maybe contact them and work together to create something others could use. He may already have it done. Wouldn't hurt to ask.
Here:
https://groups.io/g/LibreVNA-support/topic/eye_diagram_for_tdr/94118303?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,20,94118303,previd%3D1670800027915905569,nextid%3D1666762167099640731&previd=1670800027915905569&nextid=1666762167099640731
Search for a Kurt Poulsen. Good luck.
-
Ok so my problem is related to Labview requiring the NI VISA driver to be installed in primary and not secondary driver. If I remove the Keysight one everything is working fine.
-
...
IO Libraries include VISA drivers and IVI Fondation drivers. Should be compatible with NI stuff thought.
...
So not as compatible as originally thought. :-DD Now that it runs, let's see what you can plan to do with it.
-
...
IO Libraries include VISA drivers and IVI Fondation drivers. Should be compatible with NI stuff thought.
...
So not as compatible as originally thought. :-DD Now that it runs, let's see what you can plan to do with it.
Or Labview runtime is looking for some non standard functions in Visa32.dll ?
Anyway, look like everything is working well with Keysight as a secondary driver. Even for my other GPIB stuff.
-
...
Or Labview runtime is looking for some non standard functions in Visa32.dll ?
Anyway, look like everything is working well with Keysight as a secondary driver. Even for my other GPIB stuff.
It's their software. Why would you think they need to conform to any standard beyond their own?
Again, now that it runs, let's see what you can do with it. Please, please please, not another ham antenna tuning... :-DD
-
It's their software. Why would you think they need to conform to any standard beyond their own?
From Wikipedia:
Instrument drivers are specified by the IVI Foundation[1] and define an I/O abstraction layer using the virtual instrument software architecture (VISA). The VISA hardware abstraction layer provides an interface-independent communication channel to T&M instruments.
The goal of VISA is to provide a common abstraction and be provider agnostic. It's a shame it's not working :-\
Again, now that it runs, let's see what you can do with it. Please, please please, not another ham antenna tuning... :-DD
I have nothing planned short term but will definitely try it out next time I need the LiteVNA. And BTW I'm not so much interested in antenna tuning and such.
-
The goal of VISA is to provide a common abstraction and be provider agnostic. It's a shame it's not working :-\
Of course having a goal is not the same as a requirement. There is a reason I provided an installer to get the known working tools installed. You are certainly free to waste time as you see fit trying to mix and match vendor's code. Or even NIs own code for that matter. Just don't expect me to jump in and offer a lot of help.
I have nothing planned short term but will definitely try it out next time I need the LiteVNA. And BTW I'm not so much interested in antenna tuning and such.
Looking forward to it. Beware, that software is not polished production code. At best its an engineering tool for my own use. Hams just whined non-stop and after a year I released it. There are going to be unfinished features, missing features, bugs in features..... In most cases, I won't care about them. You may but don't expect me to address them.
-
Be aware too that LabView 2011 is more than a decade old and problems with the tools may have been addressed long ago!! I'm surprised it runs at all on a modern OS and NI certainly doesn't support it on Windows 10.
I did post how I ran into some problems with the newer CPUs. At this time I have no plans to do anymore with NI. Once their software no longer runs, it's done.
-
The goal of VISA is to provide a common abstraction and be provider agnostic. It's a shame it's not working :-\
Of course having a goal is not the same as a requirement. There is a reason I provided an installer to get the known working tools installed. You are certainly free to waste time as you see fit trying to mix and match vendor's code. Or even NIs own code for that matter. Just don't expect me to jump in and offer a lot of help.
I mean, the shame is on NI and/or Keysight for not being able to implement the standard correctly. Nothing you and I can do about it.
You are already helping a lot and I thank you for that.
-
Looking forward to seeing what you can do with it.
-
Changes beyond what has been released include:
3.14
Add grid / mesh select for post processing 3D
Change labels on 3D graph
Turn on light source 1
When using lower sideband, reverse Touchstone order
Correct average function
3.15
Allow loading 2D antenna plots and saving to memory
Allow indexing through the elevation in 2D plots
-
Planning to do some comparisons of printed antennas and needed a way to plot the date. I could save the data and load it back into a 3D graph but not overlay 2D graphs.
For example, this is a homemade waveguide horn being rotated 360 degrees. Yellow is looking at the top of the horn, red at the bottom. Blue is how we would normally use the antenna. You can slice the data set at any elevation and save it, or overlay more than one antenna. I'll demo some of the changes in the next video.
-
Dislord,
I attempted to load your recent post with V1.3.12.bin just to see what the performance is above the current 9.3GHz limit. If I turn it on with no connection to the PC, it starts to sweep as normal. Attempting to connect with the PC, it will not form a link. Did something else change in the protocol?
-
With much thanks to Dislord, I now have a working version of firmware. I don't think any of us are expecting anything from the LiteVNA at these higher frequencies and I think we all agree that limiting it was a good choice. However, I was a bit surprised and it performs better than I was expecting.
8G_12G_Leakage_SO_10dB:
Showing a thru (yellow) and open (violet) after calibration. I want to be clear, this is still the ideal model using the same standards provided with the V2Plus4 with the sorted load. Also, this is my unmodified LiteVNA right from the factory but with my cables. My software accounts for the leakage term and it is being used for these tests. A 10dB attenuator was then measured. We can see is starts to go off the tracks a bit over 9GHz but settles back down around 10.5GHz.
8G_12G_Leakage_SO_20dB:
Same as above but with a 20dB attenuator.
I have been experimenting with some waveguides using the LiteVNA. Most of this testing has been above 7GHz. To work around the limitations of the LiteVNA, I use it below 4GHz and then up convert to 8GHz then back down. This setup allows me to take advantage of the Lite's higher performance range. test14_MWM_0_50dB_11GHz shows the Lite with the Extender sweeping from 11.0 to 11.9GHz and inserting a series of attenuators from 0 down to 50dB.
8G_12G_Leakage_10GHzBP_WR90:
Showing the Lite directly measuring a 10GHz waveguide BP filter I put together. The last plot was measuring this same filter with the LiteVNA plus the frequency extender. I don't have the equipment needed to test this filter. The PNA is limited to 9GHz or I would use it for a comparison.
I'm impressed, we can actually see something! Pretty cool for something that cost $120 and fits in my shirt pocket.
-
Do these normally come with the connectors and accessories? Or do u buy them separate ? I'm guess they aren't cheap either.
-
Do these normally come with the connectors and accessories? Or do u buy them separate ? I'm guess they aren't cheap either.
The low cost VNAs I have all came with some sort of short, open, load, thru and two coaxial cables. Some came with a touch pointer and some came with a USB cable. The original NanoVNA I have came without a housing. The other have been enclosed with metal or plastic.
Any other accessories or connectors, you would need to purchase. Also, if you felt you required better standards and cables you would need to buy them as well. There are many photos of what is included. Do your homework. Here is some for the LiteVNA:
https://store2.rlham.com/shop/catalog/product_info.php?manufacturers_id=142&products_id=75669&osCsid=4dbrs4qrfmmbte7pdr5v7ecrc7
-
NanoVNA_V2Plus seems not to receive data after calibration or loaded cal file.
Hardware: S-A-A-2 NanoVNA V2, https://www.aliexpress.com/item/1005004678403859.html?spm=a2g0o.productlist.main.41.c45ftbBFtbBFlt&algo_pvid=dfd37afd-4cfe-4397-a090-15a75920e76f&algo_exp_id=dfd37afd-4cfe-4397-a090-15a75920e76f-20&pdp_ext_f=%7B%22sku_id%22%3A%2212000030071383955%22%7D&pdp_npi=3%40dis%21HUF%2148889.82%2122000.6%21%21%21%21%21%402102110316770478898204310d06f9%2112000030071383955%21sea%21HU%21109621073&curPageLogUid=2MetHD8BlRsg (https://www.aliexpress.com/item/1005004678403859.html?spm=a2g0o.productlist.main.41.c45ftbBFtbBFlt&algo_pvid=dfd37afd-4cfe-4397-a090-15a75920e76f&algo_exp_id=dfd37afd-4cfe-4397-a090-15a75920e76f-20&pdp_ext_f=%7B%22sku_id%22%3A%2212000030071383955%22%7D&pdp_npi=3%40dis%21HUF%2148889.82%2122000.6%21%21%21%21%21%402102110316770478898204310d06f9%2112000030071383955%21sea%21HU%21109621073&curPageLogUid=2MetHD8BlRsg)
SW v0.1.0
Without calibration it works well. I attach the data and the SWR screens.
Loaded the cal file. The data and empty SWR screens are attached.
SW v2.0.8
No input data at all with or without calibration. Screen attached.
One more sugession. I am in Hungary where the decimal point/comma problem exists. So I added the proposed line in the .ini file but didn't modified the local to comma. The screenshots were captured in this status. I tried to modify the local to comma just now (having the extra line in the .ini file), but the result is the same.
Thank you.
-
George,
There are a few things to consider. First, you're using a VNA that I have never tested. It may not be compatible with my software. Your last photo, swr_without_cal_v010.png, at least tells us that it uses something like the newer protocol. This is a good thing.
NanoVNA_V2Plus seems not to receive data after calibration or loaded cal file
In photo data_with_cal_v010.png , you can see you have not selected sweep, but when you did, you get a bunch of NaN. NaN means not a number, which is normally caused by a divide by zero. Normally what happens is the user reads a post from some expert about changing the coefficients to improve their measurement accuracy. While I can't dispute that but the user will make these changes blindly with no understanding. They enter the expert values and instant NaN. You never show a screen shot of the calibration terms. Again, the more data you provide, the better. While I am not in the habit of dumbing down my software, the latest version attempts to help this group out by avoiding divide by zero conditions.
SW v2.0.8
No input data at all with or without calibration. Screen attached.
I'm not surprised by this. If you look at photo loading_cal_v010.png, you only have one defaults file. The defaults file is unique for each major version of software. If you want to run multiple versions of my software like you are attempting to do, you would need to create a default file for each of them.
I am in Hungary where the decimal point/comma problem exists. So I added the proposed line in the .ini file but didn't modified the local to comma.
For some reason, you are trying to run software that is very old. I had posted how I had added country detection and the decimal/comma problem you mention is not now automatically handled. Of course, as I already stated, the new software would require new defaults and also new calibration files. If you do decide to try it, don't forget to download the sound.dll. You would be amazed of how many people think they can just grab any version of this file and have it work.
Last, if you are a ham and your goal is to measure VSWR of your antennas, I highly recommend using one of the open sourced programs. My software was not written for the ham and/or CBers antenna analyzer group. The software is not limited to try and save the user from doing stupid things. I had a person write me who was trying to sweep from m Hz. They had no clue that m and M have two different meanings and the software is going to do exactly what you ask... I had one person write how they were using my software to try and set the VNA's frequency range outside of what the VNA would allow, thinking this helped them evaluate the VNA's performance. Just dumb, but again, the software will certainly not prevent the user from doing such things. My software is not supported. I no longer make updates for VNAs that use the older protocol. The only low cost VNA I am currently testing with is the LiteVNA64.
I'll leave your case on git open but I very much doubt that you have ran into an actual bug that hasn't already been addressed.
***
fix SNAFU
-
Thank you for your detailed answer and proposal.
1. I used this ancient v.0.1.0 sw. version because on github this release was offered. I used it as it was. I didn't modify anything, no coefficients or other settings (except dot/comma in default.set). I suggest that the data format and protocol should work, as without cal the sw. works.
2. The default.set file is the v.0.1.0 version, as all my problems aroused originally there. Having the problem, I tried to find a new version and found the new v0.2.8 exe in your zip file and believed that it is enough to replace it. I didn't realize that for other versions I should replace the default.set, too. I will search for all the components (default.set and sound.dll as you mentioned). If I got a complete package, I would install it from scratch. Perhaps a remark on the github page can orient other people, also.
3. I am only a curious software engineer extending my home automation system and trying to solve the 433 MHz communication problems of sensors with terrible antennas. Your YouTube videos with full of details and knowledge impressed me so, that I thought that using this necessity I would learn a bit about the interesting RF world that is a terra incognita for me. Your sw. has much more potential compared to vna_qt I had tried.
4. Sorry, if I caused some annoyance, I understand that it is a challenge to solve the (repetitive) problems of noobs, like me.
Cheers.
George
P.S.
1. Trying your proposal, v2.0.8 is used, sound.dll is not searched and found.
2. I generated new default.set, the ini file contains: useLocaleDecimalPt=False.
3. The sw. works, reads the NanoVNA.
4. Generating new calibration.
5. The sw. reads something but the data read is incorrect. For example in CH0_Z both the real and imaginery part is wrong.
6. The process is repeated but before it I modified the local to dot and cleared the line from the ini file. New default.set generated.
7. The result is the same. Screenshots are attached.
-
1. I used this ancient v.0.1.0 sw. version because on github this release was offered. I used it as it was. I didn't modify anything, no coefficients or other settings (except dot/comma in default.set). I suggest that the data format and protocol should work, as without cal the sw. works.
When I posted "You never show a screen shot of the calibration terms. " I thought you would take the hint. Without providing details of what you're seeing, I have no way of helping you. Something is certainly causing a divide by zero. I can tell you it's nothing I have ever ran into.
Without my having the same hardware with the same firmware installed, I have no idea if your VNA would actually work or not. I tell people what hardware and firmware I test with. If you choose to deviate from that, you're setting yourself up for failure.
2. The default.set file is the v.0.1.0 version, as all my problems aroused originally there. Having the problem, I tried to find a new version and found the new v0.2.8 exe in your zip file and believed that it is enough to replace it. I didn't realize that for other versions I should replace the default.set, too. I will search for all the components (default.set and sound.dll as you mentioned). If I got a complete package, I would install it from scratch. Perhaps a remark on the github page can orient other people, also.
You had posted about reading the manual so you already know, it's up to you to create the defaults file based on your setup. This isn't something I would supply you and if I did, it's most likely not going to be correct.
The current released software is 3.13. If you followed the link in my signature, you would see where the new releases are for the LiteVNA and V2Plus4. If your VNA is compatible with that protocol, this is the software you should be using. It will require new defaults and calibrations and of course, that troublesome Sound file. Moving forward with these low cost VNAs, this is the only version of the software I plan to support as it's the only one a still actively use.
3. I am only a curious software engineer extending my home automation system and trying to solve the 433 MHz communication problems of sensors with terrible antennas. Your YouTube videos with full of details and knowledge impressed me so, that I thought that using this necessity I would learn a bit about the interesting RF world that is a terra incognita for me. Your sw. has much more potential compared to vna_qt I had tried.
I suspect it will be a steep learning curve for you which is why I suggest using one of the more generic open sourced programs. You could waste a lot of time and not reach what ever your goals are. Because I received so many basic questions covered in the manual, I stopped wasting time updating it. For people like yourself who are actually trying to make us of the documentation, this doesn't help matters. You would need to watch the videos where I cover the changes or like many, trial and error your way along. Things seldom work out for the random button pushers.
4. Sorry, if I caused some annoyance, I understand that it is a challenge to solve the (repetitive) problems of noobs, like me.
As long as you understand that there isn't an Act in the USA called "No VNA User Left Behind". If you read this long thread you will find people who feel that just because there are several other who post about their woes, I should lower my expectations and change what I provide to help them. I've been clear my software isn't a good choice for the beginner. Think of it as being a few decades of experiments (not antenna tuning) that I have conducted at home and compiled into one program. Just because a user can afford a sub $200 VNA isn't going to make them any more knowledgeable on how to use it and my goal isn't to educate those unwilling to do their own research.
Of course, the flip side to that is I have made some pretty major changes to the software for the few people that have taken the time to learn how to use it and putting it to use.
***
poor grammar
-
The messages crossed each other.
From your answer I realized that you may talk about the Solver while I used NanoVNA 2Plus.
Thank you for your software development work even more for the fantastic videos.
This is my last message. I appreciate the huge work to maintain not only the software but the user base, also. On the other hand, it seems to me that your relation to not-expert persons is not really helpful. When a simple problem would be solvable with a simple answer with a definite direction (which software?) you try always push down with remarks of definition not read or the 89-pages blog post is not followed. In this regard I am not the exception, but the rule.
Regards.
George
-
From your answer I realized that you may talk about the Solver while I used NanoVNA 2Plus.
People asked that I name the software. I did. It is now called Solver. I left the VNAs it supports in the title to make it clear. NanoVNA 2Plus is just the older versions.
Thank you for your software development work even more for the fantastic videos.
This is my last message. I appreciate the huge work to maintain not only the software but the user base, also. On the other hand, it seems to me that your relation to not-expert persons is not really helpful. When a simple problem would be solvable with a simple answer with a definite direction (which software?) you try always push down with remarks of definition not read or the 89-pages blog post is not followed. In this regard I am not the exception, but the rule.
I asked for further data, but you failed to post any. I suggested you upgrade to the latest version so we could at least have the same software setup but you have not yet done that. I'm not sure what outcome you would expect if you have no interest in following my advice.
If what you are seeing is indeed a simple problem, ask yourself why can't YOU solve it? It's naive to think that all problems are simple and can be solved by my giving you some magic simple answer. This isn't something I would expect of any engineer. Then again, Dave says to become an engineer just call yourself one. :-DD
I agree that people who have problems are indeed the ones who will post about the problems they are having. Isn't that obvious. :-DD You won't find people who are having success doing this. So yes, you certainly fall under that rule.
Anyway, sounds like you have at least taken my advice and are moving on. There are many open source programs to choose from and while I do not use them, many others have and they should be able to provide you will all the help you need. Good luck.
-
I messed up...
Compiled the latest master branch of DIslords "F303" firmware and download into a LiteVNA64-0.3.
Device has stopped working, DFU boot is still working..
Tried to reflash LiteVNA64-220225.bin and LiteVNA64-220830.bin but to no avail..
See https://github.com/DiSlord/NanoVNA-D/issues/57 for details..
Any chance restoring the old firmware using dfu-util?
UPDATE: This has been fixed, see resolution on github, Thank you Dislord!
-
I just fixed the same link light error Kosmic posted about on January 13th. When you are integrating the Solver into an existing Labview-VISA setup that may have been running GPIB ports, you need to use NI-MAX to enable what is called a "Passport" to get USB, Serial, or other connectivity. Enable the NiViUsb.dll NI-VISA Passport for USB. From the Measurement & Automation Explorer. Use the NIMAX menu item – My System, Software, Visa, NI-VISA xx to show the VISA Options at the bottom of the window.
I have both the NI and Keysight VISA installed and both Solver32 and 64 work fine (with appropriate runtimes). This window also has a Conflict Manager which allows the selection of either or both VISA's. This allowed selecting the correct Passports as shown:
-
Tek, LeCroy, Agilent passports all basically work as you describe. At home, I use Agilent and LeCroy to control some of my equipment.
-
Hello,
I have seen some of your video, read a little bit of the documentation and I have noticed that you have many book on VNA but you don’t find useful information. This a video of one year ago and I have not read the 89 pages of this forum. Anyway, about 30 years ago, I have took a course with a German professor: Burkhard Schiek. He was a specialist of this kind of topics. I’d like the way he teach because he used matrix instead of “fluence” graph. I was hoping to find the thesis of his student Eul because most of the publications are on IEEE without free access. I didn’t find it yet but I have found another document that could be useful for you (If you have not yet find the informations you were looking one year ago):
https://www.rfmentor.com/sites/default/files/NA_Error_Models_and_Cal_Methods.pdf (https://www.rfmentor.com/sites/default/files/NA_Error_Models_and_Cal_Methods.pdf)
Hope that could help you. (I am not a native English speaker so I hope you understand :) )
-
Somebody use the tool of the cpu manufacturer to restore his full bricks litevna:
https://groups.io/g/nanovna-beta-test/topic/93892513#4263
The topic is “How restore LiteVNA after full brick”
Apparently it was successful so I suggest to ask there
-
Hi Joe,
Just viewed your videos and I purchased a LiteVNA 64, I try o get the 2011 Labview and setup it looks fine, but when I ran your 32 software it always cannot be hooked up to my desktop.
See the attached and please give me some advice.
-
It appears that the software is trying to communicate with the M-Drive stepper motors. I have used these to automate various tests including using one to drive a linear slide with a bit of air line attached to it, as well as investigating the radiation patterns of various antennas.
You make no mention if you have attempted to replicate my rotor system or what you are trying to use these motors for. Of course, if you don't have these motors and tell the software you do, you can run into problems. So, maybe start with explaining how you have the motors wired, if at all.
If you don't have any M-Drives attached, don't enable them when you create your defaults file. Don't expect old defaults files to work with different revisions of the software.
If you still can't figure it out, provide a screen shot of the setup/diagnostics menu.
-
Guessing our new friend sorted out their problem. For others not understanding how to select the M-Drives or how to save your defaults, see attached.
-
In LiteVNA used AT32F403
https://www.arterychip.com/en/product/AT32F403.jsp (https://www.arterychip.com/en/product/AT32F403.jsp)
Allow use DFU mode, but need ATlink software
https://www.arterychip.com/download/AT_Link_EN_20210427.zip (https://www.arterychip.com/download/AT_Link_EN_20210427.zip)
For enter in DFU mode need connect bootpins on board and power on.
You can`t detect hardware version in bootloader mode (all devices answer as i write)
I can add command for enter in booloaded mode in next version firmware, example write in registers[0xef] = 0x5e, but only on next firmware version.
Do you have already make step by step instruction how to install your latest firmware fir lateVNA 64 4"?
https://nanovna.com/?page_id=103 (https://nanovna.com/?page_id=103)
-
Was going to use the original NanoVNA and noticed a screw fell out of the packing bag when I took it out. Then noticed the battery had expanded.
-
Just a few updates. I am thinking about changing to a different file hosting platform and have closed my Github account. Github was never designed to host files the way I have been using it.
In the future, I have no plans to support the original NanoVNA (old protocol). This includes VNAs like the -H and H4.
Because the V2Plus / 4 locked out any firmware development, these VNAs have really fallen behind compared with the LiteVNA. OWO did release new hardware. I have not seen it but the cost for the VNA6000 with 95dB dynamic range is over $800 with tax. You can go with the B model which is 110dB for $1,499.00.
https://www.tindie.com/products/hcxqsgroup/nanorfe-vna6000/?utm_source=sel (https://www.tindie.com/products/hcxqsgroup/nanorfe-vna6000/?utm_source=sel)
It's still a two port one-path with square wave drive and limited low frequency support. My guess is they still modulate the output as well which makes it useless for narrow band work. At this price point, the full 2-port LibreVNA would make a lot more sense. Personally, I would rather stay with with the LiteVNA. Much lower cost, smaller, and having Dislord developing the firmware makes it an A+++ rating. My plan is to only support the LiteVNA moving forward. Of course, my software may work with other VNAs that use the LiteVNA's protocol.
Because of the vast amount of feedback, I will no longer offer an installer. This seemed to work out fine for Solver64 where users were savvy enough to sort it out on their own.
I still have no plans to update or maintain a manual for my software. It's a lot of effort for something that provides little benefit. Much the same reason for not offering an installer.
Any new software releases will be 64-bit only. It's been over a year since leaning the hard way that NI (formally National Instruments) had changed to a rental model. Since then, Emerson acquired NI. After a year had lapsed, I was contacted by NI three times asking me to pay my rental fees. The last call, they threatened to lock me out of my software. I explained that I had removed all of their software after discovering it was a rental and NI had refunded my payment, but they could certainly attempt to extort me by shutting down my perpetual licenses. We would go to court over that one. I can only guess that they had left some accounts like mine on the books to overstate the value in hopes of increasing the amount of the buyout? Hard to say. Fuck them and their strong arm tactics.
***
I have been looking at a few generic file host programs and am planning on setting up a Dropbox.
-
The following lists the changes from 3.0 to the proposed 64-bit release. Moving forward any software I release will require a different runtime than the others. The basic version of Dropbox allows up to 2G storage which is more than enough to store the runtimes and VISA. It also allows large file sizes, so there is no more spanned ZIPs. I plan to archive the last version that supported the original NanoVNA, H, H4 in a separate directory.
4.00, 08/17/2023
Public Release
3.18, 8/17/2023
Add Rnorm (normalized impedance) to the defaults file
Add VNA PGM Image to the defaults file
Change gating select button for notch (remove inside the gate) vs bandpass (removes response outside the gate).
Change the gate blanking from a hard 0 to avoid discontinuities when running the FFT. (windowing, Kaiser window with shape minium (rectangualr), normal and maximum
Trigger gating after importing a Touchstone file
3.17, 8/02/2023
Remove reorder when lower sideband selected when creating touchstone files. Order is in ascending order. This
was a bug.
3.16, 4/3/2023
Add relative when using both the external coupler and frequency extender
When using the external coupler and/or extender, use the targeted freqs for the front
panel settings. Saves user from having to calc the target.
Allow memory to autoscale XY return loss graphs
Add the connector type and cutoff frequency to the calibration standards rather than manual entery.
Maximum frequency was also added but is not used at this time.
3.15
Allow loading 2D antenna plots and saving to memory
Allow indexing through the elevation in 2D plots
Add ability to use an external directional coupler by using Port2
data in place of Port1
Add FreqExtender, Sideband and Coupler to the default settings file
Add support for sliding load
3.14
Add grid / mesh select for post processing 3D
Change labels on 3D graph
Turn on light source 1
When using lower sideband, reverse Touchstone order
3.13
Add Gain and Phase to all three plots
*** Major Bug with Lite when using CW? Fault without PC software. Appears firmware
When using CW add interpolate for S21 and S12.
3.12
Remove inverter for drawing mesh
Change to switch when pressed
Change default to active
Change all axis to 3 place, SI
Add draw grid selection
Change instructuctions for antenna sweep
Change state 13 Antenna sweep to 22 (don't reset elevation in 2D)
Change state 4 to set elevation to 0 deg if in 2D
Change state 22 to calculate for both 3D and 2D
3.11
Add time domain gating
3.10
Remove the eye trim fringe
Add min/max fast mask limit test
3.09
Add Tab delimiter to the Touchstone file import function
Parallel the accumulator used for average
Limit the eye synthesized test signal's frequecy and data points
3.08
Add Eye Diagrams
When inporting Touchstone, set start and stop freq
Add time domain to plot sensitivity list
Add advanced plot trigger to eye mask and clear
3.07
Add TDR memory
3.02
Add frequency trim
3.01
Add ability to save the main graphs line widths and colors to the defaults file
-
Hi Joe.
First - thank you for making your software available and for spending time and sharing all the Videoas and documentation, really appriciated.
Secondly - did you got the Dropbox folder set up? I have seen a bunch of your Videos over the last few months and I am ready to start using your software with my newly purshased LiteVNA.
//Harry
-
Hi Joe.
First - thank you for making your software available and for spending time and sharing all the Videoas and documentation, really appriciated.
Secondly - did you got the Dropbox folder set up? I have seen a bunch of your Videos over the last few months and I am ready to start using your software with my newly purshased LiteVNA.
//Harry
I have some tests I want to run with it first and am planning a quick demo video.
My advice, with you being a beginner and ham, I would just start with the open sourced programs. I suspect these will do what you want and should have much better support. Consider joining the groups.io litevna mail list. There are plenty of hams there that you can ask questions.
-
I just acquired a NanoVNAPlus5, that's the pro version of the plus4 that supposedly is able to measure crystals. I noticed that your github repository was down and was wondering if and when you might put up on dropbox the software that will run on my machine.
I have the base version of your software 0.10 up and running and was wondering how to update that.
I have done a good bit of simulation for a set of calibration standards I am making, and have touchstone files and delay figures to load into your software, although I having trouble finding the touchstone import command.
Bravo on producing your software.
Regards,
fred b
-
I thought the V2Plus4 Pro was just a firmware change for an added $100 and still not as capable as the LiteVNA? Did you dig into the details before you bought it? Review? I think you're the first person who posted of having one.
If you read this thread you will find Dislord had added some heavy filtering in the firmware for the LiteVNA to allow it to made narrow band measurements. Due to the hardware, it is not even close to the performance I get with the original NanoVNA.
So you made it through the spanned zip file to get the 0.10 installed but didn't download the others? Had you installed Solver64 that was up on Github, it may have at least given us some idea if it would work with your Pro VNA. I have not used the V2Plus4 since I changed to the LiteVNA and I make use of features Dislord has added to the firmware. With OWO's VNAs being locked, I don't think that Dislord can support them. In other words, Solver64 may not work with your VNA.
0.10 may not support importing Touchstone files, or if it did, it may have several problems. Looks like I released that to the public on 8/25/2019 and it was old then. It's been 4 years.
-
Dropbox is now live
https://www.youtube.com/watch?v=xDZpQS3Ou6s (https://www.youtube.com/watch?v=xDZpQS3Ou6s)
-
They stated that this version had additional circuitry beyond that of the plus4 to facilitate measuring crystals. There seems to be an absence of any documentation for the plus5 version, everything I found is for the plus 4.
I bought the VNA a while ago and am now just getting around to using it. I found your videos and blog history just recently. It seems I've been working behind the curve on this. Your Dropbox is currently being overwhelmed by pull requests, so I'll have to wait until they unlock it again to get a copy of solver 64. In any case, I'm glad you have the software up. I'll get it and see.
Cheers,
fred_b
-
They stated that this version had additional circuitry beyond that of the plus4 to facilitate measuring crystals. There seems to be an absence of any documentation for the plus5 version, everything I found is for the plus 4.
I bought the VNA a while ago and am now just getting around to using it. I found your videos and blog history just recently. It seems I've been working behind the curve on this. Your Dropbox is currently being overwhelmed by pull requests, so I'll have to wait until they unlock it again to get a copy of solver 64. In any case, I'm glad you have the software up. I'll get it and see.
Cheers,
fred_b
I see where they make this claim for the VNA6000 but not the V2Plus4 Pro. Please provide a link to where this was stated. Thanks.
Dropbox sent me a notice that it was shutdown due to high traffic. Of course Github wasn't limited but many people could not figure out how to use it, even with detailed instructions.
-
On the official website https://nanorfe.com/nanovna-v2.html (https://nanorfe.com/nanovna-v2.html) it is stated almost at the end of the page that:
NanoVNA V2 Plus4 Pro now allows measuring crystals by an adjustable bandwidth setting. All other hardware versions can not measure crystals because of the rapid switching of the test signal.
In the official forum (https://nanorfe.com/forum/Nanovna-V2-plus5.html) Owo stated:
New in V2 Plus5 (renamed to V2 Plus4 Pro):
- Adjustable bandwidth; possibility of measuring very narrowband devices.
- Maximum sweep speed increased to 600 points/s; speed increases below 140MHz.
- Slightly improved noise compared to V2 Plus4.
V2 Plus4 already has the lowest noise out of all NanoVNAs, so V2 Plus4 Pro is only a small improvement there
Edit:
On the Tindie Store (https://www.tindie.com/products/hcxqsgroup/nanovna-v2-plus4/#specs), in specification it is stated:
IF bandwidth: adjustable from 0.8kHz to 10kHz (V2 Plus4 Pro)
-
On the official website https://nanorfe.com/nanovna-v2.html (https://nanorfe.com/nanovna-v2.html) it is stated almost at the end of the page that:
NanoVNA V2 Plus4 Pro now allows measuring crystals by an adjustable bandwidth setting. All other hardware versions can not measure crystals because of the rapid switching of the test signal.
In the official forum (https://nanorfe.com/forum/Nanovna-V2-plus5.html) Owo stated:
New in V2 Plus5 (renamed to V2 Plus4 Pro):
- Adjustable bandwidth; possibility of measuring very narrowband devices.
- Maximum sweep speed increased to 600 points/s; speed increases below 140MHz.
- Slightly improved noise compared to V2 Plus4.
V2 Plus4 already has the lowest noise out of all NanoVNAs, so V2 Plus4 Pro is only a small improvement there
And where does that suggest is has "additional circuitry beyond that of the plus4"? Do you feel that filtering can only be accomplished with hardware?
-
It says "All other hardware versions" implying a hardware change in "V2 Plus4 Pro" to allow the switcheable IF bandwidth (see edit above as well).
Maybe a similar effect could be implemented in software as well, but I feel that I don't know enough to have relevant "feel" there.
-
It says "All other hardware versions" implying a hardware change in "V2 Plus4 Pro" to allow the switcheable IF bandwidth (see edit above as well).
Maybe a similar effect could be implemented in software as well, but I feel that I don't know enough to have relevant "feel" there.
With firmware development locked out they roll new locked firmware that adds the feature, call it a Pro, charge $100, roll the revision and good to go. I doubt there is any difference in the hardware. While I don't have a problem with them locking out firmware developers to maintain their profits, the reason I no longer use the V2Plus4 is it is so far behind what Dislord produced.
There is a fair bit on this thread about the narrow band measurements. Dislord provided details how the implemented the filter and I added support for it. I also demonstrated various narrow band filters with the new changes. While it was a big improvement, it was not nearly as good at the original NanoVNA.
****
If you are interested in learning more about it, the conversation was somewhere around here:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4013380/#msg4013380 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4013380/#msg4013380)
-
Well gee, I thought I had read that on the nanorfe web page. The only other place I think I could have read that would be on the tindie sales page. Perhaps, I got that confused with the nanoVNA 6000.
When I was shopping for a VNA, I remember how confusing the whole subject was about tracking down which was the original, which were the clones, which were original variants of the original, and which were clones of those.
Then I set myself to the task of attempting to figure out which one provided the best performance per buck, while also satisfying the frequency requirements for my future projects. I looked at the LiteVNA, and remember seeing that it was harmonics based for the upper frequencies and that the nano VNA plus4 series used fundamental frequencies. That turned out to be the closing point for me.
I then decide to pay the extra nickel for the pro version because I eventually want to create some crystal filters, and thought somehow that the other VNA versions lacked the capability to do that. Perhaps, being a new uneducated initiate of nanoVNAs, I placed too much emphasis on the marketing copy there. :)
GitHub is really for application development teams and individuals who compile applications from source code. For people who just want to grab a pre-compiled binary and go it is a good bit of a hassle. Have you had a look at Sourceforge?
-
I looked at the LiteVNA, and remember seeing that it was harmonics based for the upper frequencies and that the nano VNA plus4 series used fundamental frequencies. That turned out to be the closing point for me.
I'm at a loss on your closing point. So the V2Plus4 is limited to 4GHzish without harmonics. It also has no support to use harmonics beyond that limit. The LiteVNA is limited to 6GHz without harmonics and has support to use them up around 8GHzish. Note in my previous graph, you can see the LiteVNA using harmonics to 10GHz (not very useful) and the sharp increase at 6GHz where it changes to use them. Note the low frequency range where the V2Plus4 is very poor. There is only a small range where my V2Plus4 will outperform my LiteVNA.
If you followed my waveguide experiments, you know while I did show the LiteVNA directly making measurements in the X-band using harmonics, to improve the performance I had put together a frequency extender that works to a bit over 12GHz.
I then decide to pay the extra nickel for the pro version because I eventually want to create some crystal filters, and thought somehow that the other VNA versions lacked the capability to do that. Perhaps, being a new uneducated initiate of nanoVNAs, I placed too much emphasis on the marketing copy there. :)
I've posted many times how the original NanoVNA outperforms all my others when measuring crystal filters. There's a reason I tell people if you work below 300MHz, that is the best choice. Above 300MHz, the LiteVNA. Under $200 total.
GitHub is really for application development teams and individuals who compile applications from source code. For people who just want to grab a pre-compiled binary and go it is a good bit of a hassle. Have you had a look at Sourceforge?
No. Only Github. Easy for me and I suspect for most of the youth who grew up with PCs. Nearly impossible for the old hams, even with explicit instructions. They need something that works like their PC file manager. Google Drive, Microsoft One Drive, Dropbox. Of course we do have a few special people that try and use their cell phones.
**********
Do us a favor. Calibrate your V2Plus2 Pro using say 800 or more data points over the entire specified frequency range. Attach the load to port1 and terminate ports2. Measure S11 and save it to a Touchstone file. Without changing any of the setup, measure S21 and save it to a Touchstone file. Use what ever software they are suggesting to make these measurements (or run it stand alone). Document the firmware you are using and how you have the VNA powered. If you don't mind, maybe run it powered off your PC as well as with a battery. It can make a big difference. Post the Touchstone files here and I will add them to my graph comparing the VNAs.
-
I didn't remember my V2Plus4 being that poor of performance at the lower end so I charged up a battery for it and repeated the test. Results are now much better. For fun I ran it with and without the leakage term to show the effects at the higher frequencies.
Basically, it's right on-top of my LiteVNA. Much more believable. The V2Plus4 is now $300. The last LiteVNA cost around $130. The LiteVNA is good to 6GHz without harmonics and maybe 8 with. The V2plus4 is limited to 4. The LiteVNA also has the SD card interface. I've tried it. It's also small enough to fit in a shirt pocket for the hams climbing around on their towers...
-
OWO's site talks about the clones averaging to hit the numbers. In the previous plot, I had used 10 averages with the LiteVNA. So for a better comparison, I disabled the averages and used the same set of cables that I used with the V2Plus4.
Basically, it looks like a wash. Maybe the LiteVNA is a bit better.
-
Here's a couple of touchstone files. There were made with the battery in the device and the USB cable connected to the PC. The battery was surprisingly difficult to push into the holder when I installed it. When I opened the case up to pull it out, I can see that the holder is bowed out a little bit by the pressure of the springs. I'd need to pry the battery out by sticking something underneath it and prying it up to get it out. I think, I just want to leave it in, until I get some mileage out of it.
I'm still quite unfamiliar with this device, so I hope I got the files done properly. BTW I'm using VNA_Qt. It looks from the display on my PC that my device is doing about 10db worse between 3.5 GHz and 4.0 GHz. That's interesting.
Firmware version: 20220301
-
Fred,
I used a flat-top battery in mine which seems to fit. Leaving the battery in with the USB connection is how I collected that last data, so perfect.
Looking at your S21 data, notice the header states S11 rather than S21.
# MHz S MA R 50
! freq S11
0.050000 0.00132 -161.92
If I plot your s21 data, the first thing I notice is the magnitude is VERY high. The next thing is the phase is stable. Think about it, the two ports are not connected to one another and both are terminated. Wouldn't you expect it to be random?
I suspect this is actually is S11 and not S21. I've attached my S21 data for my V2Plus4. I expect your Pro to be similar.
-
I was going to say the S21 data is wrong. I'm still learning out how to use the thing. I have a different capture file with both the s11 s21 in it. I have to wait till I'm back in my lab to upload it to. That will be late tonight.
When I was looking at the graph on the screen, I noticed that everything looked about the same as what's in your graph except at the very end between 3.5 GHz and 4 GHz where my device seemed to jump up about 10 dB to about -60 dB where yours looks like about -70 dB.
-
Sounds good Fred. Look forward to it.
When I first received the V2Plus4 I had posted in this thread how poor the performance was in this region. OWO at that time was still involved and had explained that there was only one program available that handled the leakage correction. This isn't something that is normally used because it can lead to other problems. It is possible that the software you are using doesn't enable it by default. I posted for you the effects of turning it on and off with my software. Once I have your data, we can see how it compares with my V2Plus4 with the leakage correction disabled.
-
It seems the only way I can figure out how to get VNA_QT to export a file with S21 in it is like this.
-
Note how your new file's header is:
# MHz S MA R 50
MA selects the magnitude angle. Ideally, this would have been in dB or decibel angle. The software I am using to plot the data does not appear to handle two different formats. It also doesn't appear to allow a conversion. No problem, so I converted it with my software. Then I noticed you have a bunch of 0's in your data. It's like your software doesn't have enough resolution. While my software will handle that condition, the viewer will not. |O So, to work around the problem, I have to fudge your data to remove the 0s. Maybe QT has a workaround. I've never used it.
Attached is showing your Pro compared with my V2Plus4. Your Pro has slightly lower noise.
-
Showing your Pro compared with my LiteVNA, which again, doesn't use harmonics until we move beyond 6.3GHz. I would say they are a wash as far as which has the lowest noise. Again, there is no averaging going on as OWO was suggesting.
-
From OWO's site:
improved USB protocol allows full speed streaming of measured data to the PC.
I hooked up an antenna to the LiteVNA and decoded a local AM radio station. Is that full speed streaming? :-DD
Note: beware of clones of our older designs claiming to go to 6GHz but when tested are not able to measure accurately above 1GHz! To make measurements at these higher frequencies requires the entire signal path to be redesigned using RF rated parts and materials, impedances need to be tightly controlled, and all parts must be rated to handle the higher frequency, which adds significant expense. Even open source designs are not able to do it at below $300-500 BOM cost, and still have noticeable drift and repeatability problems.
:-DD :-DD I have shown a lot of data off that LiteVNA.
Many users have compared the NanoVNA V2 Plus4 with professional instruments. When using the same calibration kits, the measured data and smith chart matches well.
Some what true depending on the device we are measuring. All of the low cost VNAs I have looked at use a squarewave drive. Video below shows two of my vintage VNAs compared with the low cost ones. There is no comparison, the low cost ones can't measure anything meaningful. These problems I am sure are obvious to the professional but maybe not to the amateur radio hobbyist.
R&L electronics - still selling clones despite being asked not to by the original developers
Achievable performance (V2 Plus4 Pro, calibrated, IFBW=0.8kHz, AVG=20)
Funny as they have talked about the clones using averaging to make their hardware appear better than it is. You want averages, attached plot compares your Pro with the LiteVNA, 100 averages. Personally, I normally will take the noise over the speed.
https://www.youtube.com/watch?v=y6iOTEU6Zzo (https://www.youtube.com/watch?v=y6iOTEU6Zzo)
-
VNA_Qt leaves a lot to be desired. When I captured that the display was using units of dB. I had the two traces set for s11 magnitude and s21 magnitude. In the export menu there were only basic capture and export items without allowing any selection of just what was to be captured or exported beyond Port 1 report 2.
I got a copy of Solver64 and it seems to lacks the ability to control my device. It appears to link up, but it fails to trigger a regular or calibration sweep.
VNAsaver fails to run on my computer because they've updated too python 3.9 which fails to run on Windows 7. So I'm stuck with VNA_Qt, so I can get an external hard drive and load up Windows 10 or Linux distro.
I'll post a screenshot of the VNA_Qt sweep. From that you can see that it's pretty much the same as yours except in the 3.5 to 4.0 GHz range where it looks to be about 10 decibels worse.
-
I got a copy of Solver64 and it seems to lacks the ability to control my device. It appears to link up, but it fails to trigger a regular or calibration sweep.
Odd as I would have thought it would use the same protocol as the V2Plus4. I did have a guy write me once who also described a case where he could not get the VNA to sweep with my software. He sent me some screen shots and it was easy to see that he never turned on the sweeps. :-DD :-DD True story. I have ran into people who would try to run my software without NIVISA installed. Of course that doesn't work out very well. Then there was the guy telling me that it wouldn't sweep who was entering m in place of M.
If you wanted, you could make a video showing everything from turning on your VNA to trying to run it. Maybe there is something obvious going on. It's also possible OWO purposely changed the protocol to prevent the use of third party software. Seems like a dumb idea but you never know.
From that you can see that it's pretty much the same as yours except in the 3.5 to 4.0 GHz range where it looks to be about 10 decibels worse.
From my post showing the leakage correction disabled, looks like my V2Plus4 is about 20dB worse in this upper region. It's possible that they had improved the hardware so that without the correction, they gained 10dB. What's odd is they don't allow you to select it and that the Touchstone file doesn't reflect what is shown on your screen.
-
I downloaded the latest QT and Saver software. Both connect to both my LiteVNA and V2Plus4 and I am able to run sweeps and display the data. I suspect your Pro version uses the same protocol and should just work.
One thing I noticed is the last time I had tried to use that QT software (Pretty sure this is what it was) it would hang on every press. It's actually the reason I decided to port my software over to the NanoVNA in the first place because it was so poor. This new version at least seems to have solved those basic problems. I tried the export and it does appear there is a bug with the S21 export. Still your S2P is fine outside of the zero problem. Again, I suspect another bug in QT and I was not able to find a work around. Of course, you take the 20 Log 0....
I have a some error checking in my import function to handle bad Touchstone files and just added another case for the zero and made a note it was to work around a bug in QT. I tossing out the bad data so you can at least use the good parts.
-
So, I got solver working somewhat. I and setup and read sweeps, although when I try to do a cal, it prompts me for a full 2 port cal what ever I do. The manual said if there is an absence of any attached transfer relay, solver would just do a 2 port one path cal. All I have connected is the nano. Also on the advanced tab all the plots are void of data. Is that normal?
When I try to export a touchstone file from solver all I seem to be able to do is s11 in a s1p and s21 in a s2p. Is there any way to just export s21 data in to a touchstone file?
Here are some screen shots:
-
What was the problem? I'm thinking I have heard them all by now but curious if you have a new method...
You have selected a valid port number for transfer relay, the software was able to open the port you requested and did not detect the the feedback and set the fault. The fault has no other effect than to let the operator know there is a problem with their transfer relay. When you run a calibration, the software runs through all combinations because you have told it you have a transfer relay attached. The advanced tab will display all four S parameters with the transfer relay installed.
Now, I could have, and may have had an enable feature for the transfer relay at one time. I chose to set it up this way because when I don't have the transfer relay attached, the port is null and the software knows it is not attached. Saves me having to change the settings, because I am lazy.
For exporting, I am not sure if the software will even save both S11&S22 into a file today. There may be other problems with the export as well. .... Let me restate that. There may be other problems with the software as well!!! Again, it's not an end product and changes based on what ever experiments I happen to be running. You may run into some things you feel are outright bugs that me be intentional for some test I was running.
The manual is very old and I am sure there are a lot of sections that are no longer valid for the current release.
-
The problem with the sweep was the port settings. If I set only the first one to the port for the VNA, then it would link but that was all. When I set the first two for the com port for the VNA, and it would link and sweep and do what would be expected, although I stopped for the day at that point before trying to do a cal. Before I made that last post I went and set all three port settings to the port for the VNA, and everything worked as normal except except for the calibration. So I guess I have to set the one for the transfer relay to a null port and the calibration issue will be solved.
I exported an s2p touchstone file and that appears to have the s21 contained in it.
Hopefully, everything for the crystal measurements will work. I'll build a jig after I finish my current project. I was beginning to feeling mighty disheartened that I paid twice as much as need be for a device that was going to be a problem using solver for that.
BTW The leakage terms setting seems to fail to do anything noticeable in the measurements at the high end of the s21. Is that the proper place to look for it? Does that need to be saved into the configuration file before it becomes effective?
-
The problem with the sweep was the port settings. If I set only the first one to the port for the VNA, then it would link but that was all. When I set the first two for the com port for the VNA, and it would link and sweep and do what would be expected, although I stopped for the day at that point before trying to do a cal.
Ok, that is a new one. I would never have tried to tell the software that the VNA and transfer relay are the same device. If it were actually a product, I think we would need to add a lot more protection for the users.
It makes no sense that the VNA wouldn't sweep if it links as the two ports are not related. I can add an enable for the transfer relay (pretty sure I had it at one time) if you feel that would make things less confusing. You would need to create a new defaults file to support it. I actually use the transfer relay from time-to-time and like not having to select it but am willing to change it.
Hopefully, everything for the crystal measurements will work.
"Works" has different meanings to different people. The last thing I bought from eBay "worked". Want to know how many hours and $$ it took to get it to "work" by the my definition (which is that it meets spec)? :-DD
Again the original $50 NanoVNA does a much better job of "working". For the LiteVNA, V2Plus/4 and suspect your Pro, narrow band measurements was an afterthought. The hardware was already set in stone with many poor choices and Dislord made an attempt to work around it in firmware. Maybe it will "work" well enough for you.
I exported an s2p touchstone file and that appears to have the s21 contained in it.
Guessing it does something but I doubt very much that it is correct. Maybe once you get a little further long, you can let me know.
BTW The leakage terms setting seems to fail to do anything noticeable in the measurements at the high end of the s21. Is that the proper place to look for it? Does that need to be saved into the configuration file before it becomes effective?
Well, I am not sure. You have told the software you have a transfer relay (which you don't), you then go through a full 2-port cal (which of course makes no sense as you don't have the hardware in place to do it). Then you attempt to collect some meaningful data. There are other things you could be doing as well that would effect the leakage corrections. It's also possible, but doubtful, that your VNA is so good, enabling it has no effect.
-
OWO's site shows a noise plot for your VNA using the following settings: Achievable performance (V2 Plus4 Pro, calibrated, IFBW=0.8kHz, AVG=20). Below 100dB.
Using my software with the LiteVNA, I set it to 20 averages, 800 Hz IFBW and disabled the leakage term. I think the real question is how long did it take them to acquire that data compared with the LiteVNA using my software. For me, that was several minutes.
For fun I have included my H4 as they allow harmonics to 2GHz. May be useful for some experiments but you can see why I suggest the LiteVNA for anything over 300MHz.
-
I've figured out how to operate solver better now. I have XferPort and StagePort both set to unused ports. It's prompting for a two port one path cal. I guess, I was just confused about the interface as I got to know it.
With the two port one path cal, the export s2p seems to export S11, S21, S21, S11. That's all I need.
I did a 20x average of S21 after calibrating with 800Hz IF, leakage terms off.
So, I could have gotten better for half the price... Oh well, at least this will get me though my current project. Then I'll buy a liteVNA and just keep the more expensive, less able one as a backup. :)
Come to think of it, do you think solver actually changed the IF on the nano to 800 Hz? I see in your settings where 800 Hz is used for the upper frequencies that solver tries to set the IF to 160 Hz for <= 400 KHz. I wonder if the nano is just ignoring all that. Since there's an absence of any way to monitor from the touchscreen, it's anybody's guess as to what's happening there.
-
That's correct, I fill the last two columns with duplicate data when there is no transfer relay. With the transfer relay, you will get all four.
Come to think of it, do you think solver actually changed the IF on the nano to 800 Hz? I see in your settings where 800 Hz is used for the upper frequencies that solver tries to set the IF to 160 Hz for <= 400 KHz. I wonder if the nano is just ignoring all that.
Looks like again the EEVBLOG forum is having problems with attachments. Anyway, from OWO's site showing the data for your VNA, we expect 110 dBish average in the lower frequency range where your's is closer to 95. My guess is this is not a problem with your VNA. It is very possible that the commands used to set the filters is not the same. OWO's firmware would have had to follow the same commands as what Dislord implemented or it will not be compatible with Solver. My V2Plus4 doesn't have support for it, or several other commands for that matter. The firmware is very dated and not supported.
I would just join OWO's groups.io and ask there. Keep in mind they may censor your posts, so if they don't show up you know why.
***
BTW, I did go ahead and add an enable like I mentioned. There are a few other problems that I have addressed. I'm not aware of anyone using the software outside of yourself. If you don't come across any problems in the next few weeks, I will go ahead and release these changes.
-
I made some quick simulation models of the calibration standards that came with the nanovna and used them to create touchstone files for calibration with vna_Qt. I used 10x averaging for the calibration and 20x averaging for this screen shot. I was also using the 300mm cables on each port. For the one port measurements I used the thru with the male standards. It helped. Although, I thought calibration would get rid of the cable ripples more in the S11 results.
How does the touchstone correction of the calibration work?
-
85dB for S21 in the low frequency range is not expected.
For the most part, everything I have shown with the low cost VNAs has used the ideal model. I think the only time I have shown using non-ideal standards was for testing the waveguides. A viewer did call me out for having mistakes in my math but I walked through comparing results with the LiteVNA against my Agilent PNA. That ended the discussion, so I assume the viewer was a bit lost or there really is a problem and they were unable to articulate their concern. I'll leave that to other users to sort out as it appears correct to me. For the waveguides, I have a few standards that I can use for a sanity check. Actually, the new version of Solver has included the Agilent WR90 standards in the library. I attempted to make a poor man's set based on them.
https://www.eevblog.com/forum/rf-microwave/experimenting-with-waveguides-using-the-litevna/msg4796609/#msg4796609 (https://www.eevblog.com/forum/rf-microwave/experimenting-with-waveguides-using-the-litevna/msg4796609/#msg4796609)
-
I'm wondering if that's some kind of measurement artifact. I see these little discontinuities in the sweep here and there. I made another calibration with touchstone files for the VHF band for my project. And this is what I got, 20x averaging, 601 points, 143 Mhz - 149 MHz.
-
That's a big improvement from your previous post and more what OWO claims. I wonder why you can't sweep a wider range like they show and get roughly the same results. Did they provide you with coefficients for their included standards?
-
I'm just using the touchstone files I created from the sim models I made of the supplied standards, basically a models of the male standards with the thru attached so that it goes on the end of the 300mm cables.
From what I've seen so far, I would expect the more the bandwidth of the sweep is increased the more bumpy the measurements are going to get. I'm sweeping in 10 kHz steps for that. I'm working on the UHF band now in 50 kHz steps. 20x averaging for everything.
-
Yes sir....Giant red flag here, with the new user account. Sorry about that but I have been reading this blog for hours trying to find the answer(s).
I have a LiteVNA and would love to be able to get @joeqsmith 's software installed properly but come up short.
The steps I believe i need to follow are installing the original NanoVNA V2 software with the included packages, and then moving the requisite .exe's from the more current version of the software into the root directory.
My issue is that @joeqsmith github seems to be gone. I get a 404 Webpage not found on github when clicking on any link(s) that point to the original, and have not had any luck trying to search github for the same.
Forgive me if this has been beaten to death.
Any guidance would be greatly appreciated.
P.S. I am on Windows 11 .
Thank you so much in advance for any help offered.
Respectfully,
-
Obviously your hours of reading have not included the last few pages of this topic in which joeqsmith has explained that the files are no longer on github. His sig contains a link to their new location.
-
Obviously your hours of reading have not included the last few pages of this topic in which joeqsmith has explained that the files are no longer on github. His sig contains a link to their new location.
Obviously you haven't actually looked at his dropbox any time recently. on page 18 of his manual, in RED type the following instructions/options are given:
"As of version 1.0 there are now two separate programs. One supports the original NanoVNA
and the other supports the new V2+. The installer, .INI, runtime engine and VISA drivers will
no longer be included. You may download these directly from NI, or just install the original
release of the V2+ software. Once these are installed, copy the executable files to your
directory." (Which I referenced in my original post, clearly indicating I had in fact found and read the dropbox)
Problem with THAT instruction, is that the "original release of the V2+" version of the software/installation package is not listed in the dropbox. There is a Solver64 directory, a NanoVNA directory and an NI_Runtime_VISA directory. NOWHERE in the dropbox link, is "original release of the V2+ software" listed. Are we supposed to assume that the NanoVNA directory is the "Original V2 version" ?
Perhaps you can see the dichotomy?
Lastly, if YOU had actually read the last few pages of this thread, you would (or at least should have) seen THIS reply by Joe where he clearly states that he uses github:
GitHub is really for application development teams and individuals who compile applications from source code. For people who just want to grab a pre-compiled binary and go it is a good bit of a hassle. Have you had a look at Sourceforge?
No. Only Github. Easy for me and I suspect for most of the youth who grew up with PCs. Nearly impossible for the old hams, even with explicit instructions. They need something that works like their PC file manager. Google Drive, Microsoft One Drive, Dropbox. Of course we do have a few special people that try and use their cell phones.
P.S. the really interesting clue contained in all of ^ that....is the date/timestamp, which is what? 3 or 4 days ago now?
Restraint of pen and tongue is a conditioned response. Perhaps combined with a little humility, you will get there someday.
-
@Slide_Lock
Check out Joes recent video about the Dropbox move
https://www.youtube.com/watch?v=xDZpQS3Ou6s (https://www.youtube.com/watch?v=xDZpQS3Ou6s)
He states that the NanoVNA folder on Dropbox includes the files that were up on Github and that may be what you want
He also states he isn't intending to update the manual and that any support is worth what you paid for the software (or something like that)...
So you may have to watch that video and make some educated guesses.
-
Obviously your hours of reading have not included the last few pages of this topic in which joeqsmith has explained that the files are no longer on github. His sig contains a link to their new location.
Obviously you haven't actually looked at his dropbox any time recently.
Obviously I have looked. How else could I have downloaded the files you seek within the last three days? Joeqsmith akso stated in a very recent post, which your hours of reading missed, about the manual being out of date and that he will not be updating it.
-
@Slide_Lock
Check out Joes recent video about the Dropbox move
<snip>
He states that the NanoVNA folder on Dropbox includes the files that were up on Github and that may be what you want
He also states he isn't intending to update the manual and that any support is worth what you paid for the software (or something like that)...
So you may have to watch that video and make some educated guesses.
Thank you so much for the courteous reply.
-
Obviously your hours of reading have not included the last few pages of this topic in which joeqsmith has explained that the files are no longer on github. His sig contains a link to their new location.
Obviously you haven't actually looked at his dropbox any time recently.
Obviously I have looked. How else could I have downloaded the files you seek within the last three days? Joeqsmith akso stated in a very recent post, which your hours of reading missed, about the manual being out of date and that he will not be updating it.
It's ok man. You seem cranky. I hope you have a better day today than you appear to have had yesterday.
-
So this is the error I get when trying to run Solver64:
[attachimg=1]
I was unable to locate this specific file on NI which is referenced in the dropbox readme: "ni-labview-2020-runtime-engine_20.1.1_offline.iso"
So I assumed (perhaps incorrectly) based on the compatibility chart provided by NI that the closest version (ni-labview-2020-runtime-engine_20.0.1_offline.iso) I COULD find, would actually work, since it aligns with the VISA compatibility shown here:
[attachimg=2]
Can someone help me understand what the solution might be?
The program launches just fine, however, I cannot link to my LiteVNA, even when selecting the proper com port in the application as confirmed in device manager.
-
Those pesky M-drive stepper motors. Watch the video...
-
Those pesky M-drive stepper motors. Watch the video...
Thank you Joe. I did watch the video. The "stage" checkbox was unchecked by default on mine, but I checked it, then un-checked it, saved the defaults and I still cannot connect.
A screenshot of the software on my laptop is shown below.
-
LOL. So the transfer relay, M-drive stepper motors and the VNA are all one in the same. That's what you are telling the software. Odd as Fred made the same mistake just a page or so back.
-
LOL. So the transfer relay, M-drive stepper motors and the VNA are all one in the same. That's what you are telling the software. Odd as Fred made the same mistake just a page or so back.
So I read that post and tried what Fred referred to here:
I've figured out how to operate solver better now. I have XferPort and StagePort both set to unused ports. It's prompting for a two port one path cal. I guess, I was just confused about the interface as I got to know it.
But I still get no joy when trying to connect. Below is a screen grab showing the VNA port (COM11) as well as having the Xfer and Stage ports to a random unused port, as well as device manager open in the background confirming that the VNA is on COM11, what else am I missing?
-
And if you search NI's site for the error you posted, what does it tell you?
Code Description −1073807202 VISA or a code library required by VISA could not be located or loaded.
And notice how we have seen this before in your earlier post. What do you think this means?
-
And if you search NI's site for the error you posted, what does it tell you?
Code Description −1073807202 VISA or a code library required by VISA could not be located or loaded.
And notice how we have seen this before in your earlier post. What do you think this means?
Not sure I understand here Joe. In your first reply, you eluded to the "pesky stepper motors". Now you are suggesting something else altogether?
Is it possible for you to be a little more specific? If you know what the issue is, I sure would be grateful if you would share it. It would be nice to skip the word salad guessing game if at all possible.
Not all of us out here are as intimately familiar with NI as you are.
-
I have upgraded to the version 4 Solver64. I have firmware version 1.3.15 loaded on my VNA. It seems the latest from DiSlord is 1.3.18 and the Solver64 zip folder has a 'firmware' subfolder with 'LiteVNA64 v1.3.12 fix1.bin' . Which one should we be using?
-
You can use any firmware you like. Because there is no support, it's up to you to test your setup. I stopped chasing the firmware of the week club years ago. Once I find something that works, I don't change it unless there is a very good reason. I provided the version I test with. Keep in mind though, some of the features in the unreleased firmware may never have made it into a release (for good reason). I think that last version removed all the limitations for using harmonics, which I was using to experiment with the Waveguides. I was given a warning about it's use and can fully understand not wanting to release something like that to the general user.
I used to have a simple regression test for the original NanoVNA but because Dislord's firmware was so solid, I never incorporated it into Solver. So I suspect your risk is low but it's all on you to do your job testing. If you find a problem, don't expect me to address it.
-
And if you search NI's site for the error you posted, what does it tell you?
Code Description −1073807202 VISA or a code library required by VISA could not be located or loaded.
And notice how we have seen this before in your earlier post. What do you think this means?
Not sure I understand here Joe. In your first reply, you eluded to the "pesky stepper motors". Now you are suggesting something else altogether?
Is it possible for you to be a little more specific? If you know what the issue is, I sure would be grateful if you would share it. It would be nice to skip the word salad guessing game if at all possible.
Not all of us out here are as intimately familiar with NI as you are.
When I posted You will need the correct files and can't just guess.
and I was already asked about which files to get from NI. Make sure you READ the readme file in the runtime directory. This isn't something you can just guess at.
From your post below, I'm guessing that went over your head.
I was unable to locate this specific file on NI which is referenced in the dropbox readme: "ni-labview-2020-runtime-engine_20.1.1_offline.iso"
So I assumed ...
-
joeqsmith
If ^^ THAT is my problem, then why not just say so outloud, in one sentence? I.E. "ni-labview-2020-runtime-engine_20.1.1_offline.iso is the REQUIRED file, and my software will not work with any other variation". perhaps combined with a helpful link to the correct file. Instead, you take 3 or 4 posts to run people in circles, I suspect for your own personal entertainment or enjoyment.
This seems to be a common theme with you Joe. You belittle the HAM radio community for being curious about your software, you obviously spend countless hours quoting peoples posts, and adding mundane irrelevant replies, where you constantly reference your ridiculous out of date manual which you demand people read, all while attempting to cover your bases by proclaiming that you have no intention of updating or maintaining it.
It appears that this software is your best effort at making some kind of a mark in life. It obviously gives you a superiority complex, which is actually a bit sad, because at the end of the day, it is trivial and insignificant. The offshore folks are just going to do it better, and offer their own version of YOUR software that does everything yours can do now and it will be compiled properly, with an installer package, and it will just work AND they will provide it free with the purchase of a new LiteVNA or whatever the flavor of the day is.
At that point, your buggy, nightmare to install app will fade into obscurity, just like you will, and you both will be forgotten. Relegated to the ash heap of history.
YOU will be responsible for that, because had you decided at some point to be friendly, courteous and helpful, as opposed to lourding over this 91 page thread like a J.R. Tolkien trilogy troll, you could have potentially left a positive mark in life, that people would have remembered long after you are gone.
Here is a clue: The only people that transition from GitHub to DropBox, are people who were misusing GitHub as their own personal cloud storage space and were warned, and then told to leave. Developers of real software don't do that.
Here is another clue: If you ever do decide to become even a little bit human with regards to how you interact with people, it might be a good idea, while you are creating a video, to actually stay on topic. Nobody wants to hear over and over again how bitchen you think you are because you created umpteen filters, air-gaps or whatever other insignificant widget you imagined, when the actual topic of your video is: "Solver64 on LiteVNA". You spin off into unrelated diatribes that have nothing to do with WHY people clicked on your video in the first place. It's nauseating.
In addition to that, I did a quick run back through this entire thread and by far, you have the highest word count. It's not even close, yet oddly enough, there is so little relevant information on how to get your software up and running that it's actually laughable. You spend more time berating, belittling and demeaning people than you do actually helping them, I actually believe that you enjoy it. That is narcissistic and loathesome, and I sure hope you seek help for it at some point.
Good day sir.
-
ROFLMAO!!
-
:palm:
-
I released 4.01 which was based on Fred's experience with the serial ports and my attempts to view his exported Touchstone files from QT. I also noticed that Solver's Touchstone export was still not correct. I'm a bit surprised Fred didn't call me out or at least point that one out as the order was still reversed for S2P files.
4.01, 08/28/2023
Remove reorder in S2P export (was missed from 3.17 bug fix)
When importing Touchstone files, remove S21 data that is zero'ed. Problem with QT software.
Add enable checkbox for the transfer relay rather the using a null port.
Add the transfer relay enable flag to the defaults file.
-
It appears that this software is your best effort at making some kind of a mark in life.
Hey come on - everyone deserves their 15 minutes of fame - even Joe!
:-DD
-
Write a story to fit the photos.
-
Thought I'd swoop in here after complaining another thread is giving me bowl cancer...
Here is a clue: The only people that transition from GitHub to DropBox, are people who were misusing GitHub as their own personal cloud storage space and were warned, and then told to leave. Developers of real software don't do that.
I, as an actual professional in that space, would suggest that Github isn't actually where people go to write real software. It's where people go to get hand jobbed for stars, lots of unadulterated forking and occasionally get a face full of NodeJS as a result. It's a community for the unthinkers and shokushu goukan fans. Some people don't even use git believe it or not. And those people are quite productive still when GitHub is down for the nth time in a week!
You're only bitter because even if Joe's software is shit, which is feasible as I know all mine is, you can't raise a PR against it, fork it and flap all over the remains like a demented pigeon.
But yeah DropBox. Anything but DropBox. Why Joe? WHYYYYY.
Anyway that's enough beer and posting on EEBblog for the year. Farewell again :phew:
Edit: oh also...
You belittle the HAM radio community
It's a well deserved belittling. I say that as a former full license holder here. Just ugh to the whole thing. I took great pride in tearing up the license and shredding the certificate.
The moment I did it, the air of hamness went and it's been floozies non stop since.
-
Thought I'd swoop in here after complaining another thread is giving me bowl cancer...
That ^^ quote is priceless, but only if/when you consider the comment bd139 made below:
I, as an actual professional in that space, <snip>
YOU as an actual "professional" in that space (your words) must be quite the professional indeed, all while blissfully unaware that you appear to have nearly zero command of the English language...... That is unless there is a new form of cancer called "bowl" cancer? Of course you could be forgiven if your intention was to proclaim that you have "bowel" cancer..... Either way, that made me laugh a little bit.
Carry on with your beer and floozies Mr. Consummate "professional".
-
Thought I'd swoop in here after complaining another thread is giving me bowl cancer...
Welcome back.
You're only bitter because even if Joe's software is shit, which is feasible as I know all mine is, you can't raise a PR against it, fork it and flap all over the remains like a demented pigeon.
But yeah DropBox. Anything but DropBox. Why Joe? WHYYYYY.
First, as I have stated many times my software was something I put together for my own personal use. It must be close to 20 years old now and is still no where near what I would consider a polished product. That was never my intent. It's just a tool I use to run my own RF experiments.
Many hams struggled navigating Github. I was looking for the simplest thing I could find. Something like Facebook. It would have been MS, Google or Dropbox. I block all MS traffic so Onedrive was out. I played with Dropbox for the first time and thought, surely the hams can handle this...
You have to realize, enhancing the art is only a question on their test. Like all the other questions, they are given the answers. Hams are only required to memorize long enough to pass a test. That has nothing to do with engineering or problem solving. It's what you may expect from a parrot. If the only goal of the FCC is to keep the number of members up to boost sales of equipment, we have to work to the least common denominator.
Even with simple instructions, there are people that read and acknowledge the requirement of specific files and they still fail.
I was unable to locate this specific file on NI which is referenced in the dropbox readme: "ni-labview-2020-runtime-engine_20.1.1_offline.iso"
So I assumed ...
I suspect the amount of effort in their posts that followed was far more than what they spent obtaining the required files to run the software. This is somehow everyone else's fault but their own. I'm sure others have held their hands and wipped their asses throughout their lives but I have no interest in dealing with the entitled. Personally I blame the FCC for their "No ham left behind" agenda.
Anyway that's enough beer and posting on EEBblog for the year. Farewell again :phew:
Don't make your absence so long next time. I miss the stories of floozies. If you get bored of the TEA area, we are always here.
-
Thought I'd swoop in here after complaining another thread is giving me bowl cancer...
That ^^ quote is priceless, but only if/when you consider the comment bd139 made below:
I, as an actual professional in that space, <snip>
YOU as an actual "professional" in that space (your words) must be quite the professional indeed, all while blissfully unaware that you appear to have nearly zero command of the English language...... That is unless there is a new form of cancer called "bowl" cancer? Of course you could be forgiven if your intention was to proclaim that you have "bowel" cancer..... Either way, that made me laugh a little bit.
Carry on with your beer and floozies Mr. Consummate "professional".
Dear Slide_Lock,
I would like to profusely exclaim my regret that I mistyped bowel as bowl whilst under the influence of slightly too many cans of Brewdog last night. I did not mean to offend your good self or open myself up for such criticism regarding my professionalism on the matter of software engineering. I truly hope you accept my apology and that you can refocus on the original points I mentioned which were not referred to in your response at all.
Your sincerely and with apologies,
bd139
-
Even with simple instructions, there are people that read and acknowledge the requirement of specific files and they still fail.
With respect to this particular point, much as the old phrase goes you can lead a horse to water but you can't make him drink, you can paraphrase it as you can lead a ham to instructions, but you can't make him read.
Don't make your absence so long next time. I miss the stories of floozies. If you get bored of the TEA area, we are always here.
I occasionally read a few threads but my general interest in electronics is low these days. Been too busy with other adventures.
-
Even with simple instructions, there are people that read and acknowledge the requirement of specific files and they still fail.
With respect to this particular point, much as the old phrase goes you can lead a horse to water but you can't make him drink, you can paraphrase it as you can lead a ham to instructions, but you can't make him read.
Or as Dorothy Parker put it, You can lead a whore to culture but you can not make her think. Floozies have other qualities...
-
Even with simple instructions, there are people that read and acknowledge the requirement of specific files and they still fail.
With respect to this particular point, much as the old phrase goes you can lead a horse to water but you can't make him drink, you can paraphrase it as you can lead a ham to instructions, but you can't make him read.
Or as Dorothy Parker put it, You can lead a whore to culture but you can not make her think. Floozies have other qualities...
Dunno about that. The proper floozies seem to all have PhDs (physics and psychology so far) :popcorn:
-
First, as I have stated many times my software was something I put together for my own personal use. It must be close to 20 years old now and is still no where near what I would consider a polished product. That was never my intent. It's just a tool I use to run my own RF experiments.
Yet here you are, attemptinig to share it with anyone and everyone who will put up with your drivel, run around, misdirects and belittling. News flash there Joe, no matter how many times you repeat the lie, it is still a lie.
You have to realize, enhancing the art is only a question on their test. Like all the other questions, they are given the answers. Hams are only required to memorize long enough to pass a test. That has nothing to do with engineering or problem solving. It's what you may expect from a parrot. If the only goal of the FCC is to keep the number of members up to boost sales of equipment, we have to work to the least common denominator.
Even with simple instructions, there are people that read and acknowledge the requirement of specific files and they still fail.
It's obvious to quite a few people who have PM'd me and thanked me for saying the quiet part outloud (and probably countless others), that you are about a half a bubble off, if not more, because to rational, sane, friendly people "simple instructions" are clear, concise, and have all of the requisite links to the item they are being instructed on how to properly install.
"Simple Instructions" are not individually left like bread crumbs in some old guys 92 page biography, or outdated mismanaged "manual". The laughable part is that your "simple instructions" are really nothing more than pretzle logic. I seriouly doubt you even have a clue how much information is missing, because in every single one of your videos, you wander off topic and into another dimension, not unlike the current brain dead, senior citizen that occupies the White House.
"Simple Instructions" also, generally, do NOT come with caveats. YOUR's on the other hand.....do. I.E. "These instructions are simple, if you have the patience to weed through 92 pages of me telling others how smart I think I am, coupled with a requirement that YOU watch countless unrelated videos, all while I answer your questions, with.....you guessed it...an UNRELATED question".
It might be time to ask the doctor if you are perhaps pre-Alzheimer's. You definitely exhibit some of the symptoms. At least in your ridiculous replies.
I suspect the amount of effort in their posts that followed was far more than what they spent obtaining the required files to run the software. This is somehow everyone else's fault but their own. I'm sure others have held their hands and wipped their asses throughout their lives but I have no interest in dealing with the entitled. Personally I blame the FCC for their "No ham left behind" agenda.
One thing is clear. You have a boogieman you can blame your horrendous coding skills on. The Ham radio community. How convenient it must be to lay the blame at the feet of those you fear the most. I have another news flash for you. I know at least a dozen HAM's that can run circles around you in their ability to explain how to get from point A to point B within the electronics world that HAM radio operators typically revolve around. The really neat thing is they do it with style, patience and the gratitude they exhibit to their interested understudies for allowing them to share their knowledge. You on the other hand seem content to blame others for the piss poor effort you put in to making your app useable by all. THe epic part is you disguize your angst, ad-naseum in your mantra: "I made this for me and me only"
-
Even with simple instructions, there are people that read and acknowledge the requirement of specific files and they still fail.
With respect to this particular point, much as the old phrase goes you can lead a horse to water but you can't make him drink, you can paraphrase it as you can lead a ham to instructions, but you can't make him read.
Or as Dorothy Parker put it, You can lead a whore to culture but you can not make her think. Floozies have other qualities...
Dunno about that. The proper floozies seem to all have PhDs (physics and psychology so far) :popcorn:
Did the quality of floozies correlate to shredding the license?
-
"I made this for me and me only"
All the OSS contributions I've done over the years are selfishly supporting my own needs. There's nothing wrong with that.
The rest of that comment, based on the nonsensical use of punctuation and upper-case text, compromises your already tenuous position on having a rational argument.
Did the quality of floozies correlate to shredding the license?
Yes. I have a fringe hypothesis that ham tickets actually emit a field which repels them. This I believe is a self-regulating mechanism built into the planet's ecosystem to try and keep the numbers in control and prevent us diverging into Morlocks and Eloi.
-
:-DD :-DD
-
All the OSS contributions I've done over the years are selfishly supporting my own needs. There's nothing wrong with that.
If we were dealing with an OSS "contribution" here, we would not even be having this conversation. Joe has indicated in at least one of his rambling video's, or rather, his replies (in that/those video(s)) to inquiries regarding the release of his code so that others may actually work on making it useable, that he has no intention of releasing it. That sort of kills the "open source" part of "OSS" does it not?
-
All the OSS contributions I've done over the years are selfishly supporting my own needs. There's nothing wrong with that.
If we were dealing with an OSS "contribution" here, we would not even be having this conversation. Joe has indicated in at least one of his rambling video's, or rather, his replies (in that/those video(s)) to inquiries regarding the release of his code so that others may actually work on making it useable, that he has no intention of releasing it. That sort of kills the "open source" part of "OSS" does it not?
Again missing the point.
We don’t have to do things for altruistic reasons. I didn’t. It was just easier to achieve my selfish gains by stealing a corpus of someone else’s work and adding to it. I only contributed it back hoping that someone else would take it off me. That bit is of course optional.
-
Again missing the point.
We don’t have to do things for altruistic reasons. I didn’t. It was just easier to achieve my selfish gains by stealing a corpus of someone else’s work and adding to it. I only contributed it back hoping that someone else would take it off me. That bit is of course optional.
Therein lies the difference between you and Joe. He makes videos for days, creates manuals, then creates an autobiography on eevblog to promote and "share" his "work", all while proclaiming that this is all for him and him alone.
No sir, I think it is you that is missing the point. I get that he called you out of the woodwork to help defend his indefensible position, but you said it best a few posts back when you stated his work was most likely "shit" or whatever pronoun you used to describe him. I'd leave it there.
-
Again missing the point.
We don’t have to do things for altruistic reasons. I didn’t. It was just easier to achieve my selfish gains by stealing a corpus of someone else’s work and adding to it. I only contributed it back hoping that someone else would take it off me. That bit is of course optional.
Therein lies the difference between you and Joe. He makes videos for days, creates manuals, then creates an autobiography on eevblog to promote and "share" his "work", all while proclaiming that this is all for him and him alone.
No sir, I think it is you that is missing the point. I get that he called you out of the woodwork to help defend his indefensible position, but you said it best a few posts back when you stated his work was most likely "shit" or whatever pronoun you used to describe him. I'd leave it there.
Check my post history. I do the same. Well I deleted my YouTube account so the floozies don’t eventually catch up with the video titled Transgender Transistor Tribulations after I discovered a dual PNP transistor was actually an NPN. I mean that not going to look good on Tinder is it?
Actually the chain of events was someone (not joe) posted the thread elsewhere saying that they though joe was being an ass and I know joe can be a miserable fucker sometimes (I can with the worse of them) so I read it whilst drunk and thought, hey fuck it I feel like chipping in on this one because I’ve got a stinking cold and I’m bored and feel like trolling a little bit. But I honestly have no beef with joe after reading it. I mean I wouldn’t install his software on my VNA or whatever because I give so little a shit about that at the moment. He can do what he likes. But at the same you can’t go moaning about his without sounding like a raging hypocrite when all the VNA firmware out there is shit compared to some nicely finished professional test gear. But that’s what you get at this price and I’m fine with riding a clunky wooden horse because I’m a cheap ass and would rather be spending that money on other stuff.
What you’re doing is coming in and whining about it like some self-entitled zealot that your expectations aren’t being met and after being on the internet since before those bastards from AOL came and ruined it, I’m fed up of seeing this damn thing going round in circles over and over and over again especially with ALL CAPS ….. and OVERZEALOUS!!, punctuation. It’s the same argument I’ve seen a thousand times. Step in shit on purpose then complain about it because your existence needs validation in some way. Then build a fictitious argument about discrimination over some hypothetical membership to a social group. Hint hams are a shit social group. Then attack individual members who have had enough of this shit.
The end game is nothing is solved, you are validated and amble off like a demented pigeon feeling righteous. Coo coo I’m validated. No you’re not. You’re just another boring grey pigeon. Flying vermin.
Anyway I’ve run out of time to write this post as I’m having a shit and writing it on my iPad so I’m going to wipe and use the remaining half an hour of my day to do something productive. Thanks for assisting with the constipation.
-
I know joe can be a miserable fucker sometimes
Is that a step up from a demented gray pigeon? :-DD
-
I know joe can be a miserable fucker sometimes
Is that a step up from a demented gray pigeon? :-DD
Most certainly is :-DD
I mean I’d be a miserable fucker if I had a multimeter graveyard. Oh no wait I do have one.
-
Wow this thread really has taken a turn... but that was quite the hilarious post @bd139
-
The end game is nothing is solved <snip>
Anyway I’ve run out of time to write this post as I’m having a shit and writing it on my iPad so I’m going to wipe and use the remaining half an hour of my day to do something productive. Thanks for assisting with the constipation.
Well it appears that your constipation is twofold. One, potentially gastrointestinal, but Two, definitely mental. Hopefully I helped with at least one of them?
Again, I am happy that you felt the need to come rushing to Joe's defense, while he continued to make himself look like an addled old codger, running people around in circles with incorrect guidance on how to decipher his heiroglyphic instruction set. But in reality, what you are doing is generally referred to as "elder abuse". You are perpetuating his mania by validating it with a bit of your own, all while ignoring the points that were made with regards to what Joe seems to enjoy doing in this thread, which is pretend like he is sitting on the Rosetta Stone, and offering up the key to anyone willing to tolerate his dementia long enough for him to extend it.....When and if he feels like you have earned it.
You (and his) odd need to continue bashing HAM radio license holders is curious indeed. Joe gets a pass on this, because as mentioned, he appears to be suffering, (quite a bit acutally), from a sort of God complex. You, on the other hand, are admittedly just here for the entertainment.
If you actually believe that what Joe has offered up here is a clean path to success, for those who wish to investigate the worthiness of his "software", for whatever reason they choose, then please, by all means, defend that position with a solution of your own, for example on how to locate the one file, that appears to be required to arrive at a successful installation: "ni-labview-2020-runtime-engine_20.1.1_offline.iso" . That file does not appear to exist anywhere in NI's website, yet without it, the entirety of his offering is fruitless.
I would have gladly wandered off into the distance, biting my tongue, had he not replied to my post with "those pesky stepper motors, watch the video", which caused me to watch the video again, only to discover that I had already done what he described in the video, report that in a subsequent post, and then be led off in another direction by that reply. THAT is when I realized that this guy has no desire to help anyone succeed, but rather, he takes pleasure in assiting in their failure to get his software up and running.
At that point, it, much like you proclaimed, became sport fucking for me. My only desire now, is to try and flood this thread with as many posts as I see fit, highlighting his dementia, while hopefully making other potentially interested parties aware that they have no hope for success IF they follow his "instructions" because the requisite file(s), required for success, do not exist, at least not publicly.
P.S. Points awarded for the: "I was around before AOL came in and screwed it all up for everyone" quip... That did indeed make me chuckle a little bit. Bravo.
-
If you actually believe that what Joe has offered up here is a clean path to success, for those who wish to investigate the worthiness of his "software", for whatever reason they choose, then please, by all means, defend that position with a solution of your own, for example on how to locate the one file, that appears to be required to arrive at a successful installation: "ni-labview-2020-runtime-engine_20.1.1_offline.iso" . That file does not appear to exist anywhere in NI's website, yet without it, the entirety of his offering is fruitless.
Okay, enough. I've been monitoring the developments in this thread with amusement, as Joe is just the kind of cranky hardass I like (I am an old veteran after all, so fits right in with me). I don't have a VNA so haven't tried to install Joe's software, but I had to give this a try to see what all the drama is about.
So after all of your bloviating about how ni-labview-2020-runtime-engine_20.1.1_offline.iso "does not appear to exist anywhere in NI's website," I figured I'd have to get clever or something to sus it out. Nope, I found it directly on NI's download page and downloaded it, all in probably less than 60 seconds.
(https://www.morrisonline.us/images/Ashampoo_Snap_Saturday,%20September%209,%202023_11h44m11s_001_DXferElectronicsNational%20InstrumentsNI-VISA.png)
I would normally give the link, screenshots, and whatever steps are necessary to go directly to the download, but after your show of crapping on others who contribute their efforts to the community because you can't figure out how to download something, I'll not participate in the spoon feeding either.
Joe is providing you (and this community) with a wealth of information that he doesn't have to. I'm not an RF guy, I follow him mainly for his DMM robustness work, and I've learned a lot from it. He's doing the work for his own use or interests and generously sharing it with the rest of us. He doesn't have patience for people that expect to be spoon fed and can't figure things out for themselves, and I can respect that. He's not pushing his work on anyone, and I'm sure could give less than a f*#$ whether you or anyone else cares for his attitude about it.
-
I found it too without much effort.
-
I would normally give the link, screenshots, and whatever steps are necessary to go directly to the download, but after your show of crapping on others who contribute their efforts to the community because you can't figure out how to download something, I'll not participate in the spoon feeding either.
I'm not a fan of working to the least common denominator. Even if our friend were able to locate the proper files and install them, the following quote alone suggests they they lack the technical skills to make use of it and your time documenting it for them would be wasted.
....because you created umpteen filters, air-gaps or whatever other insignificant widget you imagined, ...
Consider there may be engineers in the making following along. That's a group I am willing to invest time in. It only took a few minutes to go from a Google search to having the files.
-
The end game is nothing is solved <snip>
Anyway I’ve run out of time to write this post as I’m having a shit and writing it on my iPad so I’m going to wipe and use the remaining half an hour of my day to do something productive. Thanks for assisting with the constipation.
Well it appears that your constipation is twofold. One, potentially gastrointestinal, but Two, definitely mental. Hopefully I helped with at least one of them?
The bowel yes. The peristalsis invoked by your utterings was cathartic and I'm 1.1Kg lighter (2.4lb in dumbass units). Thank you indeed.
Again, I am happy that you felt the need to come rushing to Joe's defense, while he continued to make himself look like an addled old codger, running people around in circles with incorrect guidance on how to decipher his heiroglyphic instruction set. But in reality, what you are doing is generally referred to as "elder abuse". You are perpetuating his mania by validating it with a bit of your own, all while ignoring the points that were made with regards to what Joe seems to enjoy doing in this thread, which is pretend like he is sitting on the Rosetta Stone, and offering up the key to anyone willing to tolerate his dementia long enough for him to extend it.....When and if he feels like you have earned it.
I would refer you to my partner, a rather prominent psychologist, academic and doctor on why you are wrong. However I just dumped her, partly because the academic rigour in her sector is near zero and most of what they come out with is reasonable sounding ideas that they desperately try and fit data and conclusions to to validate their existence. Quite frankly that doesn't sit well with me as it's intellectually dishonest. So coming out with any popular psychology, which is built on the pillars of this excrement, is not a viable point to argue from.
You (and his) odd need to continue bashing HAM radio license holders is curious indeed. Joe gets a pass on this, because as mentioned, he appears to be suffering, (quite a bit acutally), from a sort of God complex. You, on the other hand, are admittedly just here for the entertainment.
Oh I'm not here for the entertainment. My day job is in the IT sector as you probably know. Technically at the moment I'm a somewhat tenured contract greybeard but I've been in the trenches of course for many years. And I've seen some of the most insane, degenerate, disgusting people in those trenches. I figured I needed a technical escape from that and some tie back to the previous career as an electrical engineer so after futzing with test gear for ages, I jumped through the hoops and got all the ham licenses here. A monkey could pass them, although some monkeys did not. This involved at the end of it, unfortunately, meeting hams. And they make the worst of the people I've seen in the IT trenches look like good mating material to keep the human race going forward. I mean where else other than a hamfest (or possibly Comic Con) can you queue up for 30 minutes in the burning sun with people nearly slipping off this mortal coil, the whiff off unwashed hair and armpits, lasagne flavoured vapes, gout and heart problems and if you happen to have your adult daughter with you, the wandering eyes of people who's only encounter with a woman was Mrs Hand and her five daughters.
All a ham license does for the majority of the holders is give them some perverted sense of value in a society that rejected them because they are rejectable. Some proudly walk around with a name badge and call sign on showing their importance, some dress up as close to police officers as they can and end up directing traffic at a car boot sale and some decorate their gardens with monstrous towers and fuck up the CATV / Internet for 2 miles in each direction. They only do this because the real world rejected their fantasies of power and control because they had that much of a personality disorder that it's the only bit of society that would accept them. And why would they not accept them...
Now a number of us when we did our licenses kept in contact, via sensible means aka WhatsApp and email like the rest of society. No one bothers now because of the racists, the misogynists, the perverts, the personality disorders and the general association with such folk.
On top of that it's a kick in the teeth because I did actually build my own receiver, transmitter and gear from scratch! (oh and a K2). All I get is people whining I'm 25Hz off frequency. I'm literally sending you this signal on a transmitter made of 11 parts I put together myself. You're sitting there on your fat stinky ass in front of several thousand dollars of Elecraft K-line stuff that you don't actually know how it works pissing on everyone. Yeah nice job.
So that's why I dislike the whole ham thing. And I think it's justified. I was attending hamfests until recently just to rip off their shit and sell it on ebay and make loads of money but I can't be bothered with that now any more either because I might catch something itchy off them.
If you actually believe that what Joe has offered up here is a clean path to success, for those who wish to investigate the worthiness of his "software", for whatever reason they choose, then please, by all means, defend that position with a solution of your own, for example on how to locate the one file, that appears to be required to arrive at a successful installation: "ni-labview-2020-runtime-engine_20.1.1_offline.iso" . That file does not appear to exist anywhere in NI's website, yet without it, the entirety of his offering is fruitless.
Like I said I don't give a fuck. I actually give a minuscule proportion less of a fuck now it's NI LabVIEW. I mean I've done my time on that before and it hurt me. But I reckon I could find that if for a moment I started giving a fuck. I mean it basically says "install the LabVIEW runtime" yeah? Sure I can work that out.
I would have gladly wandered off into the distance, biting my tongue, had he not replied to my post with "those pesky stepper motors, watch the video", which caused me to watch the video again, only to discover that I had already done what he described in the video, report that in a subsequent post, and then be led off in another direction by that reply. THAT is when I realized that this guy has no desire to help anyone succeed, but rather, he takes pleasure in assiting in their failure to get his software up and running.
This is the Internet. Expectations of accuracy and no legwork on the part of the consumer are never guaranteed. I mean how many thousands of circuits out there are absolute garbage trash and junk designed by complete and utter morons, some quite famous (Forest Mimms is the biggest fraud ever for example). You have to fill in the gaps yourself.
A while ago I published a design on here for a fully analoge scope excercising unit which bounces a little ball on the screen in X-Y mode. This was a fairly simple quadrature oscillator and a couple of triangle oscillators and two summing amplifiers. Someone built it and got pissy in DMs that it didn't work. I don't care! Fix it yourself.
By the way I assume you meant "assisting" rather than "assiting" there.
At that point, it, much like you proclaimed, became sport fucking for me. My only desire now, is to try and flood this thread with as many posts as I see fit, highlighting his dementia, while hopefully making other potentially interested parties aware that they have no hope for success IF they follow his "instructions" because the requisite file(s), required for success, do not exist, at least not publicly.
Perhaps the problem is with your demeanour, not the recipient. I mean you're doing a lot to ruin your own credibility in that statement. I mean you have switched to "pee all over the furniture" because no one fed you. It'll be humping the cushions next.
P.S. Points awarded for the: "I was around before AOL came in and screwed it all up for everyone" quip... That did indeed make me chuckle a little bit. Bravo.
Thank you. Takes a bow
-
Your rapier wit is amazing! Not kidding!
-
My only desire now, is to try and flood this thread with as many posts as I see fit, highlighting his dementia, while hopefully making other potentially interested parties aware that they have no hope for success IF they follow his "instructions" because the requisite file(s), required for success, do not exist, at least not publicly.
You are just making an ass of yourself.. :palm:
A direct search on Google for "install solver64" returns (somewhere on 6th place) a thread from NanoVNA-V2@Groups.io
https://groups.io/g/NanoVNA-V2/topic/89931588 (https://groups.io/g/NanoVNA-V2/topic/89931588)
Albert, a 77 years old man, was asking for help installing Solver64. I posted there a short installation guide, I wanted to prevent Albert and maybe others from doing a complete LabVIEW installation, as suggested by some other users. The links for the LabView runtime and NI-VISA are still working.
Albert just asked friendly for help, was not complaining and he finally succeded.
But you?..
Obviously it takes just a tiny effort to find the files Joe has specified or to search independently.
Thanks Joe! Great job!
-
The bowel yes. The peristalsis invoked by your utterings was cathartic and I'm 1.1Kg lighter (2.4lb in dumbass units). Thank you indeed.
Glad I could help.
I would refer you to my partner, a rather prominent psychologist, academic and doctor on why you are wrong. However I just dumped her, partly because the academic rigour in her sector is near zero and most of what they come out with is reasonable sounding ideas that they desperately try and fit data and conclusions to to validate their existence. Quite frankly that doesn't sit well with me as it's intellectually dishonest. So coming out with any popular psychology, which is built on the pillars of this excrement, is not a viable point to argue from.
Interesting you will tolerate the "pilars of excrement" that Joe slathers around in, in fact, you attempt to validate it by defending him with a sort of man on man love fest vigor, I heretofore had not witnessed in this forum, yet you have zero tolerance for someone like me who is simply calling a spade a spade.
All a ham license does for the majority of the holders is give them some perverted sense of value in a society that rejected them because they are rejectable. Some proudly walk around with a name badge and call sign on showing their importance, some dress up as close to police officers as they can and end up directing traffic at a car boot sale and some decorate their gardens with monstrous towers and fuck up the CATV / Internet for 2 miles in each direction. They only do this because the real world rejected their fantasies of power and control because they had that much of a personality disorder that it's the only bit of society that would accept them. And why would they not accept them...
Perhaps for some, but for others, it is a pre-requisite to be able to communicate on small slices of particular RF bands, to help those in need, or crisis, outside of the normal local and federal emergency relief sphere. It's too bad that you were unable to embrace that part of the "hobby"... Perhaps there were not enough hero worshipers to keep your inflated ego satiated in the obviously weird circle of HAM licensees you chose to ooze around in? It's a big world out there. Had you taken off your blinders, or perhaps engaged your cranial peristalsis in an attempt to evacuate the anger and discontent from your vacuous brain, you might have met some of us....Who knows either way because you have obviously moved on to browner pastures.
On top of that it's a kick in the teeth because I did actually build my own receiver, transmitter and gear from scratch! (oh and a K2). All I get is people whining I'm 25Hz off frequency. I'm literally sending you this signal on a transmitter made of 11 parts I put together myself. You're sitting there on your fat stinky ass in front of several thousand dollars of Elecraft K-line stuff that you don't actually know how it works pissing on everyone. Yeah nice job.
So that's why I dislike the whole ham thing. And I think it's justified. I was attending hamfests until recently just to rip off their shit and sell it on ebay and make loads of money but I can't be bothered with that now any more either because I might catch something itchy off them.
Nah, I think you just dislike anyone not exactly like you. If someone has interests or takes positions not in line with your own narrow view of the world, you belittle and denigrate them. You and Joe sound like two peas in a pod, hence the man on man reference I eluded to earlier. Do you guys do that weird Zoom meeting thing where you are naked from the waste down, while talking in stereo to each other?
A while ago I published a design on here for a fully analoge scope excercising unit which bounces a little ball on the screen in X-Y mode. This was a fairly simple quadrature oscillator and a couple of triangle oscillators and two summing amplifiers. Someone built it and got pissy in DMs that it didn't work. I don't care! Fix it yourself.
Thank you for validating all of my previous points in this post. After all, it would not be complete without the requisite "I developed the flux capacitor that took Marty McFly to the moon" holier than thou chest thumping on your part. Again, two peas in a pod.... Brilliant.
Perhaps the problem is with your demeanour, not the recipient. I mean you're doing a lot to ruin your own credibility in that statement. I mean you have switched to "pee all over the furniture" because no one fed you. It'll be humping the cushions next.
Not quite, I mentioned it before, but since you probably flushed your brain cell when you did the whole peristalsis routine, I will say it again so you can keep up: I am just calling a spade a spade.
-
A direct search on Google for "install solver64" returns (somewhere on 6th place) a thread from NanoVNA-V2@Groups.io
https://groups.io/g/NanoVNA-V2/topic/89931588 (https://groups.io/g/NanoVNA-V2/topic/89931588)
Yeah not sure if you are stoned, or just another boot licker like bd139? That thread references files that were (past tense) found on github. Once it was disclosed that the requisite fiiles were now on dropbox, along with a readme that stated that very specific files were required, and that Joes github had evaporated, that thread seemed like a dead end.
Also, if you had bothered to read my first post, I did ask nicely, here, just like ol Albert did....there.
-
All a ham license does for the majority of the holders is give them some perverted sense of value in a society that rejected them because they are rejectable. Some proudly walk around with a name badge and call sign on showing their importance, some dress up as close to police officers as they can and end up directing traffic at a car boot sale and some decorate their gardens with monstrous towers and fuck up the CATV / Internet for 2 miles in each direction. They only do this because the real world rejected their fantasies of power and control because they had that much of a personality disorder that it's the only bit of society that would accept them. And why would they not accept them...
Hey bd139 - nice to see you back for a spin. :-DD
-
On top of that it's a kick in the teeth because I did actually build my own receiver, transmitter and gear from scratch! (oh and a K2). All I get is people whining I'm 25Hz off frequency. I'm literally sending you this signal on a transmitter made of 11 parts I put together myself. You're sitting there on your fat stinky ass in front of several thousand dollars of Elecraft K-line stuff that you don't actually know how it works pissing on everyone. Yeah nice job.
So that's why I dislike the whole ham thing. And I think it's justified. I was attending hamfests until recently just to rip off their shit and sell it on ebay and make loads of money but I can't be bothered with that now any more either because I might catch something itchy off them.
Nah, I think you just dislike anyone not exactly like you. If someone has interests or takes positions not in line with your own narrow view of the world, you belittle and denigrate them. You and Joe sound like two peas in a pod, hence the man on man reference I eluded to earlier. Do you guys do that weird Zoom meeting thing where you are naked from the waste down, while talking in stereo to each other?
The word that eluded you there is "alluded".
-
Interesting you will tolerate the "pilars of excrement" that Joe slathers around in, in fact, you attempt to validate it by defending him with a sort of man on man love fest vigor, I heretofore had not witnessed in this forum, yet you have zero tolerance for someone like me who is simply calling a spade a spade.
I'm not defending Joe at all. I'm merely stating that the spade is the spade and you have to get used to it and work around the spade. What is not ok is coming in and telling everyone that the spade needs to be a pitchfork. Everyone of course knows the moment it's a pitchfork it's going to get rammed up their own ass. Because it's the cycle of "nothing is ever good enough".
Perhaps for some, but for others, it is a pre-requisite to be able to communicate on small slices of particular RF bands, to help those in need, or crisis, outside of the normal local and federal emergency relief sphere. It's too bad that you were unable to embrace that part of the "hobby"... Perhaps there were not enough hero worshipers to keep your inflated ego satiated in the obviously weird circle of HAM licensees you chose to ooze around in? It's a big world out there. Had you taken off your blinders, or perhaps engaged your cranial peristalsis in an attempt to evacuate the anger and discontent from your vacuous brain, you might have met some of us....Who knows either way because you have obviously moved on to browner pastures.
Notably I was not unable but I was unwilling to participate in that part of the hobby because it's a US specific thing and not what everyone else does on the planet. Also the people involved in it, who I will get to later, are quite stupid. I mean as far as the US goes I can't help that you live in a third world country as far as emergency response is concerned but we have pretty damn good 4G coverage everywhere here and for everything else we have satellite based InReach and Emergency SOS as well. And there's actually people on the end of it who will respond unlike your government apparently. In fact in the UK, we have an equivalent thing to ARES called RAYNET. They have the same mentality and the drills as the US lot but the emergency services do not need or want them to be around. So they sit around perpetually waiting for doomsday looking for anywhere they can help out with radios. This turns out to be really important things such as: taking payments for car boot sales, handing out water at cycle races and sitting around eating burgers and generally being fat asses. Recently they were fired from directing traffic at hamfests due to incompetence and were replaced with the local Army cadets who have somewhat higher level of competence and order. As they're all retired or unable to function in society as it stands they don't have a lot of money either so the result is usually some lurid decoration of a caravan, as depicted below. Occasionally if they get a bit of money a camper will be decorated in full police livery with RAYNET spooged all over the side, to the eternal embarrassment of the incumbent partner who is eternally waiting for someone to whisk her away from this weirdo she regrets marrying.
(https://i.imgur.com/jqFtovK.jpg)
Referring to my point about dressing up as police officers, here's another one. Clearly the police wouldn't let him in, which is amazing because they're mostly morons here, or he was scared of actual emergencies in some way and wanted to look pretty but not do anything useful.
(https://i.imgur.com/QYB54pG.jpg)
I can see him driving around in his 20 year old Discovery making NEE NAW NEE NAW noises.
As you can imagine I don't want anything to do with them. I also question the legitimacy of civilian responders when it comes to actual emergencies because it's near impossible to train, validate and moderate responders in any meaningful normalised way unless there are professional standards involved and in the US that is certainly not the case. In fact a lot of the time, and I know this after reading a few horror stories over the years, that a lot of time the ham community gets in the way of actual real responders. Ah hell lets throw a meme in:
(https://i.imgur.com/68bFV7p.jpg)
Anyway back to the point about the rest of the planet, so true story. I'm in the middle of the Terme Pass in Kyrgyzstan earlier this year, somewhere that the average COPD crippled operator wouldn't be able to get near without needing an emergency response even at ground level, and someone in the group lost their footing and injured their back. We're at 12,000ft. Put your money where your mouth is, and don't avoid any further point where you need to be accountable for your perspective like the first few comments and tell me what you'd do in this situation. Here's about 5 minutes before it happened.
(https://i.imgur.com/WxJZ9fp.jpg)
Location is: https://www.openstreetmap.org/?mlat=41.70705199241638&mlon=75.27044534683228#map=15/41.7080/75.2706 (https://www.openstreetmap.org/?mlat=41.70705199241638&mlon=75.27044534683228#map=15/41.7080/75.2706)
That is all the mapping data there is.
Nah, I think you just dislike anyone not exactly like you. If someone has interests or takes positions not in line with your own narrow view of the world, you belittle and denigrate them. You and Joe sound like two peas in a pod, hence the man on man reference I eluded to earlier. Do you guys do that weird Zoom meeting thing where you are naked from the waste down, while talking in stereo to each other?
Oh I get on with most people absolutely fine and dislike virtually no one. In fact the list is pretty much limited to pedophiles, scientologists and hams. Some people have even met me on here in real life and don't seem that offended by me! Anyway which narrow view of the world is this?
As for the zoom meetings I do not use my camera, because a lot of the time I don't have a top on either. Sometimes I haven't even got out of bed when I go on a zoom call and I sleep in my birthday suit. Sometimes I'm having a shit. I mean I get paid to sit on zoom calls all day so I might as well do it from the comfort of where I choose wearing what I choose or choose not to.
Thank you for validating all of my previous points in this post. After all, it would not be complete without the requisite "I developed the flux capacitor that took Marty McFly to the moon" holier than thou chest thumping on your part. Again, two peas in a pod.... Brilliant.
I don't think you've got the point yet. I will write it in simpler terms: no warranty expressed or implied. In more complicated terms, all open source licenses, which are generally a lot less generous than Joe and myself are on these matters as we are willing to help people (check all our threads). Here's the BSD license for example:
THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
In simpler terms, you're on your own, possibly backed up with some help if you're lucky.
Not quite, I mentioned it before, but since you probably flushed your brain cell when you did the whole peristalsis routine, I will say it again so you can keep up: I am just calling a spade a spade.
Did you get your biology textbook from Texas?
-
I don't think you've got the point yet. I will write it in simpler terms: no warranty expressed or implied. In more complicated terms, all open source licenses, which are generally a lot less generous than Joe and myself are on these matters as we are willing to help people (check all our threads).
Our friend's view on help differs from my own. They expect help to be in the form of simple spoon fed answers. Similar to how you get your ham license. I see more value in requiring people who ask for help to actually use their brain to solve their own problems. This isn't something normally required of hams and many get upset when you start asking them to think. I suspect many view their license as some sort of college degree or continued education in engineering. Asking them anything technical brings that into question. Look at what triggered them:
And if you search NI's site for the error you posted, what does it tell you?
Code Description −1073807202 VISA or a code library required by VISA could not be located or loaded.
And notice how we have seen this before in your earlier post. What do you think this means?
Once they realized I wasn't going to pamper them like they are apparently accustomed to, they threw a tantrum. Most professionals I expect would have read that error code and realized where they fucked up. Especially in the case of our friend who pointed out they had been unable to locate the correct files and assumed....
While I did make a screen capture on how to download the files after Veteran68's post, what I stated about it being wasted time on our friend appears true. Getting the software running is simple. I seriously doubt they will learning to use it with no technical skills beyond what was required to obtain a license.
-
If they think a ham ticket is an engineering qualification then they're misguided. It's a retard filter and not a very good one! :-DD
100% agree on all your points.
-
Not too surprised our friend has gone silent. Assuming they were were able to install the correct files and have the software running, I doubt our friend will own their behavior and ask more detailed questions on how to run it with the same username.
Hello, my name is Billy Jim Bob, Extra Class. I'm new to this software and need help. Wait for it. :-DD
-
Not too surprised our friend has gone silent. Assuming they were were able to install the correct files and have the software running, I doubt our friend will own their behavior and ask more detailed questions on how to run it with the same username.
Hello, my name is Billy Jim Bob, Extra Class. I'm new to this software and need help. Wait for it. :-DD
Have you considered a pay-for support offering? You could make a killing. :-DD
-
Not too surprised our friend has gone silent. Assuming they were were able to install the correct files and have the software running, I doubt our friend will own their behavior and ask more detailed questions on how to run it with the same username.
Hello, my name is Billy Jim Bob, Extra Class. I'm new to this software and need help. Wait for it. :-DD
Have you considered a pay-for support offering? You could make a killing. :-DD
I would have to charge enough to avoid having to deal with the hams and their "I can't locate the files" stupidity. So what's that, 50 cents an hour?? :-DD :-DD
I don't mind donating my time to help the future generation of engineers. As long as I am able, the plan is to keep the software free and take no advertising or Patreon donations for the channel. Believe me, using this business model doesn't attract a lot of investors. :-DD
-
You could get a premium rate line for Hams. Make them feel special. And just keep them on hold.
-
Hopefully he remains silent. He was not contributing any value to the thread, other than a bit of humor which was really thanks to bd139.
-
You could get a premium rate line for Hams. Make them feel special. And just keep them on hold.
It's funny. I've been reading various books and papers written by people who were amateur radio operators. Many of them had higher level degrees. Most PHD level. Most of these papers have been from the 1960s and earlier. When I was a youth, I knew two hams that built all sorts of radios. Guessing that over time the FCC has changed the requirements for their No ham left behind agenda which has reduced the overall skill level.
I still run across hams who have an interest and the skills to construct, and in some cases design, their own equipment and radios. I'm not talking code oscillators and stringing up dipoles. I call these hams the 1%ers because they are so rare. This small group is worth helping.
The problem is sorting them out. Then again, if your first question is "I can't find the correct files so I grabbed what I felt would work and now I can't understand why your shitty software doesn't work", I think we have our answer. As our friend suggests, this thread is loaded with them and if I choose to try and help, I always try to lead them to solving their own problems. Seldom works.
-
Hopefully he remains silent. He was not contributing any value to the thread, other than a bit of humor which was really thanks to bd139.
It's possible someone reported them and they had a warning from the admins. I've been there more than once and have had my timeout. I've never felt the need to report anyone myself. Certainly not our friend here. Their only value is to serve as a constant reminder of what being a ham is about.
-
You could get a premium rate line for Hams. Make them feel special. And just keep them on hold.
It's funny. I've been reading various books and papers written by people who were amateur radio operators. Many of them had higher level degrees. Most PHD level. Most of these papers have been from the 1960s and earlier. When I was a youth, I knew two hams that built all sorts of radios. Guessing that over time the FCC has changed the requirements for their No ham left behind agenda which has reduced the overall skill level.
I still run across hams who have an interest and the skills to construct, and in some cases design, their own equipment and radios. I'm not talking code oscillators and stringing up dipoles. I call these hams the 1%ers because they are so rare. This small group is worth helping.
Agree. Yes things have certainly changed over the years. It's sad. Some of the best RF books out there are written by hams as well. In fact one of my favourite books is W7ZOI's Experimental Methods in RF design, which I think taught me more about small signal BJT models than any university textbook did. But really I think this is really the relentless march of technology and the economic situation. The barriers to entry are now low. Buy a 2m HT or HF set, throw a pre-made antenna up in a tree. You can buy all of these on credit or a reasonable amount of money now. You don't need to really understand how they work and there is no financial pressure to trade buying something for creating something from trash. Some of this is the inherent complexity in some of the manufacturing of these radios which turns it into the opaque black box that does magic like a smartphone and some of it is actual intellectual disinterest in the matter. The latter is a big problem in society I find. It has become fashionable to say you're stupid at math and science rather than embarrassing so there isn't the foundation on which to build higher concepts.
When you normalise stupid, you get people who can't navigate simple problems. And rather than self-education, they expect to be spoon fed. Until recently I had the same problem with a couple of hundred outsourcers who couldn't rationalise even what the description of a problem was before attempting to solve it! :palm:. The same people wonder why they stumble through life from fungible position to fungible position and never meet their personal goals. This leads to lots of hand waving about unfairness but in reality they don't care enough about their own capabilities to improve them.
The problem is sorting them out. Then again, if your first question is "I can't find the correct files so I grabbed what I felt would work and now I can't understand why your shitty software doesn't work", I think we have our answer. As our friend suggests, this thread is loaded with them and if I choose to try and help, I always try to lead them to solving their own problems. Seldom works.
Yeah that.
On that note I'm about to log into work and will see 100 people on Slack saying "X doesn't work" with no thought past the statement that it doesn't work. We're shutting the support channels down next week so they have to raise a ticket with a stupid question in it so we can close it with "stupid question" and get some metrics on it :-DD
-
I had this video running in the background. It's some ham training on the NanoVNA. There were a couple of times I perked up. It was held on-line and the old timers did not understand the software. So they have their microphones on and the guy giving the talk has to keep pausing because of the viewers phones ringing, feedback.... The best parts are when he asked them a question and you could hear a pin drop. You could tell the old hams were totally lost. Guessing they viewed it as a social event. For example, the link is a question on resonance. My jaw dropped.
https://youtu.be/UlXgZpgE6qk?t=2667
Of course these same people are the ones who use "mhz", can't find files, don't know if there are two states and it's not true what it is?.....
I agree with your comment about the normalizing stupid. On a large scale, I'm sure it's easier to heard sheep. I mean, if you can't train a dog, maybe you shouldn't be expected to lead humans.
For hams, it seems I mostly interact with older people who maybe made it to extra class and that is the height of their technical education. Maybe there is no motive to learn anything beyond their Q&A booklet as they already reached the top. In their small world, they are the kings. The lower classes in their circle look up to them. Now you have a case of self importance. All is fine until they come outside to play.. They can't argue at any technical level so they have to go with something they know. Maybe run a grammar or spell checker :-DD :-DD
-
Also, back on topic, I fucked up the S-parameter import to address that bug I saw in Fred's QT data. Worse, it fucked up even good files. Pisses me off to have to add workarounds for QT's export. I have it fixed and expect to upload an update soon.
-
I had this video running in the background. It's some ham training on the NanoVNA. There were a couple of times I perked up. It was held on-line and the old timers did not understand the software. So they have their microphones on and the guy giving the talk has to keep pausing because of the viewers phones ringing, feedback.... The best parts are when he asked them a question and you could hear a pin drop. You could tell the old hams were totally lost. Guessing they viewed it as a social event. For example, the link is a question on resonance. My jaw dropped.
https://youtu.be/UlXgZpgE6qk?t=2667
Of course these same people are the ones who use "mhz", can't find files, don't know if there are two states and it's not true what it is?.....
I agree with your comment about the normalizing stupid. On a large scale, I'm sure it's easier to heard sheep. I mean, if you can't train a dog, maybe you shouldn't be expected to lead humans.
For hams, it seems I mostly interact with older people who maybe made it to extra class and that is the height of their technical education. Maybe there is no motive to learn anything beyond their Q&A booklet as they already reached the top. In their small world, they are the kings. The lower classes in their circle look up to them. Now you have a case of self importance. All is fine until they come outside to play.. They can't argue at any technical level so they have to go with something they know. Maybe run a grammar or spell checker :-DD :-DD
The silence in that video is hilarious :-DD.
That last comment reminds me of the local radio club I decided to go to just once. There was a technical elite in there. Well he thought he was. The only thing that made him elite was the fact that the rest of the club was thick as dog shit. So on the first time I go there he's "repairing" this poor guy's Kenwood TS-2000's LPFs. Of course one of the LPF toroids (on 80m as it always is) was smoked by a poor mismatch and the operation principle of "yeah high SWR - just turn the power up some to get more signal out". So he's got the LPF board out and is going at it with Jesus' soldering iron. Something from the 1950s by the looks. Was about a foot and a half long. In the process of getting the toroid out he managed to not only tear the damn pads off the board but one of the traces and leave a charred crater. This was patched up by soldering a bodge wire to the board afterwards. The toroid was rewound with far too thin wire as well, badly (I am a bitch for getting toroids right). I nearly died inside. Much applause from the assembled idiots. The owner was happy and I'm sure he got it home and smoked it instantly, if it even worked. So after this spectacular display of incompetence, when asked for some feedback for his ego, I gave him a critical assessment. As a mere foundation class operator (newbie scum) I was railed almost instantly by his ego in a tirade in front of the other people. I felt it was best at that time to let them all burn so I kept my qualifications and experience on the matter quiet and let him go on. Can't argue with stupid people. But I learned how the hierarchy worked and a lot about hams and clubs. Needless to say I didn't bother going back again.
Can remember his callsign. G-something Ron. Wore an RSGB name badge like it actually means something. Body odour problem.
-
I think Xrunner posted a similar story about a ham "repairing" a radio. Too bad you didn't video record your interaction with the local king. It would have made for a good YT video.
I think the problem in that video was the presenter talked about the material being at a 12th grade level. He said he was a professor, so I'm sure he was aware of the no ham left behind. He needs to dumb it down even further. It's a complex topic so I'm not sure how he's going to pull it off, but looks like he is trying his best to help educate the masses. Interesting as he talked about recently learning the basics himself. Rare you run into hams like this.
-
Yeah. I think xrunner had to bug bomb one as well :-DD
The hams like that also tend to either grow really long beards, use CW only on QRP calling frequencies and whine about competitions (lowest asshat density) or just leave the hobby entirely.
-
Yeah. I think xrunner had to bug bomb one as well :-DD
The hams like that also tend to either grow really long beards, use CW only on QRP calling frequencies and whine about competitions (lowest asshat density) or just leave the hobby entirely.
Ah yes! Fond memories ... not. Yea that was a Yaesu FT-757 HF transceiver. Was delivered for me to check out. Sat it on the bench and took a nap. When I got up I opened the cover ... to see a movement inside. Because of my deep technical expertise I realized radio parts aren't supposed to move on their own.
Quickly ran with it outside and there were live cockroaches inside. Had to bug-bomb it before proceeding. The ham got a Royal chewing-out from me later (over the phone).
Here's another one I haven't shown before, again brought to me by a local HAM several years ago. He bought it at a local HAM-fest. A JRC NRD-515 shortwave receiver. These are really nice receivers. If it would have been in good condition I'd have probably tried to buy it from him. Alas it was in absolutely terrible condition. Looked like it had been used in a jeep in Afghanistan by the local Taliban. The cover was just bent to all living f*ck. Whole thing just beat to shit. Some of the knobs just about couldn't be turned. Main thing was the audio sounded tinny and as crappy as could be. Just a really sad thing to see.
I eventually found that a main IF filter was just simply gone, and a wire had been soldered in place to bypass the missing filter. It wasn't a filter for CW, SSB, or AM bandwidth. It was in another part of the IF chain.
The filter was a JRC part - unobtainium now, and I told the ham all this. "Sorry bro - you lost this bet!" He sadly took it home ... probably to be passed on as quickly as possible to the next unsuspecting schmuck at another HAM-fest.
-
Didn't you also have a ham working on a club radio with a Jesus iron that messed up the board?
*************************************
Solver64, 4.02 is live. I added the Google search, cut and paste instructions so we don't leave any more hams behind that can't locate the correct files.
*************************************
For those outside of the USA, in regards to my sheeple / dog and leadership comment. My new lab partner came to us a three YO. PO must have really been a piece of work. Guessing I did more training with her in the first few weeks than this poor dog in the video has had it whole life. Sad is they gave up the other one, just like what happened with my new partner we found sitting in a kill shelter. If you can't train and take care of them, don't get one.
https://www.youtube.com/watch?v=kypoL0xbrF0 (https://www.youtube.com/watch?v=kypoL0xbrF0)
-
Didn't you also have a ham working on a club radio with a Jesus iron that messed up the board?
Hmmm ... I don't recall that at the moment. Not to say it didn't happen, there's just been so many incidents. :palm:
I doubt I'll be seeing too many more repairs. The HAM that moved to Alaska was sort of a facilitator in these cases. He was on the radio all the time and sort of steered people with repair needs to me. He did ask me first though. He would even bring me their radio and pick it up.
There's still a few that have my number, but they're mostly harmless. Most of the ones that would end up needing a repair can't call me, and I rarely get on the air anymore. Now I can concentrate on my own projects. :)
-
May have been BD139. Doing a search gave me a link to a large ham thread were you both were talking about repairs.
https://www.eevblog.com/forum/rf-microwave/how-alive-is-ham-these-days/msg3078764/#msg3078764 (https://www.eevblog.com/forum/rf-microwave/how-alive-is-ham-these-days/msg3078764/#msg3078764)
Here is his kit built radio. Reminds me of the old Heathkits.
https://www.eevblog.com/forum/other-blog-specific/ham-radio-is-it-dead-in-2019/msg2700968/#msg2700968 (https://www.eevblog.com/forum/other-blog-specific/ham-radio-is-it-dead-in-2019/msg2700968/#msg2700968)
Another fun thread. :-DD
https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg4367434/#msg4367434 (https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg4367434/#msg4367434)
-
May have been BD139. Doing a search gave me a link to a large ham thread were you both were talking about repairs.
https://www.eevblog.com/forum/rf-microwave/how-alive-is-ham-these-days/msg3078764/#msg3078764 (https://www.eevblog.com/forum/rf-microwave/how-alive-is-ham-these-days/msg3078764/#msg3078764)
Here is his kit built radio. Reminds me of the old Heathkits.
https://www.eevblog.com/forum/other-blog-specific/ham-radio-is-it-dead-in-2019/msg2700968/#msg2700968 (https://www.eevblog.com/forum/other-blog-specific/ham-radio-is-it-dead-in-2019/msg2700968/#msg2700968)
Another fun thread. :-DD
https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg4367434/#msg4367434 (https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg4367434/#msg4367434)
FTDX3000 not TS2000. Got ham radio amnesia. Good find!
Oh and don't get me started about that Elecraft K2 and hams. Was great fun building that and it was indeed "the last proper Heathkit experience" you can get. But they sent out duff J310 JFETs. This turned into a fairly heated debate. They sent out some replacement parts from the US immediately but after looking at the circuit I figured I wasn't going to wait the two weeks. Dug around in the junk box, found some J309's, did some measurements and thinking, a lost art, and just shoved those in. Works fine, bias was as predicted in LTspice. Posted this on their mailing list and it turned into a small argument over it absolutely not possible that it was working. It was measurably working. But clearly that was impossible. The person in question, ugh.
Finished board. Still happy with that :-DD
(https://i.imgur.com/s1XSYKx.jpg)
-
Another fun thread. :-DD
https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg4367434/#msg4367434 (https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg4367434/#msg4367434)
Putting together an Elecraft kit radio? Never heard of any local HAMs doing anything even close to that complexity. Again, I'm not saying a few where I live couldn't, or that any local HAM hasn't ever done it, but I've never heard of it where I listen. And if they had done it, they would have bragged about it. I've never heard of any local HAM putting together any sort of kit electronics - ZERO - in the 14 years since I got back into it. Even one LED and a resistor. Maybe I'm around the wrong group of HAMs, but most just do not do these things here.
They buy things already supposed to work together and hook them up. Such as PWR supply - radio - SWR meter - antenna. I've tried to get a few bored HAMs (retired) to use something like an Arduino to make a project. Like one time a guy wanted to thermostatically control a fan he had pointed at a PWR supply. I said why don't you learn the Arduino and do that project, then you will be empowered to do a lot more things on your own. I'll help you! Nope. Wouldn't have any of it.
I'm not a psychologist, but it's almost like they don't want to do anything that could result in failure. They don't want to be seen as not being able to do something or figure it out. So, they just don't do it. They don't like to talk about any sort of technical topic that they don't know already, because then the other person would seem to be smarter than they were (at least on that topic).
Of course politics and religion they talk about, because there is no "failure" involved. It's just opinions on subjective topics. But once the microphone is in their hand, they will let the opinions fly.
Of course they will fail at simply hooking up HAM gear, but they're willing to risk that or they couldn't talk to other people on the radio, but that's as far as it goes.
-
Same situation here.
Oh yeah our local 2m net which appeared to switch between growing strawberries, bitching about your wife and being offended that a black person walked past :palm:
-
I'm not a psychologist, but it's almost like they don't want to do anything that could result in failure. They don't want to be seen as not being able to do something or figure it out. So, they just don't do it. They don't like to talk about any sort of technical topic that they don't know already, because then the other person would seem to be smarter than they were (at least on that topic).
Of course politics and religion they talk about, because there is no "failure" involved. It's just opinions on subjective topics. But once the microphone is in their hand, they will let the opinions fly.
Of course they will fail at simply hooking up HAM gear, but they're willing to risk that or they couldn't talk to other people on the radio, but that's as far as it goes.
If they fail plugging things in, it's behind closed doors, not in front of their peers.
It's too bad OWO censors their groups.io reflector. I would have liked to have had an open discussion with Tom W8JI, about his thoughts on transient protection. He certainly had an opinion on the subject but once others started to point out where he was wrong, he went silent. I suspect much for the reasons you mention. Or, it's because OWO would pull my posts not allowing a dialog to take place.
https://nanorfe.com/forum/ESD-safer-circuit.html
-
Sound like an unhealthy community although I certainly understand the approach.
As for transient protection, isn't it just an SA612 on the front end? Just stick another one in :-DD
-
The LiteVNA has TVSs on both ports. Not sure that would save you when you transmit into one of the ports. Never gets old. :-DD
https://www.youtube.com/watch?v=tCHAa-sjgcQ&t=535s (https://www.youtube.com/watch?v=tCHAa-sjgcQ&t=535s)
-
Not sure I can face watching that after watching a YT the video of a smoked front end on a Rigol DSA815TG :-DD
Nice to hear if someone actually giving a crap about robust engineering at least.
-
Not sure I can face watching that after watching a YT the video of a smoked front end on a Rigol DSA815TG :-DD
Oh I have one of those, that would make a grown man cry. You know they really should print the Max Power Input right there by the input connector so these things don't happen.
Oh wait - it is there!
MAX +20 dBm
:-DD
-
Bold of you to assume that someone both read and understood that! :-DD
Through safety squints: “Hey Bob it says 20 something. Must be watts”. CEEEEE CUUEEE CEEEEE CUUEEE. Sniff sniff. Hmm burning.
-
To be fair, even a 5W CB could have damaged it.... but we know it was a ham! :-DD
-
Bold of you to assume that someone both read and understood that! :-DD
Through safety squints: “Hey Bob it says 20 something. Must be watts”. CEEEEE CUUEEE CEEEEE CUUEEE. Sniff sniff. Hmm burning.
HAMs I talk to can't relate to "dBm". Like on the Spec-An +20 dBm is the Max power input - they wouldn't know what that is.
They generally know that a cable loss or attenuation of 3 dB is 1/2 power loss, and 10 dB increase in power is ten times more. But they don't do dBm at all. Haven't a clue.
So I'll say so-and-so's transmitter was supposed to output +50 dBm and I found it was only +47 dBm - they don't understand that. They ask me "why do you say dBm instead of watts? I just say "Because that's how I was taught." :)
-
That'll be because dB is a relative logarithmic measurement and they understand neither what logarithmic or relative measurements are! Add the poor understanding of SI prefixes and even the reference point in dBm is unlikely to be understood.
There must be a way of making some easy money out of that though. Perhaps create a knowledge cult of dBm and then sell a conversion device that turns a smaller number into a bigger one somehow :-DD
-
Still, we have the internet and there are several conversion calculators available to the ham.... Oh right as our new friend reminded us, they have trouble navigating the internet. :-DD
Maybe just remember that 20dBm is 100mW which was the amount of power from their childhood walkie talkies. Have any better ideas on how to remember it, keeping in mind, they need to remember it longer than what it takes to pass a test?
-
I'll have you know my childhood walkie talkies could kick out a bit more than that (Midland shit + completely illegal Italian CB widowmaker tube amp) :-DD
But yeah no looky no findy. Monkey expect spoon fed. I'm sounding like grugbrain now https://grugbrain.dev/
-
I'm an extra class ham. I ran into several roadblocks trying to get Solver64 installed and working.
Did I whine and moan? No. I dug, and dug, and dug until I found the information I needed to get the job done. In the end, I not only got Solver64 working on my own, but I gained a lot of valuable knowledge that will serve me going forward.
It's a shame that so many of my fellow hams have no desire to tackle an issue and work it to resolution. Needing help is fine, but you need to do your due diligence before asking for help, and you need to be humble in your requests.
-
Outside of learning how to install it, what have you used the software for?
-
I'm currently using it to help me tune various long wire antennas as well as testing filters.
-
Assuming you are using the 4.x rather than 3.00, let me know if you find any problems with it. 4.02 should be fine.
Sounds like you are mostly playing around below 300MHz. What drove you to buy the V2Plus or LiteVNA? IMO, the original NanoVNA would have been a better choice.
-
I am using 4.02. I chose the LiteVNA because I plan to start setting up some microwave links in the Arizona - New Mexico area in the next year or so.
-
If you start a blog post a link here. I'm interested in reading more about it.
-
I will certainly do that.
-
I just got mine… the H version.
Has anyone written anything completely different for the device itself?
I previously had the Mini600, which was based on STM Discovery board,
and I did a plasma demo intro for it just for a bit of fun.
I haven’t looked into this one much. Are there any dramas compiling its source?
-
I just got mine… the H version.
Has anyone written anything completely different for the device itself?
...
The thread is more about software that interfaces with the VNA, not firmware that runs on the VNA. I suggest you join the group.io reflector for the NanoVNA and ask there. Another group you may want to consider is for the firmware developers and beta testers. Feel free to post here but I doubt you will get too many responses.
-
4.03 is now live. This version will allow the LiteVNA to work with waveguides without requiring the frequency extender. Obviously the Lite's performance isn't currently good enough to use for the X-band today, possibly in the future we will see an improved product.
When using the time domain functions with Touchstone imported files, some features were disabled. These have all been enabled. I don't normally import files, so this was more an oversight than anything. Discovered when cat'ing files to measure some of those 1930s UHF connectors.
https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg5100693/#msg5100693 (https://www.eevblog.com/forum/rf-microwave/cb-and-ham-radio-techs-love-their-bird-wattmeters/msg5100693/#msg5100693)
-
Hey Joe,
I've started using my VNA V2 Pro in measuring a hybrid coupler I am making. I noticed that the VNA is affecting the behavior of the hybrid, which is quite sensitive to impedance differences on its ports. Basically the problem is that the input impedance of the NanoVNA V2 is about 53.5 ohms as self reported by the device when a thru is connected between the cables after calibration.
I tried searching for some posts about this on other sites and the explanation I found was that the nanovna has a frequency dependent return loss on port 2. The suggested solution was to add an attenuator to port 2 to force the return loss higher and stabilize the port 2 input impedance. This issue was said to be due to a lack of 12 term correction in the firmware/software. So, I was wondering what you had to say about the issue and if the LiteVNA suffers from the same problem.
-
Hello Fred,
All the software/firmware/calibration in the world isn't going to fix a hardware problem. If your device is sensitive to the mismatch, about the only thing you could do to improve it is use an attenuator as suggested and give up some dynamic range. The other option, throw money at it.
What frequency range are you interested in working in. I can take a measurement with the LiteVNA 64 I am currently using. It is the latest revision of the hardware and has no modifications done to it.
-
Rather than the sensitivity of my hybrid to the impedances presented to its ports, it's the VNA's self reported port 2 input impedance of 53.5 ohms that's my concern. That's 7% from nominal. I would like the port 2 input impedance to be within a tenth or two of 50 ohms. People have also mentioned maybe the cables or even the thru are contributing to that, although I have yet to read about anybody claiming that the cables or thru that come with the nano VNA to be anything other than 50 Ohms.
I'm presently dealing with VHF centered around 146 MHz.
-
Rather than the sensitivity of my hybrid to the impedances presented to its ports, it's the VNA's self reported port 2 input impedance of 53.5 ohms that's my concern. That's 7% from nominal. I would like the port 2 input impedance to be within a tenth or two of 50 ohms. People have also mentioned maybe the cables or even the thru are contributing to that, although I have yet to read about anybody claiming that the cables or thru that come with the nano VNA to be anything other than 50 Ohms.
I'm presently dealing with VHF centered around 146 MHz.
You have a standard you use for a load. Guessing a bit of an unknown. Then you have a port match which I am guessing is also a bit of an unknown. I say guessing as I assume if you had access to better equipment and standards, you would have already narrowed down the source of errors. Consider if they are each 5%, and both swing to the worse case your measurement is better than that.
Consider that the load is what you cal to. You are telling the VNA, that is 50 ohms at 146 MHz. Let's say that the part is really 25 ohms. The VNA will measure that as 50. And if your port is now 25, it will also display 50. Then there is the problem that you can't just measure the load with your DMM and expect to get anything meaningful.
All that said, I use a load that I had sorted from Mini-Circuits for my standard. I bought several of them and compared them with a set of metrology grade standards. I picked the best two, the second best being what I use with these low cost VNAs. I use the cheap supplied standards for the short and open. Next, I use the ideal model which assumes there are no parasitics and the standards are perfect. I know the VNA will require some warmup time but lets ignore that. Obviously, the errors are adding up already and I haven't even started.
Next, I calibrate the LiteVNA from 140-150MHz using the above standards. I did not torque anything. Looking at "Loads.jpg", I then measured the original supplied load (yellow), my home made load made up of 2X1206 resistors on FR4 (red), and finally reattached my Mini-Circuits load. It's off by ab out 0.6%.
Just as an FYI, I did measure the DCR of the Mini-Circuits at 50.042 ohms and supplied load at 51.029 ohms. I'm a bit surprised to see them read about 1 ohm difference at 145MHz.
Next, using the supplied cables, I measure port 2 "Port2.jpg". It measures roughly 51.5 ohms or about 2.6%. Now, think about it. Had I used the supplied load as my reference standard rather than the Mini-Circuits ANNE I sorted, the measurement would have been reported to be much tighter. You could fool yourself into thinking it was better but without knowing what these errors are, you are just guessing.
It's nothing that spending some cash couldn't solve. Or, if you have access to some better equipment and standards, you could start to sort things out.
This video had a lot of down votes, I am guessing from some very ignorant viewers. To me, it clearly demonstrates the direct effect of using a poor load for a standard.
https://www.youtube.com/watch?v=9HEchzY0Gvw (https://www.youtube.com/watch?v=9HEchzY0Gvw)
-
This video is quite entertaining but its content is questionable; it doesn't demonstrate how a slightly bad calibration kit affects the calibration.
In the video, the presenter uses open as short, short as open, and 2dB attenuator as load. These are quite extreme and unrealistic examples for representing the effects of a bad calibration kit. Not sure how the down-votes are visible, but this could be the reason.
-
This video is quite entertaining but its content is questionable; it doesn't demonstrate how a slightly bad calibration kit affects the calibration.
Maybe you don't know who Mr Kirkby is ? :-//
IMO it was a very clear example why trusted Cal standards are needed and experimentation with self made vs Cal standards can produce similar results.
In the video, the presenter uses open as short, short as open, and 2dB attenuator as load. These are quite extreme and unrealistic examples for representing the effects of a bad calibration kit.
Extreme they are but the results are as just expected.....absolute crap !
-
Well, I'm already kind of on that. I made a some loads just for the hybrid, because I bought some cheap 2 Watt supposedly 50 Ohm RF SMA resistors for the job and then found they varied by over ohm. So for the hybrid, I got some male pcb thu-hole SMA connectors and soldered a couple of 100 Ohm 0.01% resistors on them. I made three. One of them came out bad. I'll have to take it apart and redo it. The other two test within a tenth of a ohm of each other and vary in reactance by just a little bit as far as I can tell.
I have parts to make a female SMA calibration set the same way. I just have yet to get around to doing it. I also have s parameter touchstone files for them, although they are on my computer that has a damaged video card. So, I have to wait to get a new video card before I can get to them.
Here's some pics of the loads I made for the hybrid.
***
Come to think of it, maybe that's why the supplied load with your device is 51 Ohms.
Metrology is a wiley bugger. :)
-
Here's some pics of the loads I made for the hybrid.
:-+
Done exactly the same and they should be fine for LF stuff.
A buddy is right into VNA's and has some fine Cal standards that I checked my DIY's against then decided to splash out and get a half decent SMA set.
It's only money.......
-
My current project is in the VHF and UHF bands. I spent a good while simulating the loads before deciding to make them. They should do alright for this project. If I had money, I get a good machine and standards, although since I lack money such is pretty much unobtainium for the foreseeable future. :)
-
This video is quite entertaining but its content is questionable; it doesn't demonstrate how a slightly bad calibration kit affects the calibration.
In the video, the presenter uses open as short, short as open, and 2dB attenuator as load. These are quite extreme and unrealistic examples for representing the effects of a bad calibration kit. Not sure how the down-votes are visible, but this could be the reason.
Hey, my waveguide calibration expert. Good to see you posting again. Hopefully I cleared up any misunderstanding you had.
Kirkby's demonstration shows the equipment isn't smart and does exactly what you told it to do. It was very predictable. Using such an extreme example as you put it, by telling the VNA a short is an open and an open is a short, it's obvious what the outcome will be.
I have posted data where I do not make any attempt to calibrate the VNA. It is normally the last step I take, after the results are in the ball park (close). Of course, that is a case of knowing your equipment. I can get away without cal using my old Agilent and the LiteVNA in many cases.
Well, I'm already kind of on that. I made a some loads just for the hybrid, because I bought some cheap 2 Watt supposedly 50 Ohm RF SMA resistors for the job and then found they varied by over ohm. So for the hybrid, I got some male pcb thu-hole SMA connectors and soldered a couple of 100 Ohm 0.01% resistors on them. I made three. One of them came out bad. I'll have to take it apart and redo it. The other two test within a tenth of a ohm of each other and vary in reactance by just a little bit as far as I can tell.
I have parts to make a female SMA calibration set the same way. I just have yet to get around to doing it. I also have s parameter touchstone files for them, although they are on my computer that has a damaged video card. So, I have to wait to get a new video card before I can get to them.
...
Metrology is a wiley bugger. :)
When I first attempted to use my 1070's HP VNA above a few GHz, I made my own standards and was pretty pleased with the results. Then I learned that my standards were garbage and all I really accomplished was wasting a lot of time. Learn from my own ignorance!
I purchased eight Mini Circuits ANNE terminators for about $10/ea. One of them had really good return loss. For $100, it was cheap. I had the equipment to measure it and friends who loaned me the standards that I used to measure them. The second best terminator used with the low cost VNAs was an added bonus.
Datasheets for the ANNE show typical numbers. That should have been obvious but I can tell you dealing with a few, it's not. See the following:
https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg3093968/#msg3093968 (https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg3093968/#msg3093968)
There are several threads talking about the low cost VNAs and their standards. Here are a few from the search:
https://www.eevblog.com/forum/testgear/nanovna-v24-sma-cal-load/ (https://www.eevblog.com/forum/testgear/nanovna-v24-sma-cal-load/)
https://www.eevblog.com/forum/rf-microwave/nano-vna-reads-low-swr/ (https://www.eevblog.com/forum/rf-microwave/nano-vna-reads-low-swr/)
***
Forgot.... When I made the open and short for my Agilent, a local member had helped me characterize them. The following shows their MatLab scripts I used. The open was a pain to get right. Took a few trips to the lathe to get it to where the script would converge.
https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg2987982/#msg2987982 (https://www.eevblog.com/forum/projects/20db-rf-attenuator-seeking-feedback-to-improve/msg2987982/#msg2987982)
-
Hey, my waveguide calibration expert.
Hahaha :) I hope that I didn't stir up your emotions too much by pointing out something in your video, and this slightly sarcastic greeting is for something else.
Have a good day my friend! (Yeah, if you calibrate a vna backwards, it will show backwards values)
-
I was hoping I didn't upset you by point out you were wrong. Or, at least you never pointed out where I was wrong after I provided you with a step by step.
-
I mulled the situation over a bit and decided to do a some testing and simulation.
I warmed up the VNA for about an hour. Then calibrated with the open, short and thru that came with the machine, although I used my load, which I am confident is very close to 50 ohms DC resistance.
Then, I attached the cable connected to port 1 to port 2 directly. This yielded a port 2 impedance of 47 Ohms and 1.59nH. Phase reported was very close to 0 degrees, meaning that the measurement impedance plane is well aligned with the end of the cable. At least I think it does. :)
Next, I disconnected the port 1 cable from port 2 and used the supplied thru and second cable to reconnect port 2, using both both cables and the thru supplied with the machine. This yielded a port 2 impedance of 53.6 Ohms at -78.22 degrees.
After this I built a spice model of the VNA and cable arrangement using the data from the VNA. Since the first cable is effectively calibrated out of the results, I omitted the cable from the spice model. I set up the model with a voltage source with 50 ohms impedance and a load with a 47 ohm resistance in series with a 1.59 nH inductor. The results of the run came out as expected, with a input impedance for the load of 47 ohms with a little inductive reactance.
For the second run included a 300 mm cable plus 12 mm additional for the length of the thru. I had to adjust the impedance of the cable a bit to achieve a good match with the results from the VNA. With a cable impedance of 50.04 Ohms the port 2 input impedance appears as a 53.6 Ohm impedance to port one of the VNA due to the impedance transformation effect of the cable, and phase agrees within 1 degree of the VNA result.
So, it would seem that the cables and the thru provided with the machine are of reasonable good quality. The 47 Ohm port 2 input impedance I believe is reasonable accurate. Now I just have to figure out a way to correct for that so that my hybrid sees 50 ohms at the end of the port 2 cable.
-
Hello Fred,
Good to hear you are continuing your efforts.
... which I am confident is very close to 50 ohms DC resistance. ...
There are a few recent posts about some through terminators and how poor their performance it. I mentioned the one I had from Paternak used an axial TH device. You really want to know how the parts behave at the frequency you are using them at, not at DC.
It appears you are using the VNA standalone. I really have no idea how their firmware works as far as the calibration. If you had a way to characterize your standards, I am not sure they offer a way to enter them. My software supports setting the coefficients which in the past has caused some problems. The current release allows users to enter a value of 0 for coefficients and avoids a divide by zero (NAN) condition.
When you calibrate at the end of the cable, I assume you are using the supplied F-F barrel. Then you removed the barrel to attach the cable directly to Port2. I have never checked but understand some of the supplied barrels are very poor. It's the internet so for what it's worth. Obviously you are also changing your reference plane when you remove it.
*** See link for mention of barrels performance
https://groups.io/g/nanovna-users/topic/very_poor_thru_barrel/34447489?p=
***
You're measuring from 47 ohms to 53.6 ohms going from 1 cable to 2 for me seems unexpected. Shown is the LiteVNA 64 with the same calibration as last time. Again, this is with the supplied cables. However, I have a decent thru that I leave attached to the Port1 cable.
Yellow is the with the two cables in series.
Red is with a single cable. I inserted a M-M barrel to replace the second cable. While you measure 6.6 ohms difference, I measure 0.2 ohms.
Again, nothing was torqued, old calibration, no warmup, ideal models, poor standards..... That said comparing the difference is a bit of a relative measurement, so let's make the same measurement without calibration. I get about 0.3 ohms difference. FYI, colors are swapped.
I'm sure if I took the time to make these measurements properly, things would tighten up. From what I see, if you really require better than 10%, you need to sort out the cause of the main contributors.
***
Also, if you like, I could measure the LiteVNA's Port2 using my Agilent to compare results. From previous time I have compared results for passive circuits, they have been fairly close.
-
Hey Joe,
I bought a supposedly better F-F barrel that is a little longer, nickel plated and with a flat for a wrench in the middle. In the course of my testing I swapped the one that came with the kit and the one I bought later. Their performance was very similar. So, either they are both similarly bad or similarly good. I tend to think they're on the good side, because of the SPICE simulation results. In my simulation of the loads I made I found they behave pretty much as DC loads up to about 3-4 GHz when they start becoming somewhat reactive.
The SPICE simulation show the impedance transformation of the transmission line that the coax forms. The transmission line is what ever wavelength 312mm is in a cable with a velocity factor of 0.695 c, which is the figure I found for RG-316. The conversion of the 47 Ohm load to 53.6 Ohm input impedance of the 50.04 Ohm transmission line model is exactly what is expected by transmission line theory. The SPICE result verifies that. I've modeled a bunch of quarter wave transmission line impedance transformers for Wilkinson power splitters and impedance matching harnesses for antennas. I know transmission line theory well enough to work with it, although less well enough to explain it all. :-\
As far as your results go, I make sense little of the first one, with the ~43.6 Ohm impedances. Is that the uncalibrated one?
The second results kind of makes sense, if the port 2 input impedance is significantly closer to 50 Ohms than the port 2 on my machine.
Because I am working on a new computer I have yet to set up your software on it. I installed VNA-QT, although it displays a discontinuity in the sweep results that I have yet to sort out. I like the VNA-QT for the one reason that it allows me to load s parameter touchstone files for the calibration loads. I can produce them from my simulation software with which I designed and modeled my loads. Converting the S parameter touchstone files to coefficients numbers I have yet to figure out.
Cheers,
Fred
-
Anyone else having a problem to install the 64bit version of NI-VISA (ni-visa_20.0.0_offline.iso)
32bit and 64bit are present in one install (unfortunately) and it always forces a 32bit install, I tried on 2 windows 10 64bit and one Windows 7 64bit in all cases it want's to install a 32bit version. Any idea how to force a 64bit install?
(The 64bit labview runtime installed without problem tough, and does work with solver64)
Edit: it turns out that it works without installing NI-VISA, only ni-labview-2020-runtime-engine_20.1.1_offline.iso setup on Windows 10 64bit. (LiteVNA64 HW64-0 3.1 FW1.3.07, Build Time Sep17 2023)
-
Fred,
You should post more details about your SPICE simulations. I would take the time to follow along.
I bought a supposedly better F-F barrel that is a little longer, nickel plated and with a flat for a wrench in the middle. In the course of my testing I swapped the one that came with the kit and the one I bought later. Their performance was very similar.
Its possible that you have so many other problems, they are masking what the barrels contribute to the error.
As far as your results go, I make sense little of the first one, with the ~43.6 Ohm impedances. Is that the uncalibrated one?
Yes, the file labeled "1and2cables_uncal.jpg" is with no attempt to calibrate the LiteVNA. Of course the absolute values are off a bit but the relative values are very close as we would expect.
The second results kind of makes sense, if the port 2 input impedance is significantly closer to 50 Ohms than the port 2 on my machine.
Hard to say but we shouldn't have the amount of error you are seeing. Something is wrong.
Because I am working on a new computer I have yet to set up your software on it. I installed VNA-QT, although it displays a discontinuity in the sweep results that I have yet to sort out. I like the VNA-QT for the one reason that it allows me to load s parameter touchstone files for the calibration loads. I can produce them from my simulation software with which I designed and modeled my loads. Converting the S parameter touchstone files to coefficients numbers I have yet to figure out.
Some of the last changes I made to my software were to work around problems when importing data collected with the QT software. I believe we were posting about that problem in this thread.
I've thought about adding support for databased standards but have not looked into it enough to know if all the vendors follow a standard. The standards I had access to were from Agilent using the polynomial fit. For the low cost VNAs, I pretty much use the ideal model. The software supports my other VNAs. It's these other VNAs that drove the ability to change the coefficients. It's in the common code, so all of the software goes along for the ride.
-
You should post more details about your SPICE simulations. I would take the time to follow along.
Attached is the LTSpice model I made. The model itself is fairly simple, although it implicitly deals with Transmission Line Theory, which is a whole other matter. There's a 50 Ohm source that feeds a transmission line model of the 300mm RG-316 cable that came with my VNA. I added 10 mm for the length of the thru. I used the 0.695 velocity factor of RG-316 plus the lengths of the cable and thru to determine the time delay for the combination. For the load I used the figures from the VNA results of 47 Ohms resistance and 1.59 nH of reactance, which works out to be about 1.46 Ohms and is basically negligible in this case. You'll need an understanding of transmission line theory to get why the cable transforms the 47 Ohm load into a 53.6 input impedance at the other end of the cable. That's all I can say about that, except that the SPICE model verifies the transformation rather exactly and confirms the cable is very close to 50 Ohms impedance.
Some of the last changes I made to my software were to work around problems when importing data collected with the QT software. I believe we were posting about that problem in this thread.
I've thought about adding support for databased standards but have not looked into it enough to know if all the vendors follow a standard. The standards I had access to were from Agilent using the polynomial fit. For the low cost VNAs, I pretty much use the ideal model. The software supports my other VNAs. It's these other VNAs that drove the ability to change the coefficients. It's in the common code, so all of the software goes along for the ride.
Yes, we were, although this is different. I import into VNA-QT the s parameter touchstone files I exported from the EM simulation software I used to design my loads. I have yet to build the calibration set I designed in physical form, so I modeled the standards that came with the VNA together with the thru barrel, and exported those touchstone first. That resulted in the very good noise floor measurement I got for the nano, which you may recall and which approached what 0W0 claimed the nano would do.
The touchstone files have a standard. It's rather simple. Links for the standards are on this page.
https://en.wikipedia.org/wiki/Touchstone_file
-
I went back and read all your posts for context. I didn't realize you were the person that I was working with using QT and exporting Touchstone files with zero'ed data. Agree, the format is simple enough. As far as supporting the database, it's more a question on what the companies supply. I think I would start by asking the major manufactures for examples to get a feel for how similar they are.
-
That a good point. What would be convenient for you as a coder as far as the touchstone files go? Would it be good to have the touchstone files exported with frequency entries that match the frequency span and number of points in the calibration files produced by Solver? I can change those details before exporting to match. I lack any concern at the moment as far as the database goes, because for now I am just making my own calibration sets and producing the related touchstone files.
Anyway, I got Solver running, did a cal, and repeated the measurements. The results came out the same. Attached are screen shots of the whole app so you can see the settings.
-
As far as the database standards, I'm not sure it would matter as long as the companies all do the same thing. Most of the code is pretty simple. I spend more time doing research in how functions should work than I do coding.
I think if you watched my series on rectangular waveguides where I talk about how you can't use an open for a standard, and instead how an offset short is used to simulate the open by shifting the phase, you catch on real quick what is going on with the transmission line. I am just surprised your VNA would be that bad. So, I pulled out my V2Plus4 purchased directly from OWO. We just want to know what the effects of the VNA are, so using the same cables, standards and procedure, I repeated your test using 1 & 2 cables. What do you know, it is about as bad as what you are seeing with the Professional one.
Well, at least it gives us more confidence in your measurement.
-
I was going to attempt a sanity check with the PNA for you but ended up learning something new instead about these low cost VNAs...
Let the PNA warmup and ran a SOL using my poor mans cal standards (female) that I had characterized against the Agilent standards. I am using the best load of the eight ANNE terminators I had purchased. This load is attached to a good barrel.
I then checked the OEM load that was supplied with the low cost VNA using another good barrel. Its a little off from what I read with the Lite.
-
I then connected directly to port 2 of the LiteVNA and measured 57 ohms. Brain kicks in and says, idiot, power that thing up. Here lies the rub. We can't simply measure it as the are doing some switching. Thinking it may be an artifact from sweeping, I tried to select the CW mode from their built-in firmware but it has no effect. I repeated this with the V2Plus4 with the same results.
Attached plots show the effect for both low cost VNAs. What is interesting is how the LiteVNA changes about an ohm as it chops, compared with the V2Plus4 at about 2 ohms.
Something else to be aware of.
-
Sorry by ask , I cannot find the changes at the moment, but I'm trying to update the software and cannot find the github nevermore.
Also found a cloud folder ,on which it looks the last version is solver64, but it was said was abandoned, so I'm really confused.
I have working solver32 and solver64 in windows 11, can say both work and coexist, but no idea what I should to use, what is still active and if the litevna64 firmware has any importance.
Thanks and sorry I read some pages but couldn't find the changes
-
We can't simply measure it as the are doing some switching. Thinking it may be an artifact from sweeping, I tried to select the CW mode from their built-in firmware but it has no effect. I repeated this with the V2Plus4 with the same results.
Attached plots show the effect for both low cost VNAs. What is interesting is how the LiteVNA changes about an ohm as it chops, compared with the V2Plus4 at about 2 ohms.
They have only a single receiver/mixer, but they need to measure 3 quantities for each frequency point. So the 3 readings need to be multiplexed. The source currently being measured is connected to the receiver, and the other sources are connected to a terminator. Then the receiver is switched to the next source... OTOH, the original NanaoVNA has 3 receivers/mixers. Maybe it's the better choice for 150MHz anyway?
-
I mentioned CW not having any effect, but you can also disable the sweeps in the firmware and it will still switch.
-
Attached plots show the effect for both low cost VNAs. What is interesting is how the LiteVNA changes about an ohm as it chops, compared with the V2Plus4 at about 2 ohms.
Something else to be aware of.
You've brought up something there that I am actively wondering about, the switching. I had a look at the schematic for the V2Plus4. Apparently it switches back and forth between measuring S11 and S21 for each frequency point. If I comprehend your post correctly, you're measuring the low cost VNA, with a quality PNA. I fail to make sense of what your are showing, a switching that is apparently every few MHz or so across the frequency sweep, and we fail to see that when self-measuring the port 2 input impedance of the low cost units. That's too slow for the S11/S21 switching. So, what do you think that is?
Just for giggles, could you use the PNA to measure the output impedance of port 1 on the low cost devices?
A couple more notes about the SPICE model. The original calibration cable attached to port 1 has been omitted from the model because for all practical purposes it has been calibrated out of the measurement. Also, the magnitude of signal at port 2 in the model is reported as close to -6 dB, that's because LTSpice normalizes the signal level at the internal input to the voltage source, which in this case has been set to 1V, before the source output impedance is applied to the signal, rather than to the external output of the voltage source after the source impedance has been applied to the signal. That means in VNA terms the signal level at port 2 is -0 dB relative to that level at port 1, which can be checked by looking at the signal level at node P1 in the model. Basically, V(P1) = V(P2) meaning there's zero loss in the "lossless" transmission line model.
-
Apparently it switches back and forth between measuring S11 and S21 for each frequency point.
Three measurements. Port1 incident and reflected along with Port2. I did not try to disable the S21 measurement as I didn't see it in the firmware.
If I comprehend your post correctly, you're measuring the low cost VNA, with a quality PNA.
Yes
I fail to make sense of what your are showing, a switching that is apparently every few MHz or so across the frequency sweep, and we fail to see that when self-measuring the port 2 input impedance of the low cost units. That's too slow for the S11/S21 switching. So, what do you think that is?
It's the asynchronous switching of the low cost VNAs, which I can't seem to disable from firmware.
Just for giggles, could you use the PNA to measure the output impedance of port 1 on the low cost devices?
It's a 2-port, 1 path VNA. Port 2 is an input only. Port 1 will drive the output. So no.
-
Just for giggles, could you use the PNA to measure the output impedance of port 1 on the low cost devices?
It's a 2-port, 1 path VNA. Port 2 is an input only. Port 1 will drive the output. So no.
@Fred, with a (calibrated) full 2-port VNA, the reported Sxy are already compensated for impedance mismatch at ports 1 and 2, so it does not matter whether the ports have exactly 50 Ohm or not. They don't - it is difficult to make them exactly 50 Ohm over a wide frequency range. The calibration and error correction takes care of the deviation.
But with a 2-port, 1-path VNA (aka. T/R VNA), only the source mismatch (at port1) can be compensated by the calibration and error model, but not the load mismatch at port2. For one-port measurements, already the SOL calibration at port1 does this, and for 2-port measurements, "Enhanced Response calibration" takes care of source mismatch (my NanoVNA V2.2 also offers this option).
To mitigate the load mismatch, you can add a (good) attenuator to the end of the port2 cable, and calibrate at the end of the attached attenuator. Then the calibration plane is established at the end of the attenuator, and the cable and attenuator are still calibrated out. Of course you have to renounce some S21 dynamic range when you do that.
There are two special cases where a 12-term error correction is still possible with a 2-port, 1-path VNA:
1) If the DUT is insertable at the two calibration planes in reverse direction (IOW, if both connectors of the 2-port DUT are the same type and sex), you could measure the DUT twice (in forward and reverse direction) and do full 12-term error correction with the combined measurements.
2) If the DUT is known to be reciprocal and symmetric, then a Fake Flip error correction can be done, w/o actually flipping the DUT.
Both are not supported by the firmware, so you could only do it with an external program. [ I think Joe's program also supports (1) with an automated DUT flip via external transfer relay, so that no manual flip is required. But better Joe should comment on that. ]
For more details, see
https://scikit-rf.readthedocs.io/en/latest/examples/metrology/Calibration%20With%20Three%20Receivers.html
Btw, you said that your DUT is a coupler. So it is not a 2-port, but actually an N-port, with N > 2. For full characterization of its NxN S-parameter matrix, you would actually need an N-port VNA. [ It is however possible to calculate the full NxN S-parameter matrix from (full) 2-ports measurements of each port pair. See also https://scikit-rf.readthedocs.io/en/latest/examples/metrology/Measuring%20a%20Mutiport%20Device%20with%20a%202-Port%20Network%20Analyzer.html. ]
-
Recently I watched Picotech's sales training videos for their VNAs. One story they told was how a competitor was looking at how good their port matching is.
Return loss on my old 1970s HP isn't very good:
https://accusrc.com/uploads/datasheets/6274_8754A.pdf (https://accusrc.com/uploads/datasheets/6274_8754A.pdf)
The old 2000's Agilent is much better:
https://www.testequipmenthq.com/datasheets/Agilent-E8357A-Datasheet.pdf (https://www.testequipmenthq.com/datasheets/Agilent-E8357A-Datasheet.pdf)
My software doesn't support using M/F cal standards for the full 2-port calibration. I've thought about adding it for the Agilent, which of course supports it with their software.
-
@Fred, with a (calibrated) full 2-port VNA, the reported Sxy are already compensated for impedance mismatch at ports 1 and 2, so it does not matter whether the ports have exactly 50 Ohm or not. They don't - it is difficult to make them exactly 50 Ohm over a wide frequency range. The calibration and error correction takes care of the deviation.
Yeah, I thought of that after I made the post. What ever impedance it is is calibrated out.
To mitigate the load mismatch, you can add a (good) attenuator to the end of the port2 cable, and calibrate at the end of the attached attenuator. Then the calibration plane is established at the end of the attenuator, and the cable and attenuator are still calibrated out. Of course you have to renounce some S21 dynamic range when you do that.
I've discussed this on the nano forum already. Adding an attenuator just sweeps the reflected wave from the mismatch under the carpet so to say. The mismatch and the reflection are still there. The reflection just gets to a greater or lesser extent dissipated in the loss of the attenuator. I would like a better solution, one that preserves dynamic range. Although an attenuator may get me by well enough. We'll see.
Btw, you said that your DUT is a coupler. So it is not a 2-port, but actually an N-port, with N > 2. For full characterization of its NxN S-parameter matrix, you would actually need an N-port VNA. [ It is however possible to calculate the full NxN S-parameter matrix from (full) 2-ports measurements of each port pair. See also https://scikit-rf.readthedocs.io/en/latest/examples/metrology/Measuring%20a%20Mutiport%20Device%20with%20a%202-Port%20Network%20Analyzer.html. ]
Yes, it's a hybrid coupler, so it has 4 ports. And that creates the problem in sight of the hybrid being sensitive to impedances on it's ports. The operating point shifts a couple of MHz when I switch my port 2 VNA cable from port 2 to port 3 to measure the phase and signal balance. Shifting the operating point also shift the signal levels on the ports and so that makes tuning the hybrid more of a problem than it already is.
-
I am interested in seeing your hybrid's construction and more details about the design and your application for it.
-
It's a coupled line hybrid made with lumped element components for use in a circular polarized antenna system that's going to be a commercial product, so that's about all I want to say about it specifically. In general though lumped element hybrids are fairly simple networks. Because they operate at RF frequencies, the difficulty in making them work as desired is getting the component values adjusted away from calculated ideal values to deal the the parasitics of the layout. Therein lies the need for precise measurement.
-
Only reason I asked for more details is if it would be possible to replicate your findings, now that I see my original V2Plus4 behaves similar to yours. I have zero plans to start selling antennas or any products.
Symmetrical? Based on your questions, I assume it's for the 2-meter ham band.
-
It's for low earth orbit amateur radio satellites. VHF one way and UHF the other. Which way is which, uplink or downlink, depends on the satellite.
-
I'm trying to calibrate with Sover64 (Windows 7 64Bit LiteVNA64 HW64-0 3.1 FW1.3.07, Build Time Sep17 2023)
but the files seems to be wrong the values make no sense.
I also tried the calibration on the device and in the "saver" app and that is working I see a nice -20dB.
So I assume the calibration fails with Solver64 (attached the calibration file, remove .hex)
It does make measurements though like S21 -60dB too low and -150dB when not connected.
obviously it doesn't support such a big dynamic range so somehow the calibration file is wrong.
When I use the Ref functionality then I can measure the 20dB attenuation that I connect.
A few screenshots attached to see it, I think I narrowed the problem down to the calibration file.
But when you load the calibration file shouldn't the RAW data stay the same before and after, that is not the case in my test....
So anyone any idea what I can try to fix this or maybe have an idea what I am doing wrong or is wrong?
Thanks
-
I'm trying to calibrate with Sover64 (Windows 7 64Bit LiteVNA64 HW64-0 3.1 FW1.3.07, Build Time Sep17 2023)
but the files seems to be wrong the values make no sense.
I also tried the calibration on the device and in the "saver" app and that is working I see a nice -20dB.
So I assume the calibration fails with Solver64 (attached the calibration file, remove .hex)
It does make measurements though like S21 -60dB too low and -150dB when not connected.
obviously it doesn't support such a big dynamic range so somehow the calibration file is wrong.
When I use the Ref functionality then I can measure the 20dB attenuation that I connect.
A few screenshots attached to see it, I think I narrowed the problem down to the calibration file.
But when you load the calibration file shouldn't the RAW data stay the same before and after, that is not the case in my test....
So anyone any idea what I can try to fix this or maybe have an idea what I am doing wrong or is wrong?
Thanks
You didn't provide many details and I'm guessing you run through a full SOLT cal, attach a 20dB attenuator from port 1 to port 2 and my software shows -80dB rather than -20. Suggesting your thru standard was a 60dB attenuator rather than the supplied thru. I doubt that is what you are doing but I have no idea. If that's the case, make a video showing every detail of your approach, from power on to making the measurements.
***
I am using V1.3.12 firmware but I doubt the firmware has anything to do with what you are seeing.
-
Yes I did a full SOLT calibration (to make the file, as shown in your manual), just like I did on the device itself and also did with the Saver app, they worked correctly so I don't think there is an hardware problem with the SOLT procedure.
The SOLT is done at the end of the 2 included cables with the included S O L (T is done with male/make part 0dB)
I only used an -20dB to verify, the device itself and Saver did confirm that the 20dB is working properly.
(even Solver64 confirmed -20dB, by using your Ref feature, see screenshots)
Maybe you can provide a less than 1GHz calibration file (for LiteVNA), I know I can't use it but it would confirm that it is working in the right range, then it's only making the file that is the cause of the problems. (my cal file is attached)
-
From what I have seen the LiteVNAs are consistent enough you should be able to load my cal file and get something meaningful. You never state what you use for a model. My software defaults to ideal but I have seen people attempt to use their own models. Assuming you are using the ideal, I ran through the same test. Measuring a 20dB attenuator with 801 points, no calibration. We get the same results. I then perform a SOLT using 1001 points and leave the thru standard attached which shows 0dB as expected. I then remove the thru (port ports are now floating) and measure 80dB as expected. I then attach a 20dB attenuator and measure 20dB as expected.
I have attached my calibration file.
***
Loading your cal file, I get the same results you are seeing. With you having tested with the device stand alone and getting correct results, we can assume the standards are fine. This suggests there is something wrong with how you are performing the SOLT. Provide more details about what you are doing and I am sure we could sort it out.
-
Thanks for the file and the fast response, I tried your file and that is working just fine (with my -20dB)
(and no nothing custom yet)
Tomorrow I will try to make a few more SOLT files again to see if the problem remains maybe I made a mistake, I don't know... I let you know.
-
Did you use the ideal model or try to changed things? Post a screen shot of what you are using (Setup/Diagnostics, Calibration Terms). If you load your calibration file, you will see that the coefficients are all bad. Even the SOL is not correct. The software wrote a readable file so it seems that the data was bad after the cal and not a problem when saving the data to the file.
I've seen people post invalid information on models and others trying to use it to I guess, improve accuracy without understanding what they were doing. I changed my software to allow these people to enter bad data. Just be aware of that. You went through the manual and followed the procedure. I wouldn't think you would start out by making changes like this before you learned to use the software but you have never provided any details.
I can tell you that the software is fairly old and is used regularly. Calibration is common and I have not yet seen a problem with it. There was a viewer claiming that my calculations when using waveguides was wrong but I think I put that to bed by comparing the results with my old Agilent VNA. Outside of that and the people using bad models are the only things I can remember coming up.
-
So anyone any idea what I can try to fix this or maybe have an idea what I am doing wrong or is wrong?
I had a look at the your calibration file and there are a few things I notice. First, you had the short installed for every standard rather than the SOLT. The next thing I notice is the values are not changing.
Having gone through the manual you know that the software does very little to prevent the user from causing themselves problems. As I have stated many times, this is because I don't want the software to limit my use of it. For example, if I tell the software to sweep 20TH with a 300MHz VNA, the software assumes you know what you are doing and is not going to prevent that. If you tell it to sweep from 140mHz with a span of 20mHz, guess what, that is exactly what it tries to do.
I can replicate your calibration file easy enough. I setup the VNA the way you have it, install the short, turn off the sweeping, then run the calibration. The software does exactly what you request and runs the cal with the last data recorded, which was the short. The user could insert all the standards when prompted, but because sweeping was turned off, it gladly saves the last recorded data for each standard.
Of course, you are able to read the 20dB using the relative measurement, which means that you turned the sweeping back on after running the calibration with the sweeping turned off.
The odd thing for me is why anyone would think that that disabling sweeps while trying to run the VNA is logical. So, maybe there is some other way to make this happen but I am not seeing it.
But when you load the calibration file shouldn't the RAW data stay the same before and after, that is not the case in my test....
The raw data you are looking at is after applying the corrections which includes the reference plane compensation and any averaging.
-
I remember another user who had a similar problem:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4067353/#msg4067353 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4067353/#msg4067353)
-
I remember another user who had a similar problem:
https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4067353/#msg4067353 (https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg4067353/#msg4067353)
Yes, that was the problem, Sweep must be turned on before you start the calibration.
It wasn't in the manual (at least not the parts that I read) and it is the opposite of what the Saver app requires, Saver even gives a warning that the Cal cannot start until you disable the continuous sweep.
I think that makes sense since the Cal procedure wants to take control of a few single sweeps, but obviously you can write code however you want, works just fine when you know how to set it up.
You can also just turn it on at the start of the cal and turn it back to the previous state after calibration, but since this isn't a commercial software you probably couldn't care less :)
Still, it's the availability of your software that made buying the LiteVNA an easier choice for me.
Thanks for the Help problem solved :)
-
Yes, that was the problem, Sweep must be turned on before you start the calibration. It wasn't in the manual (at least not the parts that I read) and it is the opposite of what the Saver app requires, Saver even gives a warning that the Cal cannot start until you disable the continuous sweep.
I can believe there are a lot of what I consider common sense details not included in that document. Yes, I could add warnings to try and guide users. But I'm not going waste their time pointing out the obvious. Of course, I have created several videos demonstrating how to use the software as well. It's up to users to take advantage of them or not.
I have never used Saver outside of looking at it for a video I made. It was very ham'ish which I'm sure the hams appreciate. My advice is if you like how Saver runs and it does everything you need, just use Saver. You're wasting your time (and mine) pointing out my software doesn't function like it.
You can also just turn it on at the start of the cal and turn it back to the previous state after calibration, but since this isn't a commercial software you probably couldn't care less :)
No doubt, I can control the VNAs within the limitations of the firmware. I certainly care how my software drives. Maybe more to your point, I dare say in some cases I even care what others have to say about it enough to make changes.
12. Getting Started
...
12.5 Displaying Data
The software will default to a center frequency of 10MHz with a 2MHz span and 201 data
points (Frequency spectrum shown in Figure 11). The V2+ was programmed with these
defaults when the connection was made. The V2+ is actually sweeping at this time. Select the
Sweep button and the software will begin collecting data from the V2+.
-
Looking at my code, it doesn't check to see if you have the VNA linked up before calibration as well. While it seems obvious that you would need it to be linked to run a cal, I bet for some, that too isn't obvious. I suggest both states would need to be checked.
-
I have added a check for both the link and sweep. The software will report the errors to the user and will attempt to correct them. I don't see this being a problem for me as the only time I can think of that I have attempted to run a cal without sweeping was to replicate the problem.
There are many other settings that also need to be set prior to running the calibration. The software does have a set of defaults and the user can change and save them but maybe if they have not created a defaults file, we should force that condition as well?
Keep in mind, I have added color coding to easily detect what mode the VNA is in, auto region detection, allowing the use of 0s in the calibration models, allowing 0's in the Touchstone files to allow importing from that QT software. Like above, all of these were added to help guide the user so I am asking what else do you feel should be added to prevent the user from making mistakes without limiting the use of the software?
Any users are free to comment.
-
Based on the lack of any feedback, I assume there are no other problems, or at least none that users want to discuss. Based on that, I have updated the repository to include 4.05
4.05, 12/31/2023
Twice now people have reported problems when calibrating. In both cases users disabled sweeping, disabling data collection. The software previously allowed this and used the last data collected. Apparently based on how some other software works, these users expected this software required them to disable sweeping to calibrate. This software now warns the user if a link has not been established or sweeping is disabled. It will then attempt to connect to the VNA and enable sweeps prior to beginning the calibration.
4.04, 10/14/2023
Move RefPlaneComp from state1 to state0. Allows function to be used for Touchstone export.
4.03, 09/23/2023
Use calibration standard connector type to determine if we are running a waveguide cal or coaxial rather than the externder. Allows waveguide calibration without the extender. (Lite supports any harmonics)
Add Window, FilterType, MarkerIndex, Units, to Plot trigger
Add plot trigger to TDR cursor release.