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