¿ªÔÆÌåÓý

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

Re: Strange bug with 5 kHz span

 

Thanks Erik,
I admit I was puzzled because its obvious that the nanoVNA has only limited memory storage and can only accumulate so many data points. I was guessing by Hugen's use of "segments" that he meant the scan command would allow collecting more data in additional segments of 101 points each.

Herb


Re: BNC

 
Edited

Bayonet Neill¨CConcelman


Re: Strange bug with 5 kHz span

 

Indeed. That is what I hoped but when I inspected his code I saw he did not copy my code but is using an array to store the frequencies. The frequency array has only 101 items


Re: BNC

 

Bayonet-Neil-Concelman, after the inventors.?
On Sat, 28 Sep 2019 at 18:21, hwalker<herbwalker2476@...> wrote: Bear,
From my years in the military I believe BNC actual stood for bayonet connector (hope I spelled that correctly).

Herb


Re: BNC

 

Bear,
From my years in the military I believe BNC actual stood for bayonet connector (hope I spelled that correctly).

Herb


Re: BNC

 

Years ago somebody theorized that BNC stood for Baby N Connector. It's kinda similar in some ways.

Bear W5VZB


Re: nanoVNA compared (at HF) to Keysight N9913A

 

I can't afford one either Herb but, thanks to the nanoVNA being so accurate, we don't need a FieldFox - at least for HF. We'll see tomorrow how the Nano does at higher freqs.


Re: Strange bug with 5 kHz span

 

Erik,

The latest edy555 release says the scan command supports more than 101 points:

0.2.0-20190928
edy555 released this 4 hours ago
in-device TDR support (contributed by @cho45)
add scan command for multisegment scan excess 101 points
fixed invalid sweep at the narrow span (<5kHz)
fixed failures caused by a race condition between USB and measuring loop
find device automatically in python script

Herb


Re: nanoVNA compared (at HF) to Keysight N9913A

 

John,
Thanks for the comparisons. Until I can afford a Fieldfox N9913A (like never!), based on comparative results like yours and my own end user tests, I'll trudge along happily with the NanoVNA for my hobbyist needs. Even if I could afford a Fieldfox it would probably sit on the shelf out of fear of accidently damaging it and having repair costs approaching my monthly house payment :)

Herb


Re: VSWR-Plot interrupted

 

Hello Norbert,
thank you for trying out the software! The VSWR plot is set by default to
only show values up to a max of 25 - and the "draw lines" command isn't
*yet* clever enough to draw a line to a point that doesn't exist :D So for
that reason, it shows as interrupted, because the values are far too large.

If you set the VSWR data axis max to 100, it should draw bigger values, if
I recall correctly.

It's a feature, not a bug! .. but I'll probably fix it anyway ;-)
--
Rune / 5Q5R

On Sat, 28 Sep 2019 at 16:42, <norbert.kohns@...> wrote:

Hi Rune,
I tested a BP-filter and I am wondering why the VSWR plot is interrupted.
If you take a look at the attached screenshot, there is no VSWR line from
about 268MHz till 846MHz. A tested LP-filter shows a similar symptom.
Would you please take a look at it?
Did anybody of the group see similar VSWR plots?

Kind regards
Norbert, DG1KPN




Re: Strange bug with 5 kHz span

 

David

The scan command implemented by edy555 can scan max 101 points.
I tried to convince him otherwise but failed.

Erik PD0EK


Re: NanoVNA-Saver 0.0.12

 

Hi Peter,
after much popular demand, it's now hiding at the bottom of the readme on
the GitHub page. Also available at the bottom of the "project homepage"
(which is a nice looking version of the readme):



I don't expect *anyone* to donate to me for making this. I've had a lot of
fun making it, and I'll keep working on it as long as I'm having fun. But
the option is there for those who feel such an obligation. :-)
--
Rune / 5Q5R

On Sat, 28 Sep 2019 at 15:59, peter_pc2a <pc2a@...> wrote:

Its time to give Rune a cup of coffee!
Where is the paypal button? :-)

Peter
Op 28-9-2019 om 15:06 schreef Rune Broberg:
I'd have wished they'd contact me about it instead, but as it's open
source, they are of course free to use the code.

I may need to make sure they don't reuse the name, though, so there isn't
confusion about which version is which.

Thanks for letting me know :-)




Re: NanoVNA-Saver 0.0.12

 

Sounds good! If your firmware has similar / compatible commands, there
shouldn't be any problems with it. I can't vouch for future releases, of
course, as I develop for the NanoVNA I happen to have :-) But I am happy if
my software also works for your community!

--
Rune / 5Q5R

On Sat, 28 Sep 2019 at 18:05, BH5HNU <hlimapla@...> wrote:

It may be that there is a problem with my statement. We are currently
testing nanovna-saver and nanovna-f, and it seems that they do not need to
be modified to be compatible.Of course, we don't want to release a software
that has the same name but different functions as nanovna-saver.




nanoVNA compared (at HF) to Keysight N9913A

 

I utilized an attenuator and a band-reject filter today to compare results of the nanoVNA with a Keysight analyzer:



The results were pleasantly surprising.

Tomorrow I'll be making similar comparisons at 144, 440 and 1030 MHz.

73,
John AE5X


Re: NanoVNA-Saver 0.0.12

 

It may be that there is a problem with my statement. We are currently testing nanovna-saver and nanovna-f, and it seems that they do not need to be modified to be compatible.Of course, we don't want to release a software that has the same name but different functions as nanovna-saver.


Re: NanoVNA V2

 

I do wonder whether with all the changes being proposed, you'll end up with something so expensive and esoteric that no-one will be able to afford it! Multi-board, plug-in processors, exotic materials. Probably have to be made by HP or whatever there's called today!

Nice to dream, though.

Cheers,
David
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv


Re: NanoVNA-Saver 0.0.12

 

I'd have wished they'd contact me about it instead, but as it's open
source, they are of course free to use the code.

I may need to make sure they don't reuse the name, though, so there isn't
confusion about which version is which.

Thanks for letting me know :-)
--
Rune / 5Q5R
===============================

Rune,

Yes, as a user of the nanoVNA and with a nanoVNA-F on order, I would hope that only ONE NanoVNA-saver program was required and that it would adapt to either hardware.

Duplication and different (potentially incompatible) versions are the last thing we need!

Looking forward to more cooperation.

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv


Re: errors of "error" models

Dr. David Kirkby from Kirkby Microwave Ltd
 

On Fri, 27 Sep 2019 at 20:00, yza <yzaVNA@...> wrote:

19 : "true value" - also : @Dr. David Kirkby :
/g/nanovna-users/message/3207

Hello,

We both thank you very much for the time you spent
to compose such a lengthy reply, by which you definitely
assured us that you are really interested on this subject,

I am interested. As an undergraduate student I spent some of my time at a
calibration laboratory run by the Ministry of Defence in the UK. That
placement got me interested in metrology, so measurement uncertainly.
However, I am *not* a metrologist. I have an interest in the subject, but
are not an expert.


Core of Measurement Uncertainty in VNA/nanoVNA,
that is, for example, when he insists to force his mind
to be trapped by the conventional triplet of the
"standards" (S,L,O), instead of the most general
one of "loads" (A,B,C)
-
he has been warned.

I can assure you that I am *not* trapped into assuming that the calibration
standards need to be open, short & load. I have designed and sold waveguide
calibration kits, where it is totally impossible to make a ¡°open ¡°. In
fact, I wrote an explanation of why an open can not be used for waveguide
calibrations about a year ago. You almost certainly know why, but I will
post the link, hoping to convince you I am not stuck into this
open/short/load procedure, and perhaps it will be useful to others



However, I am trying to bring to your attention the fact that in the
English speaking world, your use of ¡°loads (A, B, C)¡± is *very confusing.*
Many people will interpret that as meaning three resistive devices.
Instead I believe that you should use the term

¡°*calibration standards (A,B,C)¡±*

Personally, I would write something like

¡°calibration standards (A, B, C), where typically A, B and C are a short,
open and a load, but A, B & C can theoretically be any combination of
three devices which have a different reflection coefficient at every
frequency over which they are used¡°

Although I admit that it is longer to write, it has several advantages.

* It avoids the use of the word ¡°loads¡± which is confusing in the English
language.
* Making a reference to the three calibration standards typically being a
short, open and load will help the reader understand more.
* Stating that theoretically the calibration standards can be any
combination of three devices having different reflection coefficients, will
educate some readers who may not know this.
* By stating that theoretically any combination of three devices can be
used, will allow you to address the problem I stated earlier, that if the
phase of the calibration standards are too similar, the calibration will be
poor.

I am really trying to help you, but unless you address some of my concerns,
in particular the need to write your work in one document that at least
some English speaking readers will be able to follow, I fear nobody on this
group will understand your work.

I have a Fortran compiler (gcc), and probably could compile your Fortran
code. However, I am not going to do this unless you can give me a clearer
explanation of the scope of your work.

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


Cal-Kit Standards' Definitions

 

The NanoVNA firmware (as I understand it) assumes that the SMA Short, Open, and Load standards are ideal, with the single exception of defining the Open to have a C0 50 femtofarads.

I was wondering -- is this a sufficient definition for these standards, given the NanoVNA's frequency limit of 900 MHz? Or should we also be including values for C1-C3, L0-L3, Offset Loss and Offset Zo?

So I wrote some Matlab code to calculate a standard's Reflection Coefficient (Gamma) based on Keysight's "Full" model (using C0-C3, L0-L3, Offset Loss, Offset Delay and Offset Zo), and compared this to a simplified model in which all of these values were set to 0 except for C0 and Offset Delay.

I've attached a table of results.

My conclusion is that the simplified model (C1-C3, L0-L3, and Loss are set to 0, and Zo is set to 50) is perfectly adequate for use with the NanoVNA.

But my math could be wrong. Do my results seem correct?

(A detailed explanation of what I've done is in the top post of this blog: )

Thanks,

- Jeff, k6jca

P.S. I did NOT zero-out Offset Delay in my simplified model (I believe (but have not verified) that this delay IS assumed to be zero in the NanoVNA firmware). If the actual Offset Delays for the Open and Short standards are defined by their supplier to be non-zero, then the net effect of zeroing out these delays is to simply move the reference plane of each -- i.e. rotate the Open and Short's reflection coefficients around the Smith Chart circle. However, note that zeroing out the two delays could become an issue if the Short's delay is NOT equal the Open's delay -- you would then lose this difference in delays (should this delta be large enough to be important)).


Re: NanoVNA does not want to start -solved

DMR
 

I conducted a small test with IP5303.
IP5303 does not work longer than 30 seconds with a load that consumes less than 65 milliamps. Nanovna consumes 90-110mA.
With such a current consumption, IP5303 should power the device for a long time, until the battery energy is depleted.
Test with the new IP5303, connect a 47-38 ohm resistor parallel to the capacitor C47.
If IP5303 will turn off at a load current of 100mA, then IP5303 is fake, or the elements in its bundle are faulty, although there are few of them.