I have tested solar node’s with both ESP32 and RAK5005 with NRF52.
My experience is that when an unprotected li-ion cel was totally discharged the node did not come back after the solar panel charged the battery again.
This may be normal behaviour when charging and the cel-voltage slowly rises, the ESP or NRF will not start normally and comes in an undefined state. Because the processors auto-reset function cannot handle this slowly rising voltage.
At least that is my experience with normal unprotected li-ion 18650 cells.
I did not test this with a protected cel.
Does anyone have tested a solar node with protected cells ?
I wonder after a shutoff at 2.5 V due to darkness/bad weather etc , when the sun shines again and the protected cell ‘suddenly’ comes to live again, would this be good enough to let the solar node startup normally?
I guess it may depend on the kind of protection circuit and the brand of the battery. I do not own any protected li-ion cell so cannot test this case.
I don’t think the protected lion makes any difference, the protection circuit it’s built in on may boards, es. t-beam. I think the esp it’s powering up whit a low voltage ad dose not weok properly.
I did some testing earlier with TBeams as I was worried that my Li-ion 18650-cells get deep-discharged and found out that there are at least 1.2-version some definitions set up not correctly see:
You need to fix this and additionally set up the sds_secs to some reasonable value instead of default of one year. In my tests I set it to 1800 seconds and this means that TBeam wakes up after 1800 secs and checks if battery has been charged, otherwise it will deep-sleep again. Deep-sleep has very low power consumption so the likelihood of deep-discharge is low.
So you are saying that it is not a hardware issue but a software issue (bug?) that makes it nescessary to reset or push a button to restart the node ?
Have someone tried to disable this ‘protection’ feature in the software?
It would be interesting to test a solar powered node with protected li-ion battery without this deep-sleep feature.
Looking at the numbers:
Minimum working voltages:
For an ESP32 is about 2.2V.
For an NRF52 i found in the datasheet a working voltage of 1.7V upto 3.6V (3V nominal).
Most LoRa modules need a minimum of 2.2V to work properly.
GPS modules may be more troublesome as they are specified to work at 2.7V minimum.
Looks like a meshtastic device without GPS, will work reliable down to 2.5V.
The cut-off voltage of a protection circuit is usually 2.5V.
So having a buggy software protection for a normal li-ion cel that needs a reset after power is applied again is not as good as a real hardware li-ion protection circuit that will reboot properly.
Maybe there should be a possibility to choose between deepsleep (for unprotected cells) and no deepsleep at all with hardware protected cells.
I think that with hardware protected cells there will be no need to reset or push the menu button after a critical voltage outage of the rechargable battery when the solar panel charges the cell again.
Last month, I designed the 12V Battery Docker for my Station G1, thus I went to familiarize myself with some information on battery protection circuits.
For my design, the battery protection circuit is implemented in the mark box 4. It is designed based on XB3303A. This protection IC will disconnect the battery when its voltage lower than 2.4V and reconnected the battery when its voltage higher than 3V. Just like you described in the first post, the battery with protection IC will not back to work slowly, could be one of the reason that reboot the MCU successfully.
I found a solution for at least version 1.2 ( did not try version 1.3 yet) on the discord solary-panel channel.
So trying this command out meshtastic --set sds_secs to 1800 and see if my RAK node continue after a deepsleep shutoff.
If not satisfactory I will try something with a protection circuit but I realize that just using a protected cel will not help. The protection circuit needs to disconnect the load/node from the battery while the charging circuit is connected to the battery directly. The RAK hardware does not facilitate this.
The solution , i think, will be to use a li-ion cel with a separate protection circuit which can shutoff the node and then use a different separate charging board (tp4056 type) to charge the battery directly so the node does not see the chargingcircuit. The solar panel is then connected to this separate charging board leaving the solar connector on the RAK board empty.
There should be a voltage detector chip out there which can be used to turn the power off when the battery voltage is below a set value and turns it back on when it is above that value.
I did a lot of testing on solar powered ESP modules and designed a few boards but it has been a few years. A good LDO with a shut off pin and voltage detector are at the top of my list for any solar powered ESPs.
From a hardware perspective t-beam will reset and come back online when the battery is about 3.3v. I am using my own code not meshtastic. Every few months my t-beam gets hung up not in deep sleep. Its takes a week or two for the battery to discharge to a level where esp32 cant run, obviously solar is still working at this point but battery is discharging faster than solar can charge it. I believe the axp192 pmic has some influence on this and cuts power to esp32 and then restores it when battery voltage is high enough again. Esp32 resets and my code runs again.
Without a pmic maybe a protected battery would be better. Or maybe not, protected cells cut off around 2.8v and esp32 may well not work at that voltage so may get stuck in a boot loop from brownout detection, the same would be true for unprotected cell. This may use power and if solar is not strong enough it may never recover. Answer being to get a better solar panel.
This behavior is built into the power management chip on the tbeam and can’t be fixed in software, you have to manually power the device back up, it will not automatically power up over USB.
I have bought some T-Beams and are planing to place it at different location.
To always climb on the roof or the hill nearby is not the best solution.
Does anyone have found a workaround, maybe with an additional circuit that can trigger the power button if voltage comes back and device is still down?
Especially in winter times it it very hard to predict how many battery cells and solar power is needed to stay online.