NanoVNA Custom Software

[radiolistener]

Well, I did not know that. It makes sense then indeed. So how does NanoVNA Saver and other PC software can get Both - S11 and S21 using single request? - If there is no command then perhaps you can make one? 

yes, technically there is no command which allows to read S11 and S21 simultaneously. And if you want both, you will need to send two requests and it will take two sweeps. It is possible to add such ability, but current PC software don't know about new features, so they will continue to use old command and it will still take two sweeps

This makes a vicious circle. Firmware don't have such command because it is not used in software. And software is unable to do that because there is no such command in firmware

Sending both S11 and S21 is much slower. And there is no needs for S11 and S21 simultaneously. So, I don't see the real needs for command which can send information about both channel simultaneously. If you needs S11 and S21 you can send two data commands. And if you needs just S11 or just S21, you can send single data command. It works pretty good.

[radiolistener]

Is it even legal to use square wave signal for antenna tuning? - Harmonics violate out-of band radiation regulations for sure. It's kinda "spread spectrum" unless CW mode used, but anyway. Many of you are HAMs, right? Perhaps you can comment? - Just curious.

NanoVNA has low power output. The maximum peak power from NanoVNA is about 10 dBm and it is even much smaller on high frequency. This is about 0.01 W power. The average NanoVNA power is about -10 dBm, it is about 0.0001 W. In most countries it is allowed to use such power with no license.

HAMs in most cases using resonant antennas, which actually works as effective bandpass filter due to it's high Q-factor. So, it radiates at ham bands and has very low efficiency outside HAM bands. If you use wideband antenna it will have low efficiency due to low Q needed for wide bandwidth.

As you can see, weak signal from NanoVNA can be radiated at HAM bands and it's power as low, so it cannot affect anything.

[Kalvin]

Possibly - though to confirm, you should probably do multiple sweeps with high averaging. If the dips (or peaks) stay in place, it's a "true" error, if they move around, maybe the averaging isn't good enough to catch it, or you have indeed found a bug that I just haven't recognized ;-)

Everything is fine, there is no bugs. Phew. Three 20x averages of 20dB reflection, they all look basically the same. Conclusion: to get meaningful averaging results, same level of averaging for calibration data is necessary. Now averaging just reveals calibration noise.

Yes, I was going to ask whether the calibration is using the averaging also. If not, then the averaging during actual measurement doesn't really make sense as the calibration data is noisy anyway.

Edit: Probably the calibration should be done using at least twice the averaging compared to the averaging used during the actual measurement.

[ogden]

And there is no needs for S11 and S21 simultaneously.

Nonsense. You again invent strange (to say it politely) arguments out of nowhere, just for argument sake. Not mentioning big VNA's, even Nanovna itself measure S11 and S21 in single scan pass and display both, yet you just decided for everybody that PC application do not need such feature, at least not as fast as nanovna *hardware* allows.    FYI it is very convenient to simultaneously see "both ends" of the filter or diplexer or whatever >=2 terminal thing you measure, especially if you tune it. Then it may be even necessity.

NanoVNA has low power output. The maximum peak power from NanoVNA is about 10 dBm and it is even much smaller on high frequency. This is about 0.01 W power. The average NanoVNA power is about -10 dBm, it is about 0.0001 W. In most countries it is allowed to use such power with no license.

Yes. When transmission is within amateur band. I was talking about out of band spurious emissions that are products of square wave. Let's check FCC 47 Radio Amateur Service regulations, §97.307.(e):

on a frequency between 30–225 MHz must be at least 60 dB below the mean power of the fundamental. For a transmitter having a mean power of 25 W or less, the mean power of any spurious emission supplied to the antenna transmission line must not exceed 25 μW and must be at least 40 dB below the mean power of the fundamental emission, but need not be reduced below the power of 10 μW.

10uW is -20dBm, 25uW is -16dBm. What is level of 3rd harmonic when fundamental of square wave is at -10dBm?

[5q5r]

When NanoVNA-Saver reads a segment, it reads frequencies, S11, S21. 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

(Example there for 50 kHz - 900 MHz)

The timing here is as follows, examples from my own NanoVNA:
0.412s: Sending scan command
0.551s: Asked for frequencies
1.320s: Finished receiving frequencies  <-- This is where the application primarily waits for the device
1.422s: Asked for S11
1.510s: Done reading S11
1.613s: Asked for S21
1.708s: Done reading S21

Total time spent 1.296 seconds plus the processing done in NanoVNA-Saver. Looks like the time between the app saving data is 1.303, so the application uses 7 milliseconds for its internal processing between segments.

I have tried moving the frequencies to be read later, but the pattern is clear that the first data requested after the "scan" command is slowed down by about 6-800ms.

After each command, the application waits 50ms before it starts emptying the buffer. I doubt that this moves the timings significantly, as emptying the buffers takes more than 50ms in all cases, and the PC speed is not the limit.

I don't know how this looks for different firmwares - I only have the one NanoVNA, and I'm not going to flash all kinds of different firmware on it, as I need it for app development However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested. Prior to doing this (when the timing was 300ms), I would sometimes see values from the previous frequency span repeated. It was faster, but less reliable - and I made the decision that reliable is more important than fast. The code is there for anyone who wants to change it for their own priorities

[joeqsmith]

When NanoVNA-Saver reads a segment, it reads frequencies, S11, S21. 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

(Example there for 50 kHz - 900 MHz)
.....

I don't know how this looks for different firmwares - I only have the one NanoVNA, and I'm not going to flash all kinds of different firmware on it, as I need it for app development However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested.
...

When I first noticed the Scan command someone was posting how it worked and I was interested in looking at it but it was disabled in the Hugen code I downloaded.   What was interesting to me is that it sent up the frequency, S11 and S21 data in one call.  Plus it would handle more than the 101 points.   I had hoped it would help speed things up.      While I archived the details how it worked, when I tried to use it with the last image from Radiolistener, it was nothing like what had been presented.  It seems like there were different people creating the same commands.   

Once again, the lack of documentation for the firmware makes it less appealing at least for me at least to try it out.   In the case of the Scan command that's implemented in this particular load,  I suspect it is similar to what you have shown.    The original documentation I have shows the command not applying the calibration.   You don't mention this detail, and I would be guessing and using trial and error.   Certainly one way to develop code.

Their Scanraw may be of more interest to me as it supports some sort of averaging which I don't currently support because of how slow the Nano is.   Currently I will run a smoothing filter across each sweep.  I can easily do this and keep up with that ultra fast 1Hz rate.      I showed a plot and a link to an article about it here:

https://www.eevblog.com/forum/rf-microwave/nanovna-custom-software/msg2703604/#msg2703604


Comment I had archived about the Scan command: 

I added one command to the eddy firmware to enable on demand scans of
arbitrary length (yes, you can scan with one million steps or much more if you want)

Usage:
First pause the continuous scanning with "pause" and the use the "scan" command
to scan [from frequency in Hz] [increment frequency in Hz] [number of steps]
The frequency increment step is for now an integer
The scan command outputs

start
frequency s11_real s11_imag s21_real s21_imag
done

during the scan the calibration is NOT used so the output are uncalibrated numbers
allowing alternative calibration strategies

Example:
ch> pause
ch> scan 5000000 20 5
ch> start
5000000 0.001503840 0.000420701 -0.306770563 0.018568072
5000020 0.000695601 0.000503197 -0.306792527 0.018579231
5000040 0.000532656 0.000520238 -0.306793421 0.018573865
5000060 0.000495833 0.000512704 -0.306819111 0.018593480
5000080 0.000520689 0.000523833 -0.306812644 0.018576323

[ogden]

Good. Seems like least effort solution to PC software "individual data request for each port which results in 2x slower scanning" problem is - just make new data request command ("data01" ?) that returns data for both ports. As we see format is already there, at least on Nano side. Obviously scan shall include NanoVNA calibration corrections.

5000000 0.001503840 0.000420701 -0.306770563 0.018568072
5000020 0.000695601 0.000503197 -0.306792527 0.018579231
5000040 0.000532656 0.000520238 -0.306793421 0.018573865

[OwO]

I'm currently working on porting the firmware to the V2 and I can tell you it's a cesspool of bad design, very typical of embedded code. Implicit function calls everywhere (calling a function without including a header file that contains the declaration, and usually there is no declaration at all), everything communicates through globals, no clear dependency relationship between files, hardcoded callbacks everywhere, compiler warnings seem to be all ignored (because I found a handful of bugs just by looking at the warnings), functions just call each other with no regard to which module it is in (e.g. the si5351 driver accesses global variables declared in main.c), forward declarations in the *caller*'s file, and of course I found one that had the wrong signature. The UI code directly manipulates the ADC FFS.

So far I've decided to simply refractor and integrate the UI code into my own firmware that implements all the VNA functionality from scratch. Of course, the command interface is completely replaced so compatibility is broken and you can get far higher sweep rates. Here is the firmware being worked on: https://github.com/nanovna/NanoVNA-V2-firmware-new

[radiolistener]

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 don't know how this looks for different firmwares - I only have the one NanoVNA, and I'm not going to flash all kinds of different firmware on it, as I need it for app development

that's your mistake and the source of bugs. There is no risk for firmware update, except that you may loss your configuration settings and calibration and will needs to calibrate it from scratch after firmware update. But it takes not so long time.

Probably you're using very old firmware, it has race condition issues, high noise floor, high spikes, frequency step rounding error, frequency range rounding error, data transfer error, floating point precision loss and a bunch of other bugs. I highly recommend to use more new firmware.

However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested. Prior to doing this (when the timing was 300ms), I would sometimes see values from the previous frequency span repeated.

such behavior was possible in the old firmware which has race conditions issues and very unstable.

Now I understand the reason why edy555 added scan command. The difference between sweep and scan commands is just that scan command is synchronized with sweep and waits for scan end before executing next command. The sweep command is not synchronized and don't wait's. That's the difference.

That's why you have long delay on frequencies command executed immediately after scan command. You will needs to wait while scan command execution will be completed (it needs to wait for sweep end).

Now I see that using sweep command very often is not thread safe and may leads to data transfer errors. I will think about it and how to fix it.

By the way, NanoVNA-Q has scan command from edy555 version. So you can use it if you needs scan command. Technically all fixes from edy555 branch are included in the NanoVNA-Q firmware, include these which still not released and will be released in the future release of firmware. In addition it also has some fixes from hugen79 branch. Also NanoVNA-Q has a lot of bug fixes.

[ogden]

it's a cesspool of bad design, very typical of embedded code

Right. It is usually in case of hobby projects that are started by hobbyists who do not foresee that their creation will ever become widely popular. We shall just live with that.

[radiolistener]

I'm currently working on porting the firmware to the V2 and I can tell you it's a cesspool of bad design, very typical of embedded code. Implicit function calls everywhere (calling a function without including a header file that contains the declaration, and usually there is no declaration at all), everything communicates through globals, no clear dependency relationship between files, hardcoded callbacks everywhere, compiler warnings seem to be all ignored (because I found a handful of bugs just by looking at the warnings), functions just call each other with no regard to which module it is in (e.g. the si5351 driver accesses global variables declared in main.c), forward declarations in the *caller*'s file, and of course I found one that had the wrong signature. The UI code directly manipulates the ADC FFS.

уeah, it has poor design. There is also variable which actually #define for struct member access. It very confusing when you debugging the code

The most of warnings, except these about goto statement and floating point conversion, they are fixed in NanoVNA-Q branch.

I also thought about refactoring, but it will take a lot of time. So, I just fixed critical issues in the code and that's it

[radiolistener]

Comment I had archived about the Scan command: 

this scan command was invented by @erikkaashoek, but it is was rejected by @edy555. He implemented scan command as a thread safe version of sweep command.

So, now scan command is just a thread safe replacement for sweep command. And it cannot sweep more than 101 point.

This is why scanraw command was introduced in the NanoVNA-Q. It has the same principle as @erikkaashoek, but a little optimized and improved.

scanraw don't returns frequency, because frequency can be easily calculated by adding step frequency on each step. And it allows to perform average measurement.

But scanraw don't apply calibration to the measurement results, it just returns raw uncalibrated measurements.

If you're planning to add the same command with calibration apply, I suggest to use name scancal for such command.

[5q5r]

you can do it in the following way:

That would just give me the same data over and over. The NanoVNA stops sweeping after sending the scan command.

Even if it did not, my most common use case is to sweep one segment, then the next, then the next, etc.

that's your mistake and the source of bugs.

Good, we got that squared away then.

Probably you're using very old firmware

I think my post makes it quite clear that I have coded the particular sequence for firmwares newer than 0.2.0.  I'm running 0.2.3.

However: For devices that do *not* support the scan command, the application sleeps for a full second after setting the sweep span, to allow the NanoVNA to sweep the frequencies requested. Prior to doing this (when the timing was 300ms), I would sometimes see values from the previous frequency span repeated.

such behavior was possible in the old firmware which has race conditions issues and very unstable.

Yes, that's where the delay is used.

By the way, NanoVNA-Q has scan command from edy555 version. So you can use it if you needs scan command. Technically all fixes from edy555 branch are included in the NanoVNA-Q firmware, include these which still not released and will be released in the future release of firmware. In addition it also has some fixes from hugen79 branch. Also NanoVNA-Q has a lot of bug fixes.

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?

[joeqsmith]

......

By the way, NanoVNA-Q has scan command from edy555 version. So you can use it if you needs scan command. Technically all fixes from edy555 branch are included in the NanoVNA-Q firmware, include these which still not released and will be released in the future release of firmware. In addition it also has some fixes from hugen79 branch. Also NanoVNA-Q has a lot of bug fixes.

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?

I use the Help command and check the list of supported commands before trying to test them.    I would imagine the Info command could be used to narrow it down further. 

While my software will work with the six or so images I have tried (at least to the degree that the firmware works), because I don't use the Scan command,  I can't comment on if that will hinder you or not.   

[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