NanoVNA Custom Software

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

[DiSlord]

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

[joeqsmith]

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.   

[DiSlord]

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

[joeqsmith]

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. 

[DiSlord]

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

[joeqsmith]

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.     

[DiSlord]

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

[joeqsmith]

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.