Fix heltec-v4 power consumption

[Quency-D]

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

[IoTThinks]

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

2. 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

3. 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

[Quency-D]

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

2. 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.
3. 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]

@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]

@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]

@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.

2. 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]

@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]

@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]

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]

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.

[oltaco]

Would this be better as

  #if defined(PIN_OLED_RESET)
  digitalWrite(PIN_OLED_RESET, LOW);
  #endif

So that the call is only compiled in if PIN_OLED_RESET is actually defined?

[Quency-D]

PIN_OLED_RESET is the default definition. So this line actually has no effect.

[oltaco]

Won't this call to begin() cause an additional claim() to occur?

[Quency-D]

It will not be executed repeatedly because _isOn controls the process.

[oltaco]

Thanks for this, if there is PIN_OLED_RESET then we should be using it.

I think there are some issues with it still though, can you check? Thanks

[IoTThinks]

In this thread #1569 (comment), I suspect SSD1306Display does not use vExt at all and vExt=LOW means off instead.

If correct, then the claim() and release() may not be relevant in SSD1306Display.