The NanoVNA is a new low cost community developed VNA with assembled units coming out of China for <$50.
It is a semi open source project, some information is published in open access places like unrestricted github and currently unrestricted acccess messages in a io.groups forum, but the wiki and files collection of that forum is by membership only and so is not publicly available.
After reviewing a lot of public information, I chose to try purchase an Nanovna-H. There were trials along the way in that Hugen79’s preferred supplier on Alibaba could not accept my suburb in the address, so I searched eBay, Amazon and Aliexpress for items that appears to be a Nanovna-H. On the day, eBay and Amazon had no listings, but there were some on Aliexpress.
In this case, though the seller lied about material things, it does appear that I received a ‘genuine’ nanoVNA-H, and one of very recent manufacture as it had firmware dated two days after I placed the order.
The device was charged and needed only an hour to reach full charge, it was about 75% charged. No grief with the battery manager stuck in shutdown (yet) as some users report.
Above, the nanoVNA-H as received.
Above is a pic of the case interior, it is a fairly well made case. It is takes a little care to fit the switch toggle into its aperture, but it is ok. So, this packaging is much better protection than the very popular bare board prototypes about.
Above is the front view, still with the screen protector in place. The screen protector is scratched, so it will be removed and I will replace it with a new mobile phone screen protector.
The SMA connectors are PCB mount, and I have reservations about their longevity with repeated use, particularly if they were tightened to specification torque. I will fit connector savers, and not tighten to to specification. If the supplied pigtails are used, that provides a sacrificial component much like the connector savers.
I have seen another variant of the nanoVNA that uses bulkhead mount SMA connectors, they may be more robust.
Above is the rear view of the electronics. The little thing at left is a pair of pogo sticks connected together as a shorting device for enabling DFU mode (though it should be possible from the firmware… if it is working properly). The board seems a little different in detail around the battery connector, there appears to be some board layouts where the battery connector interferes with D2, and only one or the other are populated. In this one, D2 is well out of the way of the JST connector.
The original battery fitted to the NanoVNA-H v3.3 is a 602040 (6.0x20x40mm) 450mAh LiPo pouch cell (1S) with protection board. The battery connector is a 2 pin Molex Picoblade… get the polarity correct.
The board is marked v3.3 under the edge of the battery.
Small spring clips are used to bond the shield to the PCB.
First experience with the jog control is that it is not straight forward, sometimes it seems not to respond to user input and I doubt it is a dicky switch, perhaps firmware that does not treat user input as the highest priority.
Though popular postings online suggest that the nanoVNA-H is factory calibrated, mine was very rough and needed recalibration.
At Diagnosing a possible antenna problem by comparison with a baseline I compared recent sweeps of the antenna system with a historical baseline. It seems an appropriate real work application of the nanovna, so after OSL calibration a set of sweeps were made of the Diamond X-50N looking into the feed line.
Above is a wide sweep expanded to look for very low ReturnLoss (-|s11|dB) out of band (it is very sensitive to increases in coax loss, eg due to water ingress).
Above is the |S11|dB (-ReturnLossdB) around the 2m band which compares well with the recent Rigexpert measurement.
Above the plot of VSWR around the 70cm band has a little more noise on it, and quite a glitch at 425MHz (more on that at nanoVNA-H – occasional glitches in measured data). Glitches in the first measurement after a rest using an ADC is a common foreseeable issue that must be dealt with in the firmware.
A DFU update was tried (initiated using BOOT0) just to prove it all working.
No problems. I really did not expect any, this MCU has a bootloader in system memory so it should not be damaged by anything written to user flash (including a chip erase). If something it messes with the Options Bytes and alters the boot configuration, more work may be needed to restore normal behaviour.
Above is the ‘normal’ Options Byte shipped with the nanovna, and nBOOT1=1 means boot from system memory when BOOT0=1. If this gets messed up, it may appear bricked and require a STLINK programmer and STVP or STLINK utility to fix the Options Bytes. This gets trickier if memory protection has been enabled.
The DFU device should appear in “Devices and printers” as “STM32 BOOTLOADER” or “STM Device in DFU Mode”. Much is made about the first being wrong, but it would seem that the strings are just different fields of the device properties as seen in this capture from USBDeview.
