Higher power consumption than expected

Yeah - somehow some sloppiness in our power management crept in and all of the boards are burning too much power right now. I just debugged/figured out what the likely problem is on a NRF52 board (because it is easier to debug). Before the end of the week I should do the same and have a fix for the TBEAM - I think the GPS is burning too much power.


I’ve noticed the same with my Heltec LoRa32 v2 boards: They burn through a fully charged 700mAh battery in less than 8 hours.

On the Heltec website there is an example in which the board only requires 900uA (which would mean 700+ hours of battery life). Of course this is most likely with the ESP in deep sleep, and all radios and screen off. But still, such a short battery life is a little bit surprising.

1 Like

Fyr, LilyGO TTGO T3 LoRa32 868MHz V2.1.6 ESP32, firmware 1.0, lasts about 2 days on a 1200mA battery.
This is the same as from the first boot with firmware 0.9.1 back in August.

Today updated to 1.1.0 from 1.0, compared to the TBeam is feels the T3 is “sleeping” a lot better but unfortunately I also see some reduction in battery life now, a lot less then TBeam but still…Guestimate atm is it runs for a day and some 6-8 hours.
Tbeam 1.1.0 started with full battery this morning and with gps lock, after 8 hours it is at 3.8v and 52% (3350mA battery)

1 Like

Oh yes. Thanks for the info. I think I have what I need now - running on the bench and making the changes so we go back to our old super low power consumption.

The good news: I definitely have a fix (we were accidentally leaving the GPS awake while the CPU was sleeping - which burns lots of power). But I took advantage of this error to really cleanup the GPS code and unify the ublox and nmea codebases. I’ve also added the beginnings of ‘router mode’ - i.e. turn off bluetooth and gps almost always, run super low power and tell other nodes you are especially good at routing.

The bad news: we are moving this week and I’ve run out of time for packing. So I won’t have the fix out this week (sorry @luandro). However, it is first thing in my queue next week and I should have a nice clean device build out next weds ish.

My WIP branch is here (but really - you don’t want it yet):


Good luck with your move, safe travels.

Just curious though, does this mean you are going to have 14 days where you cant leave the house :crazy_face:

1 Like

Oh yes. Taiwan is very strict. We will be literally locked inside a hotel room.

No problem @geeksville, my field experiments will only begin after the second week of October. Would be awesome to have router mode by the end of the month. Wish there was a way I could help.

Moving to Taiwan? That sounds really exciting. Have fun, safe travels and good luck. Keep on the good work :+1:

Good catch! I noticed that my devices were all burning through battery lately, thought it was me. I haven’t measured it but a 5000mA battery is lasting around a day I think?

Update: I double checked, the 700mAh battery was empty in about 3 hours, that means an average draw of 233mA.

Hi ya’ll,

Okay - this is all pretty much fixed. I want to fix one more little thing and I’ll push out an alpha build tomorrow.

There were three different areas where accidentally too much power burn had crept in over the last monthish. The three main problems were:

  • GPS was not being kept off while main CPU is in light-sleep state or when we are not actively trying to get a GPS reading
  • GPS was not powered down most of the time. Now we turn it on, get a reading (takes typically about 10 secs with good view of sky, could be up to two min worst case and then turn it off until we need another reading). For non routers we’ll do this every two minutes, for routers it does it once per day, though in either case you can change these intervals to whatever you want.
  • We were not properly entering light sleep state, so we were burning 22mA extra while in light sleep
  • We were staying in bluetooth enabled mode for a long time, which is not good for routers.

Measurements after (I’ll put these into the runtime calculator spreadsheet soon) (all measurements from a high accuracy 4V bench supply on a sx1272 based TBEAM):

  • 180mA max current draw (screen on, xmitting, gps on, cpu running)
  • 100mA when GPS + screen + bluetooth on
  • 44mA when screen + bluetooth on (GPS powered down)
  • 32mA when bluetooth on (GPS and screen powered down - “DARK” power management state)
  • 11mA when cpu in light sleep (only lora radio powered, ready to wake everything else based on packet rx, timer expire, button press etc). <- This is the state nodes spend almost all of their time - it dominates the power calculations. I’m super happy that this number is now so low, it is half of the old lower limit.

I’ve also added the beginnings of router-mode, which includes a low-power-mode option for solar powered nodes. The new python tool is released to enable this mode “meshtastic --set-router”. But don’t use this option until I release the new device code. I want to fix an unrelated bug before pushing out a release. I’ll push this out tomorrow.


Oh, I actually saw that but thought it was normal behavior. The symptom was that the BT radio would power down for a few seconds and then bounce right back up and stay on for ~5-10 minutes at a time before powering down for a few seconds again. Kinda kicking myself now for not speaking up.

1 Like

very good power draw !
It is with tbean sx1262 and m8n gps or m6 gps ?
at 22dbm power ?

That was a sx1272 with a neo 6m.

I’ll test a sx1262 soonish. A sx1262 should be a bit lower but it also has a tcxo - which is a great feature but probably burns a bit of power.

The 8m gps has much better power management, so we could do something smarter than just killing power to it. But currently we don’t do any of that improvement.

ok - I think this is now fixed (and if you turn on router mode the power levels will be even lower). Details here: Alpha tester thread (1.1.1 of device code ready testing) 🙂

Please reply to this thread with your power related findings.

In a weekish (after some other items in my queue) I’ll update the power/runtimes spreadsheet. Also, once threading cleanup happens (soonish) power draws should decrease another 5%ish.


I want to share link of important discussion regarding power consumption below:


1 Like