I race a Formula 2 sidecar, similar to the ones you may have seen at the Isle of Man TT races. It runs a 600cc motorcycle engine.
I would like to log data from various sensors, and then view this data using software on a PC later. My idea is to log it to an SD card, and then convert it later into a format that data logging software can access.
I need to log various sensore, including GPS data, Oil Pressure, Engine RPM, Gear, throttle position, fuel pressure, fuel temperature, oil temperature, AFR from a lambda sensor etc.
I am thinking that 10 readings per second would be plenty.
Most of the sensors should be pretty straight forward analogue sensors, some though would need to use interrupts, like the engine rpm.
Do you think it is feasible to use an arduino for this project? Or should I be looking at something else, like a Teensy?
wvmarle:
Sounds feasible, except maybe the 10 readings a second from a GPS.
?
rickerman:
Do you think it is feasible to use an arduino for this project?
10 Hz is no problem... with the right GPS library and program structure. You do not necessarily need a Teensy. Most GPS devices can provide 10Hz updates, but most GPS library examples will not keep up, for a variety of reasons.
You don't identify the sensors, so I can only suggest that you get an Arduino that has sufficient hardware serial ports for each of sensors that use serial communications. Software serial port libraries can be good (AltSoftSerial) or bad (SoftwareSerial), but they all require significant CPU resources to handle each character.
Another forum user (powergravity) developed a Scooter logger that had GPS @ 20Hz and several other sensors @ 100Hz, all logged to an SD card. Lengthy thread starts here, last version of software here. Related threads of interest can be found by looking at powergravity's posts.
One of the main problems is that the SD card will occasionally take more than 100ms to complete a write operation. And after writing about 1MB of data, it would take even longer to write one 512-byte buffer, almost 1s. o_O
To avoid losing sensor & GPS data during those operations, several advanced techniques were used:
GPS data is parsed during the RX character interrupt, using NeoGPS & NeoHWSerial. NeoGPS saves "fix" structures in a queue until they can be handled (i.e., written to the SD). The fix structures are much smaller than the raw character data, so more GPS updates can be saved.
The IMU he used had several "quirks" that we discovered. The BNO055 does not quite operate at 100Hz, so it required a more flexible file format. It would probably not work on any of the SAM MCUs (e.g., Teensy).
The SdFat library was modified to call his function to read samples while the SD write was completing.
Samples were saved in several different queues. This made sure that the samples were read at an exact time, even if they couldn't be written until later, when the "time was right".
I would suggest writing several smaller sketches to learn how to interface with each sensor. Be sure to use a non-blocking program structure (i.e., don't use delay or while loops that wait for something to happen).
Then work on integrating all the unique bits into a larger program. Add one piece at a time. Ask questions when you get stuck.