Skip to content

Conversation

@Quency-D
Copy link
Contributor

@Quency-D Quency-D commented Feb 2, 2026

In this commit #1486, some users reported high power consumption during sleep mode. This commit optimizes power consumption during sleep mode.

@IoTThinks
Copy link
Contributor

IoTThinks commented Feb 2, 2026

some users reported high power consumption during sleep mode. This commit optimizes power consumption during sleep mode.

This is the issue of OLED failed to off even at turnOff.
There is extra 26mA during normal mode (powersaving off) too.
In normal mode, heltec v4 will use 78mA instead of 50mA. They may not notice it as the extra 26mA is small when they use main power.

Users reported power issues in powersaving on because the extra 26mA is too huge compared to expected 13mA total power consumption in low power mode.

  1. What if PIN_OLED_RESET is not defined like in Heltec v3, will this work?
    https://github.com/meshcore-dev/MeshCore/pull/1570/changes#diff-216d0c26407b9ddc9786164126b577503d3ec31255786a5ebeecae29775863e1R35
image
  1. I feel there is overlapping code between begin() and turnOn() code.
    So even in the perfect flow begin > turnOn > turnOff, there are overlapping code.
    https://github.com/Quency-D/MeshCore/blob/e15503d50d07fbceca16234078596669f0477820/src/helpers/ui/SSD1306Display.cpp#L24
image
  1. This RefCountedDigitalPin (vExt) is shared between OLED and sensors.
    So let's say we have 1 OLED and 3 sensors.
    So if 3 devices do 3 releases, "claims" will be a negative number like -2 or -3.

So the last sensor does "claim", even after plus 1, the "claims" number is still negative and the vExt is still off?
The last sensor will expect the vExt to be on.

https://github.com/meshcore-dev/MeshCore/blob/dev/src/helpers/RefCountedDigitalPin.h#L23
image

@Quency-D
Copy link
Contributor Author

Quency-D commented Feb 2, 2026

  1. v3 works correctly because it has a default value.
#ifndef PIN_OLED_RESET
  #define PIN_OLED_RESET        21 // Reset pin # (or -1 if sharing Arduino reset pin)
#endif
  1. There might be a slight code duplication, but it must be reinitialized after powering off for it to display correctly. The _isOn variable prevents duplicate code from being executed repeatedly.
  2. A negative value for _claims could be a problem. However, as long as the on and off claims are strictly paired, there shouldn't be any issues.

@mavericm1
Copy link

@IoTThinks If you have removed the OLED does this still cause more powerdraw? I would think if the oled is removed then it can't draw the additional power.

Can this be confirmed?

@IoTThinks
Copy link
Contributor

IoTThinks commented Feb 3, 2026

@IoTThinks If you have removed the OLED does this still cause more powerdraw? I would think if the oled is removed then it can't draw the additional power.

Can this be confirmed?

@mavericm1
I havent tried but sure removing OLED will avoid the issue.

A friend with no-oled heltec v4 has reported no issue.

@IoTThinks
Copy link
Contributor

@Quency-D 1. Why OLED RESET need to pull LOW before release?
A good "release" will set vExt to off and cut the power to OLED.

  1. It is always easier to fix the release of RefCountedDigitalPin to ensure non-negative number to claims than relying on other sensors to strictly use pair of claim and release.

@Socalix
Copy link

Socalix commented Feb 3, 2026

@IoTThinks If you have removed the OLED does this still cause more powerdraw? I would think if the oled is removed then it can't draw the additional power.
Can this be confirmed?

You don't need to physically remove the OLED to confirm. You can just build with DISPLAY_CLASS flag commented out, and power consumption will go back down to 11mA like in firmware v1.11.0

@IoTThinks
Copy link
Contributor

@Socalix Yah, true. I will test in free time. Thanks a lot. :)
However, in reality, physical removal and disabling DISPLAY_CLASS do not always have the same effect.

For now, I believe just fix the release() to avoid negative "claims" will fix this on/off issue of OLED.
We should fix the root cause instead of fixing the components depending on it.
1 file and 2 lines.
#1569

@Socalix
Copy link

Socalix commented Feb 3, 2026

Yeah, I thought @mavericm1 was trying to confirm that the new OLED/TFT code was causing the extra power consumption.

I agree your PR is nice and clean and a generic fix for other use cases.

@mavericm1
Copy link

I was just confirming as I have a v4 deployed without the oled that was upgraded ota and it has a small battery and is not a easily accessible repeater

Yeah, I thought @mavericm1 was trying to confirm that the new OLED/TFT code was causing the extra power consumption.

I agree your PR is nice and clean and a generic fix for other use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants