Beware of cheap underperforming clones

As of 2022 there are many badly performing clones on the market. V2/3GHz NanoVNA uses parts like ADF4350 and AD8342 which are costly and clones have been cutting costs by using salvaged or reject parts.

See official store and look for V2 Plus4/V2 Plus4 Pro versions only to avoid getting a bad clone. We have stopped selling V2.2 versions since October 2020, so all V2 hardware that are not Plus or Plus4 are not made by us and we can not guarantee performance.

NanoVNA V2 Forum

Note: this page is a mirror of https://groups.io/g/NanoVNAV2.
Click here to join and see most recent posts.

CW pulses

Kurt Poulsen 2020/08/18 12:01

Hi all

I have been made aware that when chosing CW the output is pulses. Same
happens when choosing center frequency and span 0. Stopping the sweep does
not help either.

Any hints form any of you ? Is it a firmware bug ?

Kind regards

Kurt

hwalker 2020/08/18 04:46

On Tue, Aug 18, 2020 at 03:01 AM, Kurt Poulsen wrote:

...I have been made aware that when chosing CW the output is pulses. Same happens when choosing center frequency and span 0. Stopping the sweep does not help either.

Any hints form any of you ? Is it a firmware bug ? ..
=================================================
Kurt,
Back in April, member John Gord reported that issue to Gabriel after trying to use the V2 as a signal generator. Gabriel replied that Port 0 is periodically switched on and off to provide ECAL temperature stabilization.

When the NanoVNA-V2 is used as a CW generator this results in a signal that is switched on and off rather that having a constant output. This should not be an issue when the V2 used strictly for its intended purpose as a VNA.

- Herb

Kurt Poulsen 2020/08/18 15:19

Hi Herb
Thank you for the info. I must have overlook that so the function CW is a bit misleading/ not so relevant
Kind regards
Kurt

ok1vaw 2020/08/18 09:17

I think the mode could be named CW Generator. This will be different from mode working as measurement with zero span. Even when it is possible to measure on single frequency with zero span, the CW means continuous wave too.

ok1vaw 2020/08/18 09:21

I have forgotten - the info about that behavior is on the GitHub since April, see https://github.com/nanovna/NanoVNA-V2-firmware/issues/3#issuecomment-657451278.

Isidro Berniol 2020/08/28 03:55

Today my NanoVNA V2 arrived and after some short testing I stumbeled upon this pulsing CW issue.

I was fustrated at all, using the unit as a signal source capable of higher frequency range then the V1 was one mein reason to buy it.

The CW mode don't make sense at all this way.
It's not a question of money to buy also one of this nice litte ADF signal generators, but It's a question of how many boxes I like to cary around.

Output level looked nice between 10MHz and 2.7GHz (-10 to -14dB), will test the whole range later.

Any idea when this will be corrected?

Regards,

Isidro

hwalker 2020/08/28 06:07

On Fri, Aug 28, 2020 at 03:55 AM, Isidro Berniol wrote:

Today my NanoVNA V2 arrived and after some short testing I stumbeled upon this pulsing CW issue.

I was fustrated at all, using the unit as a signal source capable of higherfrequency range then the V1 was one mein reason to buy it.

The CW mode don't make sense at all this way.
It's not a question of money to buy also one of this nice litte ADF signal generators, but It's a question of how many boxes I like to cary around.

Output level looked nice between 10MHz and 2.7GHz (-10 to -14dB), will test the whole range later.

Any idea when this will be corrected?
===========================================================

Isidro,
If you search through the archives you'll find the V2 does periodic temperature compensation. This does not affect its intended use as a network analyzer but when used as a signal generator you will see an interruption in the signal output when temperature compensation is being performed.

Gabriel, the V2 designer, said she will consider adding a user selectable option that temporarily turns off temperature compensation. She no longer uses this group as her primary means of user support, so you'll have to ask elsewhere if she is still considering adding the feature to temporarily disable temperature compensation.

- Herb

Isidro Berniol 2020/08/28 17:19

Hi Herb,

thank you, that makes sense.

But on the other side if the unit has a cw mode it should be doing
exactly this.

If I only like to measure at a fixed frequency I could also set the span
to zero.

But there is also an other possible solution. The A+ output of the ADF
chip isn't in use, so maybe I will add an additional SMA socket with the
outputt of the ADF chip.

This would also increase the power level by round obout 10dB.

Downside would be to only have the upper frequency range available, not
the band provided by the clock chip.

Any idea how to reach out to the developer?


Regards,

Isidro

Am 28.08.2020 um 15:07 schrieb hwalker:

- Show quoted text -
aleks07111971 2020/08/28 08:32

https://groups.io/g/NanoVNAV2

Isidro Berniol 2020/08/28 18:35

Thank you!

Am 28.08.2020 um 17:32 schrieb aleks07111971@yandex.ru:

- Show quoted text -
switchabl 2020/08/29 09:18

I've already posted this on EEVBlog, where this was discussed as well, but there may be more people here who are interested in this. I made a firmware patch that allows (non-pulsed) CW output, originally for performance testing purposes. But I've improved it a bit since and it may be more generally useful:
https://github.com/switchabl/NanoVNA-V2-firmware/tree/cw

Basically, because of the way the V2 does the reference measurements (using a switch instead of a coupler), it cannot really ouput CW during measurements, even in CW time/zero span mode. But with the modified firmware it outputs CW at least when you pause the sweep (in CW mode or otherwise). I'm not convinced this is the ideal solution, I think it would be more intuitive to turn off the output altogether when the sweep is paused and have a separate generator mode. But it is a relatively easy workaround and it suits my needs.
The output is flat-ish a bit below -10dBm and obviously there is a lot of harmonic content.

I have uploaded a binary too:
https://github.com/switchabl/NanoVNA-V2-firmware/releases/tag/cw-test3
Note this is still experimental, and based on the bleeding-edge master branch. Try at your own risk!

If there is sufficient interest and no issues, I can make a pull request and try to get it included in the official firmware.

namerati 2020/08/30 00:04

On Sat, Aug 29, 2020 at 09:18:33AM -0700, switchabl@mailbox.org wrote:
>The output is flat-ish a bit below -10dBm and obviously there is a lot of harmonic content.

How much harmonic content?

John Gord 2020/08/29 21:01

For 1GHz output, I see -14dBc at the 3rd harmonic and -22dBc at the 5th harmonic.
For 4GHz output, I see -24dBc at the 2nd harmonic and -45dBc at the 3rd harmonic.
--John Gord

On Sat, Aug 29, 2020 at 05:04 PM, <namerati@mailo.com> wrote:

- Show quoted text -
John Gord 2020/08/29 21:29

Below 140MHz, the output risetime is about 920ps, above 140MHz I see about 220ps. This is measured with an HP 54120B/54121A sampling system with risetime well under 30ps.
--John Gord

On Sat, Aug 29, 2020 at 09:01 PM, John Gord wrote:

- Show quoted text -
namerati 2020/08/30 10:25

On Sat, Aug 29, 2020 at 09:01:27PM -0700, John Gord via groups.io wrote:
>For 1GHz output, I see -14dBc at the 3rd harmonic and -22dBc at the 5th harmonic.
>For 4GHz output, I see -24dBc at the 2nd harmonic and -45dBc at the 3rd harmonic.
>--John Gord

Thank you! That is indeed a lot of harmonic content. I wonder what are
the chances that a future NanoVNA will have a cleaner output signal.

switchabl 2020/08/30 07:24

On Sun, Aug 30, 2020 at 02:22 PM, <namerati@mailo.com> wrote:
> I wonder what are the chances that a future NanoVNA will have a cleaner output signal.

Any significant improvement would likely involve filter banks, some heterodyne stage or/and low-band DDS. And once you go to all this effort, you will probably want to add an attenuator and an ALC loop as well. I don't really see that happening with this form factor and this price point (unless maybe a cheap integrated solution turns up), especially considering that for many VNA applications it really doesn't matter that much.

ok1vaw 2020/09/02 04:07

Hello, thank you very much for your effort and making the CW available. Will the CW mode be available through the USB interface as well by use of some command? And only to be sure - which firmware for V2 have you modified? I have still the June version, which was the last official one.

switchabl 2020/09/02 05:56

The patch is based on the current master branch from Github. It is basically a development snapshot and not an official release, so may come with unexpected bugs (or features).

USB control is possible in principle, but that should be considered an accident for now. In the current version, the pause flag is not cleared when you connect through USB, so it will continue outputting CW, if pause was on. And you can still change the frequency by writing to register 0x00 (sweepStartHz). But you will need to write your own code for this. NanoVNA-QT and NanoVNA-Saver will choke because they try to read measurements immediately and none are available. There is currently no way to switch between CW and measurement mode through USB.

Since there does seem to be some interest in this, I will see if this can be merged into the official firmware. So any feedback from people who have tried it so far is highly appreciated (does it work as intended? have you encountered any issues?)

Wouter van Gulik 2020/09/02 14:23

Hi all,

Today I finally finished my CW fix work and ecal mode disable.
As some of you found out already CW is not continuous with this new firmware it is.
You can also disable ECAL in this version to speed up the measurement. ECAL disable is in menu where sweep points used to be.

Today I saw @switchabl also made a CW fix mode. I am not sure which solution is better. But please feel free to test.
You can get the firmware from:
https://github.com/wutje/NanoVNA-V2-firmware/releases/tag/HEAD

Wouter
.

CT2FZI 2020/09/02 14:41

Outstanding.

Thank you Wouter.

John Gord 2020/09/02 15:16

Wouter,
Thank you!
It seems to scan faster when the "SET ECAL" box is checked. Does a check in the box mean "Disable ECAL" instead?
--John Gord

On Wed, Sep 2, 2020 at 02:23 PM, Wouter van Gulik wrote:

- Show quoted text -
John Gord 2020/09/02 16:08

Wouter,
Using your firmware, if I set, say, 150MHz CW, the signal seems to be disturbed for about 150 microseconds every 6.8 milliseconds. (It It does not turn off, but shifts in frequency briefly.) If I set 100 MHz CW, the signal shuts off for about 750 microseconds every 22 milliseconds. I assume the difference is due to the two different synthesizer chips. Do you know what is causing the disturbances?
Thanks,
--John Gord

On Wed, Sep 2, 2020 at 02:23 PM, Wouter van Gulik wrote:

- Show quoted text -
switchabl 2020/09/02 18:43

I haven't tested it myself, but from a quick glance at the code, I think that what happens is this: after every measurement, doEmit is called, which in turn calls sweepAdvance. Although the frequency step is 0, this still "updates" the frequency and for some reason this causes the PLL to loose its lock.

I can see that Wouter's approach (as I understand it) is quite different from mine. I will try to quickly compare both:

Wouter: When the frequency step is 0 (aka CW frequency is set), keep measuring, but only measure transmission. No reflection, no ecal and no reference measurements.
The main advantage I see is that this gives very intuitive behaviour. When a CW frequency is set, it outputs a CW signal (well maybe not quite, but this seems fixable). On the down side, it would seem to compromise the measurement capabilities in CW time mode. There is no more reflection measurement. And although I haven't tried it, I suspect the transmission measurement may drift and potentially loose phase lock at some point.
I haven't really looked at the ecal disable portion, but I guess this is mostly independent?
Please correct me, if I got anything wrong.

switchabl: After some experimentation, I ended up adding a "pause" state to the masurement state machine. When the sweep is pasued, the measurements are stopped altogether and a CW signal is generated. The normal CW time mode is untouched and measurements work as before. The disadvantage is that it doesn't actually output CW unless you also pause the sweep.

I am still trying to think of a solution that behaves in an intuitive way and retains the "zero span" measurement mode. Ideally, we could have a separate generator mode, where the frequency and keyboard is shown permanently, maybe together with an "RF on/off" button. But this seems like a big modification and I at least am not keen on that. I have to admit I find the code base somewhat messy and confusing.

A simpler solution might be this:
- rename the CW frequency button to something like "fixed frequency"
- add a "CW output" button, that pauses the sweep and keeps the output on
- if you pause the sweep without also checking CW out, output is turned off

What do you think?

John Gord 2020/09/02 22:08

switchabl,
I think the simplicity of what you originally did is good. All selected measurements continue in "CW" mode, but true CW output occurs if the sweep is paused. Keeping the measurements going during CW sweep is handy for fast feedback when tuning for best match or gain at a particular frequency.
I note that the Smith chart graticule is not visible in CW mode. Is that intentional?
--John Gord

On Wed, Sep 2, 2020 at 06:43 PM, @switchabl wrote:

- Show quoted text -
switchabl 2020/09/03 05:11

On Thu, Sep 3, 2020 at 07:08 AM, John Gord wrote:
> I note that the Smith chart graticule is not visible in CW mode. Is that
> intentional?

I don't believe so. Actually, it appears that the Smith chart is drawn correctly. Unfortunately, the code that draws the rectangular grid doesn't handle zero span properly and draws over it. The latest official release has the same problem. But shouldn't be too hard to fix.

Wouter van Gulik 2020/09/03 13:14

Hi all,

Thanks for all the feedback. Really appreciate that!.
I created a new version that should have fixed all issues and added THRU + REFLECTION measurement for more info & download see:
https://github.com/wutje/NanoVNA-V2-firmware/releases/tag/cw_mode_fix-beta.2

@switchabl
Yes you are correct on what caused the tiny loss that John Gord found.

>From what I read in other messages the CW mode is also known as ZeroSpan mode and that is how other VNA's work. So I tried to stick to that principle.
About ECAL; it is implemented to compensate for temperature drift, not PLL drift. Or am I missing something? And yes it is not really related, I was my first try to enable CW mode, but then I discovered that I need to have measurements to keep the display running etc.
Also ECAL could be extended to a full ECAL mode apparently, have not check it, but adding support for that should be easier now.

Yes the code is setup a bit fuzzy, lots of indirections. My guess is the goal was to keep the measurement part equal and provide different functionality in the callbacks. It does make it harder to understand.

Pausing the sweep might be a good alternative if my code is turns out to be no solution.

Thanks,

Wouter

I have not played with time mode yet

switchabl 2020/09/03 13:58

Wouter,

thanks, I will take a look. I originally wrote my code for my own use, so I could do some measurements on the output. When the issue came up on the EEVBlog forum, I figured it may be of use to other people. I hadn't been aware you were working on this too.

In general, I would prefer the device to output CW in "CW mode" even without pausing the sweep (I am a beliver in the Principle of Least Astonishment). But I don't want to compromise the measurements in this mode either (on spectrum analyzers it is usually called "zero span", on Keysight VNAs it is "CW time"). I think especially considering the relatively slow sweep rate of the SAA2, this can be quite helpful for tuning purposes.

With this approach we cannot ever do ecal or even reference measurements. This will definitely introduce some drift, I am just not sure how bad it would be. It may or may not be acceptable. I have not looked in detail at how the ecal works, but I guess it can compensate for directivity drift? I am more worried about the reference measurement. I don't know how much the source output power drifts.
In the worst case, you might drop some ADC samples or something and then the phase reference could be completely off and there would be no way to get it back. That is what I meant by "losing phase lock", sorry that was unclear, I didn't mean the PLL.

ok1vaw 2020/09/06 13:56

I have tested the firmware, the CW mode works well, finaly it is possible to measure the phase noise quality of the V2. The only thing what seems to be strange is "double stepping" on the phase characteristic - it seems like the frequency change is not continuous. See the attached pictures from NanoVna-saver when I was measuring about 2m of open end cable , where it is significant on the phase s11 and Re/Im graphs.

double_steps4.png
double_steps3.png
Isidro Berniol 2020/09/06 21:46

Wouters Firmware isn't working for me. If the ecal is marked, I can do cal but the screen is erratic, if I uncheck ecal the measurement looks ok, but cal hangs, have to switch off on.

switchabls firmware is working nice.

Perfect to have a cw mode now.

A generator mode with S11 reading in db would be nice. Frequency in big letters, buttons to set the frequency if no menu is open. stepsize depending on the digit that is underlined, like Anritsu is doing it.

Regards,

Isidro
DB1SBI

Stephen Laurence 2020/09/07 06:57

I have not tried to use or change firmware regarding the cw output.

However, I would rather not lose the sweep points control.

Steve L. G7PSZ

Isidro Berniol 2020/09/07 16:40

You don't loose sweep points control with @switchable mod.

Isidro DB1SBI


Am 07.09.2020 um 15:57 schrieb Stephen Laurence:

- Show quoted text -
switchabl 2020/09/07 11:18

@ok1vaw: Which firmware is this? I can not reproduce the phase issue on mine.

I fixed two more minor issues:
1) when you connect with QT/saver while the sweep is paused, the NanoVNA would hang
2) in CW time mode, the Smith chart would not be displayed (as reported by John; this is independent from my changes, but I thought I would address it while I was at it)
https://github.com/switchabl/NanoVNA-V2-firmware/releases/tag/cw-test4

>From my point of view, it is essentially finished. The question is how to proceed. In principle, this could now be merged into the mainline firmware. It is a simple and robust solution in that you can get CW output when you want it and it doesn't disturb the normal VNA operation in any way when you don't. For my purposes this is all I need.
It doesn't completely address the issue, because if you don't pause the measurement you still get pulses and this is not immediately obvious to the user. Wouter's approach does, but it potentially impacts measurement performance (even if only in zero span mode). I think it will at least require very thorough performance testing to ensure it is acceptable to include it.

Wouter, what do you think? Should I make a pull request now, so we have something that works or does it make sense to wait because it is likely to be superseded by your work soon?

Wouter van Gulik 2020/09/07 11:31

Hi all,

@DB1SBI is right, my firmware is not working properly; calibration has become impossible. The code is apparently even more complex then I thought.
Perhaps ECAL should be forced on during calibration? Or my ECAL mode is not properly setup during init. I will look into it.

Regarding the phase change; during CW mode the THRU and the REFLECTION are measured, perhaps this changes the phase response?

So from what I can tell there is need for several sorts of CW mode:
- True CW mode, no switching what so ever
- "Measuring" CW mode, continuous CW but THRU and REFLECTION are still measured
- "ECAL/Original" CW mode, intermittent CW mode, but with ECAL still applied.

All this boils down to which measurements are made:
In True CW mode only one thing can be measured; THRU or REFLECTION.
In "Measuring" CW mode, REFERENCE is added.
In "ECAL/Original" mode, two ECAL measurements are added.

Does this cover all use cases?
Is it useful to have this configuration outside of CW mode?
"Measuring" mode is faster then ECAL so that seems a valid a reason for some people.

Wouter

ok1vaw 2020/09/07 12:55

I downloaded and tried this one:
https://github.com/wutje/NanoVNA-V2-firmware/releases/tag/HEAD from Wouter.
I use Nanovna V2 from Tindie, in the about it vrites version git 20200903-ef260b build time sep. 3 2020 21.53.14.
First I thought it is some digitizing error, but with longer cable it is evident that two measurements have same phase.

switchabl 2020/09/07 13:41

I am not sure we actually need all the different configurations.

Switching between THRU and REFLECTION may not matter much. The termination at the coupled port of the bridge might change slightly, but hopefully the source doesn't see much of that. So we may get away with always doing both measurements.

I guess it is possible to come up with situations where you actually don't want a pulsed output during your measurements. Likely something involving active devices, where power consumption and thermals may change at low duty cycle. But I think that would be pretty exotic.

The normal time/zero span measurement mode is definitely useful. It would be more useful if there was some trigger mechanism, so you could e.g. use an external programmable attenuator for a power sweep. But even without triggering, it at least gives you almost instantaneous feedback.

So I think we need a mode that has CW output (with maybe limited or no measurements) and one that can do reasonable measurements. And maybe we can get away with one that does both (if the drift from not having reference and ecal turns out to be acceptable).

Additionally, there may be indeed some value in being able to turn the ecal off for faster measurement speeds in general. I have no idea how much performance suffers without it. From the looks of it, ECAL_PARTIAL is currently defined in common.hpp, so only the load measurement is done anyway (to compensate for directivity drift). The ecal logic seems to be scattered all over the place, so implementing that without inadvertently breaking something else is surely a challenge.

Wouter van Gulik 2020/09/07 15:21

Hi all,

I finally found was wrong. Turns out settings frequency is... settings frequency AND calling setCorrelationTable, and baseband gain reset.
Anyway please feel free to test this new release:
https://github.com/wutje/NanoVNA-V2-firmware/releases/tag/cw_mode_fix-beta.4

So selecting CW mode / zerospan will do a THRU and REFLECT measurement.
For the other measurement one can disable the ECAL to speed up the measurement.

It still feels a bit wrong to have two variables control the behavior, I feel in the long run it will be better to just let the user select the options.
I am not afraid that changing the order is going to break ECAL stuff. Not anymore. We just need to make sure we hop through the correct sequence for the RF switches.

If this version works (aka me not breaking other stuff) then I would suggest to try and get my code up for a merge request.

Wouter

Isidro Berniol 2020/09/08 05:05

Thank you for verifying.

I think we need a true CW mode and also the faster sweep is very very
interesting.

The main reason for a fast sweep is to find conectivity failures.
Shake the cable and look the response.
If it goes faster to measure only S21 or S11 then speed is the choice.

On higher frequencies also the phase change of cables is important, but
not at this frequency range.

If I understand the measurement concept right there is only one receiver
that is switched to the mesurement sources.
So a question would be if the switching of the receiver to the S11 or
S21 position would affect the output level or teh port 2 termination
resistance.

Isidro DB1SBI



Am 07.09.2020 um 20:31 schrieb Wouter van Gulik:

- Show quoted text -
switchabl 2020/09/08 05:07

On Tue, Sep 8, 2020 at 05:05 AM, Isidro Berniol wrote:
>
> On higher frequencies also the phase change of cables is important, but
> not at this frequency range.
>
Don't say that, always verify! I've been able to produce several dB of ripple at 3GHz by flexing a 1m cable. Not with a proper test-port cable of course, but not some ebay special either (Agilent-branded).
It is a bit like with torque-wrenches. You only appreciate them after you have seen your S11 measurement jump by 10dB a couple of times after re-checking a connection you thought was "hand-tight".

> If I understand the measurement concept right there is only one receiver
> that is switched to the mesurement sources.
> So a question would be if the switching of the receiver to the S11 or
> S21 position would affect the output level or teh port 2 termination
> resistance.

Those are the right questions. It is even slightly worse than that, because the source output may also change depending on the DUT (non-linearly, in a way that is not accounted for by source-match calibration), since the "reference" measurement is done without any load. I currently have no reason to believe this effect is large, but it is a pain for uncertainty modeling. It may also slightly degrade CW output, this remains to be checked.

The second issue is mostly a problem for full two-port calibration which the NanoVNA doesn't natively support anyway.

John Gord 2020/09/08 08:02

Switchabl,
I have not delved into the source code, but I was under the impression that the "reference" measurement on the NanoVNA-V2 is done with the port switch connected to the internal 50 ohm load. Is that not correct?
--John Gord

On Tue, Sep 8, 2020 at 05:07 AM, @switchabl wrote:

- Show quoted text -
switchabl 2020/09/08 09:27

No, this is not the case. The (single) receiver can be switched to measure either a) the coupled output of the directional bridge (reflection) or b) on port 2 (transmission). In a classic VNA there would be either a reference coupler of a resistive splitter after the source, but the V2 has neither.

The reference measurement is done through the reflection path. There is a four-way switch at the input port of the bridge with
a) an open circuit (unconnected pin)
b) a short circuit (grounded pin)
c) a load (50 ohm resistor)
d) port 1
For the reference measurement the open a) is used. The source output goes out through the bridge, through the switch, is reflected at the open, back through the switch, back through the bridge, coupled to the receiver.
The short b) is not used at the moment.
The internal load c) is also measured regularly ("ecal") to compensate for directivity drift (I think).

It seems to work quite well in general, but it is definitely unorthodox. And it is not a true ratio measurement so the model normally used for calibration is strictly speaking not valid. Same for port 2, so extending the architecture to a full two-port design may be problematic.

John Gord 2020/09/08 13:52

Switchabl,
OOPS. Connecting the internal 50 ohm load would be bad for a reference channel measurement, of course. It would provide very little signal! I wasn't thinking.
--John Gord

On Tue, Sep 8, 2020 at 09:27 AM, @switchabl wrote:

- Show quoted text -
ok1vaw 2020/09/08 14:24

i confirm no problem with measurement with switchabl firmware with measurement. Attached are some pictures with spectrum. It is clear, that up to 150MHz the SI575 outputs the raw rectangle output rich with odd harmonics. The output spectrum of the V2 itself corresponds to the sources inside.

adf4351.jpg
si5351.jpg
harmonics si5351.jpg
ok1vaw 2020/09/08 15:17

Maybe a small addition, the phase noise of ADF4531 is poor in comparison to the datasheet values, I have got something about -65dBc/Hz on 100kHz at 1,45GHz only, the natural frequency of the loop is quite slow, but maybe it was an intention. I think that such wideband VCO needs an ultra low noise power supply, as far as the VCO is extremely sensitive to noise on power supply, but it is clear, that price of such stabilizer IC is in the range of 10USD or more. Similar problems have cheap frequency ADF4351 evalboards from ebay (https://gm8bjf.joomla.com/images/pdf/LRS_pll_talk_2.pdf)
How much the improvement of the phase noise brings an improvement to the vector measurement value I do not know.
Maybe a question to Owo or other designer.

John Gord 2020/09/08 15:25

Not all -V2s perform alike. (At least my two do not). The CW phase noise on one of my units (purchased early in -V2 history) is
-86dBc, 130MHz, 20kHz offset, -82dBC, 150MHz, 20kHz offset.
A later unit has
-114dBc, 130MHz, 20kHz offset, -107dBC, 150MHz, 20kHz offset.
Both units are running the same firmware.
Both seem to meet specifications, in fact, I cannot see any big performance differences in their "normal" VNA performance.
I suspect the problem is phase noise in the crystal oscillator of the poorer unit, but I haven't taken it apart to verify that.

--John Gord

On Tue, Sep 8, 2020 at 02:24 PM, ok1vaw wrote:

- Show quoted text -
John Gord 2020/09/08 15:34

Replying to my own message:
Thinking about what ok1vaw said in msg 1235, the power supply seems like the more likely noise source on my poorer unit, as the noise extends well beyond the presumed loop bandwidth. The crystal reference shouldn't affect that very much.
--John Gord

On Tue, Sep 8, 2020 at 03:25 PM, John Gord wrote:

- Show quoted text -
ok1vaw 2020/09/09 02:55

I was measuring the PN on 1495MHz (the top limit of SA HP ESA-L1500A is 1500MHz) with following results:
delta f dBc/Hz
5kHz -64
10kHz -62
30kHz -60
100kHz -62
300kHz -76
1MHz -103

If we compare to the datasheet, we are about 25dB worse. I suspect the IP5305 regulator or the 3225clock. Does anybody know, what is the frequency of this crystal reference (if it is crystal, I saw similar clock chips with SAW as well)?

1495mhz narrow.jpg
1495wide.jpg
adf datasheet.jpg
switchabl 2020/09/09 07:40

I think the reference oscillator is 24MHz.

That looks way worse than on mine. Unfortunately, my analyzer has no noise markers, so I had to calculate by hand, hope i didn't make a mistake. I really have to write a script to automate phase noise measurement some time.

Carrier level: -11.9dBm (reference marker doesn't show the correct level because of RMS detector)
ENBW = 1.065 * RBW

offset
10kHz: -85dBc/Hz
30kHz: -85dBc/Hz (more like ~-95dBc/Hz off the spurs)
100kHz: -100dBc/Hz
1MHz: -123dBc/Hz

I should have taken more care with the markers, spurs should be characterized separately...
The two big spurs don't appear on your trace, maybe because of different frequency. Likely from the fractional N PLL?

I wonder if it has something to do with the external USB supply as well. I used a phone charger, powering it from a PC might be worse.

I think the IF bandwidth of the receiver is somewhere on the order of 200Hz (5ms measurement time), so I expect phase noise at these offsets to matter very little in VNA mode.

pn_narrow.png
pn_wide.png
switchabl 2020/09/09 08:15

Actually, speaking of power supplies, the sidebands at ~1MHz are probably the switching frequency of the phone charger. With a linear lab power supply they are gone (no significant changes in phase noise otherwise).

Wouter van Gulik 2020/09/09 13:39

Hi all,

I went ahead and implemented my suggested modes.
https://github.com/wutje/NanoVNA-V2-firmware/releases/tag/cw_mode_fix-beta.5
This version is much better as it stays in ECAL mode until it is done running the ECAL calibration during the first two cycles. Selecting CW automatically select CW mode. However zero span does not!

Please feel free to try these new modes.
My feeling is ECAL mode is (a little) faster compared to "no ECAL". Perhaps there still is something subtle that I missed?
I also noted that on the screen there seems to be a "stepped" phase response with ECAL, it seems to disappear with "no ECAL". Aka switching the output on and off has an influence on phase?

I also added an low output power options Unfortunately I could not test this as it only works for the ADF4350 which is used >140MHz. And that is beyond my poor scopes capabilities.
Can someone please verify this actually works (reminder! use 140Mhz+ for testing!)?

John Gord 2020/09/10 23:25

It looks like the CW phase noise problem on my older NanoVNA-V2 is indeed the 24MHz crystal oscillator.
I checked the 24MHz oscillator outputs directly, and the noiser one (marked YXC 24.000 T1A) measured -100 dBc/Hz at 20kHz offset, while the better one (marked BN24.0 D745) measured -116dBc/Hz. I fed the older -V2 with 24MHz from a signal generator, and the 150MHz output improved from -82dBc to -102dBc.
As I said earlier, the normal VNA functions don't seem to care about the extra phase noise. I suppose I may replace the noisier crystal oscillator someday, but for now I will just use the more recent unit when I want a clean CW signal.
I should note that the earlier 24MHz oscillator fed a 3v p-p signal to the Si5351, well above the 1v p-p recommended. Reducing the signal level to 1v p-p did not help, but did keep the ac coupled Si5351 input from being driven below 0v. I had worried about that turning on some internal junctions and injecting substrate current, perhaps causing the phase noise. The later 24MHz oscillator runs at the recommended 1v p-p.
--John Gord

- Show quoted text -
ok1vaw 2020/09/12 02:47

I think you are not able to measure the crystal oscillator PN directly with SA, as far as it is mostly much better than PN of the LO in the SA itself. -100dBc/Hz would be a terrible value, as far as most XO are from -130dBc up -150dBc. Attached is PN of typical 20MHz XO from Connor Winfield.
No matter what, if there is noisy VCC, it could modulate XO or the PLL VCOs too and worsen the system PN.

phase noise crystal.jpg
John Gord 2020/09/12 12:24

I agree that -100dBc/Hz would be terrible for most XOs, but it is what the "YXC" marked XO is doing. I used an 8563E spectrum analyzer, which has phase noise specified as better than -113dBc/Hz at <= 1GHz and >=10K offset. Note my statement:

" the noiser one (marked YXC 24.000 T1A) measured -100 dBc/Hz at 20kHz offset, while the better one (marked BN24.0 D745) measured -116dBc/Hz."

The direct 24MHz, 20kHz phase noise measurement of the better XO (BN24.0) is probably SA limted at -116dBc/Hz, but the noisy XO (YXC) at -100dBc/Hz is well above the SA limit.

--John Gord

On Sat, Sep 12, 2020 at 02:47 AM, ok1vaw wrote:

- Show quoted text -
Miguel Work 2020/12/26 14:39

I can use beta4 for CW in PLUS4?
Thanks!

To reply to this topic, join https://groups.io/g/NanoVNAV2