Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Nanovna-Users
- Messages
Search
Re: Voltage sensing diode
On Sat, Nov 2, 2019 at 03:16 AM, Rich NE1EE wrote:
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:
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:
--------------------------------------------------------------------------------------- Maurizio, Sending the command "help" from a serial terminal will return a list of the console command supported by your firmware. For example: version0.2.3 helpCommands: 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: 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 resistorIt 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: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...Perhaps if VBATEN was set all the time in the firmware a single 16k resistorScrub that. The bridge isn't enabled when the device is switched off because -- 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 |
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. |
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 |
to navigate to use esc to dismiss