The NanoVNA is a new low cost community developed VNA with assembled units coming out of China for <$50.
This article documents some tests using a small ferrite cored test inductor that provides a similar impedance to that of a common mode choke suited to HF antenna feed lines.
The nanoVNA-H has firmware NanoVNA-Q-0.4.3-20f33ba.dfu installed. The nanoVNA appears to be a nanoVNA-H v3.3 but it is hard to be sure, it is from China, the land of copyists and fraud. Indeed the nanovna-Q author asserts that genuine nanoVNA-H have a green overlay whereas mine is blue. Uncertainty is part of the territory!
A small fixture was OSL calibrated and impedance measured by reflection (ie s11).
The results broadly reconcile with previous measurements of the inductor, but the jitter is worth of examination.
Above is a chart showing the measured impedance components, we might expect a reasonably smooth curve for each. It has a lot of jitter on it, and you might excuse that as a result of applying the instrument and method to such a high impedance… but for two things:
- other instruments product less jitter without recourse to averaging;
- some peaks (like the one at the marker) are consistent hinting that the jitter is not simply random noise.
The peak at 7.5MHz is almost always significantly higher than its neighbors, and that is unlikely to be the effects of random noise but has some other cause.
Above is a zoomed in R,X plot and there is a pronounced glitch in X that is unlikely to be from the DUT. (Note that zooming in causes interpolation of the cal data, and that is what results in the shape of the glitch.)
Examining the schematic for the nanoVNA-H v3.3, we see the power supply decoupling uses a 100pF cap to ground from the Vcc pin (8), and a series inductor to the low impedance 5V rail. These two components exhibit parallel resonance at around 7.35MHz… the smoking gun.
Above is a simulation circuit. Q of the choke is set to 3, typical of suppression ferrites, but it may well be higher.
Above, the simulation result shows resonance at 6.9MHz, and the decoupling impedance is 678+j3, pretty shabby (and it would be higher with a higher Q choke).
Above is the recommendation from the SA612AD datasheet, a much larger cap on pin 8.
The fix
I have piggybacked 0402 100nF on C40, C42, C44 on a nanoVNA-H v3.3 PCB.
Above, C42 is now the original 100pF with a 100nF piggy backed on top. It is a delicate soldering operation, these are 0402 parts.
Lets do a raw sweep from 0.1 to 10MHz to look for glitches, we will use nanovna-saver 0.2.0 to average 16 sweeps to reduce measurement noise without affecting underlying glitches. The effect of simple averaging is to reduce the Standard Deviation by n^-0.5.
Pity about the axes… the top graph Y axis range is 21.45-21.55dB, the lower graph is 0.083-0.085. The important thing is that noise is low and there is no standout local maximum or minimum on repeated scans, the new caps have not simply displaced the problem to a new one lower in frequency.
Above is a repeat of the zoomed in test on the test inductor, so sign of the glitch around 7.5MHz. In fact a wider search from 0.05-30MHz did not reveal such a glitch.
Above is a scan of the inductor from 1-31MHz, the cal data is interpolated and the response looks quite good. repeated scans show that any local minima or maxima are noise, they do not persist from scan to scan.
Problem fixed, the glitch identified was caused by a lack of bypassing of the Vcc pin of the three SA612AD mixers, the installed capacitor was resonating with the series choke to fairly ruin decoupling around 7.5MHz.
This hardware defect is probably in all nanoVNA-H PCB up to and including v3.3. Hugen79 tells me he intends fixing this in the upcoming v3.4.
Update 23/11/2019: Above is the revised (draft?) schematic for nanoVNA-H PCB v3.4.1. Note the same change is needed for the other two mixers.
Above, the impedance plot of the revised network (mine and Hugen’s).
Update 01/01/2020: Some online discussion has misrepresented this issue and my comments on it in this and the previous article. I have stated that the issue exists in nanoVNA-H v3.3, and Hugen has stated online that it is also in all previous verions of nanoVNA-H, and as noted above is fixed in nanoVNA-H v3.4. No statement is made about whether it is a defect in other variants or versions of nanovna, certainly the schematics that I have seen by ttrftech (edy555, the originator of nanovna?) have not shown the defect, but I have not exhaustively checked all ttrftech’s schematics.
My articles are pretty clear on how to find evidence of the issue, both from measurement and board inspection. This article documents an effective and good fix, but though trivial, it may be beyond the capability of some users.