Handling battery decay and shutdown.

I see that you implemented a < 2.5 V battery light. I think that is good. I cannot test that right now, because my battery is way lower than that.

Instead I tested what happens if you suck the battery completely dry. See attached graph. It shuts completely down in uncontrolled fashion, at around 1.95 V, which happened while I was operating manually, a few seconds after the last run completed, guessing about 1.95 V.

In order to prevent failure during for example flash writing of user SAVE, I think we need to shut it down earlier, in an orderly fashion, at a particular voltage, I think 2.0 V is a round figure close to the limit, which still gives a couple of minutes of operation before crash. 2.1 V could be unnecessarily high, but possibly safer.

The method of getting the graph was to do BATT? every 0.45 seconds, for 400 samples per 180 s run, and I did runs until it crashed. Yesterday, doing a similar run, I got DMCP crashes doing the same thing (Hang detection, Reg Id d3770002, fw 3.19). I am not letting you know to solve a DMCP crash, but I am just saying that very very low battery does not orderly shut down, and could result in corrupt data (my opinion, not fact).

Battery_decay

The first graph is correct time wise. With the remaining three graphs I adjusted the times on the later two traces to display the similar runs vertically, so the note the time stamps of the the orange and green traces are adjusted and false.

Edited Aug 01, 2020 by Jaco
Assignee Loading
Time tracking Loading