开云体育

LOn Fri, 27 Sep 2019 at 19:34, Bo, OZ2M <groups.io@...> wrote:

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

I agree 100% with 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

Hi group

I have measured a low pass filter, but experience some, for me expected, oddities around the maximum usable fundamental frequency of the Si5351A. Please see the attached picture that clearly shows an abrupt change in the attenuation between ~300 MHz and ~303 MHz. The NanoVNA should be able to run in 3 x 300 MHz segments, i.e. fundamental plus second and third harmonic. So far so good. However, my experience in working with the Si5351A, and the RFzero project in particular, is that the fundamental frequency from the Si5351A can be used up 280 MHz with 100% certainty, and up to somewhere below 300 MHz depending on the actual device. But once the frequency increases, then the PLL will suddenly not lock, the frequency is of course unstable and the S/N is VERY poor.

The PLL in the Si5351A I have on my RFzero right now can lock at 299,6 MHz, but not at 299,7 MHz. But I have seen Si5351As that cannot lock above ~287 MHz. I don't think it is possible to bet on the max freq. even vs batch.

So why can the NanoVNA say it has 900 MHz, 3 x 300 MHz, usable bandwidth and not e.g. 840 MHz, 3 x 280 MHz, or use the fourth/fifth harmonics? I am a bit troubled with measurements in the 280 MHz - 300 MHz, 560 MHz - 600 MHz and 840 MHz - 900 MHz segments. Should it be an option, in the S/W, to set the max fundamental frequency? I am not thinking of the 1,5 GHz possibilities as such.

Bo

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,
which is so central to the reliable operation of any such
device - either [VNA] or [nanoVNA] !

Well, regarding the matters of a subjective character,
we don't like to repeat ourselves, so allow us, please,
to refer you to our personal replies to other honorable
members of this forum - although, if you are in hurry,
but you are still interested enough, then allow us,
please, to suggest you to search this topic for those
two 2 appearances of [personal taste], as well as,
that one 1 of [expediencies], to which we would like
to add here one more : allow us, please, to take care
of the contents, of our contributions to this very topic,
by ourselves alone.

But, regarding the matters of objective character,
allow us, please, to notice that if someone didn't
pay the owed attention to the subject matter of the
"true value", then he may be sure that he shall
definitely loose the thread of thoughts which
drives to the essence of the Estimation of the
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.

Sincerely,

yin&pez@arg

19

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

It's all opensource and you are already writing software - so why no try
adding what you want to the firmware yourself?

I'm already doing that. Unfortunately I'm not familiar with calibration math, so I have no idea how to improve it.
If you can help with the math details for better calibration, it will be nice.

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