Am I getting slower every day?

If you’ve ever been a bike commuter, you’ve probably asked yourself this question. Thanks to these little devices we can now attach to ourselves or our bicycles, we can now use our own actual ride data to investigate these kinds of questions, as well as questions like these:

• If I’m going to work from home one day a week, which day would maximize my recovery?
• Do I tend to ride faster in the morning or the evening?

Last year, I wrote a few posts about learning how to parse a set of Garmin XML data from 2013 and analyze it using pandas, matplotlib, and seaborn. This year I redid the same analyses, with a new installment of data from 2014.

In continuing my series on investigating bike data, I ran into some interesting aspects of working with device data.

I have some experience with devices, thanks to my many years of working in research labs. This post is about the fun of hunting down what’s working and what’s not.

Things to consider when working with devices

1. Are you using the device yourself?
2. Are you interacting with the user(s) (directly or indirectly)? Or not at all?
3. What is the device designed to do? Are you using it for its intended purpose?
4. How well does the device actually work? Generic measurables might include: sensitivity, specificity, accuracy, precision, battery life
5. What else is being measured?
6. Measured how?
7. How are data stored? How much data can it store? How does it connect to other devices/data stores?

In the case of a bike computer, I have been looking at:

One of the main reasons this project turned out to be interesting is that time series data has all kinds of gotchas. I never had to deal with a lot of this before, because the sorts of time series I did in my scientific life didn’t care about real-life things like time zones. We mostly just cared about calculating time elapsed.

…tick…tick…tick

Anyway one thing I wondered about with the bike data was, can we compare average speeds in the morning vs. the afternoon? But to do that, I first had to parse the datetime objects and put them in the right time zone.

One thing I wanted to do with this data set was experiment with plotting methods. I had already done some exploratory plotting with regular matplotlib, so I had some vague ideas about what I wanted to do.

First I had to select out subsets of data to compare. I knew that there were two types of rides: shorter trips in the city, and longer trips in the suburbs. I was feeling lazy, so I just did a quick threshold with SQL.

So I have some bike data that I parsed out of XML and put into a pandas dataframe. Most of the questions I wanted to ask required that the timestamp of each ride segment, or lap, be used as the index along the x-axis of a plot.

Non-obvious nuances of pandas datetime objects and indexes.

You have to sort the dataframe by timestamps, before you can convert the timestamps to use as an index.

I was looking for some fun time series data to hack on. Turns out bike computers provide a great way to interface between your friends’ unfounded modesty and their actual rides.

One friend was kind enough to donate some data for my entertainment. This friend wears spandex, rides a titanium frame road bike, and sweats a lot. I knew he was a strong cyclist. He’s also relatively consistent, which meant the data he gave me wasn’t too terribly noisy. But everyone forgets to turn on the computer sometimes, or forgets to charge the battery.