dislord / nanovna-d Goto Github PK

Firmware for NanoVNA, NanoVNA-H, NanoVNA-H4. Support SD Card, external Serial connection, fast measure, fast exchange vs CPU

GDB 0.01% C 98.46% Makefile 0.21% Shell 0.01% Jupyter Notebook 0.45% Python 0.02% Tcl 0.01% C++ 0.14% CSS 0.04% HTML 0.01% Batchfile 0.01% Assembly 0.65% Perl 0.02%

nanovna firmware

nanovna-d's Introduction

NanoVNA - Very tiny handheld Vector Network Analyzer

About

NanoVNA-H and NanoVNA-H4 are very tiny handheld Vector Network Analyzers (VNA). They are standalone portable devices withLCD and battery. This project aims to provide improved firmware for this useful instrument for enthusiast.

This repository contains the source code of the improved NanoVNA-H and NanoVNA-H4 firmware.

The documentation describes the build and flash process on a MacOS or a Linux (Debian or Ubuntu) system, other Linux (or even BSD) systems may behave similar.

Prepare ARM Cross Tools

UPDATE: Recent gcc version works to build NanoVNA, no need to use old version.

MacOSX

Install cross tools and firmware updating tool.

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

Linux (ubuntu)

Download arm cross tools from here.

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 gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 -C /usr/local
PATH=/usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin:$PATH
sudo apt install -y dfu-util

Debian

sudo apt install gcc-arm-none-eabi
sudo apt install -y dfu-util

Fetch Source Code

Fetch the firmware source and the submodule, do this once to initialize your local clone from GitHub:

git clone https://github.com/DiSlord/NanoVNA-D.git
cd NanoVNA-D
git submodule update --init --recursive

Update Source Code

To get updates from the GitHub repository, go to your NanoVNA-D directory and type:

git pull

Build the NanoVNA-H Firmware

Go to your NanoVNA-D directory and type:

export TARGET=F072
make clean
make

Build the NanoVNA-H4 Firmware

Go to your NanoVNA-D directory and type:

export TARGET=F303
make clean
make

Flash Firmware

When the build of your firmware is finished, you can flash it onto your NanoVNA device. First, let the device enter DFU mode by one of following methods.

Open the device and jumper BOOT0 pin to Vdd pin when powering the device.
Select menu Config->DFU (needs recent firmware).
Press the jog switch on your -H4 when powering the device.

Then, flash the firmware using dfu-util via USB.

For NanoVNA-H:

Go to your NanoVNA-D directory and type:

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

For NanoVNA-H4:

Go to your NanoVNA-D directory and type:

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

Or simply type directly after building the firmware (for both variants).

Go to your NanoVNA-D directory and type:

make flash

Ignore the apparent error message during flashing

The low-level tool dfu-util displays a lot of information that is very useful especially for developers, but can confuse the user. In particular, please ignore the message about corrupt firmware, this is the normal behaviour of the unit before clearing the status. It is important to note that after clearing the status, there is no longer an error condition present.

...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
...

Companion Tools

There are several numbers of great companion PC tools from third-party.

NanoVNA-App software by OneOfEleven
NanoVNASharp Windows software by hugen79
NanoVNA WebSerial/WebUSB by cho45
Android NanoVNA app by cho45
NanoVNASaver by mihtjel and the members of NanoVNA-Saver
TAPR VNAR4 supports NanoVNA by erikkaashoek
The NanoVNA toolbox by Ho-Ro
see python directory to use NanoVNA with Python and Jupyter Notebook.

Documentation

NanoVNA User Guide(ja) by cho45. (en:google translate)
NanoVNA user group on groups.io.

Reference

Schematics
PCB Photo
Block Diagram
Kit available from https://ttrf.tk/kit/nanovna

Note

Hardware design material is disclosed to prevent bad quality clone. Please let me know if you would have your own unit.

Credit

@DiSlord

Based on code from:

@edy555

Contributors

nanovna-d's People

Contributors

Stargazers

Watchers

nanovna-d's Issues

Add version FW for default NanoVNA-H

Now the menu contains useless items about (non-existent) SD card. The clock is also semi-working.
Or pls, add some options in console to hide that.

Artefacts when capturing the screen

The screen capture shows artefacts at the bottom of the image in the far right column. This is independent of the respective device and the recording program used; tinySA also shows the same artefacts. NanoVNA version 1.2.15, the issue existed also with versions 1.0.64 and 1.1.x, also latest tinySA version.

Oopsie.. LiteVNA64 flashing

So I figured my luck with the updated firmware using branch and TARGET=F303:

Put the device in DFU mode by pulling BOOT0 HIGH and flashed the H4 image, see update procedure below.
Screen stays dark..

Any ideas maybe how to fix?

~ # dfu-util -l
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [2e3c:df11] ver=0200, devnum=32, cfg=1, intf=0, path="2-2", alt=1, name="@Option Byte   /0x1FFFF800/01*048 e", serial="AT32"
Found DFU: [2e3c:df11] ver=0200, devnum=32, cfg=1, intf=0, path="2-2", alt=0, name="@Internal Flash  /0x08000000/ 512*2Kg", serial="AT32"

So i went and went ahead and flashed :

~# dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/H4.bin
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 2e3c:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading element to address = 0x08000000, size = 85704
Erase   	[=========================] 100%        85704 bytes
Erase    done.
Download	[=========================] 100%        85704 bytes
Download done.
File downloaded successfully
Submitting leave request...
Transitioning to dfuMANIFEST state

Change scale - display issue

When you try to change the scale for a trace, the buttons are not visible to select the unit. This is on a nanovna h v3.4 running latest dislord firmware.

Screenshot

Paused NanoVNA stops at random frequency of sweep range

BTW: I learned during this test that the pause command (both from the touch menu and the serial port) stops immediately at a random frequency in the sweep range. Shouldn't it either stop at START or even better turn off port 1 altogether?

Originally posted by @Ho-Ro in #26 (comment)

The most intuitive solution would be to mute port 1 (CH0) during pause instead of emitting random CW. This should be possible with reg 3 (CLK1_OEB=1; maybe also CLK0_OEB=1) and reg 24 (CLK0_DIS_STATE=00; CLK1_DIS_STATE=00) of Si5451.

@DiSlord et al.: What's your opinion?

Confused about what version my NanoVNA is, and the README.md doesn't help....

When I go to Config->Version it says NanoVNA at the top, but It has this website listed as the source of the firmware, which is 1.0.64. I read that the H version is the 2.8" display which I have, but I also read the original NanoVNA is not supported anymore. Will I brick my unit if I try and load the version 1.2? Maybe this could be made more clear somewhere on this repository.
Thanks!
Rob

Are the latest releases posted to this repository (eg v1.0.69) or another public repo?

Please include an Intel hex format file in the release

Lots of users have problems updating firmware, and one of the contributions is determination to use STM32CUBEPROGRAMMER which will not open .dfu files, but will open a .hex file. Part of the reason for this is that ST seem to have deprecated DFUSEDEMO, but have chosen to not support .dfu in STM32CUBEPROGRAMMER.

If the release included a .hex format, it would make the process simpler for those users.

(Yes, I am aware that STM32CUBEPROGRAMMER uses libusbk or like driver, and that is easily installed with Zadig.)

Keep up the good work.

Owen

Please update README.md

You write that "Recent gcc version works to build NanoVNA, no need old version.". On the other hand your instructions for Linux preparation request to install a specific 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 gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 -C /usr/local
$ PATH=/usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin:$PATH

instead of just doing

apt install gcc-arm-none-eabi

On Debian stable I build all your NanoVNA-H FW versions perfectly with the Debian standard gcc version 8.3.1 20190703 (release) [gcc-8-branch revision 273027] (15:8-2019-q3-1+b1)

Cable length measurement v1.2.22

When measuring for a cable, it shows for a cable 10 times more than the real one. Velocity is set to 66%, with a real cable length of about 7 meters, the NanoVNA reading is about 70 meters.

Cannot connect via USB immediately after plugging in

Issue: Cannot connect via USB immediately after plugging in.
To check this: Connect to USB., switch on and type after one to two seconds:
minicom -D /dev/ttyACM0
It will fail in most cases:
minicom: cannot open /dev/ttyACM0: Device or resource busy

System: Linux debian stable

Reason: The NanoVNA announces itself as a CDC device (linux port e.g. /dev/ttyACM0) with bInterfaceProtocol = 0x01. According to Universal Serial Bus Class Definitions for Communications Devices section 4.4 this is
01h ITU-T V.250 AT Commands: V.250 etc
Due to this announcement as a modem with AT commands some background processes are triggered (ModemManager?) that grab this "modem" and delay the availability of the device.
The correct interface protocol is:
00h USB specification No class specific protocol required

Fix: Change entry in usbcfg.c:

@@ -68,11 +68,11 @@ static const uint8_t vcom_configuration_descriptor_data[67] = {
                          0x02,          /* bInterfaceClass (Communications
                                            Interface Class, CDC section
                                            4.2).                            */
                          0x02,          /* bInterfaceSubClass (Abstract
                                          Control Model, CDC section 4.3).   */
-                         0x01,          /* bInterfaceProtocol (AT commands,
+                         0x00,          /* bInterfaceProtocol (No protocol,
                                            CDC section 4.4).                */
                          0),            /* iInterface.                      */
   /* Header Functional Descriptor (CDC section 5.2.3).*/
   USB_DESC_BYTE         (5),            /* bLength.                         */
   USB_DESC_BYTE         (0x24),         /* bDescriptorType (CS_INTERFACE).  */

Feature request: disable screen

Is it possible to implement a serial command to disable the screen?
I would like to test the screens impact on overall device performance
while avoiding the hassle of physically removing the screen from the
device.
Also it would be beneficial to reduce the device power consumption
while connected to a mobile device.

Bug in NanoVNA firmware - XTAL calculations

Hello DiSlord,
there was an interesting discussion about the xtal calculation on groups.io. Please check Orestes' findings.
Martin

build fails

build fails see error

Thanks

Compiling flash.c
./NANOVNA_STM32_F072/flash.c: In function 'flash_wait_for_last_operation':
./NANOVNA_STM32_F072/flash.c:3:10: error: 'FLASH' undeclared (first use in this function)
while (FLASH->SR == FLASH_SR_BSY) {
^~~~~
./NANOVNA_STM32_F072/flash.c:3:10: note: each undeclared identifier is reported only once for each function it appears in
./NANOVNA_STM32_F072/flash.c:3:23: error: 'FLASH_SR_BSY' undeclared (first use in this function)
while (FLASH->SR == FLASH_SR_BSY) {
^~~~~~~~~~~~
./NANOVNA_STM32_F072/flash.c: At top level:
./NANOVNA_STM32_F072/flash.c:9:31: error: unknown type name 'uint32_t'
static void flash_erase_page0(uint32_t page_address)
^~~~~~~~
./NANOVNA_STM32_F072/flash.c: In function 'flash_unlock':
./NANOVNA_STM32_F072/flash.c:22:3: error: 'FLASH' undeclared (first use in this function)
FLASH->KEYR = 0x45670123;
^~~~~
./NANOVNA_STM32_F072/flash.c: At top level:
./NANOVNA_STM32_F072/flash.c:26:24: error: unknown type name 'uint32_t'
void flash_erase_pages(uint32_t page_address, uint32_t size)
^~~~~~~~
./NANOVNA_STM32_F072/flash.c:26:47: error: unknown type name 'uint32_t'
void flash_erase_pages(uint32_t page_address, uint32_t size)
^~~~~~~~
./NANOVNA_STM32_F072/flash.c:36:37: error: unknown type name 'uint16_t'
void flash_program_half_word_buffer(uint16_t* dst, uint16_t data, uint16_t size)
^~~~~~~~
./NANOVNA_STM32_F072/flash.c:36:52: error: unknown type name 'uint16_t'
void flash_program_half_word_buffer(uint16_t dst, uint16_t data, uint16_t size)
^~~~~~~~
./NANOVNA_STM32_F072/flash.c:36:68: error: unknown type name 'uint16_t'
void flash_program_half_word_buffer(uint16_t dst, uint16_t *data, uint16_t size)
^~~~~~~~
make: *** [build/obj/flash.o] Error 1

No bounds checking on date input

i know this is a pre-release but there is no min-max bounds check on date & time input: can enter 0 and >12 for month and 0 or >31 for day. However, if day is > 31, it appears to be unpredictable, sometime defaulting to 19 (rollover issue).
Can enter hour greater than 24 - eg: enter 25:23:59 and rollover is to 26:00:00

Great work though!

Scannning start and stop frequencies inserted into the file names (files on the sdcard)

While messing with a multiband antenna I have to measure at several frequency bands.. After saving the s1p files to the sdcard (H4) I always have to open the files in order to see the start/stop scanning frequencies, a pity :)
Thus I've created a quick hack - inserting the start/stop freq information into the filename.
These are the few changes I've done:

file ffconf.h line 100
#define FF_MAX_LFN 64

file ffconf.h line 131
#define FF_LFN_BUF 64

file ui.c line 1128
plot_printf(fs_filename, FF_LFN_BUF, "VNA_%06X_%06X_%uk_%uk.s%dp", dr, tr, frequencies[0]/1000, frequencies[sweep_points-1]/1000,data);

Now I get the filenames stored on the sdcard with start/stop in kHz:

You have to adjust the size of the "saving information" window on the LCD as well..

NanoVNA Firmware version 1.1.00 - Incomplete menu image

I have just updated my device and found that the Display -> Scale -> Scale/Div and Reference Position menus are not being displayed properly. The right/upper corner of the image shows previous menus images and as result, some buttons for this settings are missing.

Hope this feedback helps to improve your astonishing software.

Best regards
Oscar

NanoVNA-H v3.3 and NanoVNA-H4 v4.3 and freeze on v1.1.00

Both systems freeze after long time running (possibly hours) powered via USB (power supply only, no data connection).

The screen freezes with a normal display (ie not mid scan), no response to touch, button or jog wheel. Recovers fully on power cycle (ie OFF/ON).

The -H hardware is years old, and never shown this on ttrftech firmware.

A possible memory leak?

Owen

Feature request: allow also 100 points (and 400 for H4 version)

101 points is perfect if you sweep a small band of e.g. 140..150 MHz, this gives 140.0, 140.1, 140.2,... 150.0 MHz.
But if you want to do a broadband sweep, e.g. 20k .. 2 M for a switching application filter you get odd steps of 20.0, 39.8, 59.6,... 1989.2, 2000.0 kHz, while 100 points yield nice frequencies of 20.0, 40.0,... 2000 kHz.
What do you think about my quick solution?

diff --git a/nanovna.h b/nanovna.h
index 36268c8..8dc97fd 100644
--- a/nanovna.h
+++ b/nanovna.h
@@ -248,20 +248,20 @@ typedef uint32_t freq_t;
 
 // Optional sweep point (in UI menu)
 #if POINTS_COUNT >=401
-#define POINTS_SET_COUNT       5
-#define POINTS_SET             {51, 101, 201, 301, POINTS_COUNT}
+#define POINTS_SET_COUNT       6
+#define POINTS_SET             {51, 101, 201, 301, POINTS_COUNT-1, POINTS_COUNT}
 #define POINTS_COUNT_DEFAULT   POINTS_COUNT
 #elif POINTS_COUNT >=301
-#define POINTS_SET_COUNT       4
-#define POINTS_SET             {51, 101, 201, POINTS_COUNT}
+#define POINTS_SET_COUNT       5
+#define POINTS_SET             {51, 101, 201, POINTS_COUNT-1, POINTS_COUNT}
 #define POINTS_COUNT_DEFAULT   POINTS_COUNT
 #elif POINTS_COUNT >=201
-#define POINTS_SET_COUNT       3
-#define POINTS_SET             {51, 101, POINTS_COUNT}
+#define POINTS_SET_COUNT       4
+#define POINTS_SET             {51, 101, POINTS_COUNT-1, POINTS_COUNT}
 #define POINTS_COUNT_DEFAULT   POINTS_COUNT
 #elif POINTS_COUNT >=101
-#define POINTS_SET_COUNT       2
-#define POINTS_SET             {51, POINTS_COUNT}
+#define POINTS_SET_COUNT       3
+#define POINTS_SET             {51, POINTS_COUNT-1, POINTS_COUNT}
 #define POINTS_COUNT_DEFAULT   POINTS_COUNT
 #endif

Do not scale the smith trace unless the smith grid is scaled too

With stylus tip on the left y axis also a smith trace can be scaled, but without also scaling the underlying smith grid this doesn't make sense.
Quick fix for ui.c (instead of raising a PR):

 static bool
 normal_apply_ref_scale(int touch_x, int touch_y){
   int t = current_trace;
   if (t == TRACE_INVALID) return FALSE;
+  if (trace[t].type == TRC_SMITH) return FALSE; // do not scale smith chart unless the grid is scaled
   if (touch_x < OFFSETX - 5 || touch_x > OFFSETX + CELLOFFSETX + 10 ||
       touch_y < OFFSETY     || touch_y > AREA_HEIGHT_NORMAL) return FALSE;

unable to reprograme nanovna-h

When I try to connect to the nanovna in the stm cube programmer, I get the error that the device is under read protection(see included photo).
Does anyone know how to fix this?

Thanks in advance for the help!

Cannot build without SD card support

I comment out the SD card support in nanovna.h (cloned from your current github):

// Add SD card support, req enable RTC (additional settings for file system see FatFS lib ffconf.h)
// #define __USE_SD_CARD__
// Allow run commands from SD card (config.ini in root)
// #define __SD_CARD_LOAD_

After this I get a lot build errors because of missing symbols.

Reason: #ifdef __USE_SD_CARD__ in ui.c disables too many lines of code, e.g. menu_back.

Fix: move the needed code out of the #ifdef ... #endif
main.c:

@@ -95,11 +95,13 @@ static volatile vna_shellcmd_t  shell_function = 0;
 // Enable debug for console command
 //#define DEBUG_CONSOLE_SHOW
 // Enable usart command
 #define ENABLE_USART_COMMAND
 // Enable SD card console command
+#ifdef __USE_SD_CARD__
 #define ENABLE_SD_CARD_CMD
+#endif

ui.c:

@@ -1242,10 +1242,17 @@ static UI_FUNCTION_CALLBACK(menu_sdcard_cb)
   drawMessageBox("SAVE TRACE", res == FR_OK ? fs_filename : "  Fail write  ", 2000);
   request_to_redraw(REDRAW_AREA);
   ui_mode_normal();
 }
 
+static const menuitem_t menu_sdcard[] = {
+  { MT_CALLBACK, SAVE_S1P_FILE, "SAVE S1P", menu_sdcard_cb },
+  { MT_CALLBACK, SAVE_S2P_FILE, "SAVE S2P", menu_sdcard_cb },
+  { MT_NONE,     0, NULL, menu_back } // next-> menu_back
+};
+#endif
+
 #ifdef __DIGIT_SEPARATOR__
 static UI_FUNCTION_ADV_CALLBACK(menu_separator_acb)
 {
   (void)data;
   if (b){
@@ -1272,17 +1279,10 @@ static UI_FUNCTION_CALLBACK(menu_clean_trace_cb)
 static const menuitem_t menu_back[] = {
   { MT_CANCEL,   0, S_LARROW" BACK", NULL },
   { MT_NONE,     0, NULL, NULL } // sentinel
 };
 
-static const menuitem_t menu_sdcard[] = {
-  { MT_CALLBACK, SAVE_S1P_FILE, "SAVE S1P", menu_sdcard_cb },
-  { MT_CALLBACK, SAVE_S2P_FILE, "SAVE S2P", menu_sdcard_cb },
-  { MT_NONE,     0, NULL, menu_back } // next-> menu_back
-};
-#endif
-
 static const menuitem_t menu_calop[] = {
   { MT_ADV_CALLBACK, CAL_OPEN,  "OPEN",  menu_calop_acb },
   { MT_ADV_CALLBACK, CAL_SHORT, "SHORT", menu_calop_acb },
   { MT_ADV_CALLBACK, CAL_LOAD,  "LOAD",  menu_calop_acb },
   { MT_ADV_CALLBACK, CAL_ISOLN, "ISOLN", menu_calop_acb },

Enhancement: SD access over USB connection for H4

Please add SD card access over USB connection, as that would reduce wear on SD card socket from "insert SD card, take screen shot, remove SD card, insert SD card into PC".

I don't know if there is available rom space for this though.

Message "too many arguments, max 4" disturbs NanoVNASaver.

Why do I get this response when I simple press ENTER?

too many arguments, max 4

It comes from main.c.

Programs like e.g. NanoVNASaver don't like this response:

2022-07-14 17:55:45,857 - NanoVNASaver.Hardware.Hardware - ERROR - No VNA detected. Hardware responded to CR with: 
too many arguments, max 4
ch>

My quick fix is to comment the shell_printf line 3173.

Make fails, mising nano.specs file

Make fails with:
arm-none-eabi-gcc: fatal error: cannot read spec file 'nano.specs': No such file or directory

Uncommitted file?

Provide a command line option to build FW for the MS hardware variant.

Add build support for the MS HW variant as proposed in this discussion.

Shell command behaviour differs to hugen's FW

NanoVNA-D FW: Pressing just <CR> shows a line with only '?' followed by prompt

?
ch>

while hugen79/NanoVNA-H FW shows only the prompt:

ch>

The input of an unknown command (e.g. xyz) gives identical result in both FWs:

xyz?
ch>

The different behaviour leads e.g. to an (reported, but stil ignored) error of nanovna-saver during device detection.
The easy fix is part of the bigger PR #15, but you can apply also separately it looks like:

diff --git a/main.c b/main.c
index b94303d..1f32e78 100644
--- a/main.c
+++ b/main.c
@@ -3153,7 +3153,8 @@ static void VNAShell_executeLine(char *line)
 //  DEBUG_LOG(10, "ok");
     return;
   }
-  shell_printf("%s?" VNA_SHELL_NEWLINE_STR, shell_args[0]);
+  if (**shell_args) // unknown command (not empty), ignore <CR>
+      shell_printf("%s?" VNA_SHELL_NEWLINE_STR, shell_args[0]);
 }
 
 #ifdef __SD_CARD_LOAD__

build error on v1.2.01

Hi DiSlord, trying to build the latest version from GitHub gives this error:

ui.c: In function 'ui_mode_normal':
ui.c:2974:42: error: 'UI_BROWSER' undeclared (first use in this function)
   if (ui_mode == UI_KEYPAD || ui_mode == UI_BROWSER)
                                          ^~~~~~~~~~
ui.c:2974:42: note: each undeclared identifier is reported only once for each function it appears in

I commented the use of SD card: // #define __USE_SD_CARD__, this should disable the use of UI_BROWSER in ui.c, but the #ifdef ... is missing in line 2974:

  if (ui_mode == UI_KEYPAD || ui_mode == UI_BROWSER)

My fix:

#ifdef __SD_FILE_BROWSER__
  if (ui_mode == UI_KEYPAD || ui_mode == UI_BROWSER)
#else
  if (ui_mode == UI_KEYPAD )
#endif

Buggy firmware when compiling with GCC-ARM version 12 - ok with GCC-ARM version 8

Compiling the tinySA source code with debian stable gcc version 12.2.1 20221205 (15:12.2.rel1-1) gives a buggy firmware - latest tinySA version as well as older versions.

Compiling the NanoVNA-H firmware gives comparable warnings caused by ChibiOS.
(I did not download this version to my NanoVNA-H because I assume that it also leads to a faulty device).

After downgrade to the debian oldstable version gcc version 8.3.1 20190703 (release) [gcc-8-branch revision 273027] (15:8-2019-q3-1+b1) it compiles fine.

Warnings when compiling with GCC-ARM version 12:

Compiling crt1.c
Compiling vectors.c
Compiling chsys.c
Compiling chdebug.c
Compiling chtrace.c
Compiling chvt.c
Compiling chschd.c
Compiling chthreads.c
Compiling chcore.c
Compiling chcore_v6m.c
In file included from ChibiOS/os/common/ext/CMSIS/ST/STM32F0xx/stm32f072xb.h:129,
                 from ChibiOS/os/common/ext/CMSIS/ST/STM32F0xx/stm32f0xx.h:157,
                 from ChibiOS/os/common/startup/ARMCMx/devices/STM32F0xx/cmparams.h:72,
                 from ChibiOS/os/common/ports/ARMCMx/chcore.h:70,
                 from ChibiOS/os/rt/include/ch.h:81,
                 from ChibiOS/os/common/ports/ARMCMx/chcore_v6m.c:28:
In function '__set_PSP',
    inlined from 'NMI_Handler' at ChibiOS/os/common/ports/ARMCMx/chcore_v6m.c:72:3:
ChibiOS/os/common/ext/CMSIS/include/core_cm0.h:85:28: warning: listing the stack pointer register 'sp' in a clobber list is deprecated [-Wdeprecated]
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cmFunc.h:443:3: note: in expansion of macro '__ASM'
  443 |   __ASM volatile ("MSR psp, %0\n" : : "r" (topOfProcStack) : "sp");
      |   ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cm0.h:85:28: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cmFunc.h:443:3: note: in expansion of macro '__ASM'
  443 |   __ASM volatile ("MSR psp, %0\n" : : "r" (topOfProcStack) : "sp");
      |   ^~~~~
In function '__set_PSP',
    inlined from '_port_irq_epilogue' at ChibiOS/os/common/ports/ARMCMx/chcore_v6m.c:125:5:
ChibiOS/os/common/ext/CMSIS/include/core_cm0.h:85:28: warning: listing the stack pointer register 'sp' in a clobber list is deprecated [-Wdeprecated]
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cmFunc.h:443:3: note: in expansion of macro '__ASM'
  443 |   __ASM volatile ("MSR psp, %0\n" : : "r" (topOfProcStack) : "sp");
      |   ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cm0.h:85:28: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cmFunc.h:443:3: note: in expansion of macro '__ASM'
  443 |   __ASM volatile ("MSR psp, %0\n" : : "r" (topOfProcStack) : "sp");
      |   ^~~~~
Compiling osal.c
Compiling hal.c
Compiling hal_st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling hal_ext.c
Compiling hal_gpt.c
Compiling hal_i2c.c
Compiling hal_i2s.c
Compiling hal_pal.c
Compiling hal_serial.c
Compiling hal_serial_usb.c
Compiling hal_spi.c
Compiling hal_usb.c
ChibiOS/os/hal/src/hal_usb.c: In function '_usb_ep0in':
ChibiOS/os/hal/src/hal_usb.c:842:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
  842 |     if ((usbp->ep0n < max) &&
      |        ^
ChibiOS/os/hal/src/hal_usb.c:851:3: note: here
  851 |   case USB_EP0_WAITING_TX0:
      |   ^~~~
In file included from ChibiOS/os/rt/include/ch.h:82,
                 from ChibiOS/os/hal/osal/rt/osal.h:32,
                 from ChibiOS/os/hal/include/hal.h:28,
                 from ChibiOS/os/hal/src/hal_usb.c:27:
ChibiOS/os/rt/include/chdebug.h:129:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  129 |   if (CH_DBG_ENABLE_ASSERTS != FALSE) {                                     \
      |      ^
ChibiOS/os/hal/osal/rt/osal.h:241:34: note: in expansion of macro 'chDbgAssert'
  241 | #define osalDbgAssert(c, remark) chDbgAssert(c, remark)
      |                                  ^~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:873:5: note: in expansion of macro 'osalDbgAssert'
  873 |     osalDbgAssert(false, "EP0 state machine error");
      |     ^~~~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:875:3: note: here
  875 |   case USB_EP0_ERROR:
      |   ^~~~
ChibiOS/os/hal/src/hal_usb.c: In function '_usb_ep0out':
ChibiOS/os/rt/include/chdebug.h:129:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  129 |   if (CH_DBG_ENABLE_ASSERTS != FALSE) {                                     \
      |      ^
ChibiOS/os/hal/osal/rt/osal.h:241:34: note: in expansion of macro 'chDbgAssert'
  241 | #define osalDbgAssert(c, remark) chDbgAssert(c, remark)
      |                                  ^~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:932:5: note: in expansion of macro 'osalDbgAssert'
  932 |     osalDbgAssert(false, "EP0 state machine error");
      |     ^~~~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:934:3: note: here
  934 |   case USB_EP0_ERROR:
      |   ^~~~
Compiling nvic.c
Compiling hal_lld.c
Compiling stm32_dma.c
Compiling hal_st_lld.c
Compiling hal_ext_lld.c
Compiling hal_ext_lld_isr.c
Compiling hal_pal_lld.c
Compiling hal_i2c_lld.c
Compiling hal_i2s_lld.c
ChibiOS/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.c: In function 'i2s_lld_start':
ChibiOS/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.c:461:19: warning: assignment to 'uint32_t' {aka 'long unsigned int'} from 'volatile uint32_t *' {aka 'volatile long unsigned int *'} makes integer from pointer without a cast [-Wint-conversion]
  461 |       i2sp->rx_dr = &i2sp->spi->DR;
      |                   ^
Compiling hal_spi_lld.c
Compiling hal_gpt_lld.c
Compiling hal_serial_lld.c
Compiling hal_usb_lld.c
In file included from ChibiOS/os/rt/include/ch.h:82,
                 from ChibiOS/os/hal/osal/rt/osal.h:32,
                 from ChibiOS/os/hal/include/hal.h:28,
                 from ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:27:
ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c: In function 'usb_lld_init_endpoint':
ChibiOS/os/rt/include/chdebug.h:129:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  129 |   if (CH_DBG_ENABLE_ASSERTS != FALSE) {                                     \
      |      ^
ChibiOS/os/hal/osal/rt/osal.h:241:34: note: in expansion of macro 'chDbgAssert'
  241 | #define osalDbgAssert(c, remark) chDbgAssert(c, remark)
      |                                  ^~~~~~~~~~~
ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:588:5: note: in expansion of macro 'osalDbgAssert'
  588 |     osalDbgAssert(false, "isochronous support disabled");
      |     ^~~~~~~~~~~~~
ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:590:3: note: here
  590 |   case USB_EP_MODE_TYPE_BULK:
      |   ^~~~
Compiling board.c
In file included from ChibiOS/os/common/ext/CMSIS/ST/STM32F0xx/stm32f072xb.h:129,
                 from ChibiOS/os/common/ext/CMSIS/ST/STM32F0xx/stm32f0xx.h:157,
                 from ChibiOS/os/common/startup/ARMCMx/devices/STM32F0xx/cmparams.h:72,
                 from ChibiOS/os/common/ports/ARMCMx/chcore.h:70,
                 from ChibiOS/os/rt/include/ch.h:81,
                 from ChibiOS/os/hal/osal/rt/osal.h:32,
                 from ChibiOS/os/hal/include/hal.h:28,
                 from ./NANOVNA_STM32_F072/board.c:17:
In function '__set_MSP',
    inlined from '__early_init' at ./NANOVNA_STM32_F072/board.c:82:5:
ChibiOS/os/common/ext/CMSIS/include/core_cm0.h:85:28: warning: listing the stack pointer register 'sp' in a clobber list is deprecated [-Wdeprecated]
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cmFunc.h:470:3: note: in expansion of macro '__ASM'
  470 |   __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
      |   ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cm0.h:85:28: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
   85 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler          */
      |                            ^~~~~
ChibiOS/os/common/ext/CMSIS/include/core_cmFunc.h:470:3: note: in expansion of macro '__ASM'
  470 |   __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
      |   ^~~~~
Compiling chprintf.c
Compiling memstreams.c
Compiling nullstreams.c
Compiling ff.c
Compiling ffunicode.c
Compiling usbcfg.c
Compiling main.c
Compiling si5351.c
Compiling tlv320aic3204.c
Compiling dsp.c
dsp.c:222:23: warning: argument 1 of type 'float[2]' with mismatched bound [-Warray-parameter=]
  222 | calculate_gamma(float gamma[2])
      |                 ~~~~~~^~~~~~~~
In file included from dsp.c:23:
nanovna.h:291:29: note: previously declared as 'float *'
  291 | void calculate_gamma(float *gamma);
      |                      ~~~~~~~^~~~~
dsp.c:253:23: warning: argument 1 of type 'float[2]' with mismatched bound [-Warray-parameter=]
  253 | fetch_amplitude(float gamma[2])
      |                 ~~~~~~^~~~~~~~
nanovna.h:292:29: note: previously declared as 'float *'
  292 | void fetch_amplitude(float *gamma);
      |                      ~~~~~~~^~~~~
dsp.c:260:27: warning: argument 1 of type 'float[2]' with mismatched bound [-Warray-parameter=]
  260 | fetch_amplitude_ref(float gamma[2])
      |                     ~~~~~~^~~~~~~~
nanovna.h:293:33: note: previously declared as 'float *'
  293 | void fetch_amplitude_ref(float *gamma);
      |                          ~~~~~~~^~~~~
Compiling plot.c
plot.c:903:1: warning: 'cell_drawstring' defined but not used [-Wunused-function]
  903 | cell_drawstring(char *str, int x, int y)
      | ^~~~~~~~~~~~~~~
Compiling ui.c
Compiling ili9341.c
Compiling numfont20x22.c
Compiling Font5x7.c
Compiling Font7x13b.c
Compiling Font10x14.c
Compiling flash.c
Compiling adc.c
Compiling rtc.c
Linking build/ch.elf
Creating build/ch.hex
Creating build/ch.bin
Creating build/ch.dmp

   text    data     bss     dec     hex filename
  79816     528   16048   96392   17888 build/ch.elf
Creating build/ch.list

Done

Fail to flash .dfu file

I've tried downloading the .dfu file from the release section, when flashing with dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D NanoVNA.H4.v1.2.00.dfu the program exit with an error.

dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Multiple alternate interfaces for DfuSe file
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
dfu-util: Error: File ID 0483:0000 does not match device (0483:df11 or 0483:df11)

building the firmware from source and flashing the compiled file works (but the buttons to load the calibration file and config file are missing)

Data smooth option not saved

Hello

Looks like you guys are still doing wonders, I've installed the latest firmware release (v1.2.20) into my NanoVNA-H4, all looks very nice !

I've not looked at the source code for some time now (life things) but was just wondering if the data smooth option is meant to be remembered or not across power up/downs. If it's not meant to be saved in the vna's non-volatile config settings then that's no problem and please cancel/delete this issue message, but if it is then it doesn't appear to be restored at next power on.

Anyway, amazing work as usual :)

H4 v1.0.69 - Smith chart noisy after calibration

Branch: H4
version: 1.0.69
Latest commit:

commit 5d2ddda (HEAD -> H4, origin/H4)
Merge: 672e8e3 fe83afd
Author: DiSlord [email protected]
Date: Tue Aug 31 21:15:17 2021 +0300

Merge branch 'master' of https://github.com/DiSlord/NanoVNA-D into H4

Compiled and install firmware, did a "Clear all and reset". The display looks normal.

...and the version screen:

Did a Open-Short-Load calibration, upon hitting "DONE", the S11 LOGMAG and SMITH go "noisy" with the Smith Chart being a star-like pattern.

I want to think that I'm just missing something.

Shipped version 0.5.0 (hugen79) doesn't have this issue, reinstalled 0.5.0 after 1.0.69 to verify

Build error when __VNA_Z_RENORMALIZATION__ is defined, include file missing

Enabling #define __VNA_Z_RENORMALIZATION__ gives this error during make:

main.c:1116:10: fatal error: vna_modules/vna_renorm.c: No such file or directory
 #include "vna_modules/vna_renorm.c"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
main.c:1116:10: fatal error: vna_modules/vna_renorm.c: No such file or directory
 #include "vna_modules/vna_renorm.c"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

USB enumeration

It appears that two devices with v1.1.0 firmware cannot both obtain a COM port on Win10, the first one attached does and the second one seems not the enumerate fully and produce a COM port. I note they both have the same VID,PID (to be expected) and SERIAL which may be the root cause of this problem.

Is it feasible to have each new installed firmware create a random serial number which it retains for future use. Perhaps if it recognised the factory serial no, it replaces it with a random value which it uses on later starts.

Owen

make flash fails

I receive this error when issuing make flash

% make flash
make: *** No rule to make target build/build/H.bin', needed by flash'. Stop.

thanks,

Make Fails

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

fails with no ch.bin in the build directory.

I believe it is an error during the make process

Thank You John

No indicator NanoVNA-H Battery

Hello. After updating the firmware on NanoVNA-H to version v1.2.20, I did not find an icon on the screen showing the battery charge. I also scrolled through the messages on the forum - there is also no battery icon in the screenshots.
Is this a bug or is it missing for some other reason?
Thanks in advance.

S11 impedance changed with V1.2?

With V1.1, a 50 ohm load showed +-50ohm and impedance in the S11 SMITH line:

But with V1.2 it seems to show some dimensionless value and angle?

This affects all my saved screen setups.

How do I switch back to restive + reactive display?

Increase number of Save-Recall profiles from 6 to 12 (for example)

Would be great to increase the number to 12.
When doing antenna measurements you need say 10 for short waves and 2 for VHF/UHF (and you need them calibrated separately).

NanoVnaApp link broken on readme

grey screen on current build

when I flash the current build from a git pull I get a grey screen.

loaded 1.2 with no issues

build issue on Mac

I get the following build error on Mac

main.c:1093:10: fatal error: vna_modules/vna_renorm.c: No such file or directory #include "vna_modules/vna_renorm.c" ^~~~~~~~~~~~~~~~~~~~~~~~~~

Possible problem in interpolation of calibration data - H4 - v.1.2.20

Let me start with a picture...

The glitch in |s11| at 100.04MHz concerns me. It appears to be a defect in the interpolation code.

Steps:

OSL calibrate the -H4 with fixture being 5m of RG58A/U from 1-101MHz, 100pts.
Measure L using the calibration scan range 95-101MHz 101pts (so it is interpolating the calibration data).

Attached is a zip of the cal and s1p.

Owen

VNA_230320_105615.zip

Build error: initializer element is not constant

make fails with this error:

In file included from chprintf.c:31:0:
nanovna.h:610:20: error: initializer element is not constant
 #define S_MICRO    "\035"  // hex 0x1D
                    ^
chprintf.c:56:42: note: in expansion of macro 'S_MICRO'
 static const char smallPrefix[] = { 'm', S_MICRO[0],  'n',   'p',   'f',   'a',   'z',   'y', 0};
                                          ^~~~~~~
nanovna.h:610:20: note: (near initialization for 'smallPrefix[1]')
 #define S_MICRO    "\035"  // hex 0x1D
                    ^
chprintf.c:56:42: note: in expansion of macro 'S_MICRO'
 static const char smallPrefix[] = { 'm', S_MICRO[0],  'n',   'p',   'f',   'a',   'z',   'y', 0};
                                          ^~~~~~~
make: *** [ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:216: build/obj/chprintf.o] Error 1

System: Linux debian stable, compiler:
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)

Fix: change definition of MICRO from string S_MICRO to char C_MICRO and use this char directly instead of the 1st char of the string.

--- nanovna.h.orig      2021-06-14 17:34:03.957310565 +0200
+++ nanovna.h   2021-06-14 17:45:59.881228218 +0200
@@ -607,7 +607,7 @@
 #define S_LARROW   "\032"  // hex 0x1A
 #define S_RARROW   "\033"  // hex 0x1B
 #define S_PI       "\034"  // hex 0x1C
-#define S_MICRO    "\035"  // hex 0x1D
+#define C_MICRO    '\035'  // hex 0x1D
 #define S_OHM      "\036"  // hex 0x1E
 #define S_DEGREE   "\037"  // hex 0x1F

--- chprintf.c.orig     2021-06-15 09:52:06.760886946 +0200
+++ chprintf.c  2021-06-15 09:59:38.232058680 +0200
@@ -53,7 +53,7 @@
 static const char bigPrefix[] = {' ', 'k', 'M', 'G',  'T',  'P',  'E',  'Z',  'Y', 0};
 // Prefixes for values less   then 1.0
 //                                 1e-3,       1e-6, 1e-9, 1e-12, 1e-15, 1e-18, 1e-21, 1e-24
-static const char smallPrefix[] = { 'm', S_MICRO[0],  'n',   'p',   'f',   'a',   'z',   'y', 0};
+static const char smallPrefix[] = { 'm', C_MICRO,  'n',   'p',   'f',   'a',   'z',   'y', 0};
 
 #pragma pack(pop)

NanoVNA-H - wrong text formatting of bottom line

The rightmost element of the bottom line display is overwritten by middle element IFBW:1000 101p when BW >= 1000, it reads TOP 900.000 000 MHz instead of STOP 900.000 000 MHz, see attached screen shot (same for CENTER/SPAN -> PAN

Firmware version 1.2.19

Touchscreen calibration broken in latest master

I have a NanoVNA-H, and I've built the latest firmware from the master branch and loaded it onto the device.

However, the touchscreen is now unable to calibrate the right quarter of the screen, despite repeated attempts to properly calibrate it via the menu. Below is a photo of the touch test screen after moving my stylus over as much of the screen as possible.

Interestingly, if I switch back to edy555's last release from November 2020, I am able to calibrate the screen properly and the full extent is usable. So, something strange is occurring with this branch of the firmware.

time command appears to be broken after vers 1.0.46

Can set time on 1.0.45 but on >my H4 build< of your 1.0.48, it no longer work for LSE xtal:

ch> time b 0x210305 0x083322
ch> time
2021/03/05 09:45:29
usage: time {[y|m|d|h|min|sec] 0-99} or {b 0xYYMMDD 0xHHMMSS}
ch>

As you suggested, I commented out the -DVNA_AUTO_SELECT_RTC_SOURCE line in the Makefile.
manually select RTC source, by default use LSE in makefile

Suggestions?

Font is too small for F072 devices

I have a workable solution for using an 8x8 font instead of 5x7 for the F072 NanoVNA-H devices. PTAL.
Font8x8.zip

NB: I've since added a Advanced configuration FONT toggle menu that acts immediately to permit selecting between the LARGE or the SMALL font, saves the result into the configuration. Not represented in the zip ball

Wrong formula for Q calculation in XTAL-SERIES

In measure.c:438, the formula for Q calculation is wrong. As stated in page 9 of https://www.mikrocontroller.net/attachment/473317/Crystal_Motional_Parameters.pdf (which this code is based from), the fraction's denominator should be Reff, which is 2*Zo+Rm. However, the code uses Rm instead of Reff, which leads to absurdingly high Q values.

I noticed that when I was measuring a quartz crystal and VNA told me that the Q factor was over 77000 when it should be around 6800.

I'll prepare a pull request...

doc: Please add `dfu-util` cmd in README.md for Linux users

Hello, this is how we flashed a DFU from Linux but I had to search around google a bit to find it. Can you add this to your README.md file?:

dfu-util  -a 0 -D NanoVNA.H.v1.2.00.dfu

BTW, the new virmware works great! Its like I have a brand-new VNA!

dislord / nanovna-d Goto Github PK

nanovna-d's Introduction

NanoVNA - Very tiny handheld Vector Network Analyzer

About

Prepare ARM Cross Tools

MacOSX

Linux (ubuntu)

Debian

Fetch Source Code

Update Source Code

Build the NanoVNA-H Firmware

Build the NanoVNA-H4 Firmware

Flash Firmware

For NanoVNA-H:

For NanoVNA-H4:

Or simply type directly after building the firmware (for both variants).

Ignore the apparent error message during flashing

Companion Tools

Documentation

Reference

Note

Credit

Based on code from:

Contributors

nanovna-d's People

Contributors

Stargazers

Watchers

Forkers

nanovna-d's Issues

Recommend Projects

Recommend Topics

Recommend Org