Re: Evaluating clamp on ferrite chokes
Hi Bruce and hwalker Please visit www.reeve.com and read the next report where I tuned in and contributed. The linked article are the first step to better methods ? Kind regards Kurt -----Oprindelig meddelelse----- Fra: [email protected] < [email protected]> P? vegne af hwalker Sendt: 23. september 2019 14:27 Til: [email protected]Emne: Re: [nanovna-users] Evaluating clamp on ferrite chokes Bruce, This link might interest you, . It describes a fixture and procedure for measuring ferrite beads using the DG8SAQ VNWA. I believe over their joint frequency range, measurements between the DG8SAQ and nanoVNA have shown close correlation.
|
Re: Strange bug with 5 kHz span
Hi,
I have tested a lot of firmware version, and never one of them has allowed a frequency step below 100Hz.
Are you sure of your previous test ?
To have a firmware allowing a more precise frequency granularity will be really usefull. As exemple to analyse CW filters.
Regards,
David, F4HTQ.
toggle quoted message
Show quoted text
-----Message d'origine----- De : [email protected] [mailto: [email protected]] De la part de qrp.ddc@... Envoy¨¦ : lundi 23 septembre 2019 20:30 ? : [email protected]Objet : Re: [nanovna-users] Strange bug with 5 kHz span Just tested, with previous firmware version (nanoVNA_900_ch_20190802.dfu) it works ok with 5 kHz span. I tried even 10 Hz span and it works ok. But the new firmware version (nanoVNA_900_ch_20190920.dfu) cannot works with a span smaller than 10 kHz. The same issue happens when you trying to setup start frequency 10000 k and stop frequency 10005 k. So, this issue was added in the latest firmware.
|
Re: RX-Port Input Impedance
Hi qrp.ddc The way you wrote "by connecting Ch0 with Ch1" it was obvious the you missed the end of cable calibration ? Always remember a test cable is part of the instrument as you are forced to calibrate at the end of the cable. Doing thu calibration with two test cable the phase for S11 and S21 are in sync at the S11 calibration plane (at the end of the thru adaptor) and if you then measure a DUT with male SMA on input and female SMA on output the you measure accurate and phase sync (0 degree) is maintained but if removing the female female adaptor for measuring a DUT then phase relation ship between S11 and S21 is lost and you measure inside the DUT by the distance/delay of the thru adaptor. The NanoVNA or any of the PC application cannot offset the delay of the thru adaptor during calibration. Kind regard Kurt -----Oprindelig meddelelse----- Fra: [email protected] < [email protected]> P? vegne af qrp.ddc@... Sendt: 23. september 2019 02:25 Til: [email protected]Emne: Re: [nanovna-users] RX-Port Input Impedance [Edited Message Follows] On Sun, Sep 22, 2019 at 11:57 PM, Kurt Poulsen wrote:
Incorrect, that is not a measurement of the CH1 input impedance. The
cable between Ch0 and Ch1 create impedance transformation.
Actually, you're right my previous screenshot was taken with no calibration for cable end plane. :) Previously I already performed this measurement with calibration for cable end and without and didn't found significant difference for VSWR measurement. So I simply repeated measurement with no full calibration for my previous screenshot. But how did you found that this is not cable end calibration? :) Here is measurement with full calibration at the end of cable, you can check it on TDR screenshot. As you can see VSWR is almost the same. I'm using good quality 10 cm RG405 cable, so it doesn't affect VSWR measurement much even with no calibration on cable end. I also tested CH1 with another type VNA and it shows the same result.
|
Re: Evaluating clamp on ferrite chokes
Thanks all for the replies with detailed information, and also the links, which provide a treasure of information. It looks like the nanoVNA will be extremely helpful in looking at the snap-on ferrite cores - I bought a whole assortment of them from Amazon last year when I was fighting an RFI issue - trying to prevent ingress of RF from my transmitter into a Tivo DVR that kept rebooting. The cores never seemed to have much of an effect. I have a suspicion that they are not the right material for the low frequencies involved (3.5-14 MHz). .. and back then my only tool was whether they worked or not...very unsatisfying. But now...with the nanoVNA I will get to find out what the ferrite cores can or cannot do - hooray!
|
Hello Reg,
I brought up this question of uncertainty in measurements several posts ago. Although the calculation is not complicated, obtaining the parameters to find the uncertainty boundaries is a task.
The easiest one to address is S11 and there are papers published by NIST and the Automatic Radio Frequency Test Group (IEEE) that have addressed the exact calculations. I'll see what I can find and can post.
I was unclear what the gentleman in this thread were requesting, but I believe it is the same information required to calculate the uncertainty error for any VNA measurement. For S11 this would include the directivity errors, the reflection tracking errors and the source match errors. These are exactly the three of the five elements posted by the NanoVNA after a cal is complete for S11 only. Additional ones come into play for S21 cal. Hence the measurement uncertainty in S11 is a function of these three LINEAR values which we must obtain (somehow) from the NanoVNA architecture; i.e. the bridge and the mixers.
Once these values are in hand, it is possible to find the difference (error) between the measured S11 and the actual.
For S11 we would find that the difference between the measured and the actual S11 or (S11M-S11A) is given by DELTA(S11) as follows:
DELTA(S11)=(S11M-S11A ) ~ D + TR * S11A + MS * S11A^2
D is the directivity errors, TR is the reflection tracking errors, MS is the source match errors.
Hence, devices with small reflection coefficient, the D value is the source of the major error. While the devices with large reflection coefficient, source match is a most significant error.
This is a very terse answer to a subject that is well documented but not easy to answer in a brief email.
Hope this sheds some light.
Alan
|
On Mon, Sep 23, 2019 at 12:07 PM, Rune Broberg wrote:
Maurizio,
thank you very much! I see the use for separate segments, certainly, but
with the current architecture of the code, it's not easily achievable.
Many, many parts of the code assume uniform frequency steps - they probably
shouldn't, but I would have to go through all of it to implement this and
be sure. So I think for now, I'll go on the backlog, but not for a release
in the very near future.
Regardless, thank you for giving feedback and suggestions - it is much
appreciated.
--
Rune / 5Q5R
On Mon, 23 Sep 2019 at 10:22, Maurizio IZ1MDJ <redifon500@...> wrote:
Hi Rune, thank you very much for the improvements made to the NanoVNAsaver
application. If not too demanding to accomplish, you would like to be able
to define multiple segments, for which you can choose StartFreq StopFreq
StepSize.
Your application makes nanoVNA a truly powerful tool.
Best Regards
Maurizio IZ1MDJ
Hi Rune , many thanks for your attention at my request. I understand very well that is not so easy to modify the architecture of the program. Best Regards Maurizio IZ1MDJ
|
Maurizio,
thank you very much! I see the use for separate segments, certainly, but
with the current architecture of the code, it's not easily achievable.
Many, many parts of the code assume uniform frequency steps - they probably
shouldn't, but I would have to go through all of it to implement this and
be sure. So I think for now, I'll go on the backlog, but not for a release
in the very near future.
Regardless, thank you for giving feedback and suggestions - it is much
appreciated.
--
Rune / 5Q5R
toggle quoted message
Show quoted text
On Mon, 23 Sep 2019 at 10:22, Maurizio IZ1MDJ <redifon500@...> wrote: Hi Rune, thank you very much for the improvements made to the NanoVNAsaver
application. If not too demanding to accomplish, you would like to be able
to define multiple segments, for which you can choose StartFreq StopFreq
StepSize.
Your application makes nanoVNA a truly powerful tool.
Best Regards
Maurizio IZ1MDJ
|
Hi Tom,
[image: image.png]
Coming in the next release. Pushed to GitHub in a few minutes as
development code.
--
Rune
toggle quoted message
Show quoted text
On Mon, 23 Sep 2019 at 07:31, Tom VA7TA <tma.7ta@...> wrote: Hi Rune,
I have made a large number of routine impedance measurements using
your V0.0.10 exe binary under Windows 10 Pro 64b. I have not encountered
any stability problems and in general think it works wonderfully well -
thank you!
One part of the GUI that I didn't understand intuitively the first
few times I used it was the purpose of the "Segments" box. I changed it and
nothing seemed to happen. I of course noticed immediately that it is a
multiplier for the number of steps in the sweep once I changed it and then
happened to do a calibration which shows the number of steps in the sweep.
I decided I would like to make a suggestion that I hope is worthy of
consideration.
It occurred to me that it would be obvious to the user that the
segments setting increases the sweep frequency resolution if the number of
Hz per step could be shown. Additionally I think the provision of the
"Hz/Step" information would be useful in some situations. For example when
sweeping a network with narrow high Q responses the user may wish to select
a segments setting that provides a sufficiently small step size to ensure a
narrow peak or null is not missed without increasing the sweep time any
more than necessary. A second advantage for providing the "Hz/Step" data is
that it would provide immediate indication of how a change of the segments
setting changes the sweep resolution. This feedback would make the setting
more user intuitive I think.
Considering that the number of segments would never exceed two
digits and the number of Hz per step would never exceed 7 digits there
might be room to fit the two boxes on the existing segments line within the
GUI. If for example the "Segments" label were abbreviated to "Segs." with a
two digit box then possibly there would be room for another label something
like "Hz/Step" followed by a 7 (or 9 if 2 comma delimiters) digit box on
the same line. Just might be one of many possible ways to implement it
without impacting the existing GUI layout very much.
Thanks again for your great contribution - "NanoVNA-Saver" really
enhances the usefulness of my nanoVNA for what I intend to use it for!
Enjoy!
Tom
VA7TA
|
Re: Saving results without a PC?
On Mon, Sep 23, 2019 at 09:55 PM, <bryburns@...> wrote:
press "Pause Sweep", and the data is saved in the nanovna
nice trick, but it will works until power off...
|
Re: Saving results without a PC?
Bruce,
You could calibrate the device, make the measurement of interest, go to "Stimulus", press "Pause Sweep", and the data is saved in the nanovna. The device under test can be removed and the data is preserved in the nanovna. Unfortunately, I don't seem to be able to get the serial port to work once the nanovna is connected to a computer without resetting the device which drops all of the data.
Does anyone have a cell phone application that will read data from the nanovna using an On-The-Go cable? If so, this method could bring the data into the cell phone where it could be saved.
--
Bryan, WA5VAH
|
Re: Saving results without a PC?
there is no memory on the board to store results.
|
Re: Strange bug with 5 kHz span
Just tested, with previous firmware version (nanoVNA_900_ch_20190802.dfu) it works ok with 5 kHz span. I tried even 10 Hz span and it works ok.
But the new firmware version (nanoVNA_900_ch_20190920.dfu) cannot works with a span smaller than 10 kHz.
The same issue happens when you trying to setup start frequency 10000 k and stop frequency 10005 k.
So, this issue was added in the latest firmware.
|
Saving results without a PC?
I am finally understanding the concept of calibrations and saving the settings/range in the nanoVNA. But I am wondering if there is any way to save results from out in the field and then recall/display them later, without having to drag a PC around with it. Or maybe that should go on a "wish list" for a firmware update.
|
How does one calculate the uncertainties of an out of calibration VNA and calibration kit bought on ebay?
In an ideal world everyone would do as you ask. But the nanoVNA has made it possible for people with relatively little or no VNA experience to have one. And many only have experience with hobby grade VNAs.
Even well educated people with extensive experience with professional grade VNAs often lack the mathematical skills to do completely rigorous analyses of their measurements.
I'd like to urge you to write a document describing how to do what you ask within the constraints of what is available to the individuals making the measurements. My undergraduate degree was English lit, but I'm a PhD level geophysicist with very strong mathematical skills. I don't know how to do what you ask, though I'm sure I will eventually learn. If you will create a rough draft and post it in the Files section, I'll help with polishing up your English.
Have Fun!
Reg
|
Re: Strange bug with 5 kHz span
I've seen at least one firmware version where the minimum attainable step
size was 100Hz. I don't exactly know why, but your findings fit my
observations as well.
--
Rune
toggle quoted message
Show quoted text
On Mon, 23 Sep 2019 at 18:09, <qrp.ddc@...> wrote: I catch some strange bug in the latest firmware. I tried to get better
resolution around 26.996500 MHz to see crystal resonance. Span 10 kHz works
ok. But when I trying to setup span=9 kHz or 5 kHz or any value below 10
kHz I just got strange measurement fail with saw waveform on the screen.
See screenshots.
Steps to reproduce:
1) Set center frequency 26.9965 MHz
2) Set span 10 kHz and make sure all is ok
3) Set span 5 kHz and make sure there is a bug.
Any idea why it happens?
|
Strange bug with 5 kHz span
I catch some strange bug in the latest firmware. I tried to get better resolution around 26.996500 MHz to see crystal resonance. Span 10 kHz works ok. But when I trying to setup span=9 kHz or 5 kHz or any value below 10 kHz I just got strange measurement fail with saw waveform on the screen. See screenshots.
Steps to reproduce:
1) Set center frequency 26.9965 MHz
2) Set span 10 kHz and make sure all is ok
3) Set span 5 kHz and make sure there is a bug.
Any idea why it happens?
update: I tested previous firmware version nanoVNA_900_ch_20190802 and this bug is missing. So, this bug was added in the latest firmware nanoVNA_900_ch_20190920.dfu
update 2: it doesn't matter what frequency is selected for the center frequency. This bug happens when you set span smaller than 10 kHz
|
Re: Evaluating clamp on ferrite chokes
I tried the S21 method. Connected the 2 center pins (CH0 and CH1) to the choke ends (coax shield on both ends). -20dB at the frequency of interest is a decent common mode attenuation. -30dB is good. -40dB is excellent, but is hard to achieve.
73, Mike
|
Re: Evaluating clamp on ferrite chokes
Yes, that's all you need. I ran a similar case with a single strand of #22 AWG with and without the addition of the lossy core material. Although very nice particularly for looking at common mode noise suppression, you don't need the fancy test set outlined in the prior post. A measure of S11 along with S21 will demonstrate the sweet spot or corner frequency where the complex permittivity of the core material has its real part equal to its imaginary part. There will be a distinct increase in transmission and reflection loss. I did my test with perm of 4000. Corner frequency ~ 5 MHz.
Alan
|
Yes, I am familiar with the "other" PN systems.
Thanks for the clarification. I assumed this was test set limited, however, just to be sure.
Regards, Alan
|
Re: Evaluating clamp on ferrite chokes
A poor mans test jig for checking if these cheap chinese chokes do anything.
Two SMA female chassis connectors with the ground pins soldered together and a short wire connecting the center pins. The nanoVNA is calibrated with the cables connecting to the SMA connectors and the reference plane is at the end of the CH0 SMA connector.
This impedance seen from CH0 is at 100MHz without the choke 52ohm+90nH but with the choke 190ohm+190nH
It seems these chokes are doing something.
|
Kurt Poulsen
