开云体育

Hi Reginald,
in my experience, you can run the serial port at whatever speed you desire
(within reason, I'm sure) - it is a USB serial port, and I'm happily
running it at 115200 in my software with few problems. There is the
occasional single-bit/byte transmission error, but I think that's purely
from the large number of bytes sent. (If anyone has other suggestions, let
me know - it's a TODO on the list).

TLDR: The USB driver negotiates the speed, higher speeds are fine.

--
Rune / 5Q5R

On Wed, 4 Sep 2019 at 01:26, Reginald Beardsley via Groups.Io <pulaskite=
[email protected]> wrote:

One could always use the serial port to control the nano via the console
commands.

I would expect that the speed could be raised to 115200 baud from the
9600 baud default. It might require disabling the display, but if you're
adding a larger display on the Pi Zero it doesn't matter.

In any case, the scripting language of your choice and gnuplot will
produce very nice figures.

Hi Rune --

Well, I ran pdb to look at a few things in Calibration.py --
gm1, gm2, and gm3 all come up with the same values, hence denominator is 0.
I didn't have time to see why s11short, s11open and s11load led to that
though.
I only looked at the first interation through that loop.

Maybe this will help give you a head start on the problem...

73 --
Harry

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