开云体育

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

Hi All,

I've been using my Nano quite extensively in the workshop, and I find it very handy for quickly checking the value of surface mount components, particularly capacitors and inductors.

It would be really nice if it was possible to just display the RLC values (and Q ?) in big text (no graph required) for a defined frequency (or frequencies) so it could be used in place of a separate RLC meter, many of which can only measure values at low frequencies <1MHz.

What do others think - would this be useful ?

Regards,

Martin - G8JNJ

Hi All:
I am selling my recently acquired NanoVNA , this a hugen version from aliexpress, includes the necessary calibration items also I am including a ST-link V2 programmer. $55.00 includes shipping to con US.
Thanks for the consideration. K7SRB Ross Bell

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

The block diagram is missing the measurement of the reference signal?

Op 4-10-2019 om 12:31 schreef hwalker:

In your web space I see many files, I need only DMR-CLEAR_MEMORY_DFU.dfu and an executable program, is it correct?
Should I find the program.exe?

..Again:
Reasons you might want to upgrade:
1. TDR capability in firmware. -> Can you measure the length of the coaxial cables?
2. Operation up to 1500 MHz (at reduced performance). -> No thanks (ugly dynamic... I imagine)!
3. DFU mode in firmware. -> So at the moment I can't delete the memory with the DMR-CLEAR_MEMORY_DFU.dfu file?
4. Change from 2 trace to 4 trace firmware (or vice versa). -> Better 2 tracks if it slows down with 4...?! With 2 tracks is the "aa" or "ch"?
5. Change to 800 MHz max operation for better device stability -> Interesting. At the moment I have an abnormal peak at 300Mhz on channel S21, maybe it could solve this problem (maybe it's a self oscillation).

Thanks..

Hello group,
some remarks:

On Sun, Sep 29, 2019 at 10:21 AM, Gabriel Tenma White wrote:

* V2 won't have a bigger display because it is too expensive

take a look at Raspberry Pi 3.5" lcds with 480x320 resolution, or bare with ILI9486/ILI9488 controller (a lot of them can be found on chinese shops)

* frequency range will go to at least 3.5GHz; PLL limit is 4.4GHz.
* ADF4350 is used because of cost reasons; ADF4351 is more expensive by a
factor of 5.

please consider the MAX2871 which is cheaper than ADF4350 and offers much more than ADI chips at this price (prices compared at Farnell or Digikey - I know chinese clones are far cheaper...) -the footprint and pinout is the same.


vy73
Slawek/SP9BSL

Rob,
Please understand that "DMR-CLEAR_MEMORY_DFU.dfu" will wipe your device and it will not work until you re-load whatever firmware you are upgrading to. It is used to give you a clean slate prior to installing your new firmware. Some users have not been able to upgrade successfully it they do not load "DMR-CLEAR_MEMORY_DFU.dfu" first.

All the tools and instructions you need to perform a firmware upgrade are in the links I previously provided. My best advice is that if you are happy with how the nanoVNA is performing to hold off upgrading the firmware until you see a feature or improvement released that you want.

Reasons you might want to upgrade:

1. TDR capability in firmware.
2. Operation up to 1500 MHz (at reduced performance).
3. DFU mode in firmware.
4. Change from 2 trace to 4 trace firmware (or vice versa).
5. Change to 800 MHz max operation for better device stability

Herb

I am wondering if the nanoVNA could be used to measure the noise figure for a preamp. If it could, I am assuming it would use S21 results in some manner.

Herb,
thanks for V2 logical schematics.
I'm following the V2 topic with a lot of interest.

Diego

Pluto,
That looks like the design currently being sold. V2 will use two synthesizers that overlap and allow it to exceed a 1 GHz measurement range (see attachment).

Herb