NanoVNA-H is a vector network analyzer you can solder and flash yourself

What changed from the original NanoVNA board

NanoVNA-H is a DIY vector network analyzer, and the original project it starts from is NanoVNA at the ttrftech repository, with the design credited to edy555. This repository remade NanoVNA based on edy555, but modified some circuits, added battery management circuits, and redesigned the PCB.

The measurement range and the reason for it come next. The improved frequency algorithm can use the odd harmonic extension of si5351 to support the measurement frequency up to 900MHz. The metal shield is designed to reduce the external interference and improve the measurement accuracy. The 50k to 300MHz frequency range of the si5351 direct output provides better than 70dB dynamic. And the latest version of rev3.5 hardware can be extended to above 1.5GHz, with more information at NanoVNA.com.

That whole paragraph is about one engineering decision, which is the use of a low-cost clock generator beyond its specified output band. The si5351 is a programmable clock chip, and rather than being limited to its direct output range the firmware drives it on odd harmonics and measures against that. A metal shield handles the other half of the problem, since a signal source that goes to 900 MHz in a plastic case picks up noise from everything around it.

So the hardware changes and the firmware changes are one design, not two. The board is a different PCB, with different circuits and a battery management section, and the code is different because the measurement approach is different.

The homepage is nanovna.com, the primary language is C, the default branch is master, and the last push was on 2026-05-16 with release 1.2.50 on the same day.

The source is a fork of a fork, and the credits say so

The attribution in this repository is layered, and reading it tells you where to look when something does not work.

There is a note about the current version: the source code of the current version is based on the source code modification of DiSlord, and if the compilation fails you should refer to the NanoVNA-D description, with a link to a specific issue comment in the NanoVNA-D tracker.

Below that, the original project readme follows, which credits edy555 for creating the project, with all software copyrights owned by edy555, and the ttrftech NanoVNA repository. It thanks cho45 for making major improvements to the project, and DiSlord for continuous improvement of the NanoVNA-D project.

So the lineage is ttrftech NanoVNA, then edy555's work, then DiSlord's NanoVNA-D modifications, and then this hardware revision on top. The NanoVNA-D reference in the build instructions is not incidental: it is where the current source actually comes from, and the project tells you to read that project's instructions if the build fails.

The recent release history is consistent with that arrangement. Version 1.2.50 is from 2026-05-16, version 1.2.44 is titled Synchronized to NanoVNA-D version 1.2.44 and dates from 2025-05-26, and version 1.2.43 mentions NanoVNA-H rev3.7 and NanoVNA-H4 rev4.4 and the replacement of NXP SA602A with ZeeTK NE602A.

That release note is a hardware compatibility change, and it is the sort of thing that matters: a component swap on the board means the firmware and the bill of materials have to move together. The synchronisation release naming tells you the merge cadence with the upstream.

Building is a make with one target variable

The build system is a plain Makefile, and the only thing you really choose is the target.

For the NanoVNA-H it is `TARGET = F072`, and for the NanoVNA-H4 it is `TARGET = F303`. The Makefile defaults to F072 when the variable is empty, and the alternative is left as a commented line, so the two supported boards are STM32F072 and STM32F303.

The compiler recommendation is specific: it is recommended to compile with gcc-arm-none-eabi 8, and exceptions may occur with other versions of the compiler. The CibiOS submodule has to be synced before compiling:

$ git submodule update --init --recursive

The Makefile itself is where the engineering trade-offs are visible, since every option is a commented switch. The optimisation flags are `-O2 -fno-inline-small-functions -ggdb -fomit-frame-pointer -falign-functions=16 --specs=nano.specs -fstack-usage -std=c11`, with `-ffast-math` and `-fsingle-precision-constant` added for the maths, and `-fno-reorder-blocks` for size.

Two of those comments are worth reading. The fast-math flags are there because this is a signal processing application, where a strict floating point model would cost accuracy you do not need. The commented-out `-fno-jump-tables` and `-fno-move-loop-invariants` are described as small size optimisations that cause a slowdown, which tells you the author is trading speed for flash space on a part with very little of it.

The rest of the Makefile is a set of feature switches, all defaulting to a chosen value: link-time optimization is off by default, THUMB mode is on, garbage collection of unused code is on, smart build is on, and verbose compilation is off. A smart build is what makes the build faster by not compiling modules not used in the current configuration, which matters for a project of this size on a slow machine.

Three operating systems, three toolchain stories

The build instructions cover macOS, Linux and Windows, and each has a different shape.

On macOS the cross tools and the firmware updating tool come from Homebrew:

$ brew tap px4/px4
$ brew install gcc-arm-none-eabi-80
$ brew install dfu-util

On Linux you download the ARM cross tools directly, and the wget line includes the exact version:

$ wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2
$ sudo tar xfj -C /usr/local gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2
$ PATH=/usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin:$PATH
$ sudo apt install -y dfu-util

Then the build itself is the same everywhere:

$ make

On Windows the instructions point at gnu-mcu-eclipse, and this is where the project is least prescriptive, because it is an IDE workflow rather than a command line one. You import the existing code as a Makefile project, and in Project > Properties > C/C++ Build > Setting you confirm that the toolchain is GNU MCU Eclipse ARM Embedded GCC, and in Project > Properties > C/C++ Build > Tool Chain Editor the current toolchain is ARM Cross GCC and the current builder is Gnu Make Builder, then you build the project.

For debugging, Eclipse with cmsis-dap and openocd is documented, with a debug configuration of GBD OpenOCD Debugging and a config option of `-f NanoVNA_DAP.cfg`. The NanoVNA_DAP.cfg file is in the repository root for that purpose.

The original project also documents a Docker route to build the firmware without installing the ARM toolchain at all, using the edy555/arm-embedded image, which is a useful trick if you want a reproducible build environment rather than a toolchain on your machine.

Flashing goes through DFU mode and dfu-util

The flashing procedure is the part that determines whether you need a programmer.

First, make the device enter DFU mode by one of two methods: jumper the BOOT0 pin at power-up, or select the menu Config > DFU, which needs recent firmware. The second option is the reason the firmware matters even if you never compile it, since a stock device with an old firmware does not have the menu entry.

Then flash the firmware using dfu-util over USB:

$ dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/ch.bin

The device ID and the address are worth noting. The 0483:df11 is the STMicroelectronics USB DFU vendor and product, and the 0x08000000 is the start of flash on this part, with leave meaning the device reboots out of DFU mode afterwards rather than staying there.

Or, more simply, you can use make:

$ make flash

The Makefile approach is the one most people will use, and it also means you never have to remember the dfu-util arguments or the address.

For controlling the device from a PC rather than from its own screen, the original project points at a python directory in the repository, which holds the tooling for talking to the analyzer over USB from a host.

The hardware documentation is published as well. The reference links are the schematics as a PDF, a PCB photo, and a block diagram, all in the doc directory of the original project, and this repository carries a doc/ directory with its own images including the NanoVNA-H board photo. The original project notes that hardware design material is disclosed to prevent bad quality clones, and asks to be told if you would build your own unit, which tells you the licensing posture of the design files.

What the source tree shows about the firmware

The file list at the root describes the firmware's structure, and it is a good map of what a VNA has to do.

There are the two target directories, NANOVNA_STM32_F072/ and NANOVNA_STM32_F303/, holding the board-specific code for the two supported MCUs. Then the measurement core: measure.c, dsp.c and dsp.h for the digital signal processing, vna_math.c and vna_math.h for the vector network analysis maths, and vna_modules/ for the optional measurement modules.

The RF front end has its own files, si5351.c and si5351.h for the clock generator, and tlv320aic3204.c for the audio codec. The codec digitises the received signal, because the generator alone cannot tell you the return loss without a receiver, and a codec provides a cheap one with a known response.

The user interface is lcd.c, ui.c, plot.c and the icon and font files, icons_marker.c, icons_menu.c, numfont16x22.c, numfont20x22.c, numfont20x24.c and a fonts/ directory. The plotting code is what turns the S-parameters into the traces on the screen, and the separate icon files suggest a menu-driven device with touch input.

The platform layer is ChibiOS, with the ChibiOS directory and a ChibiOS.7z archive, plus chconf.h, halconf.h, mcuconf.h and chprintf.c. ChibiOS is a real-time operating system, and it is why the code has a chprintf.c and a halconf.h: the abstraction sits between the application and the hardware.

The rest is storage and USB. data_storage.c handles saving measurements, usbcfg.c and usbcfg.h the USB configuration, hardware.c and hardware.h the board, spi.h the serial peripheral interface, common.c the shared helpers, and FatFs/ the filesystem library. There is also a Makefile, prog.sh, a.project and.cproject pair for the Eclipse workflow, and the NanoVNA_DAP.cfg for the debugger.

Editorial conclusion

Adopt NanoVNA-H if you want to build or flash your own handheld vector network analyzer and are comfortable with embedded C and an ARM cross toolchain, since the firmware is a complete, current and reproducible build rather than a sketch. Skip it if you want a calibrated instrument with a documented accuracy specification, because the documentation here describes the design changes and the frequency range but not a measurement uncertainty, and the licence terms are not stated in the repository listing. Verify first that your board revision matches the target you compile, F072 for the NanoVNA-H and F303 for the NanoVNA-H4, that you have dfu-util available, and which upstream you are actually building, since the code here is a modification of DiSlord's source rather than the original ttrftech tree.

Frequently asked questions

Official sources

1. hugen79/NanoVNA-H on GitHub
2. Issues
3. Project website
4. README
5. Releases