On Wednesday, I showed up at practice with my "Zaurus":http://en.wikipedia.org/wiki/Zaurus, "gps":http://www.usglobalsat.com/item.asp?itemid=6, "heart rate monitor":http://www.polarusa.com/Products/consumer/s610.asp, and "accelerometer":http://www.sparkfun.com/commerce/product_info.php?products_id=254. The new addition to this is the accelerometer, which adds significant resolution to the data. It supports sampling rates up to ~475Hz, but I only had it working at 25Hz (that's how fast it worked reliably with minicom). As a first pass, I turned everything on and put it in my drybag. I wanted to get a feel for how it all worked. After practice I loaded up all of the data into "R":http://www.r-project.org, and set up the data as time series. !/i/pics/061206.paddling/061206.paddling_xlr_speed_bad.png?w=400!:/i/pics/061206.paddling/061206.paddling_xlr_speed_bad.png A major error source is the correlating of the starting points of the time series. The GPS, and HR monitor are fairly easy to correlate (because they have reasonably accurate clocks onboard). The raw accelerometer output I used didn't timestamp the data. As I was using minicom to capture the accelorometer output, I ended up using the "ctime":http://en.wikipedia.org/wiki/Ctime of the minicom capture file. Assuming a capture rate of 25Hz(which it was set to), and the number of samples, I estimated the start time. I'll write a zaurus application that does this. A keen observer will note that the accelerometer also isn't calibrated well. !/i/pics/061206.paddling/061206.paddling_xlr_speed_good.png?w=400!:/i/pics/061206.paddling/061206.paddling_xlr_speed_good.png At 25Hz, you can see the individual strokes. This means it should be possible to systematically analyze what acceleration waveform correlates to the highest hull speed, and thus validate what stroke technique is most efficient. That, however, is gonna take a schwack of work.