开云体育

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

Hi Nan-

I use NanoVNA Saver

Sorry, I use scripts to directly read nanoVNA S11 and S21 values by shell commands

I suggest that you search the current NanoVNA Saver topic
/g/nanovna-users/topic/nanovna_saver_0_1_3/34559684

or in all messages, e.g.
/g/nanovna-users/search?d=0&ev=false&q=saver+impedance

Hi Nicholas,

I wrote a short script (using Matlab 2018b) when I first got my nanovna to see if I could talk to it (and probably I cobbled it together from code I found somewhere else on the internet -- I don't recall). But I didn't take it any further because I really liked Rune's NanoVNA-Saver app.

I've attached it (published as an HTML file).

If you run it you should get a list of the frequencies. Also you'll see ASCII data in the 'in' field. But you won't see this until it times out (after a few seconds), as it waits for additional data that will not be arriving.

In other words, the code is *very* basic (just to prove I could get data). But it might provide a starting point for you.

- Jeff, k6jca

perhaps because different Python conglomeration

$ python --version
Python 3.6.6
$ pip freeze
certifi==2019.9.11
numpy==1.17.3
Pillow==6.2.1
pipenv==2018.11.26
pyserial==3.4
virtualenv==16.7.5
virtualenv-clone==0.5.3

Hi Herb -

The colors are off as in your first version of the script.

.. so also change:
arr = 0xFF000000 + ((arr & 0xF800) << 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 3)

The [ nanovna.py capture(self) ] function doesn't seem to work
and I'm sure you wouldn't have re-invented the wheel if it did.
So what's going on with it not working or am I missing something?

I have the advantages of 1) being cynical and 2) simpler Python

b = self.serial.read(320 * 240 * 2)

This does not necessarily return (320 * 240 * 2) bytes into b,
hence:

# unlikely to grab entire screen buffer in one read()
while (blen > (len(b))):
sleep(0.1)
b += ser.read(blen)

#.. which I relearned from Rune.

# Perhaps it should be:
missing = blen - len(b)
while (0 < missing):
sleep(0.1)
b += ser.read(missing)
missing = blen - len(b)

--=--
Also, 'self.send_command("capture\r")' includes 'ser.readline()',
which may or may not already receive "capture\r\n", depending on timing...

I do not know why my most recent 'screenV.py' works for me and fails for you;
perhaps because different Python conglomeration...
what firmware does your nanoVNA run?

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

In your #3, what you're seeing should be due to the fact that the antenna-VNA assembly is "floating" and is
highly subject to things that are in the near field. Basically, anything that is not virtually invisible
to RF (like teflon, etc) becomes part of the antenna system when it is in the near field and when (for
example) your hand comes very close to, or actually in contact with any part of the antenna-VNA assembly,
you become part of the antenna system. Any "shielding" that is only connected to the shield side of the
antenna or the "ground" trace on the analyzer's PCB just becomes part of the antenna system as well. That
alters the impedance seen by the VNA, and that is reflected in what you see on the display. This is why
designing/evaluating antennas for handheld transceivers is such an "interesting" process!

This reminds me of something I read quite some time ago 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. I expected the effect when my hand was near the antenna, but puzzled when I got it by touching the NanoVNA. This is beggining to make sense. Oh, and I will make sure not to do any antenna testing in the kitchen ! :-) Lots of Teflon and metal in there....

With regards to the 'bdist_wheel' problem, mihtjel has replied very quickly indeed! He advises that on Mint, another dependency is required as it is not installed by default with python. An additional package needs to be installed:

python3-wheel

I installed it as he suggested and the pip install completed without error and the application even appears to start faster. I am grateful to him for looking into the matter and making this application available to NanoVNA users. It is so much easier to drive the NanoVNA from a bigger screen!

I will now wait for all my additonal bits to arrive including the SMA 50 ohm load and the stylus. The SMA 50 ohm load will remove the need for any adapters and cables and I can then run through the calibration steps again to see if that improves things. With the stylus I should be able to move the markers without my hand having to be quite as close to the unit. Not sure what to do about the switch yet, but maybe with the stylus it won't matter.

Thank you for all the responses.

On Sun, Oct 27, 2019 at 06:16 AM, hwalker wrote:

It was the only one that worked correctly for me using version 0.2.3 firmware
(sans keyboard and version screen display).

you can use NanoVNAsharp MOD V3 in order to get NanoVNA screenshot, it works ok with any firmware which supports capture command:

On Fri, Oct 11, 2019 at 08:41 PM, alan victor wrote:

I have a sense that I need to be careful here as the Q of the match network must be considered
and properly removed otherwise I may arrive at a error in assessing the antenna Q alone.

you can assume impedance matching network as a part of antenna system. That's ok. With a note - losses in transmission line between antenna and matching network will be multiplied. This is why it's better to place matching network near antenna, as close, as possible.

Hi Oristo

Many thanks for your help. If I need 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? I cannot get S21 values on the graphical plot when I use NanoVNA Saver but can read off the values direct from the VNA display. Am I doing this right?

BR-Nan

On Sun, Oct 27, 2019 at 02:21 AM, Oristo wrote:

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

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

Oristo,
Tks for taking the time to reply. Some observations:

1. With my ver 0.2.3 firmware, x = struct.unpack("<76800H", b[:153600]) does allow your current script to run to completion. The colors are off as in your first version of the script.

2. Your attached script runs fine with my ver 0.2.3 firmware and the coding seems to be "cleaner" as far as readability goes.

3. The master branches for all the nanovna.py scripts use the following function for the capture command:

def capture(self):
from PIL import Image
self.send_command("capture\r")
b = self.serial.read(320 * 240 * 2)
x = struct.unpack(">76800H", b)
# convert pixel format from 565(RGB) to 8888(RGBA)
arr = np.array(x, dtype=np.uint32)
arr = 0xFF000000 + ((arr & 0xF800) >> 8) + ((arr & 0x07E0) << 5) + ((arr & 0x001F) << 19)
return Image.frombuffer('RGBA', (320, 240), arr, 'raw', 'RGBA', 0, 1)

The function doesn't seem to work and I'm sure you wouldn't have re-invented the wheel if it did. So what's going on with it not working or am I missing something?

Regards,

-Herb

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

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

It's not clear from your question what exactly you're trying to measure - balun or RF-choke. According to your description you're trying to measure RF-choke instead of balun.

You can measure RF-choke by connecting it's braid from two sides into CH0 and measure reactance.

If you want to measure balun, then this is different story.

Hi Nan -

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?

First, set STIMULUS for the range of interest before calibrating.
Then I would go here:
He has other, related, articles:

Our Wiki application notes include related "ferrite bead measurements:"
/g/nanovna-users/wiki/Application-Notes

.. and here is a blog with some related techniques and tips:

Hi Herb -

Do you still have a copy of the above screen-saver script?

'git' does (attached):
ormpoa@newgate MSYS /g/Gateway/GitHub/oristo
$ cd nVhelp/html
$ git log | less
$ git status
On branch endian
$ git checkout 8d512e0f screenV.py

The line, " x = struct.unpack(">76800H", b)", seems to be where things fall apart.

You may fix that line by
x = struct.unpack("<76800H", b[:153600])

As I read:
struct.unpack() method restructures data from byte buffer 'b' into 'x'
according to format e.g. ">76800H"
.. which in this case is a count of 76800 half-words (uint16) in
big-endian ">",
meaning that left-most byte of each pair should be considered more significant.
So far as I know, ARM processors may be configured either little- or big-endian,
while x86 processors run little-endian.

The struct.unpack() method insists that buffer byte count exactly satisfy format

Essential differences between the attached and current versions:
The attached:
* discarded echo'ed "capture\r\n" by 'ser.readline()'
* then looped 'ser.read()' until 'b' accumulated at least (153600 ==
320 * 240 *2) bytes,
* then pruned 'b' to the first 153600 bytes
* then shifted RGB565 incorrectly into ARGB8888

The current (4083c059) version uses only 'ser.read()', not 'ser.readline()'
* but for 9 more bytes, to account for echo'ed "capture\r\n"
* 'sleep(0.1)' before 'ser.read()' reduces looping and frees CPU cycles
* prunes buffer 'b' directly into 'struct.unpack()' rather than back into 'b'

I am trying to evaluate the performance of a 1:1 balun with 11 turns RG400 on 2XFT240-K torroids. 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? I believe I cannot read off the impedance Z directly even if I use NanoVNA Saver (V0.1.4). Appreciate any help as I am pretty new and learning to use a VNA.

BR-Nan

I noticed someone has submitted code to edy555 for adding a menu option to display Q on the NanoVNA. The patched code is located at: . Screenshots of the NanoVNA with patch applied are attached.


- Herb

On Sat, Oct 26, 2019 at 09:37 AM, Oristo wrote:

first "working" script gets screen colors wrong:

Update corrects colors (endian was wrong):

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

Oristo,
Do you still have a copy of the above screen-saver script? It was the only one that worked correctly for me using version 0.2.3 firmware (sans keyboard and version screen display). I'll eventually upgrade to QRP's latest software but I'm waiting for my second NanoVNA to arrive before I do so. All the subsequent screen.py scripts freeze the display on my NanoVNA and the shell command-line prompt never returns until I re-start the shell.

The line, " x = struct.unpack(">76800H", b)", seems to be where things fall apart. I admit I don't have any idea what the format ">76800H" is doing.

Tks,

- Herb

-Herb