With winter approaching, I am starting to think about protecting my batteries when temperatures drop and sunlight is reduced.
My devices sleep most of the hour, waking occasionally to service hardware interrupts and then reporting at the top of the hour. When not doing actual work, I use the Sleep 2.0 API like this:
config.mode(SystemSleepMode::ULTRA_LOW_POWER) .gpio(userSwitch,CHANGE) .gpio(intPin,RISING) .duration(wakeInSeconds * 1000); SystemSleepResult result = System.sleep(config); // Put the device to sleep
Since deviceOS@2.0.0, I have stopped using the FuelGauge API and started relying on System.batteryCharge to monitor the battery and I dropped all that stuff about fuelGauge.wakeup(); and delays as we had all discussed back in the DeviceOS@1.5.0 days when the fuel gauge was put to sleep.
However, with deviceOS@2.2.0, I am seeing this issue again. Take a look at this console log. I deliberately put a device in a low battery state and, once it was asleep, I fully charged the battery. It failed to wake at the top of the hour so, I reset it and brought it on-line it reported 25% SOC. I then performed a power-cycle and, when it came back on-line only then did it display the correct SoC - 94%.
So, I will keep testing this but it raises some questions:
- Are we still putting the fuelGauge to sleep in deviceOS@2.2.0?
- If so, when the battery is charged between samples, does System.batteryCharge() take longer to take a measurement? Do we need to use the fuelGauge.quickStart()?
- Do we still need to provide fuelGauge.wakeup() and delay(500) like we did starting back at deviceOS@1.5.0 when these issues first surfaced?
I will keep experimenting with solutions but any help is appreciated.