You will definitely want to choose a standard network layer. I've seen some cases where people have rolled their own, and frequently the protocol is inefficient, and in the end it's a waste of time. A proven network layer provides basic functionality to solve most of the problems you'll likely face in networking with an embedded device, and that will save you precious time and money in the end.
I have familiarity with CANopen, so I'll put a bit of an explanation in here and it might help you decide if that's the way you want to go. If it doesn't fit what you need to do, I'd look at something else.
CANopen is very data centric. All CANopen slave nodes (things you control from a master node, like sensors or motor drivers) provide a dictionary that contains all configuration, control and data-acquisition data you need to read/write to get your job done. You can then read/write these objects individually via the SDO (service data object) mechanism, or read/write these objects periodically in timed CAN message transmissions via the PDO (producer data object) mechanism. Startup, shutdown, and reset, and heartbeat/node-malfunction detection are provided from NMT services, as well as a node ID assignment service (if you wish to use it). To implement a device using an embedded CANOpen library, you basically setup an object dictionary, setup PDOs to periodically send/receive data updates, and write user code that behaves based on those data entries. There are other things CANopen provides, but that is the bulk of it. Read this book for more info.
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.
Best Answer
This is sort of a shopping question, but I'll try to approach it as if you asked about what to look for in a datalogger for CAN networks.
You'll want a way to store the data, and SD/micro-SD cards are great for this. Most modern dev kits will use a micro SD card to save space.
Compressing the data requires that you have enough RAM to record a decent sized buffer of data, and that you have a fast/powerful enough processor for the task. A 32-bit micro will be good, as most compression algorithms are written for processors which can handle 32-bit words in a single instruction. You'd have at least a 4x slow-down with an 8-bit controller. I'm not sure what level of compression you want, so it's hard to say what will be acceptable. Uncompressed, 1Mbit/s would fill a 2GB SD card (the largest you can go without using SDHC, which is harder) in about 22 minutes.
You'll want a way to get the data off the datalogger. Unplugging the SD card reader is a possibility, but you'll probably want to use serial, USB, or Ethernet so that you don't wear out (or loose) the card and so that you can read data off of the card while still logging so you can have an unlimited stream of data.
I'd recommend the TI/Stellaris LM3S8962 Evaluation Kit: it has both integrated CAN and a micro-SD card, and uses a Cortex-M3 (32-bit) microcontroller running at 50MHz. It also has Ethernet and USB connectivity to offload the data. You might use the daughter board for testing, and you might use the display to indicate how full the card is. It's $90, which is reasonable for what you get in the package. You can probably get it cheaper with a board designed for logging, but that will likely take you down to 8-bit microcontrollers (making compression hard) and CAN over an external transceiver that you'll have to add on.