Open geeksville opened 1 month ago
I built one node with a small solar enclosure from RAK. (Unify Enclosure Solar IP65 100x75x38)
I was concerned that this battery could run flat. I made a quick-and-dirty modification to the firmware to add some level of software protection.
In essence:
delay()
30 minutes, then rebootThis current draw in this pseudo deep-sleep state is very good; a few µA from memory? However, below a certain voltage, I believe the buck converter on the RAK19007 baseboard switches to a linear mode. Between a certain voltage range (3.5V down to 3.3V?) the current is higher; almost 1mA at worst.
Even in this 1mA region, the current is low enough to protect the battery from many days of poor weather. Despite the small battery, I haven't actually had this happen yet since deployment, although it worked very well in testing.
The pseudo deep-sleep state is the same one used with NRF52 tracker and sensor roles, however the current draw in those cases (after normal use, instead of early in boot) is higher (~1mA, even with good voltage). I suspect some piece of hardware isn't shutting down perfectly, but I couldn't identify exactly what.
This doesn't entirely fix the situation, but I found it to help in my specific use case. I'm not sure whether something like this would be suitable for general use though.
see related comments here: https://github.com/meshtastic/firmware/pull/2040 (btw: I think some of the comments in this issue misunderstood how nrf52840 treats 'shutdown mode'.
Progress notes (mostly for future searchers/reference on state of power as of today):
Power consumption in system off (with the fixes I'll be submitting) is excellent when the battery voltage is at 3.7V. It is drawing only 5uA which is almost the optimal possible per datasheet.
Fine - same as above.
Beginning to get bad but not absolutely horrible: 50uA average. Therefore if we want to shut down because of low battery (on the rak4630) we should do so at 3.5V (to stay in the realm of low current draw - the rak LDO seems to have issues at low V)
awful - the power draw is is 13mA (enormous) while in system-off-mode. Also saving our state to the filesystem when at this voltage seems to cause #4184 100% of the time. Also it is worth noting that the rak4630 datasheet specifies a minimum battery voltage of 3.3V. Which makes sense because this is their vcc regulator circuit:
Which is unfortunate because lipos will slowly fall in voltage below 3.3V. So to robustly support the rak4630 we need to make sure to shut the board down before the battery reaches that level.
system-off-mode has current draw that is way to high with the current codebase. About 2.5mA. Will eventually investigate and instrume with the PPK2 power profiler.
Notes on RAK4630 issues (only):
ooh - the rak folks populated a regulator for their 3v3 bus but the unfortunate thing is they use that regulator for all of the sources on the board. they could have instead passed the battery v straight to the cpu VDDH input (bypassing that regulator). This would have been better because a) it would the brown out detector work correctly 😉 and b) it would have allowed the cpu to keep working properly all the way down to 2.7V (well below 'min' lipo voltage). nordic designed that input to be for lipo inputs and works fine up to 4.2v (or higher - don't remember) right now I kinda bet the brownout detector is just seeing 3.3v in until suddenly it starts bouncing allover the place once we get below that. https://docs.rakwireless.com/assets/images/wisduo/rak4630-module/datasheet/schematic-2.png
(also it would have solved the problem that someone else mentioned (@markbirss ?) that when the battery is lower than about 3.4V that regulator burns an enormous amount of power)
@geeksville it was someone else but i cannot find mention, on discord group ?
added this note from a discord discussion:
(better to shut down while we still have battery than to start browning out when we can't control the shutdown process. And all bets get wonky in those super low v cases, possibly solar panel charges battery up some and the old write to meshtastic.txt (which I just removed in #4395) was highly likely to be writing when the board is coming-up then dying repeatedly when battery is below v3.3)
note to self: turn EVENT_LOW_BATTERY back on! - WIP branch is pr-fixe1000
Category
Hardware Compatibility
Hardware
All nrf52 boards
Firmware Version
master (private build)
Description
I just happened upon this code in Power.cpp:
Freezing boards is bad, but IMO it is super important to enter deep sleep anytime we are able to detect that the battery is critically low. Because to not do this will kill lipos.
I'm happy to look into this as I continue my adventure of improving nrf52 power consumtion. But opening an issue in case any of ya'll have comments on this theory?
Relevant log output
No response