NanoVNA Custom Software

[joeqsmith]

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. 

[OwO]

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:



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

[joeqsmith]

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.   

[Mechatrommer]

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.

[joeqsmith]

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. 

[Mechatrommer]

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.

[joeqsmith]

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.   

[joeqsmith]

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! 

[joeqsmith]

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.   

[Darko8]

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

[joeqsmith]

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. 

[joeqsmith]

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. 

[joeqsmith]

I had ran it one last time for over three hours with my software and the V2+ did not hang.   

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.

[joeqsmith]

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. 

[joeqsmith]

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. 

[joeqsmith]

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.   

[joeqsmith]

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.     

[joeqsmith]

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.   

[joeqsmith]

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.   

[joeqsmith]

Not surprising, adding the battery pack had no effect on my V2+ lockup problem. 

[joeqsmith]

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

[joeqsmith]

I have gone ahead and wrote some test software to support the offset loss. 

[joeqsmith]

Working on my review of the new 4GHz NanoVNA V2 Plus 4.

[Grandchuck]

Oh, how often that has happened to me!

[joeqsmith]

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.