¿ªÔÆÌåÓý

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

My NanoVNA is overheating


 

NanoVNA-H V3.4

DiSlord 0.9.3.4 firmware

I performed and open calibration only with no cables.

The temperature in the room is 80 degrees Fahrenheit.

First picture was taken when device was turned on.

Second picture was taken 6 minutes after turning on.

Third picture was taken 15 minutes after turning on.

If I put a bag of frozen vegetables on top of the device it works great, it is perfectly stable.

If I issue a threshold 200000000 command it overheats more slowly.

I bought the device in February and it worked well in the cooler months.

Thinking about adding a heat sink somewhere, but not sure where.

Any ideas?

--
Gary AG7TH


 

As I indicated in one of my posts, my new H4 crashes with
0.8.4.7fw every 10-15mins
0.8.4.6fw every 10-15mins
0.8.4.5fw does not crash.
all at around 25degC ambient. I haven't mess with the threshold. You may try a different firmware..


 

You can try this firmware (it my last test variant)
I revert some fixes added in 0.8.4.6
(Alsi it contain last UI, need reset config)


 

Thanks DiSlord, but I need the H version. Looks like it is not in the files section yet.

Gary AG7TH

On 7/16/20 15:35, DiSlord wrote:
You can try this firmware (it my last test variant)
I revert some fixes added in 0.8.4.6
(Alsi it contain last UI, need reset config)


 

Made thermal photo NanoVNA

Heat si5351 (1.jpg) generator and LD01 DCDC (3.jpg)
CPU (2.jpg)


 

Hot pictures! Looks like all three chips are candidates for a heat sink.

I installed the old 0.8.4.5 firmware, then I put the NanoVNA in the freezer for a few minutes to see if I could make it through a calibration, looks okay so far after calibrating. Need to wait until the device warms up again to see if it stays stable.

After a few minutes I am now seeing the same thing, instability and noise all over. So it may be something that the firmware cannot fix.

Gary AG7TH

On 7/16/20 15:52, DiSlord wrote:
Made thermal photo NanoVNA

Heat si5351 (1.jpg) generator and LD01 DCDC (3.jpg)
CPU (2.jpg)


 

44degC at the packages is not too much, unless you do beefy overclocking :)


 

The ?T is 18¡ãC; 13¡ãC; and 15¡ãC. Some of the cold spots are actually on the circuit board. The two closest to the IC packages may be holes for mounting. I would not consider the holes significant. The large square cold spot on the right of all three is probably not significant either. The high temperature ranging from the Human Body Temperature +9¡ãC or +13¡ãF is a different issue.

My imager is due back tomorrow from it¡¯s annual Calibration Trip to the Factory. I will take a couple pictures of mine for control. See what a more normal temperature may be.

Are those images from the front or back of the unit. If they are through the LCD display, I would not trust the accuracy.

John Nicholas
Certified Thermographer Level II

On Jul 16, 2020, at 6:19 PM, Gary Hale <gary@...> wrote:
to
Hot pictures! Looks like all three chips are candidates for a heat sink.

I installed the old 0.8.4.5 firmware, then I put the NanoVNA in the freezer for a few minutes to see if I could make it through a calibration, looks okay so far after calibrating. Need to wait until the device warms up again to see if it stays stable.

After a few minutes I am now seeing the same thing, instability and noise all over. So it may be something that the firmware cannot fix.

Gary AG7TH

On 7/16/20 15:52, DiSlord wrote:
Made thermal photo NanoVNA

Heat si5351 (1.jpg) generator and LD01 DCDC (3.jpg)
CPU (2.jpg)



<IMG_20200716_160730.jpg><IMG_20200716_160849.jpg><IMG_20200716_161122.jpg>


 

DiSlord took the thermal pictures, and I am guessing it is his NanoVNA-H4, which I am also guessing does not have a problem.

I have a NanoVNA-H, not a NanoVNA-H4, and mine has a problem. I do not have a thermal camera.

When my unit is cool, it is stable. Without some kind of external cooling it quickly warms up and becomes unstable.

I am guessing that it is the SI3531. If it was the cpu it would probably crash, it has never crashed with any firmware.

I am going to cool off something and press it against each chip while the device is running and see what happens, which chip is overheating.

I will report back.

Gary AG7TH

On 7/16/20 17:37, John Nicholas wrote:
The ?T is 18¡ãC; 13¡ãC; and 15¡ãC. Some of the cold spots are actually on the circuit board. The two closest to the IC packages may be holes for mounting. I would not consider the holes significant. The large square cold spot on the right of all three is probably not significant either. The high temperature ranging from the Human Body Temperature +9¡ãC or +13¡ãF is a different issue.

My imager is due back tomorrow from it¡¯s annual Calibration Trip to the Factory. I will take a couple pictures of mine for control. See what a more normal temperature may be.

Are those images from the front or back of the unit. If they are through the LCD display, I would not trust the accuracy.

John Nicholas
Certified Thermographer Level II

On Jul 16, 2020, at 6:19 PM, Gary Hale <gary@...> wrote:
to
Hot pictures! Looks like all three chips are candidates for a heat sink.

I installed the old 0.8.4.5 firmware, then I put the NanoVNA in the freezer for a few minutes to see if I could make it through a calibration, looks okay so far after calibrating. Need to wait until the device warms up again to see if it stays stable.

After a few minutes I am now seeing the same thing, instability and noise all over. So it may be something that the firmware cannot fix.

Gary AG7TH

On 7/16/20 15:52, DiSlord wrote:
Made thermal photo NanoVNA

Heat si5351 (1.jpg) generator and LD01 DCDC (3.jpg)
CPU (2.jpg)


<IMG_20200716_160730.jpg><IMG_20200716_160849.jpg><IMG_20200716_161122.jpg>


 

The results are in, it is the si5351.

On the first attached sweep the chip was not cooled, the other sweeps were made while holding a frozen cotton swab against the chip for increasing amounts of time.

I started out using a frozen blueberry, but that only worked for so long, eventually the blueberry juice ran down onto the traces and NanaoVNA-Saver crashed. So I ate the rest of the frozen blueberries.

I wonder what my options are, besides buying a new H4.

Gary AG7TH


 


I wonder what my options are, besides buying a new H4.
1) use a frozen watermelon
2) drill vent-holes into the case
3) glue a small heat-sink on the top of the SI5351 chip
4) relax the SI5351's overclocking (lower its frequency)
5) increase the SI5351's Vdd voltage, ie. by 0.1-0.2V
6) replace the SI5351
..


 

Did you try to change the threshold, e.g. the frequency at which the SI5351 switches to harmonics mode?
All nanoVNA use the SI5351 way out of spec.

Try
threshold 250000000
first and calibrate till 750MHz and see if it remains stable.
If stable step by step (10MHz) increase the threshold till the SI5351 overheats again.
--
NanoVNA Wiki: /g/nanovna-users/wiki/home
NanoVNA Files: /g/nanovna-users/files
Erik, PD0EK


 

On Fri, Jul 17, 2020 at 12:29 AM, igor-m wrote:


As I indicated in one of my posts, my new H4 crashes with
0.8.4.7fw every 10-15mins
0.8.4.6fw every 10-15mins
0.8.4.5fw does not crash.
all at around 25degC ambient. I haven't mess with the threshold. You may try a
different firmware..
I built the latest H4 fw version (pulled from Dislord's github 1.5h back) with sdcard and 32kHz xtal.
Soldered xtal and socket in, flashed the fw in (shows old fw version on the LCD).
Set time (do not use leading 0), set vbat offset, re-calibrated my 4 ranges.
Did a measurement and saved s-data and LCD-shot - it works !! :)

Bad news - it crashed after about 5 minutes (the usb cable disconnected, voltage 4.17V).
It shows messy data, but the system works.

Q/A: What could be the difference between v 0.8.4.5fw (which works stable here), and the latest???


 

On Fri, Jul 17, 2020 at 05:33 AM, igor-m wrote:


Q / A: §¬§Ñ§Ü§Ñ§ñ §Þ§à§Ø§Ö§ä §Ò§í§ä§î §â§Ñ§Ù§ß§Ú§è§Ñ §Þ§Ö§Ø§Õ§å v 0.8.4.5fw
(§Ü§à§ä§à§â§í§Û §â§Ñ§Ò§à§ä§Ñ§Ö§ä §ã§ä§Ñ§Ò§Ú§Ý§î§ß§à §Ù§Õ§Ö§ã§î) §Ú
§á§à§ã§Ý§Ö§Õ§ß§Ú§Þ ???
In nanovna.h i begin use AUDIO_CLOCK_REF (86016000U)
Try revert to #define AUDIO_CLOCK_REF ( 8000000U)
// 5ms @ 96kHz
// Define aic3204 source clock frequency (for 8MHz used fractional multiplier, and possible little phase error)
#define AUDIO_CLOCK_REF ( 8000000U)
//#define AUDIO_CLOCK_REF (10752000U)
// Disable AIC PLL clock, use input as CODEC_CLKIN
//#define AUDIO_CLOCK_REF (86016000U)


 

My tests with threshold:
In the latest H4 source the threshold is set 300.000.100 Hz.
I set 201p, 1kHz BW, start=900M, stop=1000M
I started to increase the threshold till the display shows mess.

ch> threshold 322000000 << immediately started to mess

I returned back and with threshold 321.000.000 it runs stable for 20minutes already.. Hmm..

Frankly, I doubt the crashes I see here with the latest fw (and with 0846, 0847) are caused by the overheating of the SI5153..


 

Thanks for all the suggestions. I ordered an H4 and will experiment with an aluminum heat sink that bridges from the si5351 to the AIC 3204.

The si5351 was never hot to the touch, so it does not take much warming to set it off.

Gary AG7TH

On 7/17/20 00:40, igor-m wrote:
I wonder what my options are, besides buying a new H4.
1) use a frozen watermelon
2) drill vent-holes into the case
3) glue a small heat-sink on the top of the SI5351 chip
4) relax the SI5351's overclocking (lower its frequency)
5) increase the SI5351's Vdd voltage, ie. by 0.1-0.2V
6) replace the SI5351
..




 

@ Igor-m....

I used your settings and by setting the threshold up and down many many times I found my max threshold setting @ 305150000 and can leave it there for hours, it never gets unstable.

The firmware is by Dislord V 0.9.3,4 beta.

I'm measuring a 10dB attenuator on my H4, measures 9.78 dB, not one mB change.

When I feel the box, it's hardly warm.

Jos

Op 17-7-2020 om 15:58 schreef igor-m:

My tests with threshold:
In the latest H4 source the threshold is set 300.000.100 Hz.
I set 201p, 1kHz BW, start=900M, stop=1000M
I started to increase the threshold till the display shows mess.

ch> threshold 322000000 << immediately started to mess

I returned back and with threshold 321.000.000 it runs stable for 20minutes already.. Hmm..

Frankly, I doubt the crashes I see here with the latest fw (and with 0846, 0847) are caused by the overheating of the SI5153..


 

The overheating issue on my NanoVNA-H appeared early in April after I installed beta firmware titled "NanoVNA-H v0.8.3_96kHzIF_3.2kHz_sweep_points". Looking back I wonder if that firmware was a factor in sensitization of the chip.

Gary AG7TH


 

On Fri, Jul 17, 2020 at 03:54 PM, DiSlord wrote:

..
In nanovna.h i begin use AUDIO_CLOCK_REF (86016000U)
Try revert to #define AUDIO_CLOCK_REF ( 8000000U)
// 5ms @ 96kHz
// Define aic3204 source clock frequency (for 8MHz used fractional multiplier,
and possible little phase error)
#define AUDIO_CLOCK_REF ( 8000000U)
//#define AUDIO_CLOCK_REF (10752000U)
// Disable AIC PLL clock, use input as CODEC_CLKIN
//#define AUDIO_CLOCK_REF (86016000U)
OK, I've done, and I've also increased the default threshold to 310MHz here.
Flashed in, it runs for 25minutes already without a crash. I will use it now, and we will see.
Looks promising..


 

The SI chip is specified up to 200Mhz. Have you tried it with this threshold?

Mike N2NS


On 07/17/2020 1:24 PM igor-m < mikki@... > wrote:




On Fri, Jul 17, 2020 at 03:54 PM, DiSlord wrote:


..

In nanovna.h i begin use AUDIO_CLOCK_REF (86016000U)
Try revert to #define AUDIO_CLOCK_REF ( 8000000U)
// 5ms @ 96kHz
// Define aic3204 source clock frequency (for 8MHz used fractional
multiplier,
and possible little phase error)
#define AUDIO_CLOCK_REF ( 8000000U)
//#define AUDIO_CLOCK_REF (10752000U)
// Disable AIC PLL clock, use input as CODEC_CLKIN
//#define AUDIO_CLOCK_REF (86016000U)


OK, I've done, and I've also increased the default threshold to 310MHz
here.
Flashed in, it runs for 25minutes already without a crash. I will use it
now, and we will see.
Looks promising..