MJS2020: Handle low power shutdown and recovery when on solar

[matthijskooijman]

When on solar and the battery runs out, the board will probably shut down. When the sun returns and there is some solar power available again, there must be some way to recover. Without any special handling, the regular firmware startup (including measuring stuff) will probably draw so much current that the board resets right away and keeps running into some reset loop, never allowing it to start up properly again.

Some ingredients that could be used to handle this situation:

• Enable the brownout detector to shut down the MCU properly when VCC is too low. If this has sufficient hysteresis, this might help to do a bit of charging before turning on again. OTOH, this only works when the battery voltage and brownout threshold is < 3.0V (because this is after the 3.0V regulator), which is probably only minimal charge for NiMh and below the cut-off voltage for LiPo.
• As one of the first things in startup, the LoRa transceiver should probably be put into sleep mode. Without that, it consumes 3mA after reset. If the power usage is lower in reset, we should probably add a pulldown on the transceiver reset line so power usage is minimal during reset.
• Maybe we could configure the option bytes to start up at a lower CPU frequency to save power? (Or do that early in startup? Might not be worthwhile, though). Then, measure battery voltage and only if that is high enough, switch to a higher frequency. Alternatively, just go to sleep when the battery voltage is too low. One challenge is that "low voltage" might be different for LiPo and NiMH? Also, how accurate is the battery voltage measurement when charging?
• Another approach is to ensure we never go too low, i.e. when the battery voltage is getting low, stop measuring air quality (and when it gets even lower, stop measuring and sending at all) and/or sleep more often. We already had this in mind, so this might be the best guard against failure.

[matthijskooijman]

Brownout detector

We could use the BOR in the highest voltage range:

This means it will assert reset when the voltage is below 2.8V (typical) and release reset when the voltage is about 2.9V (typical). Worst-case release voltage is 2.95V. This must not be too close to 3.0V, in case of inaccuracies on the regulator, but the regulator is specified to have a max deviation of 1.5%, so 3.0V × 1.5% = 45mV, so regulator output is at least 2.955V, so that should always be enough to release the BOR under all normal circumstances. There is one caveat, though: If the supply voltage momentarily drops, the BOR might trigger. The previous values suggest that in worst case conditions, there is only room for 5mV drop. If I read the datasheet correctly, this would be the "Load regulation" figure, which is max 50mV over the entire temperature range. So maybe the largest BOR threshold is too high? One step lower is 2.55V/2.66V, which might be too low?

Reset current usage

I also checked the power usage of the SX1262 module when in reset, which is about 400μA. Since that is way less than the 3mA it takes directly after reset in idle mode, it probably is a good idea to add a pulldown to the SX1262 reset line, so that when the MCU is in reset (e.g. brown-out reset), the current usage of the SX126x is limited too. This has the disadvantage that if the MCU is reset while the SX1262 was in sleep mode, the power usage actually raises from 1μA or so to 400μA, but if the MCU is reset when the SX1262 is idle or active, it drops significantly (and it seems more likely that BOR is triggered when the transceiver is active than sleeping).

Additionally, the MCU in reset takes a about 500μA. This means that during BOR, the total current is about 0,9mA, which is still quite significant, but also about equal to the average active current. This does mean that the BOR does not protect the battery from being completely drained (so in practice, during a dark period, NiMH batteries will probably be quite deeply drained, and a LiPo will probably end up being cut off by the protection circuit, maybe even before the BOR triggers because typical cut-off voltage seem to be between 3.0V and 3.3V or so).

[matthijskooijman]

I have enabled the BOR at 3.0V on my board, let's see if that runs stable or is prone to reset.

[matthijskooijman]

it probably is a good idea to add a pulldown to the SX1262 reset line,

Bad idea after all. The internal pullup on the reset line is 50k, so the pulldown should be <= 10k or so, which means an additional 300μA draw to keep the reset line high (i.e. during sleep).

One can imagine an approach with a FET instead of a pulldown with a (big) pullup on the gate (and connecting the gate to the MCU), but to prevent additional complexity, we'll just leave things unchanged for now. Once we figure out how to properly handle startup from low battery (if that's feasible at all), we can see if additional complexity is needed here. Proto3 will have a series resistor in the reset line, which can be removed to insert another circuit during experimentation.

[Peter-dM]

Pull request issued: This implements/improves item 4 of Matthijs' comment of 8 Dec. 2020. Battery voltage lower threshold is set to 3.4 V. Maybe for a v4-v5 station this can be lower. Also different settings for PM and GPS could be considered. During GPS-fix, the battery voltage is now continuously monitored. The GPS-fix is abandoned as soon as the battery voltage gets too low. PM measurement is skipped when the battery voltage is too low. Station is now reporting the lowest battery voltage that has occurred during the measurement cycle. Power return should cause no power hick-ups/oscillations anymore. Battery too low is now indicated by sending GPS position (-1,-1). Solar panel support for v1-v3 boards added, requiring addition of 2 extra resistors and a diode..