DIYEFI.org Forum

I just heard from this board so please excuse me if I'm on wrong section or this has been said before.

I for one am strongly with embedded datalogger. It could be done as addon (like I suppose it's currently planned?) but everyone will want it anyway.

If I'd design such FW/HW I'd use separate SD-card (with cardreader components on EMS) because if you store logs on regular memory chip instead, you can't take the logs with you when you leave the car unless you take the whole EMS/datalogger with you (I see a point of external datalogger here). All people still don't have laptops or they may be old and big (people don't buy new laptops only to be able to configure their EMS). I agree that laptops are must when initially tuning the setup but after that we usually could get away with less.

Minor changes to settings could be done if EMS could store system configuration on SD/MMC (again, that card has easiest route via SPI) and also read it back on startup if certain byte on card is set (or switch if it needs to be on HW). Just think of the ease of getting card from car, analysing stuff on home comp without any hurry, making little changes on card, getting back to car and popping card back and drive to work. Also with multiple cards you can store different setups easily (you could even switch on different setups on road without laptop if needed) and transfer data as you like.

Having fs-filestructure on SD is also all good as after that you can transfer and read your files virtually from every computer which has SD-cardreader. Dosfs is at least free source fs for mcu's. I swear I used to have big list of links about SPI-programming on mcu's but it seems like I've lost my bookmarks (had major HDD-crash last year), but I doubt it's hard getting required stuff figured, it's just plain work..

Just some thoughts.

edit->just a little clarification

Hi, and welcome along :-)

All good thoughts, and I agree with most of them, thanks for sharing :-)

I love the idea personally.

If someone wants to fork the code and try to make this happen, it wouldn't be all that hard to do anymore.

All the SD file would need to contain would be the block ID and then the data. You could manipulate the serial buffer to look like it was a message received, or later if/when I refactor, just call the function to handle it directly.

I won't be working on this myself, but there is nothing stopping someone else from taking a crack if they are interested.

Fred.

Love this idea also! Was thinking about it myself, but I thought about using a usb memory stick for it.

sry_not4sale wrote:Love this idea also! Was thinking about it myself, but I thought about using a usb memory stick for it.

That would be pretty sweet, since a 4GB stick is like $12 now.

And they are even more universal than SD card readers

The main issue I can see with the USB stick is that the datalogger would have to be a USB host and handle the USB commands for data storage devices and would need the hardware associated with it. With an SD card, it just needs an SPI port (of course, it needs to handle the commands for the SD card protocol).

There are ready made solutions for both and I don't think any price advantage of the data media will have a significant impact on total cost. Also, I'm not sure that a USB stick is the right format for a secure and reliable connection in a car environment especially if you're thinking about high-performance or race cars.

Jean

Very good points

It would be hard to make a secure usb stick "cradle" too, as the sizes/shapes of this sticks vary so much

I like the USB idea because I'm not limited to a tiny amount of data, you could bang a real hdd in there with a big rubber surround and log continuously on it.

sry_not4sale wrote:It would be hard to make a secure usb stick "cradle" too, as the sizes/shapes of this sticks vary so much

You wouldn't hang the stick straight out, you would use a short extension cable to isolate the two chunky devices and let them be supported individually. I agree that a USB plug is not the best, but an sd card interface may not be that much better if you are thinking longevity etc.

It doesn't matter anyway as it would make the most sense to use the serial interface to receive the data (despite having the SPI stuff on the cpu) and at that point you can do whatever you want. More specifically, both types could be made and which ever one you like/prefer used :-)

Fred.