NanoVNA Custom Software

[joeqsmith]

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.     

[E Kafeman]

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
I have a list for older labview versions as well, if needed.

[joeqsmith]

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.   

[ehcurrie]

What triggers the following message "NanoVNA V0Unknown,Protocol 0, FW 0.0 "

[joeqsmith]

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.

[joeqsmith]

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. 

[jspencerg]

Re: The 500Hz width scan using original Nanovna
What scan and data collection/ processing settings did you use?  Thanks.

[joeqsmith]

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.

[jspencerg]

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

[joeqsmith]

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.   

[jspencerg]

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.

[realfran]

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.

[joeqsmith]

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

[gf]

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 for Firmware for NanoVNA, NanoVNA-H, NanoVNA-H4, search for _bandwidth and cmd_bandwidth.

Code: [Select]

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.

[joeqsmith]

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

[optotester]

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.

[joeqsmith]

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.     

[joeqsmith]

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.

[ehcurrie]

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

[joeqsmith]

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. 

[joeqsmith]

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.   

[joeqsmith]

Adding a simple offset to null out the frequency error is trivial.  It's an addition..   

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. 

[jspencerg]

Doesn't it look like the PNA has smaller ifbw that the lite? Learning to read these graphs...

[joeqsmith]

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. 
   

[joeqsmith]

Using the same 2.457MHz crystal, 1kHz span and sweeping the Lite's IFBW from 100Hz (starting at 0) to 4kHz.