Prev: Quotation of the day...
Next: Capacitance versus voltage for X7S caps?
From: D Yuniskis on 24 Mar 2010 16:13
Silvar Beitel wrote:
> On Mar 24, 2:16 pm, D Yuniskis <not.going.to...(a)seen.com> wrote:
>> Hi Silvar,
>>
>> Silvar Beitel wrote:
>>> Custom datalogger circuit using SD card, running on switched
>>> automotive power.
>>> It's cheerfully writing data to the card and the power quits (user
>>> turns key off, accidently pulls off power connector, engine stalls,
>>> car crashes, whatever - this could even be the preferred method for
>>> stopping it if it's robust). Up to three blocks worth of cached data
>>> need to be saved in the card (data block, FAT block, block w/
>>> directory entry) before the system can die cleanly.
>> 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 (?)
>
> 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.

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.

>>> Easy solution if there's a connection to unswitched (battery) power
>>> too, but that makes using the device as a consumer plug-in impossible.
>>> So, you need some short-term energy storage. Choices, as I see it:
>>> 1) Batteries. You'd need some circuitry to keep them from discharging
>>> after power-down. Expensive unless heavy (some cellphone-like thing
>>> vs AA's, for instance), requires user replacement occasionally.
>>> 2) Super-capacitor. Enough energy storage to do the job for a
>>> reasonable volume and cost, but poor ESR - may not be good enough to
>>> hold the supply voltage up above minimum required by SD card.
>>> 3) Standard electrolytics. Good ESR, but physically big ones required
>>> to supply enough power over required shutdown (SD card block write x
>>> 3) time.
>> 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".
>
> 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.

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.

>> 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.
>
> 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.

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.
From: Jan Panteltje on 24 Mar 2010 16:11
On a sunny day (Wed, 24 Mar 2010 11:50:35 -0700 (PDT)) it happened Silvar
Beitel <silverbeetle(a)net1plus.com> wrote in
<784b3f76-2c07-4330-8169-c1d1d9a0520b(a)x12g2000yqx.googlegroups.com>:

>Custom datalogger circuit using SD card, running on switched
>automotive power.

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

From: Vladimir Vassilevsky on 24 Mar 2010 16:18


Silvar Beitel wrote:
> On Mar 24, 2:17 pm, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote:
>
>>Silvar Beitel wrote:
>>
>>>Custom datalogger circuit using SD card, running on switched
>>>automotive power.
>>
>>>It's cheerfully writing data to the card and the power quits (user
>>>turns key off, accidently pulls off power connector, engine stalls,
>>>car crashes, whatever - this could even be the preferred method for
>>>stopping it if it's robust). Up to three blocks worth of cached data
>>>need to be saved in the card (data block, FAT block, block w/
>>>directory entry) before the system can die cleanly.
>>
>>>Easy solution if there's a connection to unswitched (battery) power
>>>too, but that makes using the device as a consumer plug-in impossible.
>>
>>>So, you need some short-term energy storage. Choices, as I see it:
>>
>>>1) Batteries.
>>>2) Super-capacitor.
>>>3) Standard electrolytics.
>>
>>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.
>
>
> I've managed to figure that out myself, thus the question about *how*
> to do it :-) I do appreciate your response, Vladimir.

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

>>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.
>
>
> 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.

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

>>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.
>
>
> Thanks. How does a $50K retainer up front sound to you?

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
http://www.abvolt.com
From: whit3rd on 24 Mar 2010 16:32
On Mar 24, 11:50 am, Silvar Beitel <silverbee...(a)net1plus.com> wrote:
> Custom datalogger circuit using SD card, running on switched
> automotive power.
>
> It's cheerfully writing data to the card and the power quits
>... Up to three blocks worth of cached data
> need to be saved

> So, you need some short-term energy storage.  Choices, as I see it:
>
> 1) Batteries.  You'd need some circuitry to keep them from discharging
> after power-down.  Expensive unless heavy (some cellphone-like thing
> vs AA's, for instance), requires user replacement occasionally.

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

> 2) Super-capacitor.  Enough energy storage to do the job for a
> reasonable volume and cost, but poor ESR - may not be good enough to
> hold the supply voltage up above minimum required by SD card.

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

> 3) Standard electrolytics.  Good ESR, but physically big ones required

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.
From: Falk Willberg on 24 Mar 2010 17:05
Am 24.03.2010 19:50, schrieb Silvar Beitel:
> Custom datalogger circuit using SD card, running on switched
> automotive power.
>
> It's cheerfully writing data to the card and the power quits

Common scenario so far ;-)

....
> Up to three blocks worth of cached data
> need to be saved in the card (data block, FAT block, block w/
> directory entry) before the system can die cleanly.

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?...

> Looking for guidance from anyone who's familiar with flash cards and
> powering (and unpowering!) devices that use them in automotive
> applications.

You found one more: me ;-)

Falk
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Quotation of the day...
Next: Capacitance versus voltage for X7S caps?