The product has a maximum update rate of 512 Hz, which is really slow. I understand that it uses a timestamp, takes three readings, buffers for FAT filesystem translation, and writes it all in ASCII/CSV format, which sounds like a lot. However, an SD card configured for sustained writing should be able to do at least 2 megabytes per second, and class 10 cards can handle 10 megabytes per second. At 512 Hz, the problem is not the SD card.
In your comment, you mentioned:
The manufacturer knows all about the
problem, and is unable to fix it with
the available hardware resources (it's
only an 8051 that's breathing really
hard). All pauses seem to be due to a)
FAT overhead, and/or b) flash erase
cycles.
Adding a buffer at the SD card is not going to solve this problem. The bottleneck is up-stream of the SD card. The manufacturer's FAQ reads:
I have an old accelerometer, can I
upgrade the firmware?
Yes. Please contact our sales
department for instructions on how to
return the unit to GCDC. We will
upgrade the firmware and return the
device promptly.
Unless you've worked out with them that they'll write you a firmware package which doesn't do any buffering/FAT filesystem translation and mutually agreed upon a protocol for a faster, gap-free data stream, adding a RAM device that plugs into an SD slot will not solve your problem.
However, just because the task is bringing their 8051 to its knees doesn't mean that this is an un-solveable problem. A faster, more powerful, more modern microcontroller could handle the data stream. The on-board RAM on a decent micro should be enough to buffer the data. Most small micros will run at 20 MHz or more, which is probably plenty fast, especially since they'll have hardware peripherals that can handle the DMA, SPI, and ADC tasks for you. Of course, there are other people who have tried to solve the same problem - Take a look at this SO question about logging data at 96kB/s.
You have a few options:
- Dead-bug a higher-performance microcontroller onto the existing PCB, and write some firmware which will handle the task. If the 8051 isn't up to it, an ATmega probably is and a Cortex-M3 certainly is. You might consider ignoring the FAT filesystem and write a simple flat file, and just emulate a USB drive with the microcontroller.
- Have the original manufacturer do this for you. I don't see any mention of this problem on the website, so they could probably be motivated to fix the problem. They have all the schematics and drivers already written, so they could probably do this without too much trouble.
- Build your own. You can have as fast an uninterrupted logging rate as you want, with as much precision as you want, with as many DOF as you want - You just have to pay for what you want. The sky is the limit on this sort of project (and the budgets reflect this). You won't get this nice a package for this much money, but I'm not sure what your requirements are.
- Buy a different one. There are plenty of dataloggers that can handle faster serial streams without gaps, and a lot of accelerometers have as fast or faster update rates. The +/-250 g and +/-28 g range on this one is unusual, however.
The "checkbusy" must send 0xFF to the SD card (that is not clear in your question). Is this SD or SDHC? The latter have some differences in initialization and operation sequences.
If we don't send dummy data after read ...
In SPI, you have to send data to be able to read from the client. Remember that the master always drives the clock line. The dummy data I send when reading SD cards is 0xFF, too.
The 512 zero bytes may be actual data from the device. Are you sure that you sent the address bytes in the correct order? The SD Simplified Specifications are available from the SD Association.
Best Answer
Don't fear the FAT. It makes your job a lot easy.
The only thing you have to do is, before you start reading values at ADC, create the FAT 16 system and a text file. Then once you start reading, simply send the data to that text as simple byte.
I have done similar thing with PIC18F458 at a clock rate of 1Kb per second. Here is a link with sample code for same controller with generation of FAT system. This helped me a lot. I hope it would help you too.
This method was best for me as all the values were written in a text file and was easy to convert it in any other format or readable for other software as MATLAB.