开云体育

On Tue, 3 Sep 2019 at 18:18, Rune Broberg <mihtjel@...> wrote:

Hello David,
following a request to add better calibration to my app for the NanoVNA, I
have implemented it in the software, but using "ideal" calibration
standards as the reference, as I have nothing better to go on.

I understand from your post that relevant data would be C0-3 of opens, and
offset delays on opens and shorts. Would there be any correction data for a
load? Could you perhaps give an example of values, so I can use appropriate
units for the input fields?

Hi,

The delays offset delays, which are going to be in ps, are likely to be in
the range 0 to 200 ps, but I would suggest the software accept values in
the range of at least -200 to +200 ps. Negative values are very rare but
can have their uses. A very crude female N open standard would have a
negative value for the delay. A resolution of 0.01 ps is necessary.

The values of C0, C1, C2 and C3 should be in the range -10000 to +10000.
It is normal in modern VNA to refer to a female short as being "SHORT -F-"

A value for the load would be a good idea, especially if someone wanted to
work in 75 ohms.

The coefficients of the kits can be found on the Keysight website here



I would suggest you read the values from the column marked "*PNA, ENA,
FieldFox" *as they are defined in the modern format, where the male short,
like that, supplied with the NanoVNA kit, "SHORT -M-" There was an older
convention, that reversed the gender, but all modern VNAs would use that.

Here I will provide links to the kits I suggest are implemented in the
firmware, without the user having to enter them, as these kits are common.

*85033D/D 3.5 mm cal kit. *
85033D/E - the 85033D, 85033E use the same coefficients. So do some other
high-end kits, but you can ignore them.


You can ignore the inductance of the short, and also the loss terms. These
are all going to be negligible at 900 MHz.

** 85032B N cal kit*


Note that one significant difference between these two kits is the 85032B
(N kit) has different coefficients for the male and female parts, whereas
the 85033D/E (3.5 mm kit) has the same coefficients for each.

When one presses the "SHORT" on the screen, you want a menu that offers the
choice of "SHORT -M-" or "SHORT -F-" so the user selects whether the
shorts, and opens are male or female. This is unnecessary on the 85033D/E,
as the coefficients are the same.

*APC7*
For completeness, you might want to define an APC7 cal kit. It's not that
common now, but one can often pick up cheap RF parts with APC7 connectors
on them. The 85031B kit would be the most common. But there are a ton of
APC7 cal kits that are goin to be almost identical



*An annoying problem - I'm not sure the best way around this. *

All the Keysight kits assume that the delay of the thru standard is zero.
This is true if one cable is male and the other female. When performing a
calibration with a female-female adapter, or a male-male adapter, one needs
to take into account the delay of that adapter. It might be best, when one
selects thru, one gets a menue like this.

THRU (0)
THRU (41.232 ps)

with the 41.232 ps being able to be changed if one wanted. THRU (0) would
be used if one cabee is male and the other female, and THRU (41.232) if
there's a female-female bullet in there. It is really annoying in the HP
VNAs I have, that there's no way to define the delay of the thru except by
copying the calibration kit to a user cal kit, then modifying it in there.

I hope you can find the time to help.
I hope that's some help. The equations for the phase shift caused by a
given amount of capacitance is in this document. Just be aware, the gender
of the connectors in that document will be something like "SHORT (F)" which
indicates the test port is female, and the standard is female. Later
Agilent switched to the format used by other manufacturers - namely "SHORT
-M-", with hyphens rather than parentheses.



The phase shift caused by an offset delay is easy to work out.

Thanks,
--
Rune / 5Q5R

Dave

On Tue, Sep 3, 2019 at 09:05 AM, Rune Broberg wrote:

the pip commands are run in a Windows command prompt, not within python
itself. Similarly, the command to start the app is also run from a

Windows

command prompt.

Thanks, Rune.

Still no joy. In the hope that there's something obvious that I haven't
done, let me explain what I've done so far...

The ONLY way I get python to launch is by clicking on the installed
Windows python icon.

Typing "python", or "pip" in the cmd.exe window just gives me a message
that whatever I typed "is not recognized as an internal or external
command, operable program, or batch file."

Note that I am doing this when the command window is pointing at the
directory which contains "python-3.7.4.exe".

If I type "python-3.7.4" at the command prompt -- a new window opens
(Python 3.7.4 Modify Setup -- see attached screen capture).

Anyway, it is all very frustrating. If you don't recognize what I'm doing
wrong, no problem -- I'm about ready to call it quits. (One of the
drawbacks of being retired -- if I were still working this is when I'd put
a call into the IT department and have them take care of it).

- Jeff