|
Among things which may confusingly scrog nanoVNA traces..
Using NanoVNA-H_AA_20191018.dfu,
Setting by menu ELECTRICAL DELAY 50p
.. then shell `edelay` reports 50.000000000
Setting by menu ELECTRICAL DELAY 50n
.. then shell `edelay` reports 50000.000000000
Setting by menu ELECTRICAL DELAY 50000p
.. then shell `edelay` reports 50000.000000000
So far as I know, there is no way to find current ELECTRICAL DELAY value
from touch screen.
So far as I know, setting edelay to other than the value used for calibration
is generally doomed..? It certainly yields weird Smith charts.
menu STIMULUS - PAUSE SWEEP stops data capture,
then e.g. selecting another FORMAT changes display, but
changing SCALE or RECALL settings while PAUSE SWEEP
has no effect on display
I thought that there was a way to disable display refresh
for improving speed of e.g. data capture and return by USB?
If menu STIMULUS - PAUSE SWEEP or shell `pause` is set,
then e.g. shell `data 0` gets no different data is obtained by repeating.
If shell `scan` is set only once, then `data 0` returns identical values each time.
shell `sweep` without arguments still returns its previous settings, which are no longer in effect.
shell `recall n` will recover from `sweep` setting..
I don't want to think about what happens
if shell `save n` after some `scan` setting...
shell `offset` with no argument does not return current value
shell `trace 2` can be set for AA firmware but (so far as I know) has no effect
I would like to document interactions among touchscreen menu CAL CORRECTION
with shell `data` `scan` and `sweep`
but have not sorted a simple conclusive test scheme,
given noisy data.
|
Erik has mentioned that the firmware (his?) disables display refresh while taking measurements. /g/nanovna-users/message/5122? I don't know if that applies to all flavours of current (in the past month) FW out there. Erik might be able to shed some light on this.
On Wednesday, October 23, 2019, 7:57:58 a.m. GMT-4, Oristo <ormpoa@...> wrote:
Among things which may confusingly scrog nanoVNA traces..
Using NanoVNA-H_AA_20191018.dfu,
Setting by menu ELECTRICAL DELAY 50p
.. then shell `edelay` reports 50.000000000
Setting by menu ELECTRICAL DELAY 50n
.. then shell `edelay` reports 50000.000000000
Setting by menu ELECTRICAL DELAY 50000p
.. then shell `edelay` reports 50000.000000000
So far as I know, there is no way to find current ELECTRICAL DELAY value
from touch screen.
So far as I know, setting edelay to other than the value used for calibration
is generally doomed..?? It certainly yields weird Smith charts.
menu? STIMULUS - PAUSE SWEEP stops data capture,
then e.g. selecting another FORMAT changes display, but
changing SCALE? or RECALL settings while PAUSE SWEEP
has no effect on display
I thought that there was a way to disable display refresh
for improving speed of e.g. data capture and return by USB?
If menu STIMULUS - PAUSE SWEEP or shell `pause` is set,
then e.g. shell `data 0` gets no different data is obtained by repeating.
If shell `scan` is set only once, then `data 0` returns identical values each time.
shell `sweep` without arguments still returns its previous settings, which are no longer in effect.
shell `recall n` will recover from `sweep` setting..
I don't want to think about what happens
if shell `save n` after some `scan` setting...
shell `offset` with no argument does not return current value
shell `trace 2` can be set for AA firmware but (so far as I know) has no effect
I would like to document interactions among touchscreen menu CAL CORRECTION
with shell `data` `scan` and `sweep`
but have not sorted a simple conclusive test scheme,
given noisy data.
|
Erik might be able to shed some light on this OK, I found /g/nanovna-users/message/1880.. when some firmware had a `start` shell command. This shell sequence works with recent Hugen 'AA' firmware: pause scan startfreq endfreq count frequencies data resume .. but I still need to sort calibration (or not) interactions
|
If you want to use this command sequence for the edy555 and hugen firmwares:
pause
scan startfreq endfreq count
frequencies
data
resume
you can insert the "cal" and "edelay" command if needed and these apply as on screen
For maximum multi measurements speed you should not "resume" but keep the nanoVNA paused
There is (because of a bad decision by me) possibly confusion on what the "scan" command does.
Edy555 original implementation was scan being equal to sweep and wait till the data was available.
I changed that to have scan doing an on demand scan with unlimited amount of points and NO calibration/edelay being apply
As this lead to two different "scan" command Rune had to sort out the mess.
I intend to change my "scan" command to "scanraw" that will be the same as what already has been implemented by another firmware developer (sorry, forgot your name....)
scanraw will pause the "on screen" measurements as these interfere with realizing maximum speed.
So "scan" will always be in all firmwares an on demand measurement of maximum 101 points with everything (e.g. calibration and edelay) the same as on the screen
|
Hi Erik,
The scanraw command was created by QRP-RX and I have it documented in the console command doc.Since your scan is different from edy555's version, should I change scan reference to what the edy555 scan performs and just leave QRP's scanraw command in place instead of yours ?
toggle quoted message
Show quoted text
On Wednesday, October 23, 2019, 9:27:16 a.m. GMT-4, erik@... <erik@...> wrote:
If you want to use this command sequence for the edy555 and hugen firmwares:
pause
scan startfreq endfreq count
frequencies
data
resume
you can insert the "cal" and "edelay" command if needed and these apply as on screen
For maximum multi measurements speed you should not "resume" but keep the nanoVNA paused
There is (because of a bad decision by me) possibly confusion on what the "scan" command does.
Edy555 original implementation was scan being equal to sweep and wait till the data was available.
I changed that to have scan doing an on demand scan with unlimited amount of points and NO calibration/edelay being apply
As this lead? to two different "scan" command Rune had to sort out the mess.
I intend to change my "scan" command to "scanraw" that will be the same as what already has been implemented by another firmware developer (sorry, forgot your name....)
scanraw will pause the "on screen" measurements as these interfere with realizing maximum speed.
So "scan" will always be in all firmwares an on demand measurement of maximum 101 points with everything (e.g. calibration and edelay)? the same as on the screen
|
Yes, in my next update I will have QRP's scanraw so all firmwares have the same scan command and some have identical scanraw
Will make Rune's life more easy......
|
Thank you, Erik - I might make use of the scanraw functions in a future
version, we will have to see :-)
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Wed, 23 Oct 2019 at 15:51, <erik@...> wrote: Yes, in my next update I will have QRP's scanraw so all firmwares have the
same scan command and some have identical scanraw
Will make Rune's life more easy......
|
Thanks - I will update the console command document accordingly.
toggle quoted message
Show quoted text
On Wednesday, October 23, 2019, 9:51:23 a.m. GMT-4, erik@... <erik@...> wrote:
Yes, in my next update I will have QRP's scanraw so all firmwares have the same scan command and some have identical scanraw
Will make Rune's life more easy......
|
QRP's scanraw command is an extension of Erik's original scan command so you shouldn't have any difficulty adapting.
The big question is do you want to be backwards compatible to Erik's old scan command or just declare all 'Saver versions going forward from 0.1.4 use the new syntax (the better way) and maybe add a quick check with a popup window to get the user to acknowledge the change.
toggle quoted message
Show quoted text
On Wednesday, October 23, 2019, 9:56:06 a.m. GMT-4, Rune Broberg <mihtjel@...> wrote: Thank you, Erik - I might make use of the scanraw functions in a future version, we will have to see :-) -- Rune / 5Q5R On Wed, 23 Oct 2019 at 15:51, <erik@...> wrote: Yes, in my next update I will have QRP's scanraw so all firmwares have the
same scan command and some have identical scanraw
Will make Rune's life more easy......
|
Larry,
in any case, I'd want to check the firmware version and other info in order
to determine what for of commands to use for this particular firmware. I
previously asked edy555 about a command to determine the "capabilities" of
the firmware but he didn't seem hugely keen on the idea. For the PC
software developer, it's of course easiest to just have a command you can
run, and then get back "scanraw-mode-QRP, scan-enabled, max-points=101,
min-freq=50000, ..." and then set up the communications bsed on this. But
this is not (yet) available :-)
I know Erik puts a specific version string in his firmwares, and once I
know from which firmware version he uses a new format, I will try to
support that. :-)
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Wed, 23 Oct 2019 at 16:30, Larry Rothman <nlroth@...> wrote: QRP's scanraw command is an extension of Erik's original scan command so
you shouldn't have any difficulty adapting.
The big question is do you want to be backwards compatible to Erik's old
scan command or just declare all 'Saver versions going forward from 0.1.4
use the new syntax (the better way) and maybe add a quick check with a
popup window to get the user to acknowledge the change.
On Wednesday, October 23, 2019, 9:56:06 a.m. GMT-4, Rune Broberg <
mihtjel@...> wrote:
Thank you, Erik - I might make use of the scanraw functions in a future
version, we will have to see :-)
--
Rune / 5Q5R
On Wed, 23 Oct 2019 at 15:51, <erik@...> wrote:
Yes, in my next update I will have QRP's scanraw so all firmwares have the
same scan command and some have identical scanraw
Will make Rune's life more easy......
|
Hi Erik - So "scan" will always be in all firmwares an on demand measurement of maximum
101 points with everything (e.g. calibration and edelay) the same as on the screen .. then how will "scan" differ from "sweep"? I intend to change my "scan" command to "scanraw"
that will be the same as what already has been implemented by another firmware developer If there is/has been only one "scanraw" behavior, then host apps need only test for "scanraw ?" response to determine support This seems less problematic than coding rules based on e.g. parsing version string. If edy555 shell recognizes some >>other<< command that Erik's firmwares do NOT (or vice versa) then testing for '?' in response to that could sort "scan" behaviors.
|
Actually, it's even easier than that - there should be a single 16bit word defined where each bit describes the inclusion of a feature.That string would be defined as a variable at the start of Main or even just a single include file, then included in the version cmd output.
The big problem is getting everyone to agree on the bit definition and to actually use it.Since several developers already use the original edy555 repo, if edy555 can assign this, it may make developing external PC apps easier.
I will enter an enhancement request.
I've attached an example for the various developers to comment on....
...Larry
toggle quoted message
Show quoted text
On Wednesday, October 23, 2019, 10:36:57 a.m. GMT-4, Rune Broberg <mihtjel@...> wrote: Larry, in any case, I'd want to check the firmware version and other info in order to determine what for of commands to use for this particular firmware. I previously asked edy555 about a command to determine the "capabilities" of the firmware but he didn't seem hugely keen on the idea. For the PC software developer, it's of course easiest to just have a command you can run, and then get back "scanraw-mode-QRP, scan-enabled, max-points=101, min-freq=50000, ..." and then set up the communications bsed on this. But this is not (yet) available :-) I know Erik puts a specific version string in his firmwares, and once I know from which firmware version he uses a new format, I will try to support that. :-) -- Rune / 5Q5R On Wed, 23 Oct 2019 at 16:30, Larry Rothman <nlroth@...> wrote: ? QRP's scanraw command is an extension of Erik's original scan command so
you shouldn't have any difficulty adapting.
The big question is do you want to be backwards compatible to Erik's old
scan command or just declare all 'Saver versions going forward from 0.1.4
use the new syntax (the better way) and maybe add a quick check with a
popup window to get the user to acknowledge the change.
? ? On Wednesday, October 23, 2019, 9:56:06 a.m. GMT-4, Rune Broberg <
mihtjel@...> wrote:
? Thank you, Erik - I might make use of the scanraw functions in a future
version, we will have to see :-)
--
Rune / 5Q5R
On Wed, 23 Oct 2019 at 15:51, <erik@...> wrote:
Yes, in my next update I will have QRP's scanraw so all firmwares have the
same scan command and some have identical scanraw
Will make Rune's life more easy......
|
On Wed, Oct 23, 2019 at 08:40 AM, Oristo wrote:
. then how will "scan" differ from "sweep"?
Sweep sets the start/stop for the next automatic sweep, but you never know when that will happen or when that will be finished when have issued a pause command the automatic sweep stops with scan you run a on-demand sweep and get notified when the sweep is done (the "c>" prompt) but the abilities and the output of scan is the same as the automatic sweep (such as max 101 points) scanraw delivers uncorrected output of unlimited amount of points including averaging over multiple points (quicker than averaging multiple scans)
|
|
|
Back to the original subject issue: Using NanoVNA-H_AA_20191018.dfu,
Setting by menu ELECTRICAL DELAY 50n
.. then shell `edelay` reports 50000.000000000 ch>edelay -50 ch>edelay -50.000000000 At least for this firmware version, there is a disconnect between negative values by shell and screen menu
|
On Wed, Oct 23, 2019 at 02:57 PM, Oristo wrote:
So far as I know, there is no way to find current ELECTRICAL DELAY value
from touch screen.
You can find ELECTRICAL DELAY with touch screen with using DELAY format for the track. It shows Group Delay in picoseconds. But you can change scale to 5 ns, it will be more conveniently to use with usual circuit. For better readability, leave end of cable opened or shorted. Because with good matched load it will be hard to find delay due to weak signal and high noise. In such case you can try to use TDR. But TDR has limited resolution due to lack of memory resources. So, if you want to find delay for well matched circuit, it's better to use PC. For unmatched circuit, you can easily find delay on Group Delay track with no need PC connection.
|
On Wed, Oct 23, 2019 at 05:36 PM, Rune Broberg wrote:
I
previously asked edy555 about a command to determine the "capabilities" of
the firmware but he didn't seem hugely keen on the idea.
Hi Rune, you can check firmware capability with help command. It returns list of supported commands. So, you can check if specific command is supported by this firmware with simple string word search :) I'm planning to implement a new command, probably it will be named "dataall" (suggestions about command name are welcome). This command will be the same as "data", but will allows to read all required data simultaneously with a single request. For example: dataall f01 will read frequency, S11 and S21 data in the following way: 50000 0.1234 0.321 0.2233 0.3456 For example command "dataall 0" will be equals to "data 0", but you can request also frequency data: dataall f0 it will return dataset in the following format: [frequency] [real(S11)] [imag(S11)] It will allows to eliminate all current issues with data transfer and improve update speed. But I'm not sure if it worth do to. What is your thoughts?
|
we can implement this feature for current "data" command, so it will be able to return all requested data in a single response. But unfortunately I don't see easy way on how to determine if firmware supports extended syntax for "data" command.
This is why I'm thinking about adding a new command with different name. It will copy "data" command behavior, but will support extended options. It will be easy to check if this command is present with string search for command name in "help" command response string. Any other idea?
|
You can find ELECTRICAL DELAY with touch screen with using DELAY format for
the track. Changing edelay from 10 to -10 by shell makes no noticeable change on DELAY format with a prominent reflection pulse and marker around 250MHz. 50x larger edelay values visibly shift the trace vertically.. Certainly, no numeric value for electrical delay setting is visible.
|
dataall f0 FWIW, I would prefer 'anydata' over 'dataall' it will return dataset in the following format: [frequency] [real(S11)]
[imag(S11)]
It will allows to eliminate all current issues with data transfer and improve
update speed.
But I'm not sure if it worth do to. What is your thoughts? That eliminates much host script foo, so great IMO, particularly if it works with scanraw averaging.
|
Oristo
