¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Nanovna-Users
  2. Messages
Expanded Topics Messages
Date
Re: Thank you

Bob Albert
 

I used to know a guy with your name, worked at ITT in California.

On Sunday, October 27, 2019, 12:38:04 PM PDT, Robert Beltz <bobbr30107@...> wrote:

Thank you for the addition.

Bob Beltz
Re: Question: Is it possible to use calibration imperfections to detect the quality of calibration standards??? #calibration

 

Erik,

Did you take a look at what I did in the following post and the subsequent posts in that thread? This involved trying to fix a poor BNC short and open.

/g/nanovna-users/message/4963

I think this is related to your question.

--
Bryan, WA5VAH
Re: Question on #consolecommands

 

Hi Herb -

Also for me in your current script,
b = b[:153600]
x = struct.unpack("<76800H", b)
Does not give me the same result as:
x = struct.unpack(">76800H", b[:153600])
?????
My script has NEITHER of those for several most recent versions,
instead:

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

This allows easy 'prune' tuning and avoids a buffer copy..

Yours get different results because ">76800H" does big-endian
while "<76800H" does little-endian
Re: Performance of 1:1 Balun

 

I'll try to help, but mostly in order to understand: Why is it you need to
put something into the calculator? Can you not use the impedance
measurements which is shown in NanoVNA-Saver under "impedance" (for any
marker you place)?

S11 return loss is available, as is S11 phase, S21 phase, and S21 gain -
directly in NanoVNA-Saver. I believe these are all you need for the G3TXQ
calculator?

There really isn't any reason to have to go to a different piece of
software to do this: If someone can tell me how to do the calculations, I
might as well put them in the software, and make a "choke measuring mode"
or something :-)

--
Rune / 5Q5R

On Sun, 27 Oct 2019 at 21:21, Nan <vk2krn@...> wrote:

Many thanks for the inputs. I am following G3TXQ method of measuring
common mode impedance. I connected the shields of the input and outputs of
the 1:1 Balun to CH0 and CH1 inputs of VNA. I am trying to get the S11 and
S21 values to input into the XL calculator and I am confused about which
readings I should take from the NanoVNA saver or directly from the NanoVNA.
(I am using 2 X FT240-52 - not K, it was my typo error)

Can someone help me understanding this more clearly? Where I am stuck now
is:

¡° To get S21 Mag(db) and S21 Phase (deg), can I use CH1 Logmag and CH1
Phase? Similarly if I need to measure S11Mag (db) and S11Phase(deg), do I
use CH0 Logmag and Phase respectively?¡± Can I get these values directly
from the NanoVNA or do I need to use NanoVNA Saver or something else?

BR-Nan
Re: Question on #consolecommands

 

Hi Rich -

I'm new to the discursion,
The more, the merrier.

but I see a blue "shadow" on everything...is that deliberate?
No, I called that 'color fringing artifact' and occurs because blue was pick up from the next byte;
there are 2 bytes for each nanoVNA display pixel, and get this effect if off by one

The image posted is 320x240,
320x240 is correct for nanoVNA images and in email attachment, but are downsampled online.

Note the yellow trace has no blue fringe.
That is because yellow has zero for blue value.

Updated Python script applies reverse gamma
to compensate PNG and nanoVNA display difference,
making grids more visible..


$ py screenV.py flut

flut.png

Re: Question on #consolecommands

 

Forgot to include the attachments to the previous post.

foo_2a.png
foo_2.png
foo_1a.png
foo_1b.png

Re: Question on #consolecommands

 

Oristo,
The color fringing wasn't readily apparent to me until I saw the photo attachment from Rich Messeder where his color fringing is easily distinguishable when zoomed in. You are correct that your current script does not exhibit color fringing (attachments: foo_1a = earliest script, foo_1b = current script).

Also for me in your current script,
b = b[:153600]
x = struct.unpack("<76800H", b)
Does not give me the same result as:
x = struct.unpack(">76800H", b[:153600])

The first two statements return an image with no fringing but the screen colors are wrong (see foo_2x attachments). The other statement returns an image with no fringing and correct screen colors (see foo_1b). The two code snippets look the same to me so I'm not sure why the screen colors differ.
------------
P.S.
Rich Messeder,
The fringing is correctable in code but wasn't even noticeable on my screen grab until I zoomed in.

Regards,

- Herb
Re: Performance of 1:1 Balun

 

Many thanks for the inputs. I am following G3TXQ method of measuring common mode impedance. I connected the shields of the input and outputs of the 1:1 Balun to CH0 and CH1 inputs of VNA. I am trying to get the S11 and S21 values to input into the XL calculator and I am confused about which readings I should take from the NanoVNA saver or directly from the NanoVNA. (I am using 2 X FT240-52 - not K, it was my typo error)

Can someone help me understanding this more clearly? Where I am stuck now is:

¡° To get S21 Mag(db) and S21 Phase (deg), can I use CH1 Logmag and CH1 Phase? Similarly if I need to measure S11Mag (db) and S11Phase(deg), do I use CH0 Logmag and Phase respectively?¡± Can I get these values directly from the NanoVNA or do I need to use NanoVNA Saver or something else?

BR-Nan
Thank you

 

Thank you for the addition.

Bob Beltz
Re: Question: Is it possible to use calibration imperfections to detect the quality of calibration standards??? #calibration

 

Well, the delays did not work as expected.
So I'l formulate my tuning question a bit more to the point.

The green line in attached picture shows the outcome of this formula "phase(S11open) - phase(S11short) - pi" of a 1 meter coax cable versus the frequency (0.5 till 900MHz)
The phase is unwrapped to avoid discontinuities.
The line should be flat on 0 independent of the frequency but it is not. 0 means the S11open and S11short are exactly opposite on the smith chart

What parameter of a generic VNA calibration set or bridge imperfection model will allow tuning away the green error at higher frequencies? So the parameter should have an increasing impact on phase errors on higher frequencies and not on amplitude or low frequency phase errors?

As you can see the tuning for the amplitude is progressing rather well. The blue lines show abs(S11open) and abs(S11short)

And I would be most happy if someone can explain how to modify global variables (without a "clear all") from a function as I fail to find how?????

afterfit2.PNG

Re: Your NanoVNA version

 

I don't know who manufactured mine...I purchased from Amazon US from AURSINC.

Attached images in detail, FWIW. Seems like nice work, and I have been able to use nanoSaver and do a firmware update. Windows 10 Pro x64.

~R~

On 2019-10-27 08:08:-0700, you wrote:
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?

NanoVNA AURSINC 7600_3871 20191027 140310.png
NanoVNA AURSINC 7600_3872 20191027 140410.png
NanoVNA AURSINC 7600_3873 20191027 140440.png
NanoVNA AURSINC 7600_3874 20191027 140532.png
NanoVNA AURSINC 7600_3877 20191027 140918.png
NanoVNA AURSINC 7600_3879 20191027 141302.png

Re: NanoVNA-Saver 0.1.3

 

Hi Eric,
no problem - the calculations seem to be *correct* which is the major
hurdle ;-) As I posted, scipy.signal.convole seems a lot faster, and is
probably a good way to do it. The test also revealed that the TDR response
was being re-calculated whenever a marker was moved, which, as it turns
out, was completely unnecessary. So that won't be the case for the next
release :-)

Thanks for your efforts,
--
Rune / 5Q5R

On Sun, 27 Oct 2019 at 13:05, <ericm@...> wrote:

Hi Rune,

I am sorry to hear that the convolve math caused so much delay and that I
didn't notice it. Not sure how to measure this. Running python 3.7.4 under
OSX does not seam to have a lot of delay. Could there be a difference in
python versions? Another member also mentioned in a PM to me that he
experienced higher CPU load.
Fortunately Oristo was able to help us out!
I will try to write down the theoretical background of these routines as
to explain the physical background.

Regards,

Eric
Re: Question on #consolecommands

 

I'm new to the discursion, but I see a blue "shadow" on everything...is that deliberate? The image posted is 320x240, but I understand that this may be different from the device itself somehow. Note the yellow trace has no blue fringe.

~R~

On 2019-10-27 10:37:-0700, you wrote:
Oristo wrote.
" ? which should make color fringe artifacts on vertical edges in the PNG"
------------------------------------------------------------------------------------------------
No fringing artifacts noticed (see attachment).
- Herb

blue fringe on SOME items.png

Re: Question on #consolecommands

 

That image is 215x161, not 320 x 240, and has color fringing.
Oops, >>email attachment<< is correct 320x240 and very clearly has color fringing.
Online images are evidently subsampled...

Try changing 'prune' from 9 to 7 or 8 in the current version at:


Also change, to see first 9 bytes:
#print(b[0:prune])
print(b[0:9])
Re: Strange bug with 5 kHz span

Ed Milcarsky
 

It appears that the latest firmares still do not support a freq step less than 100 Hz. Are there any plans to support a smaller step size? 1 Hz would be great. 10 Hz would be good. Use cases would be narrow cw filters and crystal parameter measurements.
Re: Question on #consolecommands

 

No fringing artifacts noticed (see attachment).
That image is 215x161, not 320 x 240,
and has color fringing.

In buffer, RGB565 should be:
"RRRRRGGGGGGBBBBB"
.. then 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)
converts to:
11111111RRRRR000GGGGGG00BBBBB000

If wrong-endian, then buffer is
GGGBBBBBRRRRRGGG
... and 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)
converts to
11111111BBBBB000GGGGG000RRRRR000

RGB with fringing and those shift requires wrong-endian along with buffer shifted wrong by one byte.

Attached is your image rescaled using 4x4 pixel replication, so no convolution resampling blur

herb.png

Re: Question on #consolecommands

 

Oristo wrote.

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

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

No fringing artifacts noticed (see attachment).

- Herb

foo.png

Re: Question on #consolecommands

 

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
Re: Question: Is it possible to use calibration imperfections to detect the quality of calibration standards??? #calibration

 

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
Re: Question: Is it possible to use calibration imperfections to detect the quality of calibration standards??? #calibration

Dr. David Kirkby from Kirkby Microwave Ltd
 

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.
33881 - 33900 of 39697