开云体育

Hello,

This email message is a notification to let you know that a file has been updated in the Files area of the [email protected] group.

File: NanoVNA Console Commands Oct-4-19.pdf

Uploaded By: Larry Rothman

Description:
This is the latest update of the Console Commands for the NanoVNA as of Oct 4th. It replaces the previous version (9-5-25a). Please let me know of any errors or omissions.

You can access this file at the URL:
/g/nanovna-users/files/NanoVNA%20Console%20Commands%20Oct-4-19.pdf

Cheers,
The Groups.io Team

Hi Martin,
that's a very interesting suggestion. I've put it on my backlog under
"Future / Cool ideas" ;-)

I *think* the firmware allows it. Probably. But I'm not entirely sure how
to do it.

Currently, I think I prefer to evolve the calibration methods I have put
into application itself, as this already allows saving to a files, and
loading whatever calibration is relevant for your measurement. It
still lacks a number of features, and those will take priority at first.

Thank you for making the suggestion, though!
--
Rune / 5Q5R

On Fri, 4 Oct 2019 at 15:28, Martin via Groups.Io <martin_ehrenfried=
[email protected]> wrote:

Hi Rune,

Would it be possible to use Saver as a mechanism to run the internal Nano
calibration routine, and save these plus any other settings, without having
to use the Nano interface. Then store the values to saver so that it's
possible to use Saver as a repository for the Nano values, even though
Saver doesn't use them itself ?

If it was then possible to download the values back into the Nano
memories, this would save considerable time and allow additional
configurations to be retained and quickly put back in to the Nano's limited
memories when required.

Regards,

Martin - G8JNJ

Wiki now has a "Hardware Versions" link:
/g/nanovna-users/wiki

Perhaps the nanoVNA-F could be added?

The document points to /g/nanovna-f

Personally, I prefer Smith plot displayed at the same time,
over a span (e.g. 2:1) of application frequencies,
as a quick check that components are behaving "reasonably".

every user would need to compute a value for the delay,
which would be different for the value in the cal kit.

If I correctly interpret Kurt, then with appropriate software:
* attach an unterminated length of balanced transmission line
* interactively dial that delay so that Smith plot does not spiral inward

Hi Rune,

Would it be possible to use Saver as a mechanism to run the internal Nano calibration routine, and save these plus any other settings, without having to use the Nano interface. Then store the values to saver so that it's possible to use Saver as a repository for the Nano values, even though Saver doesn't use them itself ?

If it was then possible to download the values back into the Nano memories, this would save considerable time and allow additional configurations to be retained and quickly put back in to the Nano's limited memories when required.

Regards,

Martin - G8JNJ

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the [email protected] group.

File: NanoVNA Console Commands 9-5-25a.pdf

Uploaded By: Larry Rothman

Description:
This is the latest update of the Console Commands for the NanoVNA. Please let me know of any errors or omissions.

You can access this file at the URL:
/g/nanovna-users/files/NanoVNA%20Console%20Commands%209-5-25a.pdf

Cheers,
The Groups.io Team

I think that that sort of feature - especially Q - would be really great.

Martin:
That would be great if it can be done.
I have several RLC commercial meters, none going above 100KHZ, and they all give similar but different answers.
Regards
Fred
WD9HNU

On Fri, Oct 4, 2019 at 01:59 PM, Rune Broberg wrote:

Hi Martin,
there are firmware versions that go to 1500MHz. The frequency limit does
nothing to limit the number of data points, and very, very little to limit
other features within the NanoVNA. It's just a few bytes of extra code :-)

So I don't think there are any merits to making more frequency limited
firmware versions.

Hi Rune,

Ah OK, then I misunderstood the reasoning between about the various different frequency limits in the various versions of firmware.

I was under the impression that the Nano's lower frequency limits were necessary as a trade to overcome other issues, but I'm pleased to hear that this is not the case.

Just ignore my initial posting on the subject.

Regards,

Martin - G8JNJ

Hi Rune,

Understood. I really like Saver and very much appreciate what you have achieved so far, especially in such a short space of time, and I'm very grateful for your effort and dedication.

A lot of Owen's frustration is due to problems with other VNA's and antenna analysers that have some serious issues with calculated values that never seem to get fixed, and the negative response he has had from the manufacturers when these have been flagged up, hence his reluctance to engage directly.

I agree that amateur conventions often differ from those used in the professional world, and that perhaps some of Owen's comments are merely a reflection (no pun intended) of that conflict. However is heart is in the right place when trying to point out these issues, even if perhaps his methodology is not to your liking.

The AIM VNA shows both parallel and series values, so maybe it would be useful to include those in addition to conductance & admittance and then it's not necessary to resort to external calculators and spreadsheets ?

Finally - would it be possible to add some user definable SWR marker lines to the Smith and SWR plots ?

Regards,

Martin - G8JNJ

On Fri, 4 Oct 2019 at 13:55, Rune Broberg <mihtjel@...> wrote:

If there are any miscalculations in my software, I do what I can to correct
them. I have not recently been made aware of any problems, and at no point
by Owen. I hope that any of you would immediately contact me, should you
find errors in NanoVNA-Saver! :-)

I have not read the article by Owen, but I would agree on this single point
about return loss. But I never commented to you, as it is a subject of much
debate. If there was a very clear majorty for one convention or the other,
I would stay you should go with it, but there's not a clear majority, so
use whatever you want.

If I was to use your software, which I might well do, but m interest is in
portable use, without external software, I would probably recompile and
change the sign. My HP LCR meter allows one to display this R+jX think in
multiple formats. I could give them to you if you wanted, but again, you
know what space you have.

While I am sending you a message, there's something else I thought of that
could be of use to many people, but you might not want to get involved in,
so I did not bother. Your software could be useful to those of us with the
very popular HP 8753 series VNA. It would be good if you could support
reading from them too. The Python code to open a GPIB code and read from it
is about 5 lines long. Much of the other commands you use to set up a
NonVNA would have an equivalent in 8753.

--

Rune / 5Q5R

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

Thanks, Herb and Rune!

Wiki now has a "Hardware Versions" link:
/g/nanovna-users/wiki
======================

Perhaps the nanoVNA-F could be added?

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

It is often useful to think about frequencies in terms of octaves or harmonics,
where 900 is less than an octave above 500MHz,
so potentially of interest e.g. for filter evaluations

On Fri, 4 Oct 2019 at 13:38, Martin via Groups.Io <martin_ehrenfried=
[email protected]> wrote:

Hi All,


Just about every instrument I can remember using, has RL shown as a
negative curve, even if the units themselves are positive. This is handy if
for example you are tuning a filter, as you can see the insertion gain on
the uppermost trace and the RL loss on the lower one without them
overlapping. It also matches the convention of SWR plots and when
measuring the RL of cables it matches the convention of more attenuation
being negative.

However Owen makes the point that negative loss is actually gain (double
negative) and vice versa, and the existing conventions do indeed lead to
confusion and mistakes being made. Maybe return loss should really be
called return gain, and then everyone would be happy (well maybe - but this
is not a serious suggestion).

*As soon as I looked at Rune's software, I thought "Return loss should not
be negative",* but I did not comment. There was a note in an IEEE article,
where the editor stated he has seen negative values, made the argument for
why a return loss should be positive, and expected authors to correct this.

But I have come to the conclusion that this is like arguing religion. You
are unlikely to convince a believer of religion X that he/she is wrong, and
religion Y is right, so you might as well give up!

Regards,
Martin - G8JNJ

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

Hi Martin,
there are firmware versions that go to 1500MHz. The frequency limit does
nothing to limit the number of data points, and very, very little to limit
other features within the NanoVNA. It's just a few bytes of extra code :-)

So I don't think there are any merits to making more frequency limited
firmware versions.
--
Rune / 5Q5R

On Fri, 4 Oct 2019 at 14:56, Martin via Groups.Io <martin_ehrenfried=
[email protected]> wrote:

Hi All,

I've been reading the comment about frequency range vs sample size and
other issues and I'd like to suggest / discuss some thoughts.

Although it's nice to have the capability to measure up to 900MHz, I
suspect that because of the type of use the Nano is likely to be put to, I
don't think most users need to be able to measure above 500MHz (actually
470MHz).

This is because it marks the start of the UHF terrestrial TV broadcast
band, which continues up to 800MHz + and the next frequency bands of
interest are likely to be 1090MHz and above particularly 1.3GHz and 2.4GHz
all of which are all above the upper frequency limit of the Nano. The
highest frequency amateur band below 500MHz is 433MHz (which is also an ISM
band) so having a bit of headroom above this is still useful when building
antennas or testing filters.

If the upper limit was set to 500MHz would this be adequate for most
users, and allow more data points and facilitate other stuff that is
currently not possible when up to 900MHz is available ? Or does it not
actually make that much difference if the upper limit is 500 or 900 MHz ?

Regards,

Martin - G8JNJ

Hi All,

I've been reading the comment about frequency range vs sample size and other issues and I'd like to suggest / discuss some thoughts.

Although it's nice to have the capability to measure up to 900MHz, I suspect that because of the type of use the Nano is likely to be put to, I don't think most users need to be able to measure above 500MHz (actually 470MHz).

This is because it marks the start of the UHF terrestrial TV broadcast band, which continues up to 800MHz + and the next frequency bands of interest are likely to be 1090MHz and above particularly 1.3GHz and 2.4GHz all of which are all above the upper frequency limit of the Nano. The highest frequency amateur band below 500MHz is 433MHz (which is also an ISM band) so having a bit of headroom above this is still useful when building antennas or testing filters.

If the upper limit was set to 500MHz would this be adequate for most users, and allow more data points and facilitate other stuff that is currently not possible when up to 900MHz is available ? Or does it not actually make that much difference if the upper limit is 500 or 900 MHz ?

Regards,

Martin - G8JNJ

Hi Martin,
I too read Owen's post. I'm not particularly fond of his way of implying
that I would be "resistant to correction"; and calling what I do "very
hammy". If it is one's intention to post like that, I would consider it
normal courtesy to inform the author of the software in question.

"Return loss" when shown as a negative value should probably be termed
"reflection coefficient". But using the term "return loss" and a negative
value has become the norm within at least the hobbyist community. I
consider the NanoVNA a hobby device. I might make a "stickler mode" for
those who can't look past it ;-)

I don't see that he refers to anything I have calculated as being *wrong* -
just that he doesn't like the particular things that I have chosen to
calculate (equivalent L/C for parallel X, instead of using
conductance/admittance). I have put in the readings that have been
requested by users.

If there are any miscalculations in my software, I do what I can to correct
them. I have not recently been made aware of any problems, and at no point
by Owen. I hope that any of you would immediately contact me, should you
find errors in NanoVNA-Saver! :-)

--
Rune / 5Q5R

On Fri, 4 Oct 2019 at 14:38, Martin via Groups.Io <martin_ehrenfried=
[email protected]> wrote:

Hi All,

Owen Duffy has recently posted a note about the Nano VNA on his blog.



He makes a few points about the accuracy of calculated values with both
the Nano VNA and Saver in particular.

If we first deal with the issue of Return Loss, which is probably the most
problematic par, and has certainly caught me out on several occasions.

Just about every instrument I can remember using, has RL shown as a
negative curve, even if the units themselves are positive. This is handy if
for example you are tuning a filter, as you can see the insertion gain on
the uppermost trace and the RL loss on the lower one without them
overlapping. It also matches the convention of SWR plots and when
measuring the RL of cables it matches the convention of more attenuation
being negative.

However Owen makes the point that negative loss is actually gain (double
negative) and vice versa, and the existing conventions do indeed lead to
confusion and mistakes being made. Maybe return loss should really be
called return gain, and then everyone would be happy (well maybe - but this
is not a serious suggestion).

However if we put this to one side, there is still the issue of how the
values are being calculated, and if they are in fact correct. If not then I
think this should be investigated in more detail and fixed, as there would
seem to be an opportunity to do this before it propagates further.

Regards,

Martin - G8JNJ

Thanks, Herb and Rune!

Wiki now has a "Hardware Versions" link:
/g/nanovna-users/wiki

On Sun, 29 Sep 2019 at 17:40, Jeff Anderson <jca1955@...> wrote:

On Sun, Sep 29, 2019 at 03:43 AM, Dr. David Kirkby from Kirkby Microwave
Ltd wrote:

The 85032F is not one of Keysight’s best kits.

Hi Dave,

You are probably right. I chose this kit because, of the 50-ohm cal-kits
listed by Keysight as supported for the 8753D, it seemed to have the worst
higher-order capacitance terms, thus a good choice for testing my theory.

Although more difficult to implement in the firmware, and a PITA for users,
it would not be surprising if even better performance could be obtained by

* Setting C0 to 0
* Reading C1 from the datasheet of the cal kit
* Adjusting the offset delay from the data in the cal kit, to some longer
delay, which would depend on C0. That way only two parameters are entered
into the cal kit definitions (a delay and C0). The problem would be every
user would need to compute a value for the delay, which would be different
for the value in the cal kit.

But as an academic exercise - you have convinced me that for the
professional calibration kits, used up to 1500 MHz, an offset delay and C0
are fine.

Best regards,

- Jeff, k6jca

Dave, G8WRB

Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100