|
On Wed, Oct 23, 2019 at 11:15 PM, Oristo wrote:
Changing edelay from 10 to -10 by shell makes no noticeable change on DELAY
format
with a prominent reflection pulse and marker around 250MHz.
You can notice difference on Series and Parallel RLC screen. Higher frequency has higher difference. 10 picoseconds is a small delay for NanoVNA you may lose difference in the noise.
|
On Wed, Oct 23, 2019 at 11:15 PM, Oristo wrote:
50x larger edelay values visibly shift the trace vertically..
edelay 200 picoseconds visible very good, especially at high frequencies, above 200 MHz.
|
You can notice difference on Series and Parallel RLC screen.
Higher frequency has higher difference.
10 picoseconds is a small delay for NanoVNA
you may lose difference in the noise. I agree that edelay >>affects results<<. My point is that standalone device users seemingly cannot display current edelay >>setting value<<, e.g. when RECALLing another calibration. Settings RECALLed for e.g. FORMAT, TRACE, STIMULUS and other SCALE settings are fairly obvious, not so for edelay. For example, I may have calibrations for four test jigs with the same settings EXCEPT for ELECTRICAL DELAY (and actual correction values) with no way to distinguish them (except personal memory), but they should probably have different edelay settings. I could label test jigs by "RECALL 1" or so, but more than 4 test jigs are better labelled by edelay values that seemingly require host connection to query.
|
Why not use a dash after the data command to enable extended features.
For example:? data - x y z
If there is no extended data command then it will return an error with the dash.?
Or...the firmware devs can all agree on a status word as I suggest in a previous post.?
On Wed, 23 Oct 2019 at 4:13 PM, QRP RX<qrp.ddc@...> wrote: 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?
|
On Thu, Oct 24, 2019 at 01:25 AM, Larry Rothman wrote:
Why not use a dash after the data command to enable extended features.
For example:? data - x y z
The problem here is how PC software can determine if this firmware supports extended options for data command or not. Check if firmware supports some command is very easy, you can just search command in the "help" command output. But since "data" command already exists in all firmware versions, there is no way to check if this firmware supports extended options for "data" command. If you execute extended option on an old firmware it will leads to error.
|
On Thu, Oct 24, 2019 at 01:20 AM, Oristo wrote:
My point is that standalone device users seemingly
cannot display current edelay >>setting value<<, e.g. when RECALLing another
calibration.
This is because you're using very old firmware. For example here is NanoVNA-Q 0.4.1: As you can see, if edelay is not zero, it shows Edelay value on the left top corner.
|
How do I upgrade the firmware?
|
Hi Bob How do I upgrade the firmware? Go to /g/nanovna-users/wiki... and scroll down to "Firmware" If driver issues, follow "Installing the STM32 Virtual COM port drivers:" at the bottom Follow "Easy windows firmware update using DFU files" /g/nanovna-users/files/Firmware/Windows%20guide%20on%20how%20to%20write%20firmware.pdf...and perhaps read Mike N2MS' testimonial If unclear about DFU jumper, see images with: /g/nanovna-users/message/2557e.g. /g/nanovna-users/photo/0/418?p=Created,,,20,2,400,0 /g/nanovna-users/photo/0/417?p=Created,,,20,2,400,0
|
This is because you're using very old firmware. Oops, I missed Oct 8 change log entry "feat: add electrical delay to show" .. which evidently is not in NanoVNA-H_AA_20191018.dfu
|
This is because you're using very old firmware. Thanks to NanoVNA-Q-usb-test.dfu, I now see non-zero edelay (using magnification for old eyes)
|
scanraw delivers uncorrected output of unlimited amount of points including
averaging over multiple points (quicker than averaging multiple scans) NanoVNA-Q-usb-test.dfu from QRP has scanraw.. /g/nanovna-users/message/5678
|
Hi QRP,
I'll just note, that at least early versions of the firmware (which still
exist "out there") included commands in the "help" output which did not
exist. I believe the "scan" command started like that? So I have, at least
for now, completely discounted the "help" command as a way of determining
supported features. I could be persuaded to do otherwise for
individual features, though :-)
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Thu, 24 Oct 2019 at 02:20, QRP RX <qrp.ddc@...> wrote: On Thu, Oct 24, 2019 at 01:25 AM, Larry Rothman wrote:
Why not use a dash after the data command to enable extended features.
For example: data - x y z
The problem here is how PC software can determine if this firmware
supports extended options for data command or not.
Check if firmware supports some command is very easy, you can just search
command in the "help" command output. But since "data" command already
exists in all firmware versions, there is no way to check if this firmware
supports extended options for "data" command. If you execute extended
option on an old firmware it will leads to error.
|
I'll just note, that at least early versions of the firmware (which still
exist "out there") included commands in the "help" output which did not
exist. Yes, it seems to me that testing for '?' in return from such commands is the easy way to test for support. Commands that simply change behavior with firmware version are problematic, unless they can be provoked to return '?' for some different argument count or values. Commands (such as "trace") which ignore arguments and change responses independent of anything controlled by shell commands would be most problematic.
|
On Fri, Oct 25, 2019 at 10:43 AM, Rune Broberg wrote:
at least early versions of the firmware (which still
exist "out there") included commands in the "help" output which did not
exist
This is impossible. "help" command implemented in the ChibiOS shell module and returns command list from array of registered commands. If "help" command returns command name, then this command is registered, so it is exists. If some command is missing from "help" command, it means that this command is not registered, so it doesn't exists.
|
scanraw delivers uncorrected output of unlimited amount of points including averaging over multiple points Averaging seems less powerful than I expected; 100 is quite different from 10 for e.g. CH1 terminated by 50 Ohms:
|
With that little number or points it is impossible to judge noise. Try at least 100 points
|
|
|
Averaging reduces noise with the square of the number of averages
From 1 to 10 reduces a factor 3. To 100 should reduce again with factor 3. But it seems a bit less reduction.
|
Averaging reduces noise with the square of the number of averages .. assuming independent random noise. I told gnuplot to fit a cubic: gnuplot> f(x) = a+(b*x)+(c*x*x) gnuplot> fit f(x) 'ch1_100.p' u 1:2 via a,b,c ... rms of residuals 6.24453e-006 (for 10 avg) 5.63911e-006 (for 100 avg) 1.15592e-005 (for 1 avg) From 1 to 10 reduces a factor 3. I got 1.85 To 100 should reduce again with factor 3. I got 1.1 I saw nothing problematic in main.c measure_gamma_avg(), but was a little surprised to see floats inside the loop. IMO, scanraw is probably obscure enough that supporting average only for powers of 2 would allow accumulating integer data by shifts, then converting accumulated to float gamma.
|
On Tue, Oct 29, 2019 at 10:34 PM, <erik@...> wrote:
From 1 to 10 reduces a factor 3. To 100 should reduce again with factor 3. But
it seems a bit less reduction.
More points means more long measurement and more high probability of some interference spike. I think may be there is need for a median filtering, but there is too small memory in order to do median filter for a large amount of points
|
Oristo
