开云体育

Oristo wrote.

" … which should make color fringe artifacts on vertical edges in the PNG"

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

No fringing artifacts noticed (see attachment).

- Herb

Oristo wrote,
"If QRP's NanoVNA-Sharp MOD works with your firmware while my script does not..."
----------------------------------------------------------------------------------------------------

I realized I had only previously used QRP's NanoVNA-Sharp MOD to capture measurement screens. I just now tried to capture on screen keyboard and "Version" screens. It hangs up in the serial I/O routine in the same way your script does using my version 0.2.3 firmware, so no difference there. When my second NanoVNA arrives, I plan on updating to QRP's 0.4.1 firmware.

- Herb

Did not yet try to optimize the delay. Will try
The low frequency phase wobble reduces substantially if I use loadR=50.7
Could that be the actual impedance of the coax? Or is that the value where the bridge is in balance?
I am using the default nanoVNA load for calibration and this is rather accurate

On Sun, 27 Oct 2019 at 17:01, Dr. David Kirkby <
drkirkby@...> wrote:

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

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.

I should have added, that there is possibly some point in including C0, C1,
C2 and C3 on homemade cal kits, but not inductance coefficients.

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