I think that the adf4351 would be better:
Main improvements compared to the ADF4350:
* Improved 1/f in-band phase noise (5 dB)
* EVM improvement of up to 30%
* Lower PFD spurs
* Wider output range: 35 - 4400 MHz
* Small frequency/phase jumps possible without band select.
Yes, it can be used as a drop-in replacement. It is fully pin and software compatible with the ADF4350.
Andrea IW2FDH
toggle quoted message
Show quoted text
Il 24/09/2019 04:24, hwalker ha scritto: I gleaned the following information from one of the other nanoVNA user groups regarding nanoVNA version 2.
1. The nanoVNA will eventually reach 3GHz (and at a similar price to version 1).
2. It's going to be based on the adf4350 + si5351.
3. The 3 mixers are replaced with one higher spec mixer (ad8342) that is switched between the 3 channels.
4. A variable gain amplifier is added at baseband using one opamp and switched feedback resistors for improved dynamic range.
5. The Audio codec is removed and the stm32 built in ADC is used instead.
6. The performance should be comparable or better to V1.
7. Info about the baseband VGA design: A RFIC switch is used to switch the shunt resistor in the feedback path. The switch is basically "transparent" because the off state capacitance is in the femtofarad range (it is an RF switch) which is negligible at the IF frequency. The on state resistance is small compared to the resistors being switched in. Since the amplifier gain is mainly dictated by the feedback network, and the switch is "transparent", there is nothing other than the tempco of the physical resistors that can cause a temperature dependence. The RFIC used is the same as for the receiver RF switch, and it turns out all the maxscend switches do not have the shunt diode problem (most RF switch ICs have parasitic diodes from RF input to ground which will start to conduct at lower frequencies), so it has no theoretical lower frequency limit and can be applied at the IF frequency. This is a big improvement over using normal analog switch ICs which have capacitance in the pF range.
8. Info about linearity: The code will perform a calibration of each VGA step on boot up. Since there is no temperature dependence the calibration only needs to happen once.
A preliminary block diagram is attached. You might want to treat this as hearsay until the design appears on GitHub. The design of the original nanoVNA was released in 2016 and it took almost three years for Hugen to take the ball and run with it.
|
Re: Evaluating clamp on ferrite chokes
On Mon, Sep 23, 2019 at 05:09 PM, Kurt Poulsen wrote:
@The ( /profile/TheBoss )
Very kind of you to offer Kurt. I was an EMC project manager up until I retired, so I know how pressing deadlines are. I have time now-a-days to follow my whims and will mock up a few test set-ups on my own and see what kind of data I get. I'll use the manufacturer's data as a reference as you did in your study. I already have access to a shielded test fixture used for calibrating rf current probes up to 1 GHz, and will it as a jumping off point. If I get any data that looks promising I post to the group. Regards, Herb
|
I think this promises to be a very interesting thread.
I spent my career solving wave equation problems. In my case, elastic rather than electromagnetic, the impedance is pure real. But the change to complex impedances for EM is not a big deal. It's still the wave equation.
I bought Dunsmore's book and am extremely displeased with what I have read so far. I regard the TDR chapter as pure marketing FUD. Trivial first year graduate level Fourier transform homework problems are presented without solution except "buy our proprietary software". In fact, there is no explanation of what the figures show in many cases. That might be acceptable in an application note. It is not acceptable in an expensive monograph which purports to be authoritative.
A transmission line is the intro 1D seismic case before going on to the complex and difficult reality of 3D. I've written 1D codes as homework problems, written 2D anisotropic codes professionally and worked on 2D & 3D codes of a range of complexity and methods. The more I look into the VNA calibration problem the more disturbed I am with what I read. I now have a strong sense that some emperors have no clothes.
My training was in the classical mathematical physics tradition, so EE jargon and conventions are often confusing. I'm learning to make the translation, but it's still a struggle. So I'm likely to misunderstand things from time to time. All one can do is press on.
I shall have more to say later.
Have Fun!
Reg
|
I gleaned the following information from one of the other nanoVNA user groups regarding nanoVNA version 2.
1. The nanoVNA will eventually reach 3GHz (and at a similar price to version 1).
2. It's going to be based on the adf4350 + si5351.
3. The 3 mixers are replaced with one higher spec mixer (ad8342) that is switched between the 3 channels.
4. A variable gain amplifier is added at baseband using one opamp and switched feedback resistors for improved dynamic range.
5. The Audio codec is removed and the stm32 built in ADC is used instead.
6. The performance should be comparable or better to V1.
7. Info about the baseband VGA design: A RFIC switch is used to switch the shunt resistor in the feedback path. The switch is basically "transparent" because the off state capacitance is in the femtofarad range (it is an RF switch) which is negligible at the IF frequency. The on state resistance is small compared to the resistors being switched in. Since the amplifier gain is mainly dictated by the feedback network, and the switch is "transparent", there is nothing other than the tempco of the physical resistors that can cause a temperature dependence. The RFIC used is the same as for the receiver RF switch, and it turns out all the maxscend switches do not have the shunt diode problem (most RF switch ICs have parasitic diodes from RF input to ground which will start to conduct at lower frequencies), so it has no theoretical lower frequency limit and can be applied at the IF frequency. This is a big improvement over using normal analog switch ICs which have capacitance in the pF range.
8. Info about linearity: The code will perform a calibration of each VGA step on boot up. Since there is no temperature dependence the calibration only needs to happen once.
A preliminary block diagram is attached. You might want to treat this as hearsay until the design appears on GitHub. The design of the original nanoVNA was released in 2016 and it took almost three years for Hugen to take the ball and run with it.
|
Re: errors of "error" models
Hello, We just uploaded the currently available version of /F/L/O/S/S/ FORTRAN code: Check the functionality of the program, please, by using the included text files : [INPUT.TXT] : 101 Frequencies etc, and: [SH.SC] : Short, [LD.LD] : Load, [OP.OC] : Open, and [ME.ME] : AUT which are the real raw measurements, collected by using an HP 8505A VNA Automatic Network Analyzer System in CW mode under HP-IB control, from a deliberately roughly constructed UHF Ground-Plane Antenna, which was also deliberately roughly installed just outside and in the immediate vicinity of the metal walls of the Anechoic Chamber in our past Antennas Laboratory, in order to produce as much as possible anomalies in the results of Rho and Zeta, as well as of their computed uncertainties both of complex and real value, in terms of 101 frequency steps. Next to come : numerous related references Sincerely, yin&pez@arg PS Also, take a look, please, at the related discussion "on the comparisons": /g/nanovna-users/message/29135
|
Re: Evaluating clamp on ferrite chokes
Hi Herb I did notice you already had mentioned part 2 and 3 "plowing" thru the next messages. Well I need to have a relatively low profile as I am in the midst of a huge project so only limited time. I first got my NanoVNA a couple of weeks ago, and it was unpacked for a week until I got a half day to play with it. Indeed NanoVNA can measure the same data as the VNWA. Actually there is a kind of a part 4 never published as it is only some notes and a spreadsheet and some few articles, as the core material measurement in a closed cylindric chamber facilitates measurements of the material, where I eliminate the inductance of the wire/rod passing thru the core material. Even Fair Rite does not do that, as they use a short wire thru the core. That we got of information from Fair Rite at the time we wrote the articles, but if that still applies I do not know. If you are interested send me a mail to kurt@... and I will offline send you what I have. I have a zip file with the relevant material. And no it will not be published here as I have no time for responding to question for the time being. Kind regards Kurt -----Oprindelig meddelelse----- Fra: [email protected] < [email protected]> P? vegne af hwalker Sendt: 24. september 2019 01:09 Til: [email protected]Emne: Re: [nanovna-users] Evaluating clamp on ferrite chokes Thanks for the heads up Kurt. I linked to parts 2 & 3 in a subsequent reply. I found the whole series of articles to be interesting reading and hope to construct a similar Test fixture for sorting my cache of unknown ferrites into different types. It will be interesting to see how the nanoVNA performs in such an application. Noting the results you achieved using the test fixture and DG8SAQ to evaluate Type 43 ferrite cable clamps, if you still have the fixture available how about conducting a similar evaluation using the nanoVNA and letting us know if it is up to the task. With your experience in this subject matter, I'm surprised you haven't chimed in sooner. Herb
|
Re: Evaluating clamp on ferrite chokes
Thanks for the heads up Kurt. I linked to parts 2 & 3 in a subsequent reply. I found the whole series of articles to be interesting reading and hope to construct a similar Test fixture for sorting my cache of unknown ferrites into different types. It will be interesting to see how the nanoVNA performs in such an application. Noting the results you achieved using the test fixture and DG8SAQ to evaluate Type 43 ferrite cable clamps, if you still have the fixture available how about conducting a similar evaluation using the nanoVNA and letting us know if it is up to the task. With your experience in this subject matter, I'm surprised you haven't chimed in sooner.
Herb
|
Hello, We both thank you very much all of you for your most valuable comments ! We gladly feel that we find a sound ground for a fruitful discussion, as we hope. Well, we don't mean to offend you but, in our humble opinion, the whole story of hp "error" models is just a myth serving the powerful advertisement, so, we don't believe at all that this matter is due to any lack of knowledge or of ability among Radio Amateurs, while, in direct contrast to that, the pioneered Work of whom is usually exploited by patentees. Anyway, we just ask you now to be patient enough and give us the chance to present you: (1) the fortran code by which we estimate the errors of the aforementioned "errors", in full one-port vna measurements (see, please, the related "discussion" [1]), as well as (2) sometime later, the way in which we calculate the errors of the corresponding "errors" in full two-port vna measurements. Finally, we just mention that in the case of nanovna we just took a look at the mathematical expressions included there and we have a feeling -but notice, please, NOT a proof yet- that the "error" model(s) used in the original nanovna code are missing some terms which are present in the original "error" model(s). And this is the reason that we already asked: "if is there any certain knowledge available regarding the specific error model(s) that NanoVNA uses" [2]--but unfortunately without any response yet--so, we did not be able to comment our vna-nanovna comparison results [3], and by the way: after we followed, almost fully, the suggestions given in the Excellent Work of Larry Rothman [4]. Sincerely, yin&pez@arg [1] errors of "error" models /g/nanovna-users/message/2770Saturday, September 21, 2019 04:10 [2] error model(s) /g/nanovna-users/message/2553Wednesday, September 18, 2019 00:24 [3] vna ~ nanovna : (r,x) comparative results but no comments /g/nanovna-users/message/2521Tuesday, September 17, 2019 02:31 [4] Re: List of NanoVNA Console Commands /g/nanovna-users/message/2457Sunday, September 15, 2019 15:23
|
Re: Will a nanoVNA work above 1500MHz?
Did you check it with the new nanoVNA-F? Its general parameters seem to be better by 10dB.
|
Re: Saving results without a PC?
the smartphone solution NanoVNA -webclient would be the solution but for me i get the nice graphs and possible saving of S1P etc but connection with nao fails.
I haven't seen any progress so far.Search messages.
|
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
|
gin&pez@arg
Kurt Poulsen
