Automotive datalogger power(down) supply strategy

Presumably, that is because you "just" want the user to (later) plug the SD card into a "PC" and read an intact filesystem? (i.e., you aren't planning on having any "special" application that can read the card *specifically*). Otherwise, you could just update the data in an "expected" manner and have that special application find it and respond accordingly (e.g., even "fixing up" the SD card to make everything look like a typical filesystem). Cuts this down to a single block update (?)

All of the above will *eventually* screw the user (e.g., what if the flash write fails and has to be retried? What if the user has forgotten to replace the battery?) When that happens, your device "looks bad". OTOH:

4) You tell user he has to *do* something before removing the device. E.g., just like you have to tell your "PC" that you want to unmount the volume. (i.e., what happens if he removes the SD card from your device while the device is operating??)

In that case, if the device misbehaves, it is because of an action on the user's part -- something *he* can control.

After the power fault is detected, you will need to stay up for at least

100ms (likely 500ms or so); that's substantial amount of energy. 4) Journaling fail-safe filesystem and/or RAID-like arrangement. 5) Keep the most critical data in autostore nvRAM or FeRAM. 6) Run checkdisk at system startup.

7) All of the above.

That's no simple problem. I have experience with flash cards and automotive controllers; If you are interested in my services, the contact is at the web site.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Excellent observation. "Special" application to read the card would be OK, narrowing down the write to a single block (that is in fact what is happening in the prototype - real file system support within the unit is "on the table".) But even that one-block write consumes some significant juice.

I only see 1) as having an issue, if 2) or 3) would be designed robust enough to ensure that the card ends up being consistent upon shutdown.

Good. If it were that kind of device and there was some form of communication to the user. In this case, it's a (cheap, invisible) datalogger, with little (OK, no) user interface. Or at least that's the way I/they want it to be.

-- Silvar Beitel

I've managed to figure that out myself, thus the question about *how* to do it :-) I do appreciate your response, Vladimir.

I'm hoping that these things are unnecessary in a typical micro, flash- storage, simple I/O type of datalogging gadget/accessory, but I will consider including them as needed - and as costs allow.

Thanks. How does a $50K retainer up front sound to you?

On a sunny day (Wed, 24 Mar 2010 11:50:35 -0700 (PDT)) it happened Silvar Beitel wrote in :

What would be useful information is:

1) How much time do you need. 2) What current do you need. 3) What minimum voltage do you need.

Beep

Your application can then "fix" the data that it "discovers" so that, subsequently, the user can just see it as "yet another file" (instead of scribbled marks "outside" the filesystem). If the user opts, instead, to mount the card and go looking for the file, that last bit of data will be missing. As long as he doesn't alter the file system *while* it is thusly mounted, he can later recover it by running your application.

Note that your application doesn't have to be a "data recovery application". Rather, it can be a "data viewer" -- that also happens to recover data as a side-effect.

You size your supercap/ecap to handle 3+e block writes. What if some number of those writes *fail* and have to be re-erased and retried? I.e., you will pick "e" to either allow some (fixed!) number of retries *or* you will allow *no* retries -- i.e., the user is eventually screwed.

No indicator lights? No buttons?

Tell user the most recent "half second (or whatever)" of data will *not* be stored. A discriminating user will then wait half a second longer than "necessary" before removing the device.

At *some* point, you are going to lose data. I.e. WHILE the user is removing the device and the contacts (with the "field") are making and breaking intermittently, surely *that* data is unrecoverable (?)

Just define the conditions under which the user can expect data to be available in such a way that he can plan accordingly.

Did you put the card reset and wake up time into equation?

Well, well. We Russians say: "Hope is something that dies last"

I take this remark as $50K is a big deal for you.

BTW, as a matter of business principle, I never charge anything upfront.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

There are rechargeable Li batteries, coin-size, that might do.

Bad idea. Low-voltage and it droops, and output impedance might be an issue.

OK, how about

4) write bursts. Most of the time, the data being logged is going to the little RAM buffer; only write the flash at 30-second intervals. That gives you 29 seconds during which shutdown doesn't invalidate the process. Use the fastest write mechanism available. 5) circular buffering. Preallocated file space is arranged in hundreds of records, each having a serial number and checksum. You always write the new record over the oldest, and the invalidity of an interrupted record just means it has a bad checksum, so should be discarded. The file allocation never changes, so never has to be rewritten; the file content just doesn't 'start' at time zero, you ave to scan it for the embedded serial info.

Am 24.03.2010 19:50, schrieb Silvar Beitel:

Common scenario so far ;-)

...

Do you *really* need a file system? I a similiar case I wrote raw data to the SD-card. A power cut at the wrong time would cause a loss of 512 bytes only. Guaranteed.

The PC-application reading the data is quite simple.

...

What will happen, when power comes back? Write the possibly damaged data again? Start from the beginning?...

You found one more: me ;-)

Falk

Since a special app to read the card is OK you could treat the SD card has one big circular buffer. This becomes trivial if the data to be logged is some fixed size. Include a time stamp and perhaps some form of checksum with the data. On power up read the SD card entries and find the one with the newest date. The next entry is your current write point. Just keep the write pointer in ram, no need to update the SD card since you can always figure out the write point from the time stamp. If the power fails and the write fails the crc will be bad and the PC can detect this as well as your startup code. Your init code will need to handle the case where you have a new SD card with a fat file system or other unknown data on it and take necessary steps to initialize the card to some known state for the circular buf.

[snip]

--
Joe Chisolm
Marble Falls, Tx.

Well, no you don't! :-)

Thanks for all the ideas. Taken together, a solution.

1) I don't absolutely have to have all the records up to the last second, so a few corrupted or missing ones at the end is OK.

2) Along with an index number (in this case, time is an integral part of the record so I can use that), inclusion of a check-sum or other verification field can be used to find the end of good data (or at least *an* end of good data, which is OK).

3) File system isn't absolutely necessary, but the above works with or without one (I can pre-force the file size).

So now the thing doesn't need auxiliary power at all, a nice cost savings. The startup code (and PC reader code) can use the same mechanism for finding the end of stored data so that data logging can continue when power returns (vehicle on - data logging, vehicle off - not) and that happens automagically to the user.

(I don't really need a circular buffer - I'm not expecting any data logging session to overflow the capacity of, say, a 1 GB SD card.)

Thanks again.

-- Silvar Beitel