¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Latest NanoVNA-Z-v1013M H4 firmware #H4-firmware #nanovna-H4


 

I started to assemble a next version with the latest publicly available source code "mods" (separate files only).
This version will include line-by-line changes in the source code files visible, and it will be the next commit to the existing 6th August repository backup NanoVNA-Z.
I've created a patch file, after applying the patch to the NanoVNA-Z sources and building it I get the same binary.
Now I can see the changes made. So far so good.

The new version is called NanoVNA-Z-v1013M (branch H4 only).
The name indicates:

a) it comes from NanoVNA-Z (my latest backup of the entire github repository from August 6th I consider untouched),
b) it is related to version v1.0.13 beta,
c) M means the latest "mods" were applied.

The main issue with this latest version is the resulting binary is unstable, it freezes after some time.

Nothing new afaik, it most probably comes from the new aggressive settings with AUDIO_CODEC. It could be something else as well.
I do not think it comes from Si5351 clock generator overheating - as my 5351 works "stable" at 321MHz (currently the threshold is set 300.001MHz).
A high time to start read the code :)




 

The latest NanoVNA-Z-v1013M firmware for H4 has made 24 hours without a freeze..

After a week spent with messing with various parameters (Chibios, Si5351, AudioCodec, etc.) the major source of the instability with the latest firmware pinpoints the overclocking of the AIC3204 Audio Codec.

Its datasheet max MCLK is 50MHz. The older versions of the firmware used to use 86.016MHz, the latest 98.304MHz. The ADC sampling rate is derived from MCLK. The older versions worked with max 96kHz sampling, while the latest firmware allows up to 768kHz (advertised as an "improvement").

Well, I do understand a temptation to provide experiments like "what the existing hardware can bear", but for stable operation in the field such a a massive overclocking (of almost each critical component in the box) is something I would not recommend.

I've reverted the Audio Codec settings back to the older 86.016MHz and set 96kHz "Audio Codec sampling frequency" and 12kHz "frequency offset" as my default. That allows for up to 2kHz "Bandwidth". This setting is working "rock stable" here (at ambient 29degC).








 

Tried with 86.016MHz PLL clock and 192kHz ADC sampling? - that is a setting which should work fine. I registered 2 freezes within 24hours (H4 with stock cable and stock load, powered via usb or from battery).

I have to correct my previous information on the AIC3204 max clock speed. There is the PLL inside used for generating internal clocks, PLL is used with the 86MHz as well as 98MHz settings. The table with max clock frequencies is attached below (from TI's ref manual).

Anyhow, here my H4 freezes randomly with 98MHz clock setting (ie. it freezes within several seconds while on the "Version" screen). Could be the overheating, or, it may come from some critical AIC3204 settings.


 

FYI - attached a table depicting an evolution of the key AIC3204 parameters from available sources.