MSP 430 - Ultra Low Power FRAM & SD Card Data Logging

If I were to do such a data logger, I would use the SD card without any file structure. I would consecutively write one segment (512 bytes) every 128 seconds. In between each 128 seconds, I would put the SD card to sleep and keep the data in RAM or FRAM.

There is substantial energy savings without using any file structure. Energy savings in using larger data buffer is less significant.

"Low power" and "SD-Card" are somewhat contradictory requirements - is there a specific reason to use an SD-Card?

If low power is the real key, could you use something like Atmel's DataFlash instead?

old_cow_yellow,

Thanks for the suggestion. I was thinking of using the SD card in SPI mode. If I buffer one "segment" of 512 Bytes, how do I know that that will minimize flash power usage? Also, why do you say that a larger buffer is unlikely to help? Wouldn't that greatly reduce the amount of times I have to activate the SD card?

Thanks,

Alex

It takes twice the amount of time to write two segments, three times the amount of time to write three segments, etc.

Thus the only savings of having bigger data buffer is the overhead to wake-up the SD card before you write and put it back to sleep afterwords.

old_cow_yellow said:

It takes twice the amount of time to write two segments, three times the amount of time to write three segments, etc.

But, if you wake the card up to write just 1 segment, that means you get the wakeup overhead on each and every segment write;

If you write 2 segments at once, you only get half the "wakeup overhead" per segment;

If you write 3 segments at once, you only get one third the "wakeup overhead" per segment;

etc, etc,...

But, again, why use an SD-Card when low power is a key constraint??

Yes, using bigger RAM data buffer will save the overhead of turning the SD card on and off multiple times. But the savings is not very significant.

Low power may be a key constraint, but not the only constraint. If it were the only constraint, then one should use a dead chip which consumes no power at all.

old_cow_yellow said:

Low power may be a key constraint, but not the only constraint

Indeed - that's why it's important to know why the OP specifically wants to use an SD Card.

What is the requirement that drives the choice of the SD Card? Could that requirement not be better met with another solution - thus obviating the problems inherent in an SD Card (specifically, its power consumption)?

http://www.catb.org/~esr/faqs/smart-questions.html#goal

old_cow_yellow said:

use a dead chip which consumes no power at all.

Very true!

old_cow_yellow said:

Yes, using bigger RAM data buffer will save the overhead of turning the SD card on and off multiple times. But the savings is not very significant.

And this is the reason why a file system is a bad idea if poewr is n issue: writign to a file system requires to update the file info on every write, which requires updating the directory entry (which means reading, updating, erasign and writing the data). Which takes a multiple of th etime a simple write to an empty flash segment takes.
So 'formatting' (= erasing) teh SD card before usage, and then simply write sequentially to it is by far the least.energy.consuming way.

However, powering-up an SD card does comsume some power, and indeed, grouping mroe than one write will reduce this too. However, keepign two writes too distant increases the risk of data loss if the device is powered-down between two writes.
It's everyones own choice to weight these facts accordign to the applciation.

old_cow_yellow said:

Low power may be a key constraint, but not the only constraint. If it were the only constraint, then one should use a dead chip which consumes no power at all.

P.s.: it' sgood to read you again. You've been very silent lately.

It looks like an external FRAM system is probably the best way to go. I will just have to provide a utility to get the data from the memory system.

If I decide to go with FRAM, I would need to optimize the bit storage. I could have either 10 bit or 12 bit samples. It looks like I could store the samples across the standard word boundaries (one byte) by using bit wise operations. For example, I think I could store the lower byte in the first address, and then take the upper byte and bitwise concatanate it with part of the lower byte of the next sample. This would then be stored in the second address and so on.

Does anyone have a suggestion on how to do this? I don't know if there is a term for this kind of operation. I googled "storing data across word boundaries", but I didn't find much.

Thanks,

Alex

Alex Behnaz said:

I googled "storing data across word boundaries", but I didn't find much.

However, there are two ways. You may just convert the data into a bitstream, adding bit by bit (10, 12, whatever). The receiver needs to know the size of each element and can extract it.
That's what you already figured out.

You can optimize this algorithm for 12 bit by using nibbles instead of bits. (byte 1 = lower 8 bits of vlaue 1, byte 2 = upper 4 bit of value 1 and lower 4 bits of value 2, byte 3 = upper bits of value 2)

Another approach is selective packing. 2 12 bit values are packed this way:
Byte1 = lower 8 bit of value 1, byte 2 = lower 8 bit of value 2, byte 3 0 upper 4 bits of value 1+2. This is a bit faster, as the lower bytes do not require any bit shifting.
For 10 bit values, you'd pack 4 values into 5 bytes similarly, getting the lower 8 bits of each value into separate bytes and then the upper 2 bits into a 5th byte.

If your values are left-justified (upper 12 bits of a word), then put the upper 8 bits into one byte and combine the lower 4 bits. This also has the advantage that for a rough estimation, the 8 most significant bits are already 'unpacked' in the byte stream. I think the ADC12 has such a data mode (ADC12DF=1, 2s complement data mode)