NanoVNA Custom Software

[ogden]

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 

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.

[radiolistener]

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 

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.

[radiolistener]

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

[radiolistener]

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:

Code: [Select]

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, it solves your issues, allows to enter negative electronic delay and also improves precision for data transfer from NanoVNA to PC.

[ogden]

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.

[joeqsmith]

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. 

[radiolistener]

There's no link.

Here:

[joeqsmith]

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.

[radiolistener]

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.

[joeqsmith]

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.

[radiolistener]

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.

[joeqsmith]

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.

[radiolistener]

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

[joeqsmith]

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.   

[joeqsmith]

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

[radiolistener]

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.

[radiolistener]

/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

[radiolistener]

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

[ogden]

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.

[joeqsmith]

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

[joeqsmith]

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?   

[radiolistener]

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?

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.

[ogden]

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?

[radiolistener]

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.

[ogden]

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.