Re: Using Linux CLI dfu-util question.
Hello Andy,
When you look what is online on USB you will see (nanoVNA):
$ dfu-util -l
...
Found DFU: [0483:df11] ver=2200, devnum=16, cfg=1, intf=0, path="20-1", alt=1,
name="@Option Bytes /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=16, cfg=1, intf=0, path="20-1", alt=0,
name="@Internal Flash /0x08000000/064*0002Kg", serial="FFFFFFFEFFFF"
When flashing, you have to select alt=0, and USB ID 0483:df11.
e.g.
$ dfu-util -v -d 0483:df11 --alt 0 -D NanoVNA_with_scan_and_1500MHz_tinhead.dfu
This worked on MacOS, but I am shure it will also work on Linux.
73, Rudi DL5FA
|
Using Linux CLI dfu-util question.
Greetings !
I have been sitting on the sidelines collecting information and sorting out what is useful to me etc.
At some point I suppose there will come a time when I have a go at reflashing the firmware for
something new and whizzbang.
I was made aware (by a kind Italian) of dfu-util, a Linux command line program.
As I understand it, I would use it like this with this command - "dfu-util -a 0 -D your-firmware-file.dfu"
But, in another thread I am seeing reference to requiring some device ID number being attached to the command line.
My very brief review of the limited information available says that you only need this if you have multiple devices
connected, and wish to specify an individual device. If only one device is connected, the dfu-util will write or read from it
without any special pointers.
So, would my command line outlined above be correct, or have I got to add some magic ID code into it ?
73 de Andy
|
Re: NanoVNA firmware extended to 1500MHz with added scan command
Hello erik, Rune and tinhead,
Thank you very much for the quick help.
I could calibrate (hopefully) the nanoVNA-1500 board.
See the attached photo nanoVNA-1500_Through_LCD_DSC08128.jpg
The python3 program nanoVNA-saver 0.0.9 from Rune also works with the 1500 firmware,
see the screen shot nanoVNA-saver-1500-Through.png
Now it needs further testing.
|
Re: NanoVNA firmware extended to 1500MHz with added scan command
i'm on windows, so have different tools (DfuFileMgr.exe), for you "dfu-tool set-product somefirmware.dfu df11" should work
|
Re: NanoVNA firmware extended to 1500MHz with added scan command
Hello tinhead,
Thank you very much for the file with the original USB ID 0483:df11.
The flashing now works.
Just a question, how can you convert the USB ID in a .dfu file?
73, Rudi DL5FA
|
Re: NanoVNA compared to VNWA
Hi George,
thanks for the credit!
I made several known "Miss-matches" like from 0.1:1 till 10:1. If you use 0805 smd components they work fine up to several GHz. Yes, maybe the Chinese friends jump on it!
Best regards
Norbert
|
Re: NanoVNA firmware extended to 1500MHz with added scan command
the id in Erik's firmware is 0483:0000, so you can convert it, or try to pgm with -d 0483:0000, or take the attached version
|
Re: Time Domain Functionality on device
FWIW there is no reason to truncate the time domain transform except for lack of memory.
A routine means of resampling data is to transform to frequency, pad the high frequencies with zeros and inverse transform.
The length of the trace in time is set by the frequency increment. For a full sweep of from 70 kHz to 900 MHz with 101 points, the length of the TDR trace is ~111 ns. That limits the maximum cable length to about 11 meters. Sampling at 1 MHz intervals will increase the length of the TDR trace to 1 microsecond which is sufficient for 100 meters.
Measuring the length of a cable is best done in the frequency domain by fitting a line to the phase of an open or short reflection from the end of the cable. That will provide very precise information, much better than trying to pick a peak in the time domain. Picosecond travel time to the end of a cable should be obtainable by doing a linear fit to the phase.
It gets more complex if there are multiple reflection events, but the problem is tractable on a PC using a sparse L1 (aka basis) pursuit. The multiple reflection case is probably not solved well by least squares, though it might be stable for 2-3 reflectors.
If there are multiple reflections, the frequency domain will be a sum of R1*exp(j*2*pi*f*t1) + R2*(exp(j*2*pi*f*t2) .... etc. Because it is a sum of products, the A matrix gets rather messy. The only way I can think of to solve it using least squares (L2) would be to transform to time, window the desired event, transform back to frequency and then solve for Ri & ti.
This is where having an STM32F303CCT6 would make life a lot easier.
BTW thanks for documenting the build process on Linux.
Have Fun!
Reg
|
Re: NanoVNA firmware extended to 1500MHz with added scan command
Hello erik,
Thank you for the firmware extension.
I have tried to flash your firmware under MacOS:
$ dfu-util -v -d 0483:df11 --alt 0 -D NanoVNA_with_scan-and_1500MHz.dfu
But I got the error:
dfu-util: Error: File ID 0483:0000 does not match device (0483:df11 or 0483:df11)
What can I do to fix it?
73, Rudi DL5FA
|
Re: NanoVNA compared to VNWA
On Sat, Sep 14, 2019 at 12:54 AM, <norbert.kohns@...> wrote:
Hi George,
thank you very much for evaluating my measurements.
Attached is a picture of the "Standards" that I made. For my opinion these are
very reliable. You can reconnect them and you will still get the exact same
result.
Best regards
Norbert
Nice work Norbert, Wouldn't it be great if someone made up a bunch of these objects and offered for them sale, possibly on ebay. They could be offered with various resistor values from 5 ohm to 500 ohms, with similar reactive components to those that you have used. Also, would like to see them characterized with a commercial VNA so we could see how our NanoVNA is really doing. Of course, SNP files would be provided with them. This would be a nice calibration/validation addition to this unit. Perhaps, our Chinese friends are listening.
|
Short-Open-Load - expected reflected power
Well, I had intended to post something, but on using a better 50-ohm load, and revisiting the calibration procedure a number of times, I now have short-open-load displaying at their expected positions on the Smith chart with the nanoVNA 10 kHz-1500 MHz firmware (sweeping 50 kHz-900 MHz.).
One thing which was confusing me was also using the 1-3000 MHz RF Bridge. I somehow had it in my mind that when the bridge had short or open loads it too would show 100% transmitted power. Of course, this cannot be the case as some of the power will be lost in the resistive divider.
Thanks for making me think (a little)!
Cheers,
David
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
I'm beginning to think that my expectations are incorrect! I'll start a new thread about that, but in the meantime here are three screenshots showing the transmitted power through my 1-3000 MHz bridge with three different terminations on the Device Under Test (DUT) port; short, open and 50-ohm load.
Cheers,
David
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
just in case someone wish to play with it, when you set first "Center" frequency to 1 (and click on x1) and then "stop" to e.g. 100k, you will get 1Hz to 100kHz range displayed.
|
Hi all,
thank you for all support on this Wiki and group. The documents made it easy for me getting started with calibration and basic use of the great little NanoVNA.
73, regards
Lars SM0TGU
|
From: qrp.ddc@...
here is my bridge with fix.
=====================================
Oh, thanks for that. Mine was a boxed unit, and I made some DC resistance measurements:
Resistances, all ports open circuit.
i/p => gnd 25 ohms
o/p => gnd 0 ohms
DUT => gnd 0 ohms
and the input resistors appear to be single 49.9 ohm.
I've attached some photos. Do you think the DC resistance values are correct?
Thanks,
David
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
Hi Dave,
I've certainly seen the problem in cases where the screen did not turn
white, and the device worked fine moments later. So I'm not entirely
convinced it's the same issue?
In any case, stability improvements in the firmware would be much welcome
and appreciated! :-)
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Sat, 14 Sep 2019, 12:36 david mugridge, <dave@...> wrote: David,
Your nanovna not changing frequency is much more likely to be the stability
issue I've described here:/g/nanovna-users/message/2379
You
could see if you can reproduce the problem in the same way I described in
that post.
Allowing a bit more time for the frequency to change will not improve
things. It either changes frequency in less than 10 milliseconds or not at
all.
I've suggested how the stability can be improved by a tweak to the
firmware.
Rgds,
Dave
On Sat, 14 Sep 2019 at 10:06, Rune Broberg <mihtjel@...> wrote:
Hi David,
I have seen situations where the NanoVNA had not changed frequency after
being asked to do so in the about 500ms I've arbitrarily decided to give
it. In this case, it would repeat the data it had prior to changing
frequency, but still send the new frequencies (as some more time would have
passed)
I will try to put some handling of this problem in the next version, which
might just be increasing the delay a little.
--
Rune / 5Q5R
On Sat, 14 Sep 2019, 10:56 David J Taylor via Groups.Io, <gm8arv=
[email protected]> wrote:
From: DMR
RFpro, Firmware 10KHz-1500MHz.
By default, when turned on, 50KHz-900MHz.
Expand the boundaries in the frequency setting menu.
Added dfu menu item, now it is not necessary to close the jumper with
tweezers. This assembly is based on source codes EDY555 & Hugen. At one's
own risk. Work with other software is not guaranteed.
The display measures the reference capacitance 15nf, Port S11.
================================
Thanks for the note. I tried this firmware and indeed it does provide
an
indication of resonance up to 1.5 GHz. I note two oddities:
- when first switching on, the S11 scaling is 1 dB/division, and I'm
unsure
how to change this. Somehow, selecting the yellow trace format it went
back
to a more useful 10 dB/division, but on switching the device back on it
returned to 1 dB. It may be that switching the trace between logmag
and
phase, and back again, restores the 10 dB scaling.
- using the nanovna-saver-v0.0.9, after changing the frequencies and
running
the sweep, the old sweep remained, but the frequencies had changed.
Running
the sweep a second time resulted in a new sweep matching the frequency
scale. This could have just been finger trouble on my part.
On issue I do still see is that while the S11 plots are sensible with
an
antenna connected, with an open ch0 and ch1, the yellow S11 plot shows
from -7 dB to -10 dB across the 0-900 MHz frequency range.
Cheers,
David
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
David, Your nanovna not changing frequency is much more likely to be the stability issue I've described here: /g/nanovna-users/message/2379 You could see if you can reproduce the problem in the same way I described in that post. Allowing a bit more time for the frequency to change will not improve things. It either changes frequency in less than 10 milliseconds or not at all. I've suggested how the stability can be improved by a tweak to the firmware. Rgds, Dave
On Sat, 14 Sep 2019 at 10:06, Rune Broberg <mihtjel@...> wrote: Hi David,
I have seen situations where the NanoVNA had not changed frequency after
being asked to do so in the about 500ms I've arbitrarily decided to give
it. In this case, it would repeat the data it had prior to changing
frequency, but still send the new frequencies (as some more time would have
passed)
I will try to put some handling of this problem in the next version, which
might just be increasing the delay a little.
--
Rune / 5Q5R
On Sat, 14 Sep 2019, 10:56 David J Taylor via Groups.Io, <gm8arv=
[email protected]> wrote:
From: DMR
RFpro, Firmware 10KHz-1500MHz.
By default, when turned on, 50KHz-900MHz.
Expand the boundaries in the frequency setting menu.
Added dfu menu item, now it is not necessary to close the jumper with
tweezers. This assembly is based on source codes EDY555 & Hugen. At one's
own risk. Work with other software is not guaranteed.
The display measures the reference capacitance 15nf, Port S11.
================================
Thanks for the note. I tried this firmware and indeed it does provide an
indication of resonance up to 1.5 GHz. I note two oddities:
- when first switching on, the S11 scaling is 1 dB/division, and I'm
unsure
how to change this. Somehow, selecting the yellow trace format it went
back
to a more useful 10 dB/division, but on switching the device back on it
returned to 1 dB. It may be that switching the trace between logmag and
phase, and back again, restores the 10 dB scaling.
- using the nanovna-saver-v0.0.9, after changing the frequencies and
running
the sweep, the old sweep remained, but the frequencies had changed.
Running
the sweep a second time resulted in a new sweep matching the frequency
scale. This could have just been finger trouble on my part.
On issue I do still see is that while the S11 plots are sensible with an
antenna connected, with an open ch0 and ch1, the yellow S11 plot shows
from -7 dB to -10 dB across the 0-900 MHz frequency range.
Cheers,
David
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
here is my bridge with fix.
|
Yes, I've heard someone else mention that. I can't quite think what causes
it, *assuming* the firmware didn't change the format of the commands used.
I currently just have the one NanoVNA, and as I need to use it for
development, I have been a bit reluctant to flash experimental firmware on
it. I may have to try :-)
Rune / 5Q5R
=====================================
Yes, I also have just the one, and that was the first time I'd flashed new firmware. I was hoping that getting back to a known working version wouldn't be too difficult if I did need to do that! The flashing is very quick.
73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
Hi David,
I have seen situations where the NanoVNA had not changed frequency after
being asked to do so in the about 500ms I've arbitrarily decided to give
it. In this case, it would repeat the data it had prior to changing
frequency, but still send the new frequencies (as some more time would have
passed)
I will try to put some handling of this problem in the next version, which
might just be increasing the delay a little.
Rune / 5Q5R
========================================
OK, Rune.
No problem, providing it looks as if /something/ is happening after you press the Sweep button so that the user gets feedback right away. Of course, it would help if the firmware sent the frequencies first and then the data!
Tried the multiple-sweep option for the first time, and that looks most helpful!
73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv
|
David J Taylor
SM0TGU
