I’ve seen a few threads talking about particular battery models, problems with drainage while off, and one discussing ways to extend battery life - but nothing I can see with empirical measurements.
I’ve got an A-06 here, which has just finished a video playback test - a standard definition video playing in VLC, all settings at default, on a loop until the DevTerm switches off - at 3 hours 49 minutes.
Is that roughly what other people are seeing, in terms of battery life? Can anyone with an A-04 or CM3 model share the results of a similar test, for comparison?
Do you also see the battery drain while the DevTerm is off? I haven’t received my A6 yet, but it seems like a common problem and I haven’t seen any official response to it.
Also, might be good to mention what brand/style/capacity of batteries you’re using. I’m guessing the only way we’ll ever get any good info about proper batteries is if someone creates a spreadsheet and we crowdsource it with observed data. Some batteries will likely stand out as particularly good, while others will probably be obviously less good. And it might make it easier to estimate how battery capacity translates to uptime for the DevTerm (though specific model and performance settings would need to be listed too).
Haven’t tested that yet - I only finished building it on Sunday. I know it definitely doesn’t draw power from the mains while off-and-charged - I’ve got it hooked up to a bench-top power supply.
Flat-top li-ions, claimed at 3,400mAh each. “LCLEBM” brand, which… is neither a word nor a brand, so I’m guessing they’re something generic underneath the colourful wrap.
EDIT:
As an additional data point, it took 2h18 for the batteries to charge from empty in the DevTerm.
Mine doesn’t draw when it’s really off. But if I start the DevTerm, and then shut it off (using soft power button, or holding down the power button to force the power off) I do get a constant drain.
I have the CM3 model, so it would be great if you could confirm that the A06 doesn’t do this.
I’ve seen a couple of other mentions of similar behaviour on the forum. So, some testing:
shutdown -h now - No real power draw (0.001A)
Power button, click Shut Down - No real power draw (0.001A)
Power button, hold for ~20s to cut the power - 0.114A power draw dropping to 0.106A after a few seconds.
On the latter front, the power actually gets cut at around 10s with no change in behaviour whether I continue to hold for the full 20 seconds or not; once cut, there’s a really audible coil whine, suggesting something’s being phantom-powered. That could account for the drain-while-off people are seeing.
If I power the device back on again, the coil whine increases in volume and begins wavering - suggesting active use - then suddenly silences. Behaviour after power-on appears normal, and a soft shutdown returns it to zero power draw again.
Looks like there’s a flaw in the force-power-off functionality, but at least it doesn’t seem to get triggered if I shut down normally!
If I had to guess - and it’s just a guess, I haven’t had a look at the schematics and probably wouldn’t understand them if I did - the “force power off” is cutting the power somewhere along the way but not informing whatever’s on the other side that it’s doing so. As a result, the thing on the other side is attempting to continue to draw power - and finding it from an unexpected source.
I’ve seen similar in the Raspberry Pi PoE+ HAT: if you connect it to both USB and PoE at the same time (for some reason), you get a ridiculous coil whine because they forgot to include the thing from the reference design that disconnects one power type when the other’s connected so power goes somewhere it’s not expected.
Tracking it down will require staring at the schematics and/or prodding things with a multimeter - but it’s certainly reproducible: hook the DevTerm up to a bench supply (or any supply that lets you monitor the current draw), let it fully charge, turn it on, force power it off - and watch the amperage fail to go below 0.1A.
It should not be the case. All power rails are generated by the AXP228, and nothing else is directly connected to VBUS from the USB and VBAT from the battery.
The wining is probably caused by L101 when the battery is being charged and the system is off, as the AXP228 is trying to balance how much current from the USB cable goes between charging the battery and the running system.
It is common for inductance to produce a high pitch noise, and as annoying as it can be, this is most of the case not a sign of a problem in the device itself, just that the wire are slightly moving with the frequency used by the DC2DC module.
Though, I would recommend to NOT use the emergency shut off for now until I clarified something. The AXP228 is somewhat poorly documented and this is something that do bother me:
When you push-and-hold PEK longer than IRQLEVEL, HOST can write “1” into“REG32H [7]” to inform AXP228 to shutdown, which can disable all power output except LDO1.
Pico-8 at 100% results in an 80% load on the 1st gear. It’s technically ok but as soon as you want to also use a browser or something the system gets super sluggish. 2nd gear feels like the appropriate gear for Pico-8 development to me.