Heltec Tracker v1.1 U6 wastes power about firmware HOT 11 OPEN

The Heltec Wireless paper for example despite having a similar board and a very efficient screen, draws as much current as the Hetec v3 with a screen on, something is guzzling lots of power

Now that's something I can probably play with, at least to see if disabling any particular part of the code changes the behavior. For what it's worth, it might be worth doing some more measurement with the Wireless Paper. I've definitely seen that high-idle current, but I have a funny feeling I've also a much lower idle current at times.

I see that you are only measuring 7mA difference with screen-on vs screen-off for Heltec V3. Maybe the screen is a bit of a red herring here?

Anecdotally, one of the the local guys in my area claims big Meshtastic power-savings by under-clocking the ESP32-S3 processor to 20MHz, but no idea just how badly this could break everything?

Update: with an example sketch (non-Meshtastic), I dropped the processor speed from 240MHz to 20MHz, and the power consumption fell from ~65mA to ~10mA

from firmware.

If this is indeed the problem:

I think I'm going to add the concept of a SharedGpio and Gpio micro helper classes. Then have both the GPS enable code and the screen enable code use an instance of this little class to turn their power/on off.

A SharedGpio(Gpio *inA, Gpio *inB, Gpio *out) will be a subclass of Gpio that turns on out if inA OR inB is set to on (initially - later if useful we could add an opcode like AND, XOR, whatever is needed)

@todd-herbert and @HarukiToreda thoughts on this idea?

from firmware.

Update: with an example sketch (non-Meshtastic), I dropped the processor speed from 240MHz to 20MHz, and the power consumption fell from ~65mA to ~10mA

If the default firmware could run at 65MHz (same as rak4631) that would be amazing! The power savings would be greatly appreciated.

Just at a glance, it sounds like BLE and WiFi need that 80MHz clock on ESP32, but maybe there's some hope for this with some sort of alternative distribution channel? Don't think I should disrail this issue thread even more (oops); there's a moonshot idea about that option on the Discord server though if you're interested.

from firmware.

Related: #3760.

from firmware.

intruducing SharedGpio is good concept to have. The Heltec Wireless paper for example despite having a similar board and a very efficient screen, draws as much current as the Hetec v3 with a screen on, something is guzzling lots of power, I suspect something similar may be occurring, this will help as an example to tackle such cases in the future.

from firmware.

from firmware.

If this is indeed the problem:

I think I'm going to add the concept of a SharedGpio and Gpio micro helper classes. Then have both the GPS enable code and the screen enable code use an instance of this little class to turn their power/on off.

A SharedGpio(Gpio *inA, Gpio *inB, Gpio *out) will be a subclass of Gpio that turns on out if inA OR inB is set to on (initially - later if useful we could add an opcode like AND, XOR, whatever is needed)

@todd-herbert and @HarukiToreda thoughts on this idea?

It seems totally sensible! It'd be interesting to see how much power might be saved there.

Actually, one thing that's just come to mind: I spotted the other week is that UC6580 (the GPS on the Wireless Tracker, right?) isn't put into a standby state: GPS.cpp L970. I'm not sure what the technical reason for that is though; that's well over my head! Does the power consumption drop if the GPS is disabled? How about if position.gps_update_interval is set longer than 20 minutes? Could be a good clue.

I'm having a look at detangling that class slightly, after having tangled it slightly more myself just recently.. oops. Not sure what standby states are available with the UC6580. My first instinct is to bother @jp-bennett and @GPSFan for hardware info! Edit: it's not super relevant to this whole discussion, but I've pushed to #4161, just to show a rough draft. Not super attached to any of it though

from firmware.

I spotted the other week is that UC6580 (the GPS on the Wireless Tracker, right?) isn't put into a standby state: GPS.cpp L970.

That true/false determine whether to fully power off the GPS, or just drop it into standby. I think that #ifdef is from when there was only the one device using that GPS chip, and the power rail was connected to more than the GPS. Hazy memory there.

I like the idea of the GPIO class, but there's a lot of inherent complexity in the GPS power toggle.

from firmware.

I think that #ifdef is from when there was only the one device using that GPS chip, and the power rail was connected to more than the GPS. Hazy memory there.

All good! Had just wondered if there was some specific piece of technical knowledge there that for me to uncover ("yeah we don't power that one down because of bug x")

from firmware.

Update: with an example sketch (non-Meshtastic), I dropped the processor speed from 240MHz to 20MHz, and the power consumption fell from ~65mA to ~10mA

If the default firmware could run at 65MHz (same as rak4631) that would be amazing! The power savings would be greatly appreciated.

from firmware.

Just while I'm looking at #4161, I think that shared gpio class idea would probably drop nicely into GPS::writePinEN.

from firmware.