NanoVNA Custom Software

[radiolistener]

Right, okay. I was just confused by your earlier post where you suggested I could do scan/data 0/data 1/data 0/data 1/... and get new data. Which isn't possible with the stock firmware. So I thought your version was different. :-)

yes, you're right, I just forgot, that "scan" command disable sweep. So, such method won't works with "scan" command. But it works good with usual "sweep" command.

[5q5r]

Yes, but that doesn't work on the original firmware, at least not after 0.2.0. That's why I changed it; I talked to edy555, and he told me that software should use the "scan" command for future firmware versions. Whether he makes it faster is up to him.

it works with any firmware version

Firmware version 0.2.0-0.2.2 at least had problems with it - it would return data from the previous span if polled too fast after a sweep command. I think earlier firmwares showed this problem as well.  That's why I talked to edy555 about it in the first place.

So no, it doesn't work with "any" firmware version: Sadly, the various firmwares are not generally compatible.

[radiolistener]

Firmware version 0.2.0-0.2.2 at least had problems with it - it would return data from the previous span if polled too fast after a sweep command. I think earlier firmwares showed this problem as well.  That's why I talked to edy555 about it in the first place.

yes it is possible to read the same sweep two times in a row. But I don't see a big problem with that. Just wait for the next sweep

There is no need for delay. Just execute data command again and you will get next sweep.

[5q5r]

There are serious problems with that approach: When reading multiple segments in a row, reading the wrong data for a given frequency span gives completely wrong readings.

The frequencies command would return the requested span of frequencies, but the data commands would sometimes return the old data. So it wouldn't even be sufficient to check if the frequencies were right.

Your approach of executing the data command again only seems to work for the limited use case of doing continuous single-span sweeping.

[radiolistener]

okay, now I understand the problem. I will try to fix it.

[radiolistener]

try this one. If all works as expected,  this version should guarantee that the "data" command will read correct data after "sweep" command. But needs to test.

[joeqsmith]

scanraw use integer frequency arithmetic, there is no floating point error for integer arithmetic. It always calculate exactly the same value.
....
The result is always predictable. This is why scanraw don't needs frequencies command.

Understood.

scanraw returns requested frequency range only. It doesn't shift frequencies. If you requested start frequency 12345 Hz and frequency step 100 Hz, then scanraw guarantee that the first frequency will be always exactly 12345 Hz, the second frequency will be exactly 12345 + 100 = 12445 Hz, the third frequency will be exactly 12345 + 100 + 100 = 12545 Hz etc. Scanraw command guarantees that frequencies will be exactly the same as requested, with no shift, with no rounding error.

This is why scanraw returns error if requested range is out of device frequency range (10 kHz - 1500 MHz).

You can find supported frequencies by send sweep commands and then execute frequencies command:

Code: [Select]

sweep start 0
sweep stop 4000000000
frequencies

Just look for the first and last record and you will know device limit

Understood.   Of course, it requires the older Frequencies command, which is how I had been determining the limits.

When using the Scanraw to average the data, there appears to be no user feedback that the Nano is doing anything.  The LED stops flashing and the unit appears hung.  Again, blind faith, pry it comes back in some amount of time..

it didn't hung. It just capture device for exclusive use during command execution time. When the command will be completed, the normal sweep operation will be restored and you will be able to continue use touch screen as usual.

My point is from a user perspective.  Depending on the parameters passed down to the command, it may require minutes to run.  During that time, nothing is happening on the Nano.  The PC can't detect if it's doing anything.  The LED that normally would show that it is scanning, doesn't appear to be used.  For all practical purposes, it appears dead. 

If you specify start/stop or center/span it leads to uncertainty. The frequency step will be calculated on NanoVNA side and it may have rounding error and you will need to request frequency list. As it used with usual sweep and data commands.

It leads to redundant transfer for frequency data and more long measurement time. And PC cannot control frequency step value, because it will be calculated on NanoVNA side with it's rounding precision. This is why using start/stop center/span is a bad idea.

scanraw uses start/step parameters in order to guarantee that the frequency list will be exactly as requested with no rounding and no shifting. It allows to exclude frequency data from data transfer, because frequency can be easily calculated on PC side and it will be exactly the same. Because it uses integer arithmetic and fixed frequency step. It allows to significantly improve data transfer and measurement speed. And excludes frequency step uncertainty.

Understood.  I doubt the rounding would make any difference to me as a user.    I only request the frequency when I change it so that really doesn't come into play when looking at the measurement times.   From my experience, start, stop, center and span are all fairly common commands for NA and SAs.   The analyzer normally calculates the step size.   It's been ingrained into me by the industry.   

Overall speed wise, from what I can tell, the scanraw is very slow for doing 101 samples without average.   Hands down, if I needed to run a longer average, it would be faster but the smoothing has been good enough and I get the updates live.    I've thought about using a running average but haven't had a need for it yet. 

Using the Scanraw and sending up 101 data points when compared with the original method appears to be very slow.  I suspect the only gains are when using the average feature.   

scanraw is introduced for a large datasets. For example if you request 1000 points, scanraw will be done in 6 seconds. If you use data command it will require about 15 seconds for 10 sweeps.

For 3000 points scanraw takes 17 seconds.

With 10x average, 1000 points measurement takes 15 seconds.

This is how it works

Understood.   If it were possible to get the system to collect data on the PC faster,  that's what I would want.   Fast enough that as I make adjustments that there is no perceptive delay.  Then again, that $50 number forgives a lot.... 
 

It's odd as I started using segmented sweeping shortly after getting the Nano and having it miss or be out of sync hasn't been a problem.   I tried several tests with your previous image and it seems to work fine. 

I have downloaded your latest version and plan to let it run the latest regression tests overnight.   It's about a quarter of the way through now and I'm not seeing any problems with it. 

I tried downloading a really early version and running it.  I couldn't make it past one loop without getting bad data from the Nano.   Even if I don't end up using any of these new commands, these updates you have made appear to be a substantial improvement in making the Nano more robust.   


************************************

Your latest version passed the regression test without any errors.   There are commands that I don't currently support as I havn't found a use for them.  Also, the order the commands are sent is  pretty much the same as I would use when normally talking with the Nano.   The fact it doesn't detect a change in the this new version and your previous one should give you some idea how primitive the tests are.   

I made a couple of custom transfer relays for the Nano, both with poor performance.   One uses GaAs.  I've thought about using this relay (which would not wear out) to allow me to enhance my tests.  Currently I just install a thru and do what I can with it. 

[radiolistener]

My point is from a user perspective.  Depending on the parameters passed down to the command, it may require minutes to run.  During that time, nothing is happening on the Nano.  The PC can't detect if it's doing anything.  The LED that normally would show that it is scanning, doesn't appear to be used.  For all practical purposes, it appears dead. 

This is done intentionally. LED blinking leads to a small power supply voltage fluctuations due to Ohm's law, which leads to a little voltage jumps for SA602 mixers and ADC REF power supply. Also it leads to noise from rise and fall pulses.

Power supply purity is critical when you deal with 80-90 dB range signals. This is why LED is off during measurement, to eliminate redundant noise source.

You can check that device still alive by monitoring data transfer through USB port. If device sends you a lot of data, it cannot be dead

[joeqsmith]

My point is from a user perspective.  Depending on the parameters passed down to the command, it may require minutes to run.  During that time, nothing is happening on the Nano.  The PC can't detect if it's doing anything.  The LED that normally would show that it is scanning, doesn't appear to be used.  For all practical purposes, it appears dead. 

This is done intentionally. LED blinking leads to a small power supply voltage fluctuations due to Ohm's law, which leads to a little voltage jumps for SA602 mixers and ADC REF power supply. Also it leads to noise from rise and fall pulses.

Power supply purity is critical when you deal with 80-90 dB range signals. This is why LED is off during measurement, to eliminate redundant noise source.

You can check that device still alive by monitoring data transfer through USB port. If device sends you a lot of data, it cannot be dead

It may take minutes for it to start to send data.   I didn't try to see how far I could push it out but I tried it at around 1 minute, 45 seconds and it did eventually respond with data.   
scanraw 0 10000 10000 101 1000

Plug in the wrong parameters and there is no way I know of to abort it.  Still, if what I am seeing is actually correct, that's 1000 sweeps in 105 seconds or around 10X faster than what we have today. 

[radiolistener]

It may take minutes for it to start to send data.

no, scanraw command starts to send data immediately. There is no memory to store all points, so it needs to send each measured frequency to PC.

[joeqsmith]

It may take minutes for it to start to send data.

no, scanraw command starts to send data immediately. There is no memory to store all points, so it needs to send each measured frequency to PC.

Odd. That's not what I see with a dumb terminal. 

Using scanraw 0 10000 10000 1000 1000 requires about 17 minutes before the Nano responds.   1Hz with 10X the data.     

I sent something like scanraw 0 10000 1 1000000 10.   I assume it's been crunching on it for over 45 minutes now.  During this time, I have tried sending various commands to see if it would respond to anything but it appears not to.  The touchscreen has no effect.   

While you may not perceive these as valid use cases for your command, if that's true you need to limit the parameters that can be sent to it and document these limits. 

***
I had assumed you accumulated the data for the average then did a simple divide before sending.   It sounds like this may not be the case and it may be something other than an average. 

[radiolistener]

Odd. That's not what I see with a dumb terminal. 

Using scanraw 0 10000 10000 1000 1000 requires about 17 minutes before the Nano responds.

just tried. It responds in 1 second and sends each frequency step with about 1 second interval. Probably your terminal has some kind of buffering or cache. Try PuTTY

[joeqsmith]

That's really odd.   The scanraw 0 10000 1 1000000 1 required well over an hour before it responded.    Again Nano is locked up from a user perspective this entire time.   

How should it work then?  For the case of scanraw 0 10000 10000 1000 1000, does it do 1000 sweeps at each discrete frequency, do the division then send that one frequency?   

I just tried Tera Term and sure enough, it is sending something.   I still see no way to abort it.  It doesn't appear to respond to any commands until it is finished.   

[radiolistener]

That's really odd.   The scanraw 0 10000 1 1000000 1 required well over an hour before it responded.    Again Nano is locked up from a user perspective this entire time.

This is problem with your terminal application. There is no delay. The first response takes about 0.5 second.

[radiolistener]

How should it work then?

scanraw 0 10000 1 1000000 1 works in the following way:

- measure frequency 10000 Hz
- send measured data to PC
- measure frequency 10001 Hz
- send measured data to PC
- measure frequency 10002 Hz
- send measured data to PC
...

if you requested 1000000 points it can take long time

[joeqsmith]

How should it work then?

scanraw 0 10000 1 1000000 1 works in the following way:

- measure frequency 10000 Hz
- send measured data to PC
- measure frequency 10001 Hz
- send measured data to PC
- measure frequency 10002 Hz
- send measured data to PC
...

if you requested 1000000 points it can take long time

Is there a reason you don't want to discuss the average?   Or am I not being clear when I am asking how the average works? 

And, is there a way to abort it? 

[radiolistener]

Is there a reason you don't want to discuss the average?

Average works in usual way. For example average 3x is specified.
Then it performs 3 measurements: a1, a2, a3.

each measurement is complex, it includes real and imag part.

the result will be calculated in the following way:
real part = ( real(a1) + real(a2) + real(a3) ) / 3
imag part = ( imag(a1) + imag(a2) + imag(a3) ) / 3

And, is there a way to abort it?

yes, you can abort it with power off NanoVNA 

[joeqsmith]

Is there a reason you don't want to discuss the average?

Average works in usual way. For example average 3x is specified.
Then it performs 3 measurements: a1, a2, a3.

each measurement is complex, it includes real and imag part.

the result will be calculated in the following way:
real part = ( real(a1) + real(a2) + real(a3) ) / 3
imag part = ( imag(a1) + imag(a2) + imag(a3) ) / 3

And, is there a way to abort it?

yes, you can abort it with power off NanoVNA 

Hang in there.  It's slowly sinking in.   

After some trial and error, it seems you limit the number of accumulations to 1000.  1001 errors out.   For a single sample with averages set to 1000,  scanraw 0 10000 1 1 1000, it seems as though you can read at about 1KHz.  So, for 100 samples, can it sweep at 10Hz without averaging?    At least running it with the Tera Term and sending scanraw 0 10000 1 101 1,   it doesn't appear so.    I wonder is the poor update rate really the time it takes to sweep (perhaps limited by the loss of lock)  or is it the data rate. 

[radiolistener]

sweep requires change frequency. Change frequency needs for wait PLL lock, etc.

Average don't needs to change frequency. It just needs to get more samples. This is why it works much more faster than usual sweep.

scanraw works pretty fast for usual measurements. If you want realtime fast sweep several times per second, I think NanoVNA cannot do that, because there is needs some time for pll lock, for channel switch, for gain stabilization, etc.

Average don't needs to switch channel, don't needs to change gain, don't needs to change frequency and don't needs to wait for PLL lock. This is why it can measure several samples more fast.

[joeqsmith]

Thank you for all the information. 

Does your new firmware wait for the lock status?   

Have you looked into the purpose of the other two commands (threshold & transform) you added?   If so, could you provide a brief description?   

[radiolistener]

Does your new firmware wait for the lock status?   

yes, it check hardware status of PLL lock. In, comparison original edy555 firmware just use some delay with no actual check for hardware PLL status. The idea to check PLL status was introduced on this thread by user radioactive.

Have you looked into the purpose of the other two commands (threshold & transform) you added?   If so, could you provide a brief description?

These commands were added by edy555 in original firmware it will be available in the next edy555 firmware release. It just merged to NanoVNA-Q.

"threshold" command allows to change frequency threshold for 1-st harmonic. By default it uses 300 MHz threshold. Bad quality si5351 chips cannot work at 300 MHz. In such case you can decrease threshold.

"transform" command just a console command for DISPLAY => TRANSFORM menu. It enables TDR mode on NanoVNA.

[joeqsmith]

Your lock check routine appears to only be used when changing ranges.  Others appear to use a fixed delay time. 

I tried to download your latest files and now see this error:

./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
 extern uint32_t dfu_reset_to_bootloader_magic;
        ^~~~~~~~

Looks like you have been busy.   Lot's of changes.....

[radiolistener]

I tried to download your latest files and now see this error:

./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
 extern uint32_t dfu_reset_to_bootloader_magic;
        ^~~~~~~~

interesting. I don't have such error, some compiler dependent issue.
You can solve it by adding this line at the top of board.h file:

Code: [Select]

#include <stdint.h>


[joeqsmith]

I tried to download your latest files and now see this error:

./NANOVNA_STM32_F072/board.h:49:8: error: unknown type name 'uint32_t'
 extern uint32_t dfu_reset_to_bootloader_magic;
        ^~~~~~~~

interesting. I don't have such error, some compiler dependent issue.
You can solve it by adding this line at the top of board.h file:

Code: [Select]

#include <stdint.h>


Thanks.  After adding, it builds without any other changes.   It's running the regression now. 

*****

Passes.   

[joeqsmith]

I connected my home made GaAs transfer relay to the nano with two different loads.  I then toggle between the two, collecting and plotting the data while in each state.   The firmware I am using is the one I mentioned in the previous post, so I assume it will have whatever fix was specifically added to try and address the out of sync problem.   

You can see there are two discrete lines for the two states.  If the firmware or my software were to fall out of sync, these two lines are going to swap positions.

This is using my normal method of start, stop, data0, toggle and repeat.   Again, I have never had this be a problem when I use my segmented sweep and am not expecting to find anything.  I'll let it run overnight. 

It's possible that something else was wrong but because of how I talk with the nano, I never run into it. 


**** 

I had the wrong data being plotted, but caught it before calling it a day.   It ran all night and never fell out of sync.