开云体育

Thanks, just need to find the DFU programming software now.

Oristo wrote: I could move that block closer to the left edge, though.

How about this?

Please remember that with rapid S/W development, there will always be some kind of niggling issues somewhere in the code.
To be safe, you can stick with releases from either edy555 or hugen.
Erik also has some cutting edge releases that are based on the 2 sources above.
Check out the firmware folder in FILES. edy555 is at 0.2.2 and erik has just released 0.2.2_1The last Oct 2 release from hugen had some issues.
Read the Oct 2 userguide for flashing instructions - EVERYTHING you need is in the WIKI or FILES sections.
Now play!

When I heard there was the ability to extent the range to 2.5 GHz, I got over exited. Because I'm not forking out $800 bucks for a Analyzer. So which build do you recommend?

How would I go about upgrading the firmware safely?

IMO, most danger comes from potential static discharge
when jumpering DFU contacts.
Firmware bugs may leave nanoVNA in hung state at power on,
so forcing hardware DFU is an ongoing requirement.
I and others added a switch, e.g.

There are several DFU articles linked in Wiki and Files, e.g.

Please DO NOT use that firmware - it was purely experimental and was indicated as such when Erik talked about it.There will be no support if you have any issues.
However, it you DO want to play with it,?/g/nanovna-users/files/Firmware/NanoVNA%20firmware%20build%20by%20Erik

help is updated for new firmware functions

TRANSFORM submenu

37 : The [LeastVNA]

@Gary O'Neil - 6 October 2019 : /g/nanovna-users/message/4194

35 : Straight In The Heart of The Matter - 6 October 2019
/g/nanovna-users/message/4184

-

Dear Gary,

Swell !

We already wrote a detailed draft, as a reply to your
interesting message above, of equal if not more length than that
and we will send it sometime later.

However, we have to interpreter your lengthy message as a kind
of manifestation of hesitation by you - not at all an
unjustifiable one ! - to accept our [AnyVNA] description, that
is of what you already called it "any" VNA, which signifies a
lack of consensus from your side to accept unreservedly that:

"Primarily, [AnyVNA] measures ( Amplitude Ratio , Phase
Difference ) couples in terms of Frequency"

because, according to you:

"More precisely, any VNA measures amplitude vs. frequency, and
either measures or computes phase in accordance with the
architecture of its design"

in which you drop the [Ratio] and [Difference] terms and
exclusively or-ed the measurement with computation, that is
- in our humble opinion - you reduce the Vector Network Analyzer
to a Scalar one, and most importantly, you cancel your attempt
to separate "hw" from "sw" and/or "fw".

After that, because our point of view stays constantly as a
facupov one, that is : From A common User's Point Of View, and
because we trust you, we accept your reservations regarding the
phase in the different ways of "any VNA" realization, and while
we are waiting your full explanations on why your modifications
increase the precision of your "any VNA" description, we
decrease right now our expectations from [AnyVNA] to [LeastVNA],
but we greatly increase its description by giving even more
details as follows - always facupov:

The [LeastVNA] :

(a) has at least one port realized by an external connector
with two sides : an internal and an external ones,

(b) uses an either internal or external device plus internal
circuitry in order to separate two cosinusoidal waves of the
same frequency coexisting at least into its port and beyond
that internally : an Input to- and Output from- the port,
caused by one-or-two coexisting signals at the external side
of its connector,

(c) measures in a range of frequencies "whatever needed" to
form a couple of two dimensionless quantities :

( Amplitude Ratio , Phase Difference )

between two cosinusoidal signals of the same frequency
resulting from- and analogous to- these two Input and Output
waves, respectively, as the first and second operands in these
formed division and subtraction operations,

(d) indicates these two quantities to its user,

(f) provides the user with a conceptual "error" model, that
is with a set of a rather small number of rather simple
algebraic equations, connecting the measurement of any load
with unknown or "known" nominal value Gamma with its indicated
value gamma,

using intermediately three 3 parameters "S", obviously
determinable by measuring three 3 "standard" loads of "known"
nominal value, with obviously the same indications in this
range of frequencies, independently of any other load of
unknown nominal value,

that is, after 4 = 3 + 1 measurements in total,

BUT :

(g) does not provide its user with the means to complete his
measurements because it ignores the uncertainty of these
three 3 "standards" and the inaccuracy of these 8 = 4 x 2
indications.

And we are basing our today description on that 51 years
old simplification - perhaps in the first ever publicly known
related paper - that is:

"is simply a microwave frequency vector ratio voltmeter",

given by Richard H. Hackborn at 'An Automatic Network
Analyzer System', Microwave Journal, May 1968, p.46.

However, yes, indeed. Our research has to do with an investigation
of the possibility of founding a seeing facupov of [AnyVNA] through
[LeastVNA] from now on, or equivalently, after your apt comments,
to see it conceptually. Therefore, we think that we have your
unreserved consensus to this sharable point and thus we put this
Very Cause into our small objective world, that is into our "sow"
from now on.

Please, stay tuned !

Kind regards,

73

nikolitsa oe3zgn|sv7dmc & petros oe3zzp|sv7bax @ arg iaoi nfi

37

Sorry for the stupid question. But a recently saw a firmware update with
the ability to go up to 2.5GHz freq. But I can't seem to find a solid wait
to upgrade on windows.

How would I go about upgrading the firmware safely?

73

On Sun, 6 Oct 2019 at 21:30, <in3elx@...> wrote:

Now I am forced to save only 2 memories:
0) 1Mhz-900Mhz; track 1: SWR CH1; track 2: Smith CH1
1) "empty"
2) "empty"
3) "empty"
4) 1Mhz-900Mhz; track 1: LOG CH1; track 2: LOG CH2

Why?

Ciao Roberto,
I wish I had the time to look at the code but my 'real' job keeps me
very busy. :-(

The developer of the firmware you are using might be reading this
group... or might not.
It's good to ask here first, because someone else might have already
seen the bug, or maybe has a way to work around it.

If no one here has any thoughts to share, then the best idea is to
report the bug to the developer on Github.
For edy555, you can go to and
click on the 'Issues' link near the top.

Thanks for helping to make the NanoVNA project better!
73 de Buck, KC2HIZ
--buck

Hi aa_talaat,

Your smith plot, using linear sample points, is similar to expected results using a Simsmith model. First straight line caused by very wide sample points.
SimSmith model is shown in:

Second SimSmith model in above link is performed with Log sample points to fill in low frequency range.
Ferrite material loss for this device, represented as parallel resistance, Rp, is 600 to 700 Ohms at high frequencies. Near constant parallel loss results with near constant S21 loss at high frequencies, as shown in your measured S21 trace.

John KN5L

On Sun, Oct 6, 2019 at 9:30 PM <in3elx@...> wrote:

I have a problem with all types of firmware (NanoVNA-edy555, NanoVNA-H):
If you execute and save more than two calibrations,
the others ... show always SWR 1:1, even with the SMA connector open (CH0)!

Usually memories (calibrated) that I saved are this:
0) 1Mhz-900Mhz; track 1: SWR CH1; track 2: Smith CH1
1) 1Mhz-30Mhz; track 1: SWR CH1; track 2: Smith CH1
2) 30Mhz-100Mhz; track 1: SWR CH1; track 2: Smith CH1
3) 80Mhz-500Mhz; track 1: SWR CH1; track 2: Smith CH1
4) 1Mhz-900Mhz; track 1: LOG CH1; track 2: LOG CH2

Note: before any upgrade I used the file for cleaning "DMR-CLEAR_MEMORY_DFU.dfu " (131 kB; Sep 30).

FWIW, I don't think DMR-CLEAR_MEMORY_DFU.dfu helps
unless some desired firmware otherwise fails to load.

Now I am forced to save only 2 memories:
0) 1Mhz-900Mhz; track 1: SWR CH1; track 2: Smith CH1
1) "empty"
2) "empty"
3) "empty"
4) 1Mhz-900Mhz; track 1: LOG CH1; track 2: LOG CH2

Why?

My >> guess<< is that
this may be another consequence
from overlap of code and data flash segments.

Developers traditionally like to add new features but dislike testing.
Ideally, code functions and issue resolutions should require
automated unit regression tests, which can be hard for GUI.

I guess this currently happens especially with recent edy555 releases,
which may be more focused on PC software programmer requests:


..than on-device usability.

NanoVNA-H lists fewer issues:


Your issue could be added, if repeatable...

FWIW, I see no issues recalling 4 different calibrations
saved with NanoVNA-H__900_ch_20191003.dfu
from

Hi Bryan
Thank you for your comment. I see you have not fully under my trick, so I will take some small steps to explain what is going on.
Consider we have calibrated at the female SMA calibration plane at the end of the female female adaptor which we do using the supplied male calibration kit and we then add a male to female adaptor and we place a component e.g. a coil on the far end of this added adaptor, one way or the other. The added male to female adaptor constitutes a shunt capacitor to the coil by the delay in ps in this adaptor multiplied by 20fF as 1ps=20fF. For such an adaptor the delay is about 50ps so we have 100fF or 1 pF shunted to the coil and that gives a resonance frequency of 150MHz, if the coil has no self capacitance, which Is has. Bottom line, this 1pF changes the self resonance downwards in frequency. The way the inductance changes you need to do some calculation, but at least you know that the effective inductance will change and drop when we approach towards resonance as the capacitance "steals" some inductance.
In the real life we would like to use a female SMA bulkhead/PCB edge adaptor, for soldering the coil (in this example) to the far end, so we need after the calibration to remove the female female adaptor, which has a delay of 82ps, so now our calibration plane is sitting somewhere out in the blue air. It is actually 17mm from the male calibration plane, to which we fit the bulkhead/pcb edge adaptor, because the velocity in the female female adaptor is 1 mm per 4.83ps and 82/4.83 is giving 17mm without decimal. So what to do ??
That is exactly what the display/scale/Electrical Delay can fix, as it simply pulls the calibration plane backwards and 100ps is just a nice number which pull the calibration plane 18ps into the test cable allowing to add up to 100ps again. As when we then add the bulkhead/PCB edge adaptor we the must move the calibration plane forward again to the rearside of the added adaptor, and a phase trace it the tool to use, as when it show 0 degree out measurement plane is equal to the shifted calibration plane. Thus there is nothing shunting the test object e.g. your coil. There is only a very minor snag as such, because if you used a bulkhead/pcb edge adaptor shorted with a cupper disk, then the delay shall be adjusted by a few ps (now with 180 degree as reference and a hopeless case for th NanoVNA as wobbling up and down between + and - 180 degree )because we have actually removed the fringe C from the center pin being maybe 100fF, but a benefit as we the cane measure capacitances down to a fraction of a pF. Measuring Q requires that if we use a shorted bulkhead/pcb edge adaptor to check the resistance is 0 ohm or few mohm, and that can be this moving backward/forward does not fully satisfy this requirement, as the electrical delay take for granted the impedance of the adaptor/test cable is pure 50 ohm.
I hope this get you on level with this trick
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af bryburns via Groups.Io
Sendt: 7. oktober 2019 03:49
Til: [email protected]
Emne: Re: [nanovna-users] Inductor S21 measurement using nanoVNA

Kurt,

Good points for more precise calibration. It would certainly be more precise than my suggestion. I certainly agree with you that it is a good idea to calibrate as close to the measurement plane as possible.

My basic question is fairly simple. How much change will your approach make to the measurement of a 13 micro-Henry inductor? At 1 MHz a 13 uH inductor has a reactance of 2*pi*13 ohms which is about 82 ohms. At 10 MHz the reactance is about 820 ohms. As an example, how much impact does 100 pico-seconds have at 1 MHz or even 10 MHz. It seems a 100-pico-second delay error would be a pretty small phase change at 1 MHz or even 10 MHz. Perhaps I don't understand your procedure completely.

--
Bryan, WA5VAH

On Sun, Oct 6, 2019 at 09:03 PM, Kurt Poulsen wrote:

I have a suggestion which work with good precision up to 100Mhz

Link added to /g/nanovna-users/wiki/Application-Notes

If you are modelling the terminal SOLT elements correctly you should have the same number of equations as elements. The correct calibration procedure should therefore be extended to beyond, 12, 16 or even 32 point calibration techniques. The use of linear programming or least squares estimation techniques are for the case of fewer equations than the number of elements. It will introduce errors in an unknown and perhaps uncontrolled manner.

Hi David,
I will try sending you an experimental version at some point, and if it
works, I could include that code in the future releases. Whether it keeps
working is a different matter altogether.

Rune
================================

Many thanks, Rune.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv

On Sun, 6 Oct 2019 at 19:26, Oristo <ormpoa@...> wrote:

If the NanoVNA could provide a negative Electrical delay it could be
fixed.

IMHO, we really need a way of *properly* defining a calibration kit in
*firmware*. That means as a minimum a delay, (which can be negative), and
at least fixed capacitance C0 to support *professional* cal kits.

To support poorer kits C0, C1, C2, C3, L0, L1, L2, loss terms and
impedance.

Dave.


--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom

Hi David,
I will try sending you an experimental version at some point, and if it
works, I could include that code in the future releases. Whether it keeps
working is a different matter altogether.

--
Rune

On Mon, 7 Oct 2019 at 08:26, David J Taylor via Groups.Io <gm8arv=
[email protected]> wrote:

The only discrepancy - which is fatal to the software working - that I have
seen thus far, is that the developers have changed the prompt line, which I
use to detect when output from the device has finished. Being able to
detect either prompt might make it work, or there might be other
differences. I don't have a way to test this at this time.

edy555's firmware has recently received a number of updates the use of
which is limited to newer firmwares, but which are pretty much required to
have both fast and stable PC control of the NanoVNA. I'm looking at
implementing support for these in the next version, or the one after, of
NanoVNA-Saver.

I'm all in favour of trying to support the variety of devices and firmwares
that are appearing, but the software is primarily going to be tested
against the hardware I have - a NanoVNA-H running edy555's 0.2.2 firmware
at the moment.

Rune / 5Q5R
======================================

Rune,

I have both the nanoVNA and the nanoVNA-F, and I would be happy to test
any
updates you may bring.

On another PC I do have Python installed (2.7, but could update) so
perhaps
I could help with (some elements of) the source too? I don't know whether
that PC has the right drivers, though.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv

On Mon, Oct 7, 2019 at 04:02 AM, <neb40gsm@...> wrote:

In reference to Alex_M modified version, nanoVNAv1.03TDRb4 doesn't use Python
anymore to measure TDR cable length.

I will be glad to see remark in the about window that TDR code in C# was developed by alex_m :)

You can also add window type selection option. In most case Blackman window provides best result for TDR, but sometimes Rectangle and Triangle window also useful. I didn't added it just because don't have time to work on UI interface.

It's already here, just select window type depends on user selection:

public static complex[] TDR(complex[] vector, WindowType window = WindowType.Blackman)
{
var size = DSP.GetPOT(vector.Length);
size = Math.Max(size, 16384);
vector = vector.ToArray();
if (window != WindowType.Rectangular)
{
DSP.ApplyWindow(vector, window);
}
var ifft = DSP.ZeroPadded(vector, size);
ifft = DSP.IFFT(ifft);
// padding attenuation compensation
DSP.Scale(ifft, (double)size / ((double)vector.Length));
return ifft;
}

The only discrepancy - which is fatal to the software working - that I have
seen thus far, is that the developers have changed the prompt line, which I
use to detect when output from the device has finished. Being able to
detect either prompt might make it work, or there might be other
differences. I don't have a way to test this at this time.

edy555's firmware has recently received a number of updates the use of
which is limited to newer firmwares, but which are pretty much required to
have both fast and stable PC control of the NanoVNA. I'm looking at
implementing support for these in the next version, or the one after, of
NanoVNA-Saver.

I'm all in favour of trying to support the variety of devices and firmwares
that are appearing, but the software is primarily going to be tested
against the hardware I have - a NanoVNA-H running edy555's 0.2.2 firmware
at the moment.

Rune / 5Q5R
======================================

Rune,

I have both the nanoVNA and the nanoVNA-F, and I would be happy to test any updates you may bring.

On another PC I do have Python installed (2.7, but could update) so perhaps I could help with (some elements of) the source too? I don't know whether that PC has the right drivers, though.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv