开云体育

One more thing.

It might be an idea to change the name of Port 0 to Port 1 and Port 1 to Port 2 in the S/W GUI so it matches S1x and S2x etc. instead of e.g. S10 ...

I acknowledge that in programming the starting point if often zero (0) and not one (1). But from an RF point of view it will probably be good karma.

Bo

This is the bottom side of the shielded version. The shields are on the right and cover the RF portions. Many..... most maybe.... do not have these shields. If yours does not, do not fret. They make no significant difference in practical use.

The space on the lower left is where the battery goes, secured by a piece of double sided tape or a dab of contact cement. Battery solder tabs are in the upper left corner.

WA8TOD

Avast antivirus cheched the nanovna-saver executable , and now the program can be execute in normal way.
Regards
Maurizio IZ1MDJ

On Fri, Sep 27, 2019 at 07:36 PM, Larry Rothman wrote:

For you to say this and that is a waste of time belittles the accomplishments
of many Amateurs.

You're don't understand what I say. I don't say that TDR is waste of time. I say that attempt to integrate it into firmware is waste of controller memory in the detriment of more useful functions.

TDR is very interesting feature. But NanoVNA is unable to handle it self (with no PC) with a good resolution due to low memory resources in the cheap controller. It doesn't means that you cannot use TDR with NanoVNA. You can do it on PC.

It just means that it's better to not make NanoVNA measurement more worse and to cut-off very useful functions just to get TDR inside firmware with a low and not usable resolution.

I think the better way is to use controller memory for more measurement points, to use more precise calibration and to add more useful measurements instead of DEMO version of TDR inside firmware with low resolution. The better way is to implement TDR feature on PC side and use controller resources for more useful features.

There is no question if TDR needed or not. It is definitely must have. The question if it worth to make measurement more worse, cut-off useful measurements just to add low-res TDR on firmware side? Or if it's better to make NanoVNA more precise, more stable and more useful with more measurements, but with TDR implementation on PC software side (with much better resolution and more usable)?

I would be happy to see TDR inside firmware, but not in the detriment of precision and more needed features. Unfortunately NanoVNA controller cannot handle all things simultaneously, there is needs to make decision if we needs more precise measurement, or DEMO TDR inside firmware. Any case doesn't prevent to use NanoVNA for TDR. The question is where to implement it - on firmware side or on PC software side. That's what I'm talking about.

Yes, it is a shame to have to go to a different board material.? That would probably severely handicap the Chinese vendors of the hardware since most board houses that offer low setup charges and flexible quantities and terms only handle FR4.? In the microwave community we are moving away from Teflon (and similar materials) in favor of standard board materials combined with inexpensive gain provided by MMICs.? A great example of this is the 10 GHz transverter made by W1GHZ, which you can find (if you are not already ware of it) by going to his website.? He also uses thinner than normal FR4 boards to reduce radiation, ie losses.? I do not know if any similar techniques could be employeed in the VNA.? But using gain from MMICs to recover losses from the board seems like a winner - if it can be applied.
From a user's perspective: keeping an army of Chinese manufacturers busy beating the cost and price down is certainly very attractive
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

Actually, the suggestion of V2 being modular is interesting.
Many Chinese electronic products are manufactured using a main PCB to hold charging and other ancillary circuits and the wireless and/or processors are on daughter-boards that are then soldered to the main PCB.
If the DSP and the RF mixer/gen could be designed as modules, that may provide for alternatives going forward.

I forget off-hand but one of the US Amateur groups designed a VNA using an STM compute module that plugged into the main board.

Good idea.

73...Larry

Hello Mike

Yes, adding the ADF4351 is a possibility. I was merely referring to the additional PCB, perhaps FR4 has to be abandoned, and component costs.

Bo

Bo,
Someone suggested using a drop-in alternative chip that would extend operation up to 4 GHz.? This would be very useful because it would then cover the 3.3 - 3.5 GHz band.? It would be a good thing if one more band can be covered for minimal additional cost.
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

Hi

Here are some thoughts about a v.2. Make a modular design consisting of RF, processor/digital, display and battery boards. Then each part can be replaced when a better solution is available e.g. replacing the processor/digital board for more power if relevant while keeping the RF board. The display board may not be need by everyone thus reducing cost. I prefer to operate my NanoVNA from the PC due to size and the poor quality of the wheel. Also the battery may not be needed by everyone.

Once you go above ~2 GHz the PCB material becomes a serious issue among other things.

Also name the first port Port 1 and the second port Port 2 instead of Port 0 and Port 1 respectively. This will be more in line with Sxy-port numbering.

Bo

Rune,

Thanks for your continued outstanding work! :>).

I am running 0.0.12 on Windows 7. All I am doing is downloading the file, creating a shortcut to it , and clicking on the shortcut. No issues observed.

Calibration assistant works fine for me. This is a nice addition. Saving calibration is important after creating a new calibration.

S21 Marker phase is now the same as the plot and I think both are correct :>).

I really like the new plot scaling capability because that allows one to "zoom-in" on features of interest in the data without changing the frequencies of interest and running another sweep. This is very useful for careful looks at the information we have available.

I have one suggestion for scaling in a future release: When a max to min range of 10 dB in amplitude (S11 amplitude dB or S21 amplitude in dB) could you include 1 dB horizontal lines on the plots? Perhaps an equally useful solution would be to let the user specify the dB per division for the y-axis This would help interpretation when looking at things like pass-band ripple, S21 attenuation of a cable, or .... This idea is relevant to phase plots as well.

I have been using the averaging capability and think I am reliably measuring S21 stop-band filter rejection down 50-60 dB from pass-band attenuation values. The filter I am measuring is a stop-band filter for the 88 to 108 MHz FM broadcast band here in the US. The averaging does help in this situation to reduce the noise that is present in the nanoVNA at those amplitude levels. I see plot-to-plot variations of less than 0.5 dB pk-to-pk. I consider this quite impressive for such an inexpensive device and free software.

Again, great work on this software. Very helpful!

--
Bryan, WA5VAH

Hi

I am relatively new to the NanoVNA thus the NanoVNA-Saver but I have spent a number of hours in front of an 8753C :-) I really like the NanoVNA-Saver and therefore have some ideas for further improvements. If I didn't like it I wouldn't even bother to make suggestions :-D

Ideas rel. to 0.0.12
- make it possible to save the full NanoVNA-Saver window and/or each plot without having to do a screen dump via another tool
- It would be ideal if there is a save dialog with an input field that is used as preamble in the file name(s) and/or also for caption in the pictures. In the file name please use underscore instead of spaces
- the dialog box could have check boxes for which pictures to save, perhaps even a check box for adding a time stamp YYYYMMDD_HHMM to the file name(s)

- in addition to the S-parameter files also to have a set of files for plain amplitude/attenuation vs. frequency

- x dB auto markers, e.g. 1 dB, 3 dB, 6 dB, 30 dB, 60 dB is difficult in general on the NanoVNA, and buttons for finding these points on LPF, HPF, BPF and Notch fillters
- more than three markers in general

Cosmetics
- the lines on my monitor are rather thin. It might be related to my screen resolution being 2560 x 1440 pixels on a 32" monitor. But it might be an idea to allow for thicker traces lines
- reduce the number of decimals, e.g. fF and pH resolutions are not important
- there is a missing space between the impedance value and the Ohm-symbol, 1234.5ohm-symbol -> 1234.5 ohm-symbol (ISO 80000)
- there is a missing space between the band value and the meter, 2200m -> 2200 m (ISO 80000)
- show the marker color in the caption of the marker value panes
- auto 1000 separators on frequency input boxes
- COM port dropdown box listing COM-ports and the logical names if available. It will make it easier to find the device. Perhaps even auto connect if logical name is found

Segments
- I am not sure I understand "segments", however, I do understand points which might be an old habit. The Hz/step unit of the segments is confusing to me

Bo

qrp.ddc,

You are absolutely wrong in saying TDR on the NanoVNA is a 'waste of time'.

This is essentially an Amateur Radio hobby forum.

Amateurs have been at the forefront of many new innovations in radio communication - because they EXPERIMENT with practically anything and everything technical.

For you to say this and that is a waste of time belittles the accomplishments of many Amateurs.

TDR on the NanoVNA is an EXPERIMENT!
It is to be played-with!
It is to be commented on in ways to MAKE IT BETTER.

All you are doing is pushing negativity about. Please don't.
Most of the forum members here will absolutely agree that playing with that particular version of firmware is interesting.

If you cannot understand that - don't use that version of firmware.
Simple, eh?

So - instead of bashing the TDR function, how about you coming up with some alternate functionality that you would like to replace the TDR with.
That way everyone here can experiment with different 'flavours' of firmware.

You said you would like to see: better calibration, more measurement points, more graphs etc.
It's all opensource and you are already writing software - so why no try adding what you want to the firmware yourself?
Several others are already doing that......

Regards,
Larry

How can you tell if it is shielded?? I see several small shielding "cans" on the PCB.? Is that the only shielding that the "shielded" ones have???
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

Rune,?
The only problem I had was that Norton AV thinks it is malware and quarentines it.
Mike WY6K


"... somewhere in the distance, there's a tower and a light, broadcastin' the resistance, through the rain and through the night..."

On Fri, Sep 27, 2019 at 03:44 AM, hwalker wrote:

I don't understand all the theoretical limitations associated with different
FFT sizes; but from a practical use point of view if my $50 device, as a
additional throw-in, can measure a 65 meter length cable accurate to 0.1 meter
then I'm impressed.

more FFT size leads to better time resolution. I don't need to measure cable length with TDR, this is not reliable way, because it depends on cable velocity factor which may vary even through cable length and is not stable, it very depends on temperature, frequency and other factors. More easy and reliable way to measure cable length is to use meter or with measurement tape.

TDR allows to analyze cable and connector issues, such as bad contact, impedance change, delay to incident plane, etc. But it needs at least picosecond resolution to be usable. This is why firmware TDR implementation is useless. With nanosecond resolution it's just a toy for those who want to see what TDR is. NanoVNA memory is too small for better resolution, because it needs at least 16384 points FFT. But you can do it on the PC.

I think that waste valuable controller memory for useless feature such as TDR just for one-time use DEMO purposes is a bad way. It is better to use this memory for more useful features, such as better calibration, more measurement points, more graphs etc. If you're needs TDR, you can do it on PC with much better resolution

Hi Norbert,
Thanks for testing the new functionality! The warnings are normal, sadly,
and really just show how the data from the NanoVNA sometimes shows up very
corrupted on the PC. I don't know what causes them, nor really what can be
done about it. I would have expected a pure serial-over-USB connection to
have far fewer of that sort of error.

I hope the software proves useful for you regardless!

Rune / 5Q5R
=============================================

The first time I ran the software - the current release - I got COM errors as well. They went away when I switched on the nanoVNA. Oops!

One thought, if the current drain of the nanoVNA is too high (when charging) perhaps it's beyond what the USB port can supply? By chance, I'm running mine via a powered, USB 2, hub. Thin USB cables can cause power drop problems too.

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

UOn Fri, 27 Sep 2019 at 15:12, yza <yzaVNA@...> wrote:

18 : @Dr. David Kirkby from Kirkby Microwave Ltd :

/g/nanovna-users/message/3181

Hello,

Thank you very much for your interest in our work !

No problem at all. This looks interesting.

We much appreciate that; indeed. Therefore, allow

us, please, to inform you that, on the one hand
English is -obviously- not our native language,

I realise that. I believe if the information was written in English, to
that the best of your English permits, that would be adequate.

and,

on the other hand, we are deeply regret since our
limited presentation abilities still create so much
confusion to you, even after you already read all
of our references on this subject, of course,
because these are : "the document" "including
adequate references, much like a scientific paper"
you ask for.

People are not going to read all the references in an attempt to follow
you, unless they have some idea what you are trying to achieve. Your very
first post in this thread is

*We just uploaded the current version:*

we don’t know what what this is about. There are other threads from you
started on a similar topic.


However, and in addition to these,

we already wrote, but obviously you didn't notice
it too, at:

14 : /g/nanovna-users/message/3111

This is part of the problem. Your work is spread across multiple threads.
It is very difficult to follow.

Please ask people how many people are following this. I expect it is very
few.

Nevertheless, it is needless to say that we don't
agree at all with your, obviously subjective, comment
that "The whole issue is far from simple"
-
which, by the way, it appears as it is orchestrally
emanated from some honorable specialists of
this forum

I believe that I am correct to say that the problem is not simple. If you
look at the VNWA, there are no proper uncertainty specifications. The
designer of that product is a university professor, but in my opinion at
least, there are no adequate specifications of uncertainty. The subject is
not easy.

Uncertainty of VNA measurements is still an active area of research. There
are many IEEE papers on the topic.

-
as it unreasonably discourages any Radio Amateur,
who is absolute beginner or newcomer to the subject
to even give it a chance to attempt to follow it !

I do not believe absolute beginners will be worry about uncertainty of
S-parameter measurements, as they will not even know what S-parameters
are! Absolute beginners will not know why a short, open and load are used
for calibration.

I personally believe that only once has a certain level of experience will
people start to question the uncertainty of their measurements.

Many amateur radio enthusiasts have very good knowledge of the use of VNAs.


And, as your scientific titles imply, it is certain that

you know very well that this is the worst anti-scientific
attempt to patronize the unsuspecting innocent
victim who comes here wanting to learn.

That is an unfair comment. I am just trying make you aware that few people
are following your posts. That is why this thread contains more posts from
yourself than everyone else added together.

Anyway, since we always try to be good

listeners, we shall also attempt to follow your
valuable subjective suggestions on this very subject
and to learn our lessons : Thank you once more !

I am trying to be constructive. I am trying to bring to your attention that
few, if any people are following your posts, which is why very few are
replying.

Now, regarding the objective points you had the

kindness to also set, which, we assume, you are
definitely referenced to:

[17] : From A Common User's Point Of View
/g/nanovna-users/message/2521

allow us, please, to also gladly answer them, as follows:

No I have not looked, as I do not have a good understanding of what you are
writing about.

(1) You are absolutely right about the "incomplete

definitions of the equations".

This was a deliberate omission, in order to check how
many of the honorable members of this forum
-
who desperately declare their thirsty for the Knowledge,
that is they also passionately seek it in way which
exactly coincides with that permanent of ours
-
are indeed interested for it. Therefore, we also thank
you very much, since you are giving us the happiness
to notice that:

If I understand you correctly, you are saying that you are *deliberately
not defining the terms in your equations to see who is following you. *That
sort of practice *maybe* acceptable if you are trying to teach school
children, but it certainly *not* appropriate practice in this forum. I
believe that the subject is sufficiently complicated for people to
understand, without your deliberate attempts to obscure the subject, just
to see who is following you.

I believe that you need to attempt to make your work understandable by as
many uses of this group as possible, rather than purposely obscure the
subject.

the capital letters are representatives of the "true value"

-
[ well, if you don't have a feeling of what this exactly
[ means, then allow us, please, to inform you that
[ you are not alone, but just one of us, and that all
[ together we are, with many others who have the
[ scientific honesty to admit that they also don't know
[ what that really means, because, in our humble
[ opinion, this is a notion lying on the boundaries
[ between the philosophy and the science, that is it
[ is a primitive notion, an undefined term, and all that
[ in addition to the fact that there are many others,
[ who do not accept that exists such a "true value"
-
A, B. C of three "known" loads, and Gama is of the

If A, B & C are the calibration standards, I would suggest that you use the
term “calibration standards”, rather than “loads”. I appreciate that
English is not your first language, but the term “loads” in the English
technical of VNAs will be considered by most as resistive devices.

*Normally*, the calibration standards for a one port calibration would be
termed the short, open and load in the English speaking world. In waveguide
and high microwave frequencies other standards are necessary.


"unknown" one, while the small letters are the

representatives of the corresponding (VNA or
nanoVNA) "raw" measurements, with the rest
of the multi-letters to stand for either the well-known
indexed S-parameters or for intermediate variables
-
just for the corresponding indexed Numerators to
be used in the calculations and|or the computations
-
which facilitate, as we hope, not only the
comprehension but also the programming, in the
way we are mentioning in [17], that is of complex
variables as they are all the aforementioned ones.

(2) Regarding your interesting contributing notes
about the phase matter, allow us, please to reserve
ourselves from commenting it right now.

Sincerely,

yin&pez@arg

Please understand that I am trying to help you and others by bringing to
your attention the fact that few, if anyone on this group is following you.


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

On Fri, Sep 27, 2019 at 01:04 PM, Rune Broberg wrote:

I just released 0.0.12:



This release of NanoVNA-Saver offers a number of new features, all of which
have been widely requested.

First of all, there's now the option of scaling the plots: right click them
for a menu, where it's possible to set the maximum and minimum values for
the frequency and data axes. Sadly not yet ready for the polar plots, and
mouse control of zoom is also pushed to a future release.

Second, it's not possible to have "bands" displayed in the frequency based
plots: Select "Display setup" to find the option for this. The default data
is for amateur radio bands - or you can put in your own.

Thirdly, the calibration procedure has received a new "calibration
assistant": A series of popup messages prompting you to switch between
calibration standards, and code to automatically sweep them for you and
store the results.

Finally, there's as always a number of bugfixes and stability improvements.

With more than 800 downloads of the 0.0.11 version, I can't wait to hear
what you all think of it this time - and I can't thank this community and
mailing list enough for the support, encouragement, suggestions and testing
you have provided!

I am interested in knowing what platforms you are getting this software
running on, *particularly* if you had had to jump through hoops or do
anything unexpected to get it to run: Do email me at mihtjel@... if
you can tell me what you had to do to make it work, so that I may update
the documentation, or make things easier to install in the future.

Thank you!
--
Rune / 5Q5R

Hi Rune, at the moment I haven't downloaded the latest version, but the new features further improve the program.
In particular, the new calibration routine is really welcome.
As soon as I try the new version I will post my impressions of use and any suggestions regarding subsequent changes.
Best Regards
IZ1MDJ Maurizio

On Fri, Sep 27, 2019 at 04:56 PM, sala nimi wrote:

Transmitter outputs are not matched to the output transistor or fet collector
impedance. That impedance is usually very high. Usually matching circuits are
made so that efficiency is best, that is the output device does not get too hot

max efficiency happens when you match output impedance with the load on the output connector.
More hot on the load means better match and better efficiency. This is pretty easy.

For maximum efficiency and maximum match you're needs to tune it in such way to get maximum hot on the load.

So if you really measure output impedance of a transmitter, you get
strange results.

I do that many times and never got strange results. The result is always expected - about 50 ohms for good equipment

Hi Rune
I forgot the saving calibration is not providing and info for where to save. I doubt it is saving at all.
The guided calibration is perfectly done clear and crisp to understand
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af Rune Broberg
Sendt: 27. september 2019 13:05
Til: [email protected]
Emne: [nanovna-users] NanoVNA-Saver 0.0.12

I just released 0.0.12:



This release of NanoVNA-Saver offers a number of new features, all of which have been widely requested.

First of all, there's now the option of scaling the plots: right click them for a menu, where it's possible to set the maximum and minimum values for the frequency and data axes. Sadly not yet ready for the polar plots, and mouse control of zoom is also pushed to a future release.

Second, it's not possible to have "bands" displayed in the frequency based
plots: Select "Display setup" to find the option for this. The default data is for amateur radio bands - or you can put in your own.

Thirdly, the calibration procedure has received a new "calibration
assistant": A series of popup messages prompting you to switch between calibration standards, and code to automatically sweep them for you and store the results.

Finally, there's as always a number of bugfixes and stability improvements.

With more than 800 downloads of the 0.0.11 version, I can't wait to hear what you all think of it this time - and I can't thank this community and mailing list enough for the support, encouragement, suggestions and testing you have provided!

I am interested in knowing what platforms you are getting this software running on, *particularly* if you had had to jump through hoops or do anything unexpected to get it to run: Do email me at mihtjel@... if you can tell me what you had to do to make it work, so that I may update the documentation, or make things easier to install in the future.

Thank you!
--
Rune / 5Q5R