dislord / nanovna-d Goto Github PK
View Code? Open in Web Editor NEWFirmware for NanoVNA, NanoVNA-H, NanoVNA-H4. Support SD Card, external Serial connection, fast measure, fast exchange vs CPU
Firmware for NanoVNA, NanoVNA-H, NanoVNA-H4. Support SD Card, external Serial connection, fast measure, fast exchange vs CPU
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 :)
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
Hello DiSlord,
there was an interesting discussion about the xtal calculation on groups.io. Please check Orestes' findings.
Martin
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.
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:
Attached is a zip of the cal and s1p.
Owen
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)
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).
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
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 },
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
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,
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..
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
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.
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?
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
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.
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
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
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.
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;
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). */
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
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
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)
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!
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.
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" ^~~~~~~~~~~~~~~~~~~~~~~~~~
Make fails with:
arm-none-eabi-gcc: fatal error: cannot read spec file 'nano.specs': No such file or directory
Uncommitted file?
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.
see also erikkaashoek/tinySA#36
Another user's tinySA also shows this, so it is obviously a systematic problem.
https://groups.io/g/tinysa/message/7071
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)
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...
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.
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!
when I flash the current build from a git pull I get a grey screen.
loaded 1.2 with no issues
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.
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__
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.
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
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.
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
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
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
Add build support for the MS HW variant as proposed in this discussion.
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.