NanoVNA Custom Software

[joeqsmith]

For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:

scan 50000 900000000 101
frequencies
data 0
data 1

you can do it in the following way:

scan 50000 900000000 101
frequencies
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
...

I assume that the data0&1 will cause the Nano to sweep and update the display then.   

I wonder what drove the change.   If it really takes 1.3 seconds to pull both data sets plus the frequency list, it seems like from your post that the data0 for example could be repeated with an update rate of half that.    Still, not great but it seems be this may be an advantage.   

[joeqsmith]

For those running a newer edy555 firmware (0.2.0+) supporting the "scan" function, the command sequence is as follows:

scan 50000 900000000 101
frequencies
data 0
data 1

you can do it in the following way:

scan 50000 900000000 101
frequencies
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
data 0
data 1
...

I assume that the data0&1 will cause the Nano to sweep and update the display then.   

I wonder what drove the change.   If it really takes 1.3 seconds to pull both data sets plus the frequency list, it seems like from your post that the data0 for example could be repeated with an update rate of half that.    Still, not great but it seems be this may be an advantage.

It appears that the scan must be sent prior to each data set being read, or the same data is read.   The LCD does not appear to update.   So the ordering listed makes sense.   Ignoring the floating point errors, you may be able to ignore the frequencies command and just call say data 0.   The more I look at it, I am missing the point.  The way I structured my code appears very stable and again keeps pace with the slow Nano.  So Scan is out unless I really missed the point of it.

scan 50000 900000000 101
frequencies
data 0
data 1

Sending the Scanraw, followed by Frequencies, the displayed frequency list will not match the requested range.   The software could calculate the frequencies, ignoring the floating point errors.  It's blind faith...

Normally when running a sweep, setting the start frequency to 0Hz will cause the actual start to be whatever the lowest supported frequency is.  With Scanraw, it will report out of range.   I'm not sure why the commands don't work the same in this respect.  As is, without the frequency tracking and lower limit not being coerced, without support for the original command set it would be difficult to find the lower limit.

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

When using the Scanraw and setting the upper frequency to 900MHz and a lower to 100KHz, will cause an out of range error.  I started with 10KHz to 1G which also errors out.   100KHz to 100MHz seems to work.  Same with a 10MHz upper limit.
This was a mistake on my part, using improper syntax.

scanraw
usage: scanraw {channel(0|1)} {start(Hz)} {stEp(Hz)} {count} [average]
ch>

Setting the average parameter to 0 causes an error.  I would have expected that to disable the average.  Again, trail and error.  It's possible that not including the average parameter disables it.   Just a guess.

Again, problems could be on my side.  I have no documentation on how it should be used and what the fringe cases are.  It's a pure design be trial and error, using blind faith.    Oh mighty Nano, please except my offering.....   

I would expect a new command like scanraw to use the start and stop frequencies along with span and such.   I would also expect to be able to use the standard commands like frequencies with it.    Having  a command to enable average and set what ever parameters it needs, then use the other existing commands to support it.   

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.   
 

***
Added a plot showing the result with the Average parameter set to 100.  Without documentation, I am not sure how the average is performed but assume the system performs 100 sweeps to do it.   What is interesting is it takes roughly 11 seconds per command or a sweep every tenth of a second.   If that's true and the Nano can actually scan this fast, not loose lock and send corrupt data,  forget all this scan stuff and speed it up.   I would much rather see a 10Hz sweep rate.   

[V_9]

Dear joeqsmith
i would like to thank you for all this knowledge you are offering.
May I ask you please, what is the program you use and present in your images?
Can you share it with me or let me know about it?
Thanks.

[joeqsmith]

Dear joeqsmith
i would like to thank you for all this knowledge you are offering.
May I ask you please, what is the program you use and present in your images?
Can you share it with me or let me know about it?
Thanks.

If you look at the first few posts in this thread, you will find it's custom and written in LabView.   There is a member here creating a fully open source interface.   I don't know much about it and only tried it out when they first posted about it.   I would imagine by now it's fairly mature.  Being supplied to the public, I would expect it is much more user friendly and well documented.   I would also imagine the support would be there from people using it as well as the author.    Personally, I suggest you have a look.

My software by contrast is really being developed to conduct my own personal experiments with the Nano.  It's an engineering tool at best.  While I have thought about releasing it a few times, reality steps in, bitch slaps me and snaps me out of it.    Lack of time to support it is still the biggest concern I have.  I suspect the majority of uses of the Nano are amateurs and to be frank, I suspect the software in it's current state would not be well suited for this group.     So have a look at the open source and enjoy your Nano.  It's a pretty slick device IMO. 

[V_9]

thank you again for your response

[radiolistener]

The NanoVNA stops sweeping after sending the scan command.

You can use sweep command instead of scan. It works great and allows to update S11 and S21 in a single sweep. At least with NanoVNA-Q it works in such way

How would I programmatically recognize a NanoVNA-Q firmware? Which versions have the scan command? Is it from a specific version number and up? Is it fully compatible with the original firmware, or would I have to make special handling for it?

it has board name: NanoVNA-Q

Yes, it is fully compatible with the latest original edy555 firmware. The only difference is that the data command returns more precise values and frequency range has no rounding error. These bugs are fixed.

[5q5r]

The NanoVNA stops sweeping after sending the scan command.

You can use sweep command instead of scan. It works great and allows to update S11 and S21 in a single sweep. At least with NanoVNA-Q it works in such way

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 has board name: NanoVNA-Q

Yes, it is fully compatible with the latest original edy555 firmware. The only difference is that the data command returns more precise values and frequency range has no rounding error. These bugs are fixed.

Sounds good wrt the board name.  I'm a little confused that you say it's fully compatible, though, if the scan command behaves differently. What rounding error are you saying the edy555 firmware has?

[radiolistener]

Sending the Scanraw, followed by Frequencies, the displayed frequency list will not match the requested range.   The software could calculate the frequencies, ignoring the floating point errors.  It's blind faith...

scanraw use integer frequency arithmetic, there is no floating point error for integer arithmetic. It always calculate exactly the same value.

For example, if start frequency is 1000000 and frequency step is 1000. It is guaranteed that frequency list will be exactly the following:

1000000
1001000
1002000
1003000
1004000
...

The result is always predictable. This is why scanraw don't needs frequencies command.

Normally when running a sweep, setting the start frequency to 0Hz will cause the actual start to be whatever the lowest supported frequency is.  With Scanraw, it will report out of range.   I'm not sure why the commands don't work the same in this respect. As is, without the frequency tracking and lower limit not being coerced, without support for the original command set it would be difficult to find the lower limit.

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

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.

Setting the average parameter to 0 causes an error.  I would have expected that to disable the average.  Again, trail and error.  It's possible that not including the average parameter disables it.   Just a guess.

average = 1 means no average, just single measurement.

average = 0 means zero measurement count and no data. This is why it returns error for zero average.

I would expect a new command like scanraw to use the start and stop frequencies along with span and such.

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.

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

[radiolistener]

I'm a little confused that you say it's fully compatible, though, if the scan command behaves differently.

"scanraw" and "scan" are different commands.

"scan" command works exactly the same as "scan" command in original edy555 firmware.

What rounding error are you saying the edy555 firmware has?

original firmware has frequency rounding error. For example, if you selected 50000 to 900000000 range, you will find that there is no 50000 and 900000000 frequency. All frequency are shifted with random value, about 16 Hz or something like that.

The worse thing is that the real frequency also may be different from that value which you will get with frequencies command. And there is no reliable way to know that it uses proper frequency.

It will be even more confusing, because NanoVNA shows different frequency range than you get with frequencies command.

These bugs are fixed in NanoVNA-Q.

[5q5r]

"scan" command works exactly the same as "scan" command in original edy555 firmware.

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

If it's fully compatible, I think I'll just let it use the same interface as the stock firmware for now.

[radiolistener]

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

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