Comments on: Data Logging to the Arduino EEPROM http://www.eightlines.com/blog/2008/09/data-logging-to-the-arduino-eeprom/ Experiments in Physical Computing Tue, 06 Jan 2009 03:04:27 +0000 http://wordpress.org/?v=abc hourly 1 By: blalor http://www.eightlines.com/blog/2008/09/data-logging-to-the-arduino-eeprom/comment-page-1/#comment-107 blalor Mon, 17 Nov 2008 02:49:33 +0000 http://www.eightlines.com/blog/?p=45#comment-107 Just popped in here after finding your site through a subscription to the "arduino" technorati tag feed in Google Reader. How random. (Yes, I'm the afore-mentioned "blalor"). :-) Glad you're making progress! Brian Just popped in here after finding your site through a subscription to the “arduino” technorati tag feed in Google Reader. How random. (Yes, I’m the afore-mentioned “blalor”). :-)

Glad you’re making progress! Brian

]]> By: Brent http://www.eightlines.com/blog/2008/09/data-logging-to-the-arduino-eeprom/comment-page-1/#comment-105 Brent Sun, 16 Nov 2008 22:57:32 +0000 http://www.eightlines.com/blog/?p=45#comment-105 One of the biggest issues is storing a float in a byte isn't really possible. If you divide by 10 and receive an amount which contains a decimal you lose that precision. A real time clock is one of those things I wish the Arduino had. That way you could add a timestamp to the interrupt. But again, storing the datetime to a EEPROM takes space that it doesn't really have. One of the biggest issues is storing a float in a byte isn’t really possible. If you divide by 10 and receive an amount which contains a decimal you lose that precision.

A real time clock is one of those things I wish the Arduino had. That way you could add a timestamp to the interrupt. But again, storing the datetime to a EEPROM takes space that it doesn’t really have.

]]> By: Eightlines Creations › Mapping GPS Data http://www.eightlines.com/blog/2008/09/data-logging-to-the-arduino-eeprom/comment-page-1/#comment-102 Eightlines Creations › Mapping GPS Data Sun, 16 Nov 2008 20:35:38 +0000 http://www.eightlines.com/blog/?p=45#comment-102 [...] project off I was having quite a few issues with managing the size of the data in the allotted EEPROM space on board the Arduino. I built up an SDCard writer based on several specs I found in the [...] […] project off I was having quite a few issues with managing the size of the data in the allotted EEPROM space on board the Arduino. I built up an SDCard writer based on several specs I found in the […]

]]> By: Troy http://www.eightlines.com/blog/2008/09/data-logging-to-the-arduino-eeprom/comment-page-1/#comment-101 Troy Wed, 12 Nov 2008 20:28:29 +0000 http://www.eightlines.com/blog/?p=45#comment-101 Re the quoted text below: 1) do you need the resolution of each wheel revolution? what about dividing revolutions by 10? That's a much smaller number to track, just multiply by 10 later to rehydrate. 2) for the sample rate instead of every minute can you store your average and when that changes log the new average with a timestamp? It's more bits per sample but possibly way less samples overall. --- "The EEPROM was the next issue. 512 bytes is a serious limitation. Some math was required to see if I what wanted to do was even possible. If I were to poll every minute over a ride I’d be able to record 8.5 hours of one byte readings. That’s pretty good, seeing a 200km ride would take approximately 6 hours. One byte is capable of storing 256 possible values. Is that enough, or would I need more values? If my revolutions were 255 with a wheel circumference of 2110mm I’d be traveling an average speed of 32km/h. Clearly not enough. I’d need to peak at 70km/h, with an average at maybe 30-40km/h." Re the quoted text below:

1) do you need the resolution of each wheel revolution? what about dividing revolutions by 10? That’s a much smaller number to track, just multiply by 10 later to rehydrate.

2) for the sample rate instead of every minute can you store your average and when that changes log the new average with a timestamp? It’s more bits per sample but possibly way less samples overall. — -

“The EEPROM was the next issue. 512 bytes is a serious limitation. Some math was required to see if I what wanted to do was even possible. If I were to poll every minute over a ride I’d be able to record 8.5 hours of one byte readings. That’s pretty good, seeing a 200km ride would take approximately 6 hours.

One byte is capable of storing 256 possible values. Is that enough, or would I need more values? If my revolutions were 255 with a wheel circumference of 2110mm I’d be traveling an average speed of 32km/h. Clearly not enough. I’d need to peak at 70km/h, with an average at maybe 30-40km/h.”

]]>