Electronic – RAM device that plugs into microSD slot

buffermicrosdram

I have a pair of small battery-operated self-logging 3-axis accelerometer devices that each use a microSD flash device for storage (the GCDC X250-2). Unfortunately, the devices do not buffer microSD writes, so the recorded data has frequent gaps.

I would like to find/create a portable device that has a cable that plugs into a microSD slot, and connects to a large ram cache, so writes can proceed without delay. Ideally, this device would spool to an SD card or other permanent storage.

There are many microcontrollers available that can talk to the SPI bus, simulate an SD card, and write data to RAM. It should also be possible to program a small Linux PC to do this, effectively emulating an SD card. The problem is finding a cable or something that can plug into a microSD slot!

Any ideas for a complete system, or the components needed to build one?

Best Answer

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.