Hi Mike, I've heard a number of users mention antivirus problems. I have tried submitting it to VirusTotal, and it seems the "only" things it reports is a set of a few antivirus programs worried about Python programs being trojans. I think maybe it's a case of ophidiophobia. ;-) Thanks for your report! -- Rune / 5Q5R On Fri, 27 Sep 2019 at 18:13, mike watts via Groups.Io <wy6k= [email protected]> wrote: 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 Friday, September 27, 2019, 6:05:03 AM CDT, Rune Broberg <
mihtjel@...> 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
|
Re: Experimental 256 point FFT Firmware
On Fri, Sep 27, 2019 at 10:23 PM, Larry Rothman wrote:
If the Nano TDR shows shows me a reflection a foot or two away from a
connector, don't you think I will look at the connector before anything else?
If I'm looking for discontinuities in the circuit, which total length is 1 foot total and TDR can show it one or two foot away from real point, I think it will be useless. To be more clear what I'm talking about, here is pictures of TDR measurement for the same S1P file captured with NanoVNA, with different FFT size. This TDR implemented on PC side, so it doesn't limited with memory and don't requires TDR support in the firmware and allows to use any size FFT for tests. Actually I capture this S1P with old firmware which doesn't have TDR in the firmware at all.
|
Re: Si5351A max fundamental frequency
This is why hugen came out with his 800MHz version of the firmware.
|
Hi Kurt,
thanks for all your help with the calibration! I'm still working on it, and
as you say, I need some better functions for saving the resulting
calibration, that it may be used later.
You are right that I haven't implemented scaling for the Y-axis of the
phase display: I'm not entirely sure if it makes sense, so I disabled it
for now. If it's requested and wanted, I'll add it in. :-)
The R+jX scaling is getting another look, as it's clearly not entirely
functional at the moment. There's also some rounding taking place in some
of the charts where the software attempts to show "nice" values for the
tick marks. This might be interfering with the user settings. The scaling
is, clearly, a first attempt. :-)
Thanks again for your help, and for your feedback on the software! I hope
it proves useful for you!
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Fri, 27 Sep 2019 at 17:33, Kurt Poulsen <kurt@...> wrote: Hi Rune
Version 0.0.12 great news.
I have tested your calibration using the Delay and L/C coefficients
together with my HP83033C female calibration standards and tested the
calculated data for equivalent L and C and at 100MHz they are OK.
The scaling of the Data Axis is super but some problem still exist. The
R+jx is if setting to + - 11 is showing 10. I suppose it will come but the
Dara Axis for any of the phase displays are greyed out. That was what I
stumbled over.
I did a T-Check manipulation where I copied the S11 to S22 and S21 to S12
after I subtracted the Thru adaptor delay (42ps) from S21/S11. Result
attached but is not nice simply because there is no 12term error correction
performed. Adding a 10 or 20dB attenuator in front of Port1 would help as
linearizing the port1 input impedance to be closer to 50ohm
Keep up the good work very much appreciated.
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
|
Re: Experimental 256 point FFT Firmware
OK, no problem then.
However, please remember - considering the cost of the NanoVNA - it puts more capability in your shirt pocket than most of its predecessors used by Amateurs.
As I mentioned, it takes no effort to flash different versions of firmware onto the device. We aren't doing microwave design were pico-seconds matter.
And you can take it up an antenna tower - without a PC.
If I need to check out a length of cable from my Tx to the antenna, it is more than adequate to show the approximate location of any issues - and that includes connectors.
If the Nano TDR shows shows me a reflection a foot or two away from a connector, don't you think I will look at the connector before anything else?
It is good enough to play with and get a feel for how it works and that in my opinion is not a waste of time.
Others are using the Nano to learn from - from both a programming and an RF point of view.
There has been some great dialogue in the forum regarding TDR and RF theory in general.
You are sharing your TDR knowledge as well - that's great!
I've worked in the RF field (no pun intended) for 40 years and I'm still learning.
All I am saying here is that the various diagnostic functions that are being graciously developed for the Nano by very talented individuals, may not be for everyone but, they are NOT a waste of time for everyone.
Cheers,
Larry
toggle quoted message
Show quoted text
On Fri, Sep 27, 2019 at 02:21 PM, <qrp.ddc@...> wrote: 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)?
|
Hej Bo,
I'll address the port numbering first: Port 0 and Port 1 should probably be
"Ch0" and "Ch1", and are taken from the port numbering on the physical
device:
While it's quite confusing to have S11 be reflection on port 0, and S22 be
reflection on port 1, that's a physical decision design ... ;-)
I'll address your other comments (thank you for them!) as I go through the
thread.
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Fri, 27 Sep 2019 at 20: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
|
Dr. David Kirkby from Kirkby Microwave Ltd
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
|
Si5351A max fundamental frequency
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
|
Re: errors of "error" models
19 : "true value" - also : @Dr. David Kirkby : /g/nanovna-users/message/3207Hello, 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
|
Re: Experimental 256 point FFT Firmware
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
|
Re: nanovna Battery Specifications
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
|
Re: Experimental 256 point FFT Firmware
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..."
toggle quoted message
Show quoted text
On Friday, September 27, 2019, 12:18:16 PM CDT, Bo, OZ2M <groups.io@...> wrote:
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
|
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
toggle quoted message
Show quoted text
On Fri, Sep 27, 2019 at 01:18 PM, Bo, OZ2M wrote:
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
|
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..."
toggle quoted message
Show quoted text
On Friday, September 27, 2019, 12:00:44 PM CDT, Bo, OZ2M <groups.io@...> wrote:
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.
Bo
|
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
|
Bo, OZ2M
gin&pez@arg
Warren Allgyer
WY6K Mike Watts