¿ªÔÆÌåÓý

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

Re: NanoVNA does not want to start -solved

 

Placing a 20 - 100 ohm resistor has not brought a solution. The IP5303 will not start wiyh the SW1 switch.
Also, as a test with a 6V / 3W light bulb on the load pin 8, it will not start. Here the load must still be sufficient. With pin5 I can start the IP5303, and the light is on, but after the 45sec sleep time, restarting no longer works with the pwr switch. I will have to search for another solution. I am thinking of a larger C3 capacitor, so that when the SW1 is closed, there is a larger charge current for a while. I'm also going to look up more circuits with the IP5303.


Re: NanoVNA Saver - bug report?

 

Hi Rune

Many thanks; the full path fixes it...

/home/nick/nanovna-saver/full_sweep

but

~/nanovna-saver/full_sweep

does not work.

A few suggestions on the user interface...

- how about removing the plots from the main window and having them open in separate re-sizable windows? That can be saved as .png files?

- how about then moving all the cal stuff onto the main window?

The above motivated to ease the pressure on screen space.

I find I have to run my 17 inch monitor at 1024 x 768 to be comfortable. Perhaps I should get a bigger monitor!

- how about save/load calibration opening "object picker" windows so you can select which cal you want to use from the file system rather than having to remember what you called them?

73
Nick
G3VNC

On 19/09/2019 20:17, Rune Broberg wrote:

please try putting the full path to the file in the field, not just the
file name. It may be a matter of which folder the software sees as its
working folder (generally controlled by your OS).


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

 

I can't see anything that tells me what the maximum input is before the device is destroyed.
Inputs appreciably outside power supply limits will be problematic.
ESD was most problematic for CMOS not internally protected.
50 Ohm bridge pretty much protects the active chips;
bridge resistors can of course be damaged
by exceeding power dissipation rating (V*V/R)

Wouldn't a diode introduce capacitance across Ch0 ?
Or inductive lead effects at VHF/UHF and ruin any measurements ?
Having variable amounts of built-in parasitic reactances,
each nanoVNA already needs "calibration".


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

Andy G0FTD
 

One other thought.

During a discussion yesterday on this group, measurments were taken as to what the OUTPUT levels were from Ch0.

They were 200mv peak to peak IIRC.

As such, I think I'd want to assume that this would be the maximum level that any of the ports could handle and would want
to account for.

0.6v (600mv) for a basic diode to start clamping sounds a bit risky to me.

If I'm missing something here then I'm willing to learn ;-)

73 de Andy


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

 

Thanks Erik.
I read the slides from the link but did not notice mention of another protection method that I've seen using zener diodes.

Referring to the attached image, drawing A is mentioned in the slides.
However, I have also seen the use of back-to-back zener diodes in series as shown in drawing B that I think would provide a higher input range.
Lastly, I wonder how the use of a two-color LED as in drawing C would work, with its higher forward voltage. (and visual indication?)

The original aim of the diode protection was to limit input voltage to 0.6V at the radio's sensitive front-end.
The VNA uses a resistance bridge - how much signal can it tolerate before physical damage or actually modifying what you're trying to measure?


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

 

You could use something like a ESD0P4RFL. Will need some space on the board. And it's quite small, but very low capacitance.


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

Andy G0FTD
 

Erik..

Two things here confuse me.

1 - I've looked at the SA612 spec sheet. I can't see anything that tells me what the maximum input is before the device is destroyed.
That would determine what methodology and parameters to design any protection circuit for.

2 - Wouldn't a diode introduce capacitance across Ch0 ? Or inductive lead effects at VHF/UHF and ruin any measurements ?

73 de Andy


Re: Finger tightening SMA connections

 

On Thu, Sep 19, 2019 at 06:53 PM, Reginald Beardsley wrote:


Most of the problem is because the SMA hex is so hard to get a grip on.
Reg, for this reason I picked up some "SMA Nuts" on eBay after I discovered I had the same issue with my NanoVNA. Now each of my three SMA standards wears a collar.

Below are a couple of eBay links to sellers in the States.





If they interest you, maybe there's someone in the UK selling the same? Try searching for "drone SMA nuts"

So far, they are great! (I used the first vendor, above). As for durability, we will see...

- Jeff, k6jca


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

 


slide 11

Simple and cheap: Back to back diodes
? Protection not dependent upon configuration
? Diode type is not critical (except, don¡¯t use PIN diodes)
? Limited to low input power levels => receive only applications
? +30 dBm = 1 watt max (when using ? watt diodes)
? If either diode fails open => receiver front end not protected
? Spurious signals in receiver can be a problem
? Some mfgs offer choices on spurious levels (DX Engineering RG-5000 series)


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

Andy G0FTD
 

So the question is, what precautions can be taken to protect the NanoVNA ?

Prayer is not an option ;-)

73 de Andy


Re: Does anyone know how sensitive the nanovna is to electrostatic discharge?

 

The CH0 input of the nanoVNA is basically an attenuator connecting to a SA612 mixer without any additional protection.


Re: Firmware summary

 




Ps. I included the ssh key part as I could not "git submodule update
--init --recursive" without a one.

Interesting! I had the same issues, and instead finally resolved it by
editing the .submodules file:

- replace the 3rd line with "url =
- add a new line to the end of the file

Finally type "git submodule sync", and then "git submodule update --init
--recursive" works correctly.

I prefer your fix!

Rgds,
Dave


Re: NanoVNA Saver

 

Thank you very much for your post, John. Posts like yours certainly give me
motivation to continue working on the application, even when I find issues
that are difficult to solve in an elegant manner. :-)

--
Rune / 5Q5R

On Fri, 20 Sep 2019 at 07:48, John Nightingale via Groups.Io <if455kc=
[email protected]> wrote:


This old man is just swept away by what you have been producing, Rune!
This very ordinary user has kept quiet about this superb application
and left comments to the savants. Now, though, with this 0.0.10 release,
I just have to convey a massive "thank you" on behalf of all of us
lesser users, ham radio operators particularly. We hams now have
something we could only have dreamed of until a couple of months ago;
it amounts to a $10k instrument.

A Linux system is in use here. The application works perfectly in
every detail tested so far. A special "thank you", too, for troubling to
furnish something better for old eyes than that minute font, Rune!

Mention will be made of something that defeated this user initially
because other less alert users may also bump into it. The reason for the
following has not been investigated but it will be something dim witted
done at this end because of being compelled to use the blunt instrument
of a 74 year old brain! The "SWEEP" option was found, repeatedly, grayed
out when trying to perform calibration. What was going on proved to be
very simple. The initial port assignment had been "/dev/ttyACM1". The
application had found the correct port by itself, as designed. What was
going on proved to be, somehow, reassignment to "/dev/ttyACM0". Of
course no sweep could be done with the application looking into a vacant
port. Manually forcing back the port to "/dev/ttyACM1" fixes the issue.

Many many thanks, Rune, on behalf of all the hams who now have a
truly superb tool.

John
at radio station VE7AOV
+++++



On 2019-09-18 1:36 p.m., Rune Broberg wrote:
I just released 0.0.10:


It's not the most exciting release, but it offers some quality of life
improvements, such as the ability to choose the font size (particularly
useful for Linux users, whose default is a massive 11 pt font).

It also adds debug logging: -d to get log messages to the terminal, or -D
filename.txt to log to a file. Useful if you see crashes!

Additionally, it now supports importing magnitude/angle touchstone files,
and there's been a number of little bugfixes.

As ever, I look forward to hearing what bugs you find, and what new
features you want! :-)
--







Re: Firmware summary

 

Hi David.

I've updated the post with instructions, on the opposing side of the SMA connectors CH0 and CH1, there are two pins on the PCB labelled VDD and BOOT0.
They need to be shorted with the powered off state, then with those shorted power on the device.

Sorry for the confusion.

Ps. I included the ssh key part as I could not "git submodule update --init --recursive" without a one.

Kind Regards
Ohan Smit
ZS1SCI


Re: Firmware summary

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Fri, 20 Sep 2019 at 07:09, Rune Broberg <mihtjel@...> wrote:

Hi Reg,
Ohan made a guide.

This sentence

¡°Flash by setting the device to DFU boot, either in software or by short of
pins, then:¡±

could usefully be expanded. I don¡¯t know how to do either

Dave
--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales.
Company number 08914892.
Registered office:
Stokes Hall Lodge,
Burnham Rd,
Althorne,
Chelmsford,
Essex,
CM3 6DT,
United Kingdom


Re: Firmware summary

 

Hi Reg,
Ohan made a guide. I'm not certain the SSH keys are required, but it's all
there:



--
Rune / 5Q5R

On Fri, 20 Sep 2019, 00:35 Reginald Beardsley via Groups.Io, <pulaskite=
[email protected]> wrote:

If you are modifying the FW *please* maintain a file in the Firmware
folder with release notes and version information along with the location
of the source repository.

If you make comments such as "TDR is now in the FW" *please* state which
version. This has turned into an Abbott and Costello skit.

I had asked about a post about instructions for building the FW on
*Linux*, not Windows. The search feature doesn't produce anything useful.
The maddening part is I'm pretty sure I thanked the person who did that,
but I cannot even find a list of my own posts.

I've downloaded both the ST development tools and the Gnu tools onto a
Debian 9.3 system, but I'm now so confused about who has done what that I'm
reluctant to actually do *anything*. I don't want to reinvent the wheel.
and unsure about whether the version that came on my unit is buggy and
needs fixing to use the command line console.

I'd like to see if I can improve the dynamic range at higher frequencies
with some DSP. Depending upon the nature of the situation, I think it
might be possible to pick up 20-30 dB improvement.

But at the moment I'm completely befuddled by "Who's on First".

Also, if you're quoting and commenting inline *please* delimit the quotes
from your own comments. There have been a number of posts I gave up trying
to figure out. They looked as if there were 3 or more authors.

Reg




Re: nanoVNA Real Resistance Measurement Range

 

Greetings Dr. David,

Thank you for flagging my less than clear and possibly misleading post! I did not intend to infer that my DIY 50 Ohm load has the quality of a 53 dB return loss instrumentation standard! After reviewing the wording I understand how one could get that impression. In an earlier post (#2562) in this thread I had previously described measuring my DIY BNC 50 Ohm load using the SMA loads supplied with my nanoVNA for the calibration. I provided a screen shot and S1P file showing results. Amazingly the RL match to the SMA references measured in the 50s up to 450 MHz. At 890 MHz it dropped to about 30dB. I should have clearly qualified the relative reference and referred to that earlier post. I was trying to provide a foundation as to why I think that BNC connectors can be used for routine Z measurement at frequencies VHF and lower.

My goodness my DIY loads are not even shielded and could possibly be used as lossy antennas at SHF, (:/)). The reality is that unlike yourself I don't have any means to properly compare my loads to any laboratory level standards. And as you point out it would be extremely difficult to establish a 53 dB reference. Sounds like your well equipped for the high end of the microwave spectrum!

Amazingly at 450 MHz and below (according to my nanoVNA) my BNC load including the BNC/SMA adapter matches the SMA load calibration with a return loss of around 50dB up to 450 MHz. I decided to see if I could repeat the test and have attached the files. This time 147MHz showed a RL of 48dB, 450MHz 53dB and 890MHz 47db (usually more like 30dB at 890MHz). I am amazed that I can repeat this test this well considering how critical a 50dB match is. It wouldn't surprise me to see a big reduction in these numbers with just a minor change of temperature.


I have not experimented with the nanoVNA S21 capabilities yet. I certainly agree about the need for 100 dB dynamic range for cavity tuning. A spectrum analyzer with a tracking generator works nicely but I imagine there are expensive VNAs that will do that job even better.


Best Regards,
Tom
VA7TA


Re: NanoVNA Saver

 

This old man is just swept away by what you have been producing, Rune!
This very ordinary user has kept quiet about this superb application
and left comments to the savants. Now, though, with this 0.0.10 release,
I just have to convey a massive "thank you" on behalf of all of us
lesser users, ham radio operators particularly. We hams now have
something we could only have dreamed of until a couple of months ago;?
it amounts to a $10k instrument.

A Linux system is in use here. The application works perfectly in
every detail tested so far. A special "thank you", too, for troubling to
furnish something better for old eyes than that minute font, Rune!

Mention will be made of something that defeated this user initially
because other less alert users may also bump into it. The reason for the
following has not been investigated but it will be something dim witted
done at this end because of being compelled to use the blunt instrument
of a 74 year old brain! The "SWEEP" option was found, repeatedly, grayed
out when trying to perform calibration. What was going on proved to be
very simple. The initial port assignment had been "/dev/ttyACM1". The
application had found the correct port by itself, as designed. What was
going on proved to be, somehow, reassignment to "/dev/ttyACM0". Of
course no sweep could be done with the application looking into a vacant
port. Manually forcing back the port to "/dev/ttyACM1" fixes the issue.

Many many thanks, Rune, on behalf of all? the hams who now have a
truly superb tool.

John
at radio station VE7AOV
+++++?



On 2019-09-18 1:36 p.m., Rune Broberg wrote:
I just released 0.0.10:


It's not the most exciting release, but it offers some quality of life
improvements, such as the ability to choose the font size (particularly
useful for Linux users, whose default is a massive 11 pt font).

It also adds debug logging: -d to get log messages to the terminal, or -D
filename.txt to log to a file. Useful if you see crashes!

Additionally, it now supports importing magnitude/angle touchstone files,
and there's been a number of little bugfixes.

As ever, I look forward to hearing what bugs you find, and what new
features you want! :-)
--


Does anyone know how sensitive the nanovna is to electrostatic discharge?

 

When a VNA is connected to an antenna (often they are outdoors) there are some potential issues with electrostatic discharge (ESD.) In dry areas of the world ESD can be an issue even when working with objects that are purely indoors. I have seen issues when working on tables indoors. Other VNA devices are known to have issues. Does anyone know how sensitive the RF inputs to the nanovna are with regard to ESD? Is there any ESD protection built into the RF connections on the nanovna?
--
Bryan, WA5VAH


Re: Better, Worse, Worst....... baloney.

 

Reginald and Dr. Dave

Since you both completely missed the point of my post I must assume the fault for that is mine in the presentation.

My post did not focus on what parameters were being measured or on the accuracy of the value measured for any of the chosen parameters. The point of the post was the consistency of measurement among three versions of Nanovna and two independent devices.

Warren Allgyer
WA8TOD