Data Logging 1
Intro
Rob Faludi gave us this simple Arduino setup and the code to utilize the EEPROM on the Arduino as a small onboard data logger. I have the ATmega168, which can hold 512 bytes. Here’s the sketch Rob did in Fritzing:
The momentary switches from left to right are STORE, RETRIEVE and CLEAR.
The code is here:
http://www.faludi.com/classes/craftingwithdata09/code/datalogger_continuous_faludi.pde
The Setup
Yep, it looks like the picture.
Experiment 1: Walking Pace
This experiment was a bit of a bust, but nonetheless informative. Most of it was of the I should have already known that category though. I figured for the first pass I would just stick with the photo sensor Rob proposed, but we could have used any number, and he encouraged us to do so.
With this experiment, I treated the data logger as a primitive location/gait device. I simply walked up and down the hall from the shop to the entry gallery and back, with the Arduino on a battery, aiming the photo sensor at the evenly spaced lights. A number of variables were therefore controlled: the path was a straight line, the lights served as a measuring stick, and the Arduino runs on its own clock, so sample rate is fixed. I ran my stopwatch on my iPhone just to make certain I wouldn’t overrun the initial data in the EEPROM:
So the results were a mess:
I will cut to the chase because none of this is breathtaking: I was switching from battery power back to the USB to download the EEPROM to my laptop. By cutting the power supply, the EEPROM is erased. Those data points come from readings after powering back up with the USB. I also haven’t mapped the photo sensor very well. It would be more helpful if it’s low value were closer to zero.
So there I was feeling foolish having walked up and down the hall twelve times with no results. If I can stand the embarrassment, I intend to repeat this by moving to XBee’s to download. I suppose I could just carry my laptop with me, but that might be too easy.
Experiment 2: One Mississippi
This experiment is very basic, and kind of dumb, but I needed to get to the bottom of what I was doing wrong.
First off, I realized after the first failure that I might not be using the STORE, RETRIEVE and CLEAR pins correctly, so I ran some tests. STORE it turns out, does not initiate the storage process, but rather ends it. The data points are being fed into the EEPROM continuously. CLEAR does clear it, so it sets the starting point. Once you are confident you have roughly 500 points of information or so, STORE stops the storage process. Data points can be exported to text as first-in-first-out, and it appears that the first data point is dropped, but I am still uncertain about that.
This experiment is simple: I wanted to test the whole mechanism without leaving the bench as my laptop was tethered at the moment and low on power as it always seems to be these days. I decided to test how consistently my “One Mississippi” count was. I first ran it through, by covering the sensor every five counts. This one is a bit noisy as you’ll see, though, because I didn’t reset at the end of 5 myself: I kept going all the way up into the 100’s, so the count gets longer depending on the length of the spoken number. The second and third tests were a little more consistent as I went to 10 each time, and then reset. Here’s the chart, uncorrected for variations in start points:
And here it is again, with starting data removed so that all tests have two low counts before the jump to high:
Excel would only let me import 253 data points, claiming I had exceeded the natural size of a worksheet (okay, I added “natural”), but I think there’s a way to work around this. They give some hint about how to address the “Chart Wizard” (quotes intentional), but it didn’t work on first or second pass.
In the meantime, I clearly need to work on my One Mississippi if I’m going to rely on it for serious timekeeping.