开云体育

On Sun, 27 Oct 2019 at 16:02, <erik@...> wrote:

Doing a manual optimization using
openC0=300e-15 F
openC1=-250e-24 F
did result in an reduction of the amplitude variations (blue lines, see
attached picture)
Changing shortL0 seemed to have a similar impact as openC0 so I do not
know how to reduce both amplitude and phase variations (red lines)

Someone else (forget who), showed to my satisfaction at least, that there
was no need for anything beyond C0 for cal kits. He checked 3 kits I own

* 85054B 18 GHz N
* 85052B 26.5 GHz 3.5 mm
* 85050B 18 GHz APC7.

He used some Octave code which showed that for those cal kits at least,
there was no point having any more than C0, as the effects of C1, C2 and C3
are smaller than the uncertainties of the calibration kits.

Your value of 300 fF for C0 seems large. I would expect that to be below
100 fF for almost any kit.

I suspect you are ignoring the offset length, and trying to do it all with
a capacitance, which will not work.

Dave

On Sun, 27 Oct 2019 at 15:34, <erik@...> wrote:

In an older post,(I now fail to find), Kurt explained it is possible to
use, after calibration, a long high quality coax to test and improve the
correction factors of the calibration standard.
So here I am trying to set this up (while learning GNU octave at the same
time).
I calibrated and subsequently measured a 1 meter coax with both open and
short at the end.
The blue lines give the magnitude over frequency (0.5 till 900MHz over
1020 points) of the long coax with both the open and short measurement (I
assume the down angle is caused by energy absorption in the coax and thus
linear and it should be a straight line) and the red lines give the angle
variations (after correcting with a polyfit assuming a constant angle/Hz),
again this should be a straight line
Next step would be to do a least squares fit using the C0,C1,C2 for open
and L0,L1,L2 for short and the length of the short/open to get a perfect
straight lines for the magnitudes and angles
I can share the octave scripts I have created thus far
Any feedback if this approach might work?????

You really don't need to worry about the inductance of a short. Neither my
20 GHz HP 8720D, nor the 40 GHz version, the 8722D, have the ability to
enter the coefficients of the inductance. So really it is a waste of time
on a 1 GHz VNA. It is true that home-built standards are likely to have
more inductance than professional ones, but in my experience at least, it
is unnecessary at 1 GHz.

The small inductance can be compensated for by a *slight* adjustment in the
offset delay of the short. If I look at the offset delay of the short of
the 85052B 3.5 mm cal kit on my 8720D, the value is* 31.798* ps (see
picture), with no ability to specify L0, L1, L2 and L3. If I look at the
Keysight website for the same kit



the offset delay is 31.785 ps, with values for L0, L1, L2 and L3. So
basically adding 0.013 ps to the delay is fine for a 20 GHz VNA with a
26.5 GHz cal kit.

For the 3.5 mm kit, the coefficients for male and female parts are the
same. For N cal kits, that is rarely the case.

I just checked the delays of the shorts for the 85054B 18 GHz N cal kit in
my VNA,

Female short 28.003 ps - Keysight website says 27.990 ps
Male short 63.106 ps - Keysight website says 63.070 ps.

So I would argue, just specifying an offset delay of the short is fine, and
there's no need to specify L0, L1, L2 and L3. Even if the user just takes
the data from the Keysight website, and does not adjust it at all, the
difference at 1 GHz is irrelevant.

I too need to learn Octave. I use Mathematica, but want to get away from
this proprietary stuff.

You don't say what values you are using for the delay at any point. Are you
considering that?

If this works for you:

"arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)"

.. then byte pairs for each pixel are out of order (wrong-endian)
or struct.unpack() pairs bytes from two pixels (because wrong even/odd buffer prune),
which should make color fringe artifacts on vertical edges in the PNG

Here's the same 1:1 choke being measured on the NanoVNA.

Hi Herb -

Hard coding "magic" numbers is not good coding practice

"<76800H" must match 153600 == 320 * 240 * 2 == nanoVNA screen size in bytes

Anything which breaks those "magic" numbers will also almost certainly break more in this script.

So both scripts are running to completion on my set-up with the correct screen
colors now. I'm not sure why "arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr
& 0x07E0) << 5) + ((arr & 0x001F) << 3)" works for you and not for me.

Bit shifts must be coordinated with BOTH:
* struct.unpack() big/little-endian setting
* even or odd byte count pruned or discarded from response[s] after sending "capture\r"

If those shifts do NOT work for you, then either:
* some even number of bytes are being discarded
(e.g. by ser.readline()) or by prune value in b[prune:blen]
* different endian setting, either in firmware or struct.unpack() or your PC OS
* different number of bytes returned by your firmware
between 'ser.write(cmd.encode())' and screen capture data

3. As previously noted, trying to grab a screen with an on screen keyboard or
"Version" screen causes either script to hang somewhere in the ser.read
function. Does this happen with when you use QRP's latest firmware?

No, it works fine, which is why I appended that PNG
to /g/nanovna-users/message/5790

If QRP's NanoVNA-Sharp MOD works with your firmware while my script does not
then perhaps MOD sends "pause\r" before and "resume\r" after..

Thanks Chris, I?ll try to install the biggest possible one that fits well.

El dom., 27 oct. 2019 a las 9:58, Chris Weiss (<cweiss@...>)
别蝉肠谤颈产颈ó:

Chris Weiss wrote:

Keep an eye out for thickness - You've only got ~6mm to work with between the two PC boards.

---------------------------------------------------------------------------------------------

One user who wanted a larger battery solved the thickness problem with additional stand-offs (see attachment).

- Herb

No reason to dilute the other threads on this topic. This is the latest article on this subject from the people at Maury Microwave. Another worthwhile read. The link below takes you direct to the paper and the figures are there for at least this month.



Join the sub for free to download a pdf copy.

Alan

Doing a manual optimization using
openC0=300e-15 F
openC1=-250e-24 F
did result in an reduction of the amplitude variations (blue lines, see attached picture)
Changing shortL0 seemed to have a similar impact as openC0 so I do not know how to reduce both amplitude and phase variations (red lines)

Oristo wrote,

"I do not know why my most recent 'screenV.py' works for me and fails for you;
perhaps because different Python conglomeration..."
--------------------------------------------------------------------------------------

On my NanoVNA with version 0.2.3 firmware, the following changes made your most recent script run to completion with correct screen colors.

1. #x = struct.unpack("<76800H", b[prune:blen])
x = struct.unpack("<76800H", b[:153600])

Prior to your suggested change, the error I received was that a consistent buffer size of 153600 was required. None of my web searches explained how that buffer should be allocated. Hard coding "magic" numbers is not good coding practice, but in this case it works :)

2. #arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)
arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)

Your earlier script worked for me with the correct screen colors. It has the line "arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)" and when I made that change in your current script the screen colors are correct.

So both scripts are running to completion on my set-up with the correct screen colors now. I'm not sure why "arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)" works for you and not for me.

3. As previously noted, trying to grab a screen with an on screen keyboard or "Version" screen causes either script to hang somewhere in the ser.read function. Does this happen with when you use QRP's latest firmware?

I know QRP is wondering what the point of all this is when his NanoVNA-Sharp MOD works perfectly well at grabbing a screen capture. For me its just the exercise of learning Python and understanding another tool for using the NanoVNA.

- Herb

In an older post,(I now fail to find), Kurt explained it is possible to use, after calibration, a long high quality coax to test and improve the correction factors of the calibration standard.
So here I am trying to set this up (while learning GNU octave at the same time).
I calibrated and subsequently measured a 1 meter coax with both open and short at the end.
The blue lines give the magnitude over frequency (0.5 till 900MHz over 1020 points) of the long coax with both the open and short measurement (I assume the down angle is caused by energy absorption in the coax and thus linear and it should be a straight line) and the red lines give the angle variations (after correcting with a polyfit assuming a constant angle/Hz), again this should be a straight line
Next step would be to do a least squares fit using the C0,C1,C2 for open and L0,L1,L2 for short and the length of the short/open to get a perfect straight lines for the magnitudes and angles
I can share the octave scripts I have created thus far
Any feedback if this approach might work?????

Nan wrote: I am trying to evaluate the performance of a 1:1 balun with 11 turns RG400 on 2XFT240-K torroids.

Here's some AIM4170D results for 9 turns RG400 on 2xFT240-K toroids for comparison.

I cannot order at TaoBao :-( I get the following message:

Original: 根据相关地区法律法规及淘宝网政策，该商品无法运送至您所在的国家或地区
Google translate: According to relevant local laws and regulations and Taobao policy, this item cannot be shipped to your country or region

I'm in the Netherlands. This is too bad, I have a clone which works reasonable, but some slight problems make me want the nanoVNA-H version. Hugen, do you have any solution to this problem? Any other way to order?

Keep an eye out for thickness - You've only got ~6mm to work with between
the two PC boards. You may also need some double-sided tape or hot glue to
hold the thing in place.

--
-Chris

Hi Nan,

SimSmith can be used to predict figure of merit difference between 52 and 43 11T on 2X 240 cores. K is similar to 52. Attached is a plot. Little difference above 14MHz. 43 somewhat improved below 14MHz.

Additional information for using SimSmith:


John KN5L

Seems like a good start for a ham project for the test bench

Nothing to stop you

.. except nanoVNA storage limitations.

Things like this are better attempted here: /g/nanovna-f

Hi Warren -

When I use the bridge with the NanoVNA I connect Port 1 to the Input of the
bridge, Port 2 to the output, and terminate the REF port with the NanoVNA 50
ohm load. I then calibrate the VNA for "Through" only with the DUT terminal
open. This sets the CH1 Logmag return loss to zero. From this point forward
calibrated NanoVNAs give identical readings to the RF Bridge down to
reasonable levels.

On recent firmware, this works up to the point of trying to display CH1 in SMITH format.
Small horizontal excursion to OSL occurs for SCALE 1x but becomes only vertical for e.g. SCALE .2x

Adding a firmware option to OSL calibrate CH1 with an external bridge would be neat...

Nothing to stop you - the source code is available to allow you to drive a different screen. As long as the resolution remains the same it should not be too difficult. With a touch interface there is no real need for a rotary encoder, that would perhaps be more work unless it was limited to the functionality of the existing switch.

Am easier method is perhaps to just drive it with a PC?

Mike
G0MJW

On Sun, Oct 27, 2019 at 08:26 AM, Nan wrote:

What are the parameters I need to look at when using the NanoVNA, which would
tell me that there is sufficient choking impedance at the frequency of
operation?

The figure you are primarily interested in is the S11 Resistive component when the two wire ends of the choke are connected across CH0.

You can also measure it as S21 by connecting the two wire ends between the center pin of CH0 and CH1 and then manipulate the data to give you the impedance.

However if you measure S21 insertion gain be aware that the value you are presented with is only valid in a 50 Ohms system, and the common mode impedance on the outside of a coax cable screen varies with wavelength and can be anything from a few tens of Ohms to several K Ohms.

So you can use the figures you obtain as guidance or for comparison purposes, but it won't tell the full story of how well (or badly) the choke will work in situ.

Type K material is similar to type 61 and is more suited to HF band applications. Type 52 may be a better choice for the majority of bands or type 43 or 31 for the LF bands.

Steve, G3TXQ's (SK), website will give you some guidance WRT what to expect with different windings and materials.



Regards,

Martin - G8JNJ

On Sun, Oct 27, 2019 at 11:40 AM, <subs@...> wrote:

that the shield side is effectively the "other half of the dipole". Usually
the shield of an antenna system would be earthed, but in this case when using
the NanoVNA, it would indeed be floating and subject to the influence of
outside factors such as the hand effect.

This is an important 'Gotcha' that catches out many people when measuring antennas.

They disconnect the feeder and measure the antenna at the feedpoint, then wonder why they get unexpected results.

If you are measuring a coax fed antenna and using the VNA at the feedpoint, make sure you connect the outer of the coax to the outer of the VNA SMA connector so that it's more representative of the actual antenna system.

If you are using a balanced antenna with a balun that is working effectively, you should not see any difference between sweeps with the coax screen connected or disconnected.

The Nano VNA is small enough and sufficiently self contained to appear as a balanced load at low frequencies. However as soon as you connect it to a PC, which may in turn be powered from a grounded mains supply, you have an unbalanced load.

You always need to think, "is the antenna I'm measuring configured as it would be when in normal use or am I adding (or leaving out) something in the system that makes it different".

Regards,

Martin - G8JNJ