Datalogging

[jharvey]

I vote SPI to a SD card, for now. Then USB later on down the road.

I lean that way for round 1 because SPI is native to the processor and I'm quite certain that either the SD code is already written or it's easily ported. You remember the reasons why we aren't doing the advanced features, for round 1 right. KISS goes a long way in making it feasable.

Hmmm, I can't seem to think of any other embeded devices with USB as the storage medium. Almost all the cameras, cell phones, ect that I can think of use SD or similar, not USB. When USB is used, it's not for storage, it's only used for transfer. I suspect that's because embeded devices can't support the power supply required to support slave devices. My guess is that USB for this chip would be a from scratch process. The only exception I can think of is that camer printing directly to a printer thing. It's a sepcail version of USB however, and not really common place.

Also it's much easier to get throught the boot process for SD then it is to enumerate USB. For SD it can be done in a couple lines, and can be captured on a scope to confirm it's working. USB requires a lot of code, and debugging really requires a lot more hardware.

If we use a FAT file system on the SD, we shouldn't have a problem using SD or USB later down the road.

[deviousKA]

Why not just go with an separate device to log to an sd card? A pic or avr with serial communication + sd card would be easy.

Once your to that point, might as well add some sort of lcd screen to the datalogger also, Id like to see something like this incorporated into the proposed lcd dash (freeview?) and not on the ecu board, but thats just my opinion.

Having an lcd attached also provides some limited ecu configuration (potential).

Heres an AVR board,
http://www.compsys1.com/html/avr_sd_dev_board.html

[Fred]

I'm with devious on this. Although we do have SPI, I don't like the idea of actually using it as it will eat 4 pins per connection take more code, more ISR code, more latency to other devices, etc etc. SPI or I2C sporadically to accessories to do more ECU work are an OK idea down the line, but not as an accessory that isn't core to running the engine.

The two ways to get data out of this thing are going to be serial and CAN in a universal format. I've added special support to stream data constantly pretty much for this reason, the speed increase over megajizz was only a nice bonus :-)

Of course, it's open source, so you just know someone with too many pins will do just this with the SD/SPI setup :-) And that is totally fine!

You are free to add it now if you want, github, fork, push and let me know :-)

Fred.

[Fred]

A good thread that deserves a bump. Having a secondary chip do the logging is dead simple with our advanced comms protocol. Just plug it into the serial port, and as soon as it sees data flowing it could configure the EMS and start requesting packets as programmed and record them all in plain old binary stream files (one for each type) with some sort of type/timestamp list file associated with each one, or for all with some structure.

Fred.

[kjb]

Maybe something to consider: OpenLog and Logger comparison.

[Fred]

Thanks, with FreeEMS packetised logging, that is exactly what you'd need perfect, tiny, cheap, simple. Awesome. Thanks for the link :-)

[Spudmn]

I should be able to help out here.

I work with CAN and Embedded Coms and have also built my own data logging system.

I have code that will write to a SD card and store files in FAT16.

I have written it so that it has very small RAM usage and if you lose power you won't lose the whole file.

I need to pull it out again and make sure that its nice a clean.

If we want to go with the remote board that stores the data stream then the CAN bus would be a good idea.

From what I can see on the Puma board (only had a quick look) there is no CAN bus and the serial coms is USB.

I would like to request that at least a couple of pads be put on the board before the USB chip so that I can tap off the Tx and Rx at TTL levels to feed the remote logger.

[Fred]

Thanks for the post and offer!

There are two pins that bring out one of the CAN modules so a chip can be installed on the connector board below the Puma. If you want that, put it in the puma dev thread so it can be discussed in the right place and so that Marcos and Jared see it. They may not here.

Fred.

[Spudmn]

Some more random ideas I have had.

Solder and glue the SD card onto the board. The user can down load the files via USB maybe as a Mass storage device.

Needs a second serial port so that it can get GPS data from a module.

Needs some capture and compare inputs to collect wheel speed encoders etc

Lots of A2D.

G Sensor inputs

IR input to pick up pit wall beacon.

Rf transmitter to send lap times back to Pit.

Wifi for down loading files.

What I might do is start with the Puma board and change the code to be a data logger.

[jharvey]

Fred what pins would be good for CAN? We have several that might already have taps, I'd like to see if they might be accessible.