Heltec Tracker v1.1 U6 wastes power

[geeksville]

per discussion with @HarukiToreda and @todd-herbert

https://github.com/HarukiToreda/Meshtastic-Experiments?tab=readme-ov-file#power-measured-on-meshtastic-firmware-2310-from-battery

was taking some measurements not too long ago, and it does look like it's consistently drawing 50mA more than similar boards

ooh - just from looking at the schematic I think I see a problem: GPIO3 on the CPU is used to control the enable for the TFT screen power supply (U6). I don't see anything variant.h for that board that is setting that up. So we might always be leaving that (expensive) supply on. I'll check tomorrowish and if so, have it only on when we want the display powered.
oh i see that supply is shared with gps. But when GPS and screen are both not needed we can turn it off.

[geeksville]

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?

[HarukiToreda]

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.

[GUVWAF]

Related: #3760.

[lyusupov]

[todd-herbert]

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

[todd-herbert]

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

[jp-bennett]

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.

[todd-herbert]

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")

[madeofstown]

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.

[todd-herbert]

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.

[todd-herbert]

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

[StevenCellist]

Am by no means a Meshtastic expert - heck, not even a user - so this might be completely out of place. But I am a Tracker power-user. What might be good to know, is that the ADCEnable / VBat-enable should not be configured to be output-high as it drains about 60mA. Instead, input-pullup is the way to go with almost immeasurable power drain. So that may be a useful piece of information in this thread...

[todd-herbert]

What might be good to know, is that the ADCEnable / VBat-enable should not be configured to be output-high as it drains about 60mA.

Wow yeah that's interesting! For some reason they've gone with a BJT there with no base resistor??
It looks like ADC_CTRL is only output-high for a few ms at a time, but that's no excuse for near-shorting the GPIO like this!

[StevenCellist]

Yeah I saw that it is only used shortly, but then again I'm no Meshtastic expert so wasn't sure if that was it or if it's used in other hidden places. So thought I'd mention it in case

[todd-herbert]

Hey even if it's only for a brief moment, that's got to be bad for the hardware, if nothing else!

[StevenCellist]

See my earlier findings here - sorry, misreported 40mA for 60mA but still the same problem.

[GPSFan]

Maybe someone should ping on Aaron-Lee about why they used a BJT without base resistor. There are some specialized BJTs that have built in series base and base-to-emitter resistors, maybe Heltec was going to use one of those and the Tracker got cost reduced to use a cheaper part by some bean counter. They use Mosfets for essentially the same task in other places on the Tracker as well as BJTs with series base resistors.
They could easily swap out that part in a 1.2 version, as well as putting back control of VIO for the GPS.

[madeofstown]

I've noticed that both of my Heltec Trackers tend to run pretty warm(specifically around the USB port)... Could it be because of the current implementation for battery monitoring?

[todd-herbert]

@madeofstown I don't think it'll be that battery monitoring thing, but you never know. The excess current draw for the boards does seem to be roughly what you'd expect the GPS to consume, so that SharedGPIO class that was mentioned above might at least cut the power consumption back in line with other ESP32-S3 boards by allowing the GPS hardware to be powered down (depending on config).