¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

 

Hi Rudi
Great..
Well you are on your way. I see there is still a small problem as you have not calibrated so the female female adaptor is subtracted during the Thru calibration. When everything is done right the trace in the Smith chart shall run clockwise along a SW2 circle (the 50ohm changed to 25ohm). You trace is running anticlockwise. In the NanoVNA saver the S21 thru delay is a positive delay. Have you made it negative ?? The calibration shall be so the the two SMA male connector must have same phase reference in S21 and that is done by the subtracting the delay of the female female adaptor.
Wheen the T-Adaptor then inserted is adds a s21 delay which causes the trace in the Smith chart to run clockwise
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af reuterr@...
Sendt: 9. november 2019 06:01
Til: [email protected]
Emne: Re: [nanovna-users] T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

On Sat, Nov 9, 2019 at 12:14 AM, Kurt Poulsen wrote:
If you got a SMA male male adaptor try to S11 calibrate at the end of
the male male adaptor and either use my female calibration data and
remember to subtract the female famale delay when calibration the S21.
Hello Kurt,

Thank you very much for your valuable hints.

I made what you reccomendet:
1. Connect the Tee direct to CH0: T-Check_RG316-25cm_CH0-6dB_DSC08176.jpg
2. Add an 6 dB attenuator after the Tee.
3. Shorten the coax cable to RG316 25 cm.
4. Tuned the calibration in NanoVNA-Saver.
5. Adjusted the .S2P file S12 for the 6 dB attenuation.
5. So, up to 450 MHz it is within the 5% Limits. T-Check_Short_CH0-6dB.png

Now I know the direction to work on, if neccessary.
It is always nice to know your limits :-)

73, Rudi DL5FA


Re: NanoVNA-H Big spikes around 300MHz on new unit.

 

it's hard to say something, because there is not enough data on the screen and screen quality is very bad, because this is not screenshot, this is photo.

You can get real screenshot with NanoVNA MOD v3:

Very-very old firmware may not support capture screenshot function. In such case I recommend to update firmware with more new.

For further assistance, please show screenshot (please not a photo, because it's hard to read) which includes at least S11 LOGMAG with 10 dB scale and Smith chart.

You can also try to update with NanoVNA-Q, it has hardware check and will show indication if there is si5351 issue.


Also, note old firmware versions have big spikes at 300 and 600 MHz.


NanoVNA-H Big spikes around 300MHz on new unit.

 

Hello,
A friend of mine has just received a new NanoVNA-H bought from an ebay seller in Essex.

It's one of the cased units with black front and all accessories very nicely presented in a box and even a usb-c to usb-c which works with his Android phone app.

The problem is that after calibrating it and looking at a VSWR plot of the supplied 50 Ohm load there is a massive spike at around 300MHz.

He set the centre frequency to 297MHz with a span of 10MHz and re-calibrated, in order to better see the issue. Scale was set to 0.2/Div.

Attached is a screen shot.

Has anyone else seen this issue, or know the cause?

It can still be returned, but if it is a known issue with a simple fix then that may not be necessary.

Thanks,

Barry
G4MKT


Re: Problem installing NanoVNA saver on Ubuntu 18.04LTS...

 

Hi Ian,
I noticed that the error talks about "No module named 'apt_pkg'"

It looks like others have experienced that particular error, and might have
a solution for it:




It seems from that link that there might be a symlink missing for some
particular package version.

--
Rune / 5Q5R

On Sat, 9 Nov 2019 at 15:32, Ian Beeby <ian@...> wrote:

Ok, so I have now:

a) commented out the version check in setuo.py;
b) run python -m pip install --user --upgrade pip - FAILED so ran
python3.7 -m pip install --user --upgrade pip - SUCCESS (so it seems);
c) re-run python3.7 nanovna-saver.py which resulted in the same traceback
errors as before - a problem with PyQt5

So for some reason it seems that the library is still deficient:-(

Ian

--
Amateur Radio Station G8OGJ
Matlock, England
g8ogj.org




Re: Problem installing NanoVNA saver on Ubuntu 18.04LTS...

 

Ok, so I have now:

a) commented out the version check in setuo.py;
b) run python -m pip install --user --upgrade pip - FAILED so ran python3.7 -m pip install --user --upgrade pip - SUCCESS (so it seems);
c) re-run python3.7 nanovna-saver.py which resulted in the same traceback errors as before - a problem with PyQt5

So for some reason it seems that the library is still deficient:-(

Ian

--
Amateur Radio Station G8OGJ
Matlock, England
g8ogj.org


VNA fixture for SMA and BNC #test-jig

 

Hello,

I recently assembled by SMA and BNC fixture board. You can find the gerbers and Kicad files at



The PCB is designed to work with the SMA or BNC versions of my VNA, but is likely going to be useful for NanoVNA too. It has the following features:

Built in female calibration standards for open, short, load, and thru.

A ZIF socket for easy testing of parts with leads where open, short, load, and thru calibrations may be applied.

A flat part of the board for testing SMA parts. The parts can be held down to the board with a toggle clamp or there are holes through the PCB to apply a vacuum to suck the part down to the board.

Four inputs for other types of test loads as needed.

If you want SMA and BNC boards, you should make separate boards for these, or otherwise the board is going to be too cramped.

Dan


Re: Larger Display

 

Great work!

The ILI9488 displays are 480x320, so twice the pixels, and also come in 3.5
and 4.0 inch LCD sizes. They are controlled very similarly to ILI9341,
with the main difference being the ILI9488 has 24-bit color input and the
ILI9341 has 16-bit color input. I intend to use it on my VNA design.

Dan

On Fri, Nov 8, 2019 at 8:16 AM Larry Rothman <nlroth@...> wrote:

Excellent work and document, Herman.
Thanks for sharing.


...Larry

On Friday, November 8, 2019, 7:02:54 a.m. GMT-5, Herman De Dauw <
on1bes@...> wrote:

Recently I have replaced my 2.8" LCD with a 3.5" version. Document is in
the Files section.
'73 on1bes







Re: errors of "error" models

 

#75: A Mechanical Production of the [LeastVNA] Description

Hello,

Allow us, please, to inform you that we just uploaded a mechanical
production of the [LeastVNA] description, at:



Sincerely,

gin&pez@arg

:75#


Re: Looking for firmware with battery indica

 

Great! Thanks for confirming the issue. I've already opened an issue in hugen's git repo regarding this.?
As for the inverted trace text, did you try tapping the trace menu button a few times?
I found that the first tap selects the trace but does not permanently highlight and second tap changes its state.?
Trying this with the jog is more interesting. Using the jog to highlight a menu button in the trace menu doesn't actually select that trace. You need to press the enter switch to select. Only then can you select and deselect the trace.?
That operation is consistent across all the various dev builds.?
In any case, going forward whatever version 2 of this great little device turns out to have, I hope the devs make the selection switches more responsive.?
Cheers
Larry.??



On Sat, 9 Nov 2019 at 4:23 AM, KV5R<kv5r@...> wrote: Howdy Larry,
I'm running reald-040-1, and have confirmed, playing around in touch menus causes jog to lose green highlight of menu items. I did several tests:
1. as you said, in and out of version, and other menus, several times;
2. in and out of several touch menus, without going to version;
-- menu by jog stopped working (off/on to correct it);
3. Once, I got jog highlight to start working again, without off/on, by going in/out of several touch menus and jogging.

(more testing...) HA! I narrowed it down a bit.
1. Touch Config and and then Back
2. Menu is still displayed, without a green highlight. Jog left. Menu by jog quits working. Jog right simply closes menu.
3. Do #1 again; this time jog right. Highlight reappears; menu by jog starts working again.
It's repeatable; any time an operation (typically Back) results in leaving a menu open without a green highlight, then Jog left, breaks menuing by jog.
Repeating the operation by touch, then Jog right, restores menuing by jog.
Even when menu by jog is broken, touch still works and makes touched button green, but that does not restore proper Jog operation. Touch Back and then jog right gets it working gain.
Hope that's helpful to our devs.

Anyway, I just use the jog for moving markers, as it's still iffy for selecting menus, frequently requiring 2-3 actuations. I understand it's scanned, not interrupt-driven, and is easily missed by the busy little processor.

The only little problem I see in reald is it doesn't reverse text colors (fg/bg) to show which trace is selected, as hugen does. So one must cycle a trace off/on (or move its marker by touch) to make sure it's selected, before using Format, Scale, etc.. No biggie, but the pre-selection of trace might be confusing to new users, particularly with no visible indication of which one is selected, prior to a subsequent trace-related operation.
73, --kv5r


Re: Looking for firmware with battery indicator, 1500 and big font

KV5R
 

Howdy Larry,
I'm running reald-040-1, and have confirmed, playing around in touch menus causes jog to lose green highlight of menu items. I did several tests:
1. as you said, in and out of version, and other menus, several times;
2. in and out of several touch menus, without going to version;
-- menu by jog stopped working (off/on to correct it);
3. Once, I got jog highlight to start working again, without off/on, by going in/out of several touch menus and jogging.

(more testing...) HA! I narrowed it down a bit.
1. Touch Config and and then Back
2. Menu is still displayed, without a green highlight. Jog left. Menu by jog quits working. Jog right simply closes menu.
3. Do #1 again; this time jog right. Highlight reappears; menu by jog starts working again.
It's repeatable; any time an operation (typically Back) results in leaving a menu open without a green highlight, then Jog left, breaks menuing by jog.
Repeating the operation by touch, then Jog right, restores menuing by jog.
Even when menu by jog is broken, touch still works and makes touched button green, but that does not restore proper Jog operation. Touch Back and then jog right gets it working gain.
Hope that's helpful to our devs.

Anyway, I just use the jog for moving markers, as it's still iffy for selecting menus, frequently requiring 2-3 actuations. I understand it's scanned, not interrupt-driven, and is easily missed by the busy little processor.

The only little problem I see in reald is it doesn't reverse text colors (fg/bg) to show which trace is selected, as hugen does. So one must cycle a trace off/on (or move its marker by touch) to make sure it's selected, before using Format, Scale, etc.. No biggie, but the pre-selection of trace might be confusing to new users, particularly with no visible indication of which one is selected, prior to a subsequent trace-related operation.
73, --kv5r


Re: T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

 

On Sat, Nov 9, 2019 at 12:14 AM, Kurt Poulsen wrote:
If you got a SMA male male adaptor try to S11 calibrate at the end of the male
male adaptor and either use my female calibration data and remember to subtract
the female famale delay when calibration the S21.
Hello Kurt,

Thank you very much for your valuable hints.

I made what you reccomendet:
1. Connect the Tee direct to CH0: T-Check_RG316-25cm_CH0-6dB_DSC08176.jpg
2. Add an 6 dB attenuator after the Tee.
3. Shorten the coax cable to RG316 25 cm.
4. Tuned the calibration in NanoVNA-Saver.
5. Adjusted the .S2P file S12 for the 6 dB attenuation.
5. So, up to 450 MHz it is within the 5% Limits. T-Check_Short_CH0-6dB.png

Now I know the direction to work on, if neccessary.
It is always nice to know your limits :-)

73, Rudi DL5FA


Re: T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

 

Hi Rudy
It is only going to 490MHz and he might use shorter testcable with better performance. If you got a SMA male male adaptor try to S11 calibrate at the end of the male male adaptor and ether use my female calibration data and remember to subtract the female famale delay when calibration the S21. Alternatively do a S11 calibration using the male calibration data (so to speak ideal) and do not subtract the female female delay but instead enable an electrical delay equal to the female female delay. Then you will se improvement but never the right figure. I have forgotten to mention if you use the supplied female female adaptor it has a high loss and that also provided poorer result than a low loss female female. Besides that if you in the spread sheet subtract 1 from the T-Check then you have the "percentage" result right away as 0.1/div = 10%. A good T-Check is never beyond 5% and for the frequency range up to 500MHz for a VNWA it holds in most cases 1-2%. The T adaptor may also be an element of poorer T-Check, a good quality T-Adaptor is mandatory but not so important as long the 10/12 term error correction is not applied, Sorry to disappoint you.
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af reuterr@...
Sendt: 8. november 2019 20:05
Til: [email protected]
Emne: Re: [nanovna-users] T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

Hello Kurt,

Thank you very much for your enlightening words.
I thought it was easier to achieve.

What only wonders me, how about the T-Check of Erik, that looks good, how does that come?
See T-Check_Erik.png

73, Rudi DL5FA


Re: UI Suggestion: Big Numeric Display Format for CW Stimulus Mode

KV5R
 

Thank You DL9CAT for implementing the larger font and "big info screen" in your fork of the 4-trace firmware!
I have installed your 0.4.0-1 and is working well.
73, --KV5R


Re: Looking for firmware with battery indicator, 1500 and big font

 

KV5R,Can you do a small test on that version?
Using the touch input, go to config, then version then touch to exit version.
Do that a few times and go into other menus in between.
Now, try to use the jog switch - press enter then tell me if you see the on-screen buttons selected (turn green) as you push the jog switch left or right.
I found that after a few version screens selected by way of the touchscreen, you can no longer see menu changes using the jog switch.
I just want to see if anyone else sees that. It's in hugen's code base, not reald's code.

Thanks,Larry

On Friday, November 8, 2019, 3:47:26 p.m. GMT-5, KV5R <kv5r@...> wrote:

I just installed "reald-0.4.0-1 with bigger font and info screen" and it works fine.
Did 2 cals: 50k-900M and 50k-1500M with no problems (900-1500 range is a little squiggly, as expected).
I used Reset on the nano and did not need to clearconfig 1234. But YMMV.
I was using hugen-AA before and it's also fine. Changed to reald for the "info screen" feature.
All it needs now is batt cal feature.
Note Windows users: reald doesn't put up a dfu on his github; you'll need to use Defuse File to to convert the hex into a dfu, then use Defuse-Demo to load it into the nano as usual.
73, --KV5R


Re: Looking for firmware with battery indicator, 1500 and big font

KV5R
 

I just installed "reald-0.4.0-1 with bigger font and info screen" and it works fine.
Did 2 cals: 50k-900M and 50k-1500M with no problems (900-1500 range is a little squiggly, as expected).
I used Reset on the nano and did not need to clearconfig 1234. But YMMV.
I was using hugen-AA before and it's also fine. Changed to reald for the "info screen" feature.
All it needs now is batt cal feature.
Note Windows users: reald doesn't put up a dfu on his github; you'll need to use Defuse File to to convert the hex into a dfu, then use Defuse-Demo to load it into the nano as usual.
73, --KV5R


Re: T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

 

Hello Kurt,

Thank you very much for your enlightening words.
I thought it was easier to achieve.

What only wonders me, how about the T-Check of Erik,
that looks good, how does that come?
See T-Check_Erik.png

73, Rudi DL5FA


Re: Short-Open-Load - expected reflected power

 

I too initially questioned the quality of the RF Bridge, primarily due to the price.
A transverters-store clone from eBay seller seller25812 was substantially defective:
* one of each 100 Ohm pair was disconnected at the balun end
* center conductor of the balun reference coax was shorted to shield at both ends
* labels for DUT and REF are reversed, relative to schematic for Ukraine version

It works OK after correcting...


Re: NanoVNA newbie having problems with new unit

 

Larry,
Thanks for the suggestion. AID64 on the my Chromebook also shows "No USB devices found." with the NanoVNA connected. Oristo thinks android emulation for some USB devices is a work in progress on current Chromebooks. The WebApp works so the hardware interface between the Chromebook and NanoVNA is functional.

- Herb


Re: T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

 

Hi Rudy
Your problem is that you are not aware how a T-Check is processed. The oscillations you see is because your S11 calibration is done with the reference impedance 50ohm and when you the insert the T adaptor then you measure 25 ohm thru the test cable connected to Ch0 and that is causing impedance transformation. Besides that the output of the T- Adaptor connected to the Ch1 via the test cable is not 50ohm but the input impedance of Ch1 not 50 ohm and this input impedance is not transferred via the Ch1 test cable directly but also subject to impedance transformation thru the Ch1 test cable.
All in all a oscillation based on the sum of all these factors.
In a real VNA like the VNWA the T-Check measurement is done for a complete calibration of S11, S21, S12 and S22 via a test set and the build in 12/10 term error correction take place. The VNWA software does the figure out the output impedance og the TX port which can be monitored via a custom trace as SS and the input impedance of the RX Port seen via a custom trace called SL. The condition for a T-Check is simply the imperfections of the TX output and RX input is compensated as the were idealy 50 ohm.
There is a trick in the VNWA software the a full 12/10 term error correction can be performed by pressing the F2 key on the keyboard as then the t_Check adaptor is sweep in both forward and reverse direction and thus doing a full 12/10 term error correction. By a normal forward or reverse measurement only 6/5 term error correction applied. THE NanoVNA HAVE NO ERROR CORRECTION so you cannot do a T-Check the correct way
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af reuterr@...
Sendt: 8. november 2019 16:28
Til: [email protected]
Emne: Re: [nanovna-users] T-Check for my nanoVNA - Results look excellent below 150 MHz and acceptable up to 300 MHz

I need help from an expert.
My T-Check setup is now 2 x 50 cm RG402 coax cable and a SMA Tee with a 50 Ohm Load, see picture NanoVNA_T-Check_SMA-Tee_RG402_DSC08175.jpg

The result, calculated with the spreadsheet from QRP is shown in NanoVNA_T-CheckR-RG402.png

The S21 gain shows a big oscillation, see NanoVNA_T-Check-T_RG402-50cm.png

If I remove the CH1 coax cable from the SMA Tee S11 looks like:
NanoVNA_50-Ohm-Load_RG402.png
So, I think the calibration was OK.

The attached file NanoVNA_T-Check-T_RG402.S2P can be imported in VNWA, see VNWA_T-Check-T_RG402.png

How does that come?
What I am doing wrong?

73, Rudi DL5FA


Re: NanoVNA vs. NanaVNA-Saver #calibration

 

Rune,

If I calibrate via NanoVNA-Saver can I save it to the NanoVNA so that I can use the NanoVNA as a standalone device?

Mike N2MS

On November 8, 2019 at 3:25 AM Rune Broberg <mihtjel@...> wrote:


Hello Ulrich,
the NanoVNA-Saver application calibration is in addition to a calibration
done on the device. You should always use the *same* calibration on the
NanoVNA itself when using NanoVNA-Saver's application calibration.