Strategies to deal with unpredictable power supply

Question

I want to install a Pi in my car and use it to record GPS data. What strategies (in my program) can I follow to minimize problems due to power being interrupted when writing to the SD card?

So far I can think of:

• Storing data and only writing intermittently
• Only writing when vehicle speed is not close to zero (i.e. about to turn off ignition)
• Write to a temp file which I can afford to have corrupted, then persist that every now and then

I'm wondering whether there are

• Filesystem modes I can stay in most of the time that would survive a sudden shutdown
• Ways to make recovery from power down while writing more dependable

Obviously (I think) some data loss is unavoidable, but how could I minimize it?

Answer 1

There are two options (at least) on the supply side:

• Many cars now have an accessory socket that is not switched by ignition... if your car has one, use that (but be careful to unplug when not in use!) which should give you a reliable supply (although this may drop during engine cranking)
• If you are designing your own power converter, add a big enough reservoir capacitor to ensure that the supply stays up long enough after vehicle switch off... you could also detect vehicle off (vehicle supply falls below a threshold) to a GPIO, to ensure you do not start writing after power-off

Answer 2

There is a concept in Windows Embedded called Enhanced Write Filters. They use it to avoid corrupting loss of data due to loss of power etc. The OS writes it to a RAM overlay. The file system is not corrupted when there is a loss of power and you can "commit" the data to the memory only if you desire.

Likewise, on Linux operating systems, there is a technique to keep the file system intact and you can write to the SD card only if you desire. This question explains how to build a read only file system and you can save the changes only if you desire. This means you would using your option 3: " Write to a temp file and persist when necessary". The question also points to an article " How to build a read only file system". Perhaps, that might be the first place to start!

Answer 3

It all depends on the amount of data you are prepared to loose. If you cannot afford to loose anything, it will require that you find a way to connect your PI directly to the battery (with a fuse of course), so that it is not turned off when the ignition is turned off.

Then again, a typical car battery would have around 80 Ah and the PI will consume between 500-1200 mA (depending on if it is a model A or B), so that will probably drain your car battery in between 2 and 6 days, so I don't think you will find this acceptable.

If you still cannot afford to loose data you might be able to design some kind of custom hardware where you can control the power supply from the PI and also monitor the state of the ignition. If the ignition is turned off, you flush your data to the SD-card, shutdown the OS and then as last step turn off the power supply. The power supply also needs to be turned on when the ignition is turned on, to let the PI start again. This is all doable, but quite a large project.

However, if you find it acceptable to loose some data at shutdown, I would design the daemon that saves the GPS data periodically to a file in such a way that it executes an fsync call after each write (to flush the data to the SD-card). If you do this every few seconds (and are also using the default journaling ext4 file system) this would probably mean that you will only loose the last few seconds at each power loss.

Please keep in mind that Raspbian (at least my installation) did not come with an fsck of the root file system at boot time. You have to do the following to enable it at every mount:

tune2fs -c 1 /dev/mmcblk0p2

You also have to change the last line for the root file system in /etc/fstab to contain a 1, like this:

/dev/mmcblk0p2  /               ext4    defaults,noatime,commit=120  0       1
                                                               Change this ^^^^^

If you don't do this then your root file system might not be bootable from time to time, so if you are running a headless system where you turn off the power without doing a controlled shutdown, this is absolutely necessary.

Answer 4

This looks like a good addition that will nicely sanitise the car electrics for the pi, and handle detecting loss of car ignition, supply the pi with power in the meantime, and send a signal to the GPIO pin to tell it to shutdown the pi safely.

Unfortunately seems to be out of stock at the moment, but you can pre-order.

Answer 5

If you must deal with losing power often, careful choice of filesystem and boot methods (read-only, journal, unattended fsck, quick recovery..) might help make sure the system comes up reliably.

On the application side, using certain databases (sqlite?) should guarantee a whole write or no write status on the data when re-opened.

Better would indeed be to try to avoid having to shut down except when necessary. With a smaller controller, you often watch the power supply and if it goes down, you have a small window to shut down things, save any nonvolatile data and possibly sleep or stop the processor until power is restored. With a big general purpose processor like the PI, that might require a pretty long gap.

So, having an on-line power reserve and a warning when the main supply goes down might help. If it's glitchy, you may need to differentiate between temporary power loss (don't write, hold your breath) and probable shutdown (save and clean up).

In a car you'll have +12/24 V and PI uses +5 V, so there is potential (heh) for something in or before the converter. You might be able to diode-OR another reasonably sized 9-12 V battery before the converter that will take over when voltage drops, for example. Considering the relatively heavy power draw, that'll need to be kept charged somehow. You might also be able to rig a comparator or a special voltage monitor for the main power line and get alerted when main power is down. (I don't know offhand what would be a fast way to signal a PI.)