FIRST: take advantage of your mentors expertise

[techhelpbb]

Originally Posted by de_

I think the mentors could put together a nice inexpensive realtime datalogger that records any abnormality/exceptions during say the last 15 seconds on a flash card and has a really smart diagnostic messaging interface to monitor key system events such as high and low power exceptions to the Crio and bridge, monitor in and outbound network traffic rates and key parameters, events. The Crio could communicate with it via the network or I/O card capturing exception key events especially those that lead to the Crio doing a reboot. A $20 Arduino + a little extra hardware should be able to do it.

I'm sure that can be done. Just one point. Flash cards are relatively slow. that's why my FPGA oscilloscope I made for the robot uses computer memory (still not as fast as static RAM like that which you find inside the ATMEGA on the Arduino).

How much of a factor the storage speed effects this design will depend on the maximum samples per second you desire. If you just want say 5,000 samples a second there are existing SD memory based data loggers that can handle that. That's really getting towards the maximum number of samples per second of most TrueRMS DMM as well.

For example:
http://ocw.weber.edu/automotive-tech...-87-multimeter
"...it has a 1ms (1000 samples per second) Min Max mode, the newer models; Fluke 87 Series III, and Fluke 87 Series V, have a 250µs (4000 samples per second) mode..."

Some examples:
http://www.ladyada.net/make/logshield/index.html

Something to think about with this:
http://arduino.cc/forum/index.php?topic=100366.0

See FAT16Lib's post:
"This is a very good card for data logging. Not because of the average write rate of 198 KB/sec but the max latency of 81396 usec. Some cards have a max write latency of 200000 usec.

The 198 KB/sec is way faster than needed to log 1000 records per second with 14 byte records.

Once again the design problem is to overcome the occasional long write latency that is inherent in SD cards.

Even class 10 cards have this problem. The assumption is that devices like video cameras have lots of buffer so they achieve high average write rates for very large files. This allows occasional pauses by the card to erase large areas of flash. You can only write to erased flash."

[de_]

Thanks for some great links and info.

Re logging: I really only hoped to log exceptions (out of normal parameters for an operating robot) so hopefully we are not talking 1000s of writes per second and if we are, as you pointed out, it could be written into the Arduino memory and then dumped offline to a USB stick or compact flash card).

Part of the goal is to give a team a good development and testing system problem solving tool and partly to provide supporting evidence of field issues versus robot issues.