¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: Brick my Nano

 

Thanks Hugen
I think I have to install the drivers first because DFUSe Demo does not "see" my device...


Re: Brick my Nano

 

Thanks Gyula
Better to get, or make a dongle then.....
Have a great weekend
73 de HB9IIU


Re: Brick my Nano

 

Stm32f032 has a built-in BootLoader that can be updated without any risk.

hugen


Re: Brick my Nano

 

Hi Daniel,
Can you read on my website when use ST-LINKv2 dongle :

73, Gyula HA3HZ


Brick my Nano

 

Hi

What are the chances that I brick my NanoVNA when trying to upload a new firmware?
What can go wrong?
Or what does one to be very careful with?

Daniel
73 de HB9IIU


Re: Voltage sensing diode

 

On Sat, Nov 2, 2019 at 03:16 AM, Rich NE1EE wrote:


I got the IMG. Could not get the screen to respond, so turned if off and on.
Worked after that.
This bug present in all firmware. It is related with numpad editor and numeric editor mode.
You can fix it just by pressing joystick left or right.

Unfortunately fix is not so easy, because it involves a bunch of code changes.
I have fix for that bug, but it requires too many changes in the code, so I didn't pushed it into code, because it may break something.


Re: errors of "error" models

 

gin&pez@arg

1) The pdf document you have provided and archived for us is written for a C++ complier. This document plus the subtitle of this post "combined fortran, maxima and gnuplot code for [errors in "error" models]", implies to me your intention to port your Fortran code into the C++ environment, and provide the C++ version here for the convenience of this group. Is my interpretation of your intent correct on this?

2) Please confirm that the G-mini equation you have derived and posted here:



is a "minimal" one port subset of the full set of two port equations posted here:



3) The Nominal values for the SOL standards in the G-mini equation assumptions in #17 at:

/g/nanovna-users/message/4747

are (numerically) defined as perfect. Neither of the above equations provide for standards characterization influences. Are the standards inaccuracies defined and embedded in the uncertainty boundary definitions?

4) The equations defined at



a) The set of Equations (0) through (8) are void of calibration/characterization data, and only require reflection SOL calibration measurements of a single port (S11?). Please confirm that both one and two port calibration is embedded in these calculations, and also confirm that SOL measurements are required on only one port, with the through reference plane defined by the SOL standards used to perform the calibration.
b) Equation (0 ) and its inverse Equation (8) are unclear. I assume the upper case Gamma is the computed reflection coefficient, and the lower case gamma is the measured (DUT) reflection coefficient. Please confirm.
c) In Equation (0), please confirm that S12S21 is an intermediate variable defined in equation (6), and does not imply S12 * S21.
d) In Equation (0), S11 is summed with the computed result of all remaining calculations defined as Equation (0). In other words S11 + (S12S21 * G) not (S11 + S12S21) * G
d) Equations (1) through (4) define the common intermediate denominator D, and intermediate numerators N11, N21N21, and N22 used in Equations (5), (6), and (7) respectively.
e) Equations (5) and(7) are the final calculated reflection coefficient results.
f) Equation (6) is a calculated transmission coefficient. Please explain how to differentiate between forward and reverse transmission results.
g) Uncertainties due to errors in accuracy, and those accounted for through characterization of the calibration standards used (by their absence here) are removed to the DERDEI contour calculations by the relevance of their contributions to the overall uncertainty in the accuracy of the measurements.
h) These equations alone will yield measurement results no better, and no less accurate than existing calibration processes, but are computationally much more efficient.

5) If my interpretation in 5 a) is correct, and only one port is required to be SOL calibrated; have you validated and compared these equations independently for each port in a full two-port system, calibrated with one set of SOL measurements performed at both ports uniquely and independently? This "validation" task cannot be completed on the NanoVNA which has only one reflection port.

6) The forthcoming C++ software (ported Fortran code) will produce the DERDEI (uncertainty) contour calculations given reflection and/or transmission coefficient measurement results and a file of uncertainty boundary estimates as inputs. It is anticipated that the DERDEI uncertainty contour tool will be independent of the calibration algorithm outlined in 4 above, and thus serve the VNA community overall, without compromise, using reflection/transmission coefficient results provided from any source. To that end; I continue to recommend the use of the Touchstone format as the data format of choice for data entry into the DERDEI tool.


73

Gary, N3GO


Re: Voltage sensing diode

 

On Fri, Nov 1, 2019 at 06:31 PM, QRP RX wrote:
NanoVNA-Q 0.4.3 firmware is released:

Glad to upgrade...will have to wait til Sunday to actually mod the VNA so that the battery display works...
Meanwhile...
After upgrading and reseting, I got the IMG. Could not get the screen to respond, so turned if off and on. Worked after that.
I also figured that a good time to put a 50 O load on CHO, press CAL RESET, and take a snapshot w nanosaver 0.1.4.
Hope that this is what you are looking for.
--
On the banks of the Piscataqua
Rich NE1EE


Re: Firmware and dfu-util (Linux)

 

On Fri, Nov 1, 2019 at 07:46 PM, Barry Jackson wrote:


I notice that some .dfu firmware files that I have seen are in the 80kB to
100kB plus so the 16kB looks wrong to me.
16 kB is a page size. It means data chunk size which controller can accept for flashing.
So, software needs to split 80-100 kB firmware to 16 kB data chunks and send it one-by-one.


Re: Console command and FW 0.2.3 edy555

 

On Sat, Oct 19, 2019 at 02:12 PM, Maurizio IZ1MDJ wrote:


I have update the firmware to edy555 0.2.3 , all look ok .
In next step I tried to use console command , which commands is supported ?
---------------------------------------------------------------------------------------

Maurizio,
Sending the command "help" from a serial terminal will return a list of the console command supported by your firmware.

For example:
version
0.2.3

help
Commands: help exit info threads version reset freq offset time dac saveconfig clearconfig data dump frequencies port stat gain power sample scan sweep test touchcal touchtest pause resume cal save recall trace marker edelay capture vbat transform threshold


- Herb


Re: Voltage sensing diode

 

NanoVNA-Q 0.4.3 firmware is released:

Now you can use "vbat_offset" command to setup voltage drop for your diode. :)

In order to save vbat_offset permanently you're needs to save main config with "saveconfig" command or CONFIG => SAVE menu.

Also it has a new battery icon design :)


Re: Console command and FW 0.2.3 edy555

 

Same for me Maurizio
Di you find something in the meantime?
Daniel HB9IIU


Re: Voltage sensing diode

 

On Fri, Nov 1, 2019 at 04:11 PM, Rich NE1EE wrote:
We don't really need a lot of precision, do we? How about a simple resistor
network?
It would mean that the UI would need a linear input dialog: a slope for the resistor networks, and b = 0; and for the diodes, a slope of 0 and b=nnn mV (or whatever)

--
On the banks of the Piscataqua
Rich NE1EE


Re: Voltage sensing diode

 

On Fri, Nov 1, 2019 at 01:53 PM, Nick wrote:
On Fri, Nov 1, 2019 at 05:13 PM, Nick wrote:
Perhaps if VBATEN was set all the time in the firmware a single 16k resistor
at VBAT input (instead of D2) might suffice.
Scrub that. The bridge isn't enabled when the device is switched off because
the firmware is not running.
We don't really need a lot of precision, do we? How about a simple resistor network? Max VBAT ~3.6V with no bridge, 3.15V with bridge, linear response w slope ~= 0.75, 36 uA with no bridge > a long time to drain 450 mAh batt...
--
On the banks of the Piscataqua
Rich NE1EE


Re: Success in automatic bridge and calibration error correction calculation #internals #calibration

 

How embarrassing
There was a mistake in the VNA calibration routine in Octave

Please ignore all this.....
--
Erik, PD0EK


Re: Buttons and power switch in case

 

Nice looking!

Roy
WA0YMH

On Fri, Nov 1, 2019, 12:17 PM Harold Farrenkopf via Groups.Io <hfarrenkopf=
[email protected]> wrote:

Bought the 3D printed case off eBay with the intention of mounting
individual mini push-buttons that I had but found an old 3 by 4 keyboard
that had nice feeling buttons so I cut it up and glued it in the case's top
half. I also glued a toggle switch for the power in the lower half instead
of that cheap slide switch. Now the playing begins. Need to update firmware
with one that has better button detection because that is part of the
crappy jog switch's poor operation. Is there a version of firmware that
improves the button detection now that I have good buttons?
BTW, nice performance for the money! I've always used HP/Agilent VNA's for
work and for the last 17 years, the 8753ES with the 6GHz and TDR options.

Harold, VA3HF




Re: Android NanoVNA WebApp - does not work on version 6x

 

Apparently only for 7+ now
.. and not even that for an acer CB5-571 Chromebook that emulates Android 7.1
The app installs fine from Play Store; simply search for nanovna.
Unfortunately, the app always reports "No device found!" to Connect.

This Chromebook can communicate with nanoVNA using Diginow Serial Terminal.


Re: Voltage sensing diode

 

On Fri, Nov 1, 2019 at 05:13 PM, Nick wrote:


Perhaps if VBATEN was set all the time in the firmware a single 16k resistor
at VBAT input (instead of D2) might suffice.
Scrub that. The bridge isn't enabled when the device is switched off because the firmware is not running.
.


Firmware and dfu-util (Linux)

 

I am interested in testing other firmware than that installed on my "white with gecko logo" version of nanovna.

I have dfu-util installed in my Mageia linux desktop which reports as follows from the vna:

[baz@localhost Original]$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Found DFU: [0483:df11] ver=2200, devnum=6, cfg=1, intf=0, path="4-1.5.4", alt=1, name="@Option Bytes /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=6, cfg=1, intf=0, path="4-1.5.4", alt=0, name="@Internal Flash /0x08000000/064*0002Kg", serial="FFFFFFFEFFFF"

So question one is why does it see two different devices for the vna?

If I attempt to download the contents of either Alt 0 or Alt 1
I get around 16kB of binary file from each. Both are binary equal when compared with diff.

So question two is how big is the stock firmware and is the 16kB file that I am recovering the whole of it? If not why not?

[baz@localhost Original]$ dfu-util -d 0483:df11 -a 0 -U original.dfu -vv
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
Limiting default upload to 16384 bytes
Upload [=========================] 100% 16384 bytes
Upload done.
[baz@localhost Original]$

NOTE dfu-util refers to *Upload* from device where I would refer to *download* from the device. :\

I notice that some .dfu firmware files that I have seen are in the 80kB to 100kB plus so the 16kB looks wrong to me.

However I want to be sure that I have a backup of the original before attempting an install of a different firmware.

I have attached a much more verbose output from the download if it helps anyone.

Only constructive comments please as threads are bloating beyond sanity in the list

Barry
G4MKT


Buttons and power switch in case

 

Bought the 3D printed case off eBay with the intention of mounting individual mini push-buttons that I had but found an old 3 by 4 keyboard that had nice feeling buttons so I cut it up and glued it in the case's top half. I also glued a toggle switch for the power in the lower half instead of that cheap slide switch. Now the playing begins. Need to update firmware with one that has better button detection because that is part of the crappy jog switch's poor operation. Is there a version of firmware that improves the button detection now that I have good buttons?
BTW, nice performance for the money! I've always used HP/Agilent VNA's for work and for the last 17 years, the 8753ES with the 6GHz and TDR options.

Harold, VA3HF