5
\$\begingroup\$

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?

\$\endgroup\$
10
  • \$\begingroup\$ I dont think you will find any thing that will just plug in, but you always can hack an old MicroSD, rip out the internals and attach a flat conductors to break out the pins. \$\endgroup\$
    – jsolarski
    Mar 3, 2011 at 7:20
  • 1
    \$\begingroup\$ Though I did find this uSD Extender. \$\endgroup\$
    – BobC
    Mar 3, 2011 at 7:54
  • 1
    \$\begingroup\$ And this for only $5.71! \$\endgroup\$
    – BobC
    Mar 3, 2011 at 9:35
  • 3
    \$\begingroup\$ @BobC - Reading the product page, it appears to claim that the device buffers the data to internal Flash. In any case, you should probably contact the manufacturer and complain that it's missing. A uSD card should write more than fast enough to capture the 512 Hz data. There's no reason for gaps at those write speeds. \$\endgroup\$ Mar 3, 2011 at 14:17
  • 3
    \$\begingroup\$ If you're gonna bother with everything involved in buffering the writes, just finish the job and build your own datalogger. It'll probably be easier. \$\endgroup\$ Mar 4, 2011 at 8:08

4 Answers 4

6
\$\begingroup\$

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.
\$\endgroup\$
1
  • \$\begingroup\$ I'm running bleeding-edge firmware (I'm testing pre-release candidates), and am pushing GCDC hard to let me into their source tree. The 8051 processor is from Silicon Labs, which is powerful but has very little RAM. Unfortunately it is a uBGA package, and is well beyond my home soldering capabilities. This work is for a hobby project that may eventually yield revenue, but is presently budget-limited, so new hardware isn't planned. \$\endgroup\$
    – BobC
    Mar 5, 2011 at 15:26
2
\$\begingroup\$

There are more accelerometer + SD card fish in the sea:

If yours doesn't work properly, get your money back.

That said, the SD should buffer writes. It sounds like their FAT library is flushing the file after every write. It would be interesting to fix if they provide you the source code to their firmware. Otherwise, you're starting from scratch and you'd be better off with your own hardware too.

\$\endgroup\$
0
\$\begingroup\$

An option is to just solder off the connector and add wires instead. You can wire it to another board directly or go through another board that has both the connector and connectors you can connect the buffer to.

\$\endgroup\$
0
\$\begingroup\$

I would suggest use a MSP430** to do the buffering. Use something like this to interface the uC. Depending on how you implement the buffer in the software, this article may be useful.

**personal preference but any micro controller could work.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.