NanoVNA Custom Software

[joeqsmith]

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     
 

[joeqsmith]

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.

[cyp_eev]

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.

[joeqsmith]

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

[cyp_eev]

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:

Code: [Select]

[NanoVNA] 
useLocaleDecimalPt=False


[joeqsmith]

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.

[cyp_eev]

No problem, you're welcome, anytime.

Thank you!

[DiSlord]

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)

[cyp_eev]

PS in my fw i also add expert option for change dot or comma as digit separator (sended to console)

Good to know, thanks!

[joeqsmith]

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.   

[joeqsmith]

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

[DiSlord]

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

[joeqsmith]

Looking at R for the powered core supply. 

[joeqsmith]

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.   

[joeqsmith]

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.   

[joeqsmith]

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. 

[joeqsmith]

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

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

[joeqsmith]

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. 

[joeqsmith]

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. 

[joeqsmith]

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.   

[joeqsmith]

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.

[joeqsmith]

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. 

[joeqsmith]

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

[joeqsmith]

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.

[joeqsmith]

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.