开云体育

On Mon, 7 Oct 2019 at 16:36, <erik@...> wrote:

Adding setting the three parameters
* offset delay of the open
* offset delay of the short.
* C0 of the open
and saving them as part of a config or calibration dataset I know how to do

That would be useful. Note for many of the kits, the male and female
components have different parameters.

Could there be a few user-defined kits? In an ideal world, a few of the
common calibration kits owned by several members on this list (85032B,
85033D/E), as well as a few user-defined ones. I have

* 85050B APC7
* 85032B 3.5 mm
* 85054B N
* 85038A 7-16
* 85039B (75 ohm, type F)

*None of those are popular,* so I would not suggest they need to be in the
firmware. Depending on memory/space on the screen, the 85052B / 85052D
would be nice to have on the menu, but those use exactly the same
coefficients as the 85033D and 85033E.

As strange as it may seem, the 85039A and 85039B type F 75 ohm kits seem
quite popular on eBay. The whole idea of a VNA calibration kit for the F
connector strokes me as a bit odd, but there does seem to be a lot of them
sold. But being 75 ohm, supporting them would no doubt need changes in
several places, and I can't imagine many NanoVNA users wanting to test
devices with F connectors on them.

A few user-defined kits, ideally which one can name, but if not CALKIT 0,
CALKIT 1 etc would be fine.


Dave

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

edy555's 0.2.3 release does NOT lock-up with the capture command.
When I run capture from the command prompt, I get a 2 page dump of non-printing output to the terminal, then I get the ch> prompt back
I assume it's a binary display buffer dump.
The attached file is my teraterm terminal.tty dump:? in console, I hit return twice, then version, then info, then capture, then exit

@Larry
Can you try the edy555 0.2.3 release and see if that also locks up on capture?

Can someone specify how these should be added to the calibration correction calculation?

This is the current code where "measured" is the raw data that gets corrected

void apply_error_term_at(int i)
{
// S11m' = S11m - Ed
// S11a = S11m' / (Er + Es S11m')
float s11mr = measured[0][i][0] - cal_data[ETERM_ED][i][0];
float s11mi = measured[0][i][1] - cal_data[ETERM_ED][i][1];
float err = cal_data[ETERM_ER][i][0] + s11mr * cal_data[ETERM_ES][i][0] - s11mi * cal_data[ETERM_ES][i][1];
float eri = cal_data[ETERM_ER][i][1] + s11mr * cal_data[ETERM_ES][i][1] + s11mi * cal_data[ETERM_ES][i][0];
float sq = err*err + eri*eri;
float s11ar = (s11mr * err + s11mi * eri) / sq;
float s11ai = (s11mi * err - s11mr * eri) / sq;
measured[0][i][0] = s11ar;
measured[0][i][1] = s11ai;

// CAUTION: Et is inverted for efficiency
// S21m' = S21m - Ex
// S21a = S21m' (1-EsS11a)Et
float s21mr = measured[1][i][0] - cal_data[ETERM_EX][i][0];
float s21mi = measured[1][i][1] - cal_data[ETERM_EX][i][1];
float esr = 1 - (cal_data[ETERM_ES][i][0] * s11ar - cal_data[ETERM_ES][i][1] * s11ai);
float esi = - (cal_data[ETERM_ES][i][1] * s11ar + cal_data[ETERM_ES][i][0] * s11ai);
float etr = esr * cal_data[ETERM_ET][i][0] - esi * cal_data[ETERM_ET][i][1];
float eti = esr * cal_data[ETERM_ET][i][1] + esi * cal_data[ETERM_ET][i][0];
float s21ar = s21mr * etr - s21mi * eti;
float s21ai = s21mi * etr + s21mr * eti;
measured[1][i][0] = s21ar;
measured[1][i][1] = s21ai;
}

Adding setting the three parameters
* offset delay of the open
* offset delay of the short.
* C0 of the open
and saving them as part of a config or calibration dataset I know how to do

Seems to work well.

One small request - Could the velocity factor that has been used please be added to the TDR marker text, or displayed in some other way, so that it's more obvious if you have used the wrong value for the type of cable being measured.

Regards,

Martin - G8JNJ

Hot off the presses, folks:

Version 0.2.3

edy555 released this 1 hour ago

-change toggle behavior of trace menu and marker menu
-add transform command to change mode of TDR
- add threadshold command
-remove cal glitch between different harmonic modes
-NanoVNA-saver in multisegment mode shall work well

** Needs touch calibration and save it after flashing firmware.



Regards,
Larry

Hello,

This email message is a notification to let you know that the following files have been updated in the Files area of the [email protected] group.

• /NanoVNA Console Commands Oct-7-19.pdf

Uploaded By: Larry Rothman <nlroth@...>

Description:
This is the latest update of the Console Commands for the NanoVNA as of Oct 7th. It replaces the previous version (Oct-4-19). Please let me know of any errors or omissions.

Cheers,
The Groups.io Team

Are there any *firmware* releases that have support for *proper*
calibration kits? By that I minimum of

* offset delay of the open
* offset delay of the short.
* C0 of the open

More parameters would be useful, especially of lower quality kits, but the
above would be a start

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 W5DXP (and others) -

Help for use of FORMAT options is wanted.
I know a little about LOGMAG, PHASE, SMITH, but:
* when to use others?
* what other settings interact?

On Mon, Oct 7, 2019 at 04:03 AM, Kurt Poulsen wrote:
Kurt,

Thanks for your more detailed explanation. I think I understand the "trick" you are suggesting more thoroughly. It certainly makes a difference if you want to more precisely characterize the 13 micro-Henry inductor at higher frequencies like 30 MHz to 100 MHz.

--
Bryan, WA5VAH

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

Erik,
Your release 0.2.2_1 may have a bug with the 'capture' console command - device locks-up when I try to use capture.
Regards,
Larry

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

As I stated in an earlier post, our communications get somewhat contaminated in translation. Please understand that you have my unreserved agreement on your definition. My use of quotation marks encompassing any... i.e. “any” VNA was intended to communicate that I am not all knowing with respect to the architectural differences employed by various equipment manufacturers. In the context of our discussions, I also believe that the hardware choice is not relevant, and that it is your desire to focus on the software independent of the hardware choice in the evaluation of the derived measurement uncertainties. My overtly verbose description was an attempt to separate the hardware from the software, to ensure my understanding of the point that the hardware employed for the measurements is irrelevant.

I have not yet read your response in its entirety. I sensed a priority to put your mind at ease, and respond immediately in that regard. I will comment on anything I feel unclear about your response after giving it my undivided attention.

73

Gary, N3GO






agreement

--
73

Gary, N3GO

I have been unable to upgrade the firmware on my NanoVNA on Windows. Every approach I try ends up with the DFU tool claiming that the file I'm trying to program is the wrong format. I pointed to several different .dfu files, and also tried to use the DFU file manager to read the file, with the same error. I got the same issue on two different Windows laptops, both running Windows 10. Maybe there is a driver step I'm overlooking, or that is assumed in the instructions?

However, I was able to program my NanoVNA on the first try on my Mac, using the same .dfu files.

Ralph

Hi W5DXP:

How about this?

I notice that your PNG lacks recent TRANSFORM update.

Tricky CSS in
automagically draws menu tree leaves, branches and twigs
by redefining relatively simple HTML (<dl><dt><dt>, <ul><li>, <p> <tt>)
that reflects menu structure and which markup is relatively easy
to revise and supplement with tool tips and links.

I lack wit or ambition to invent CSS that dynamically optimizes path generation.
I reject JavaScript, based on traumatic stress as Unix system administrator
when enterprise IT released pathological proxy.pac.

I lost sleep last night, pondering Stan's suggestion for CSS changes
which may result in overall cleaner (if not smaller) diagrams.

I still think it better to first complete
adding more help links and tool tips for recent firmware extensions.

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