Tour de Living Room

A number of years ago, Marika and I got a Peloton bike, and I've often wondered whether the data from logged rides is available. This week I did some digging, and I found a couple people exploring the same question. It turns out Peloton offers the same type of REST API that I learned about when I was exploring the PUC data! Unfortunately, it's largely undocumented, but I was able to get what I was interested in by following those links above. The bike records several different statistics: the speed I'm pedaling measured in revolutions per minute (rpm), the resistance applied to the pedals measured as a percent, the output power resulting from those two factors measured in Watts, and my heart rate measured by my watch in beats per minute (bpm).

Because I'm a physicist, I was both delighted by the use of SI units for the power (Watts) and total energy (Joules), and disappointed that resistance is simply given as a percentage. I know that the output power depends on both the cadence and resistance, so we can plot those 3 together and see what the relation is:

It's a little hard to see, but if you look at points with similar resistance (color), they show a roughly linear relation between the cadence and output. As resistance increases, so does the slope. Unfortunately, the data Peloton gives is rounded to integers, so it's hard to get a precise measure of the relation.

The classes we take on the bike give target ranges for cadence and resistance over the course of a ride. The bike shows where you are relative to the min and max, and I've noticed that sometimes I can stay roughly in the center, and other times I'm ping-ponging from end to end. My impression was that it was higher resistances that made it more difficult to stay stable, so to back that up I split the rides into regions based on changes in the target resistance/cadence, and plotted the standard deviation of my cadence:

This doesn't show a relation as cut and dry as I expected, but we can see that the highest deviations all are during resistances higher than 30%, which is where I start to feel strained.

The final thing I wanted to look at was long term trends – Can I see improvement in my performance? I took some summary statistics for each ride, and plotted them with the number of days since we got it. First I looked at the distribution of output power over each ride:

The dots show the median power, and the lines show the 25th/75th percentiles. At the very beginning, I was a bit overambitious, and tried a class that was way above my abilities, then settled into a more consistent level. After a significant break (our time living in the RV, which barely has space for us and Eros, let alone a bike), I've been on a nice upward trend. The other improvement I wanted to look for was a trend in heart rates – Ideally, I should be able to achieve the same output power with a lower heart rate.

Since it takes time for my heart rate to respond to changes in effort, I decided a better measure was the max rate with the total work done over the course of each ride. You can see above, I do manage to hit higher work totals for the same heart rate, and for the lower work totals, my heart rate is lower – Progress!

If you have your own Peloton and want to see your stats (or maybe develop a Peloton analysis package?) you can find my code here.

Sync or Swim

Recently I was reminded of this demo of coupled oscillators, using metronomes on a moving platform:

Even though the metronomes are set to different frequencies and start at different points, by connecting their motion through the table, they come into sync automatically. I was curious if I could make a simple simulator that would exhibit the same effect. Each metronome has a number of torques acting to make the bob swing back and forth: there's gravity pulling down on the bob, a spring pulling the bob upright, a drag force that depends on the velocity, and an external force from the platform. In many ways this resembles the resonant pendulum I posted so long ago, but the coupling from having many oscillators makes things interesting. We can write the torque on each metronome as

The force from the platform is the sum of all the metronomes, since swinging the bob around applies a reaction force at the base of the metronome. I set up this simulation and threw in a bunch of numbers for the various parameters. After a bit of tweaking, I got something that looked pretty good:

This gets reasonably good looking by the end, but still a little out of sync. If we run it for even longer, we can look at the error between the angle of each metronome and the average angle:

It takes about 100,000 steps for them to get into a good synchronization – Not quite like the video above, but another fun toy to play with!

Re: Re: Re: Charge

A topic of much debate when using battery-powered devices, like phones, laptops, or electric toothbrushes is, how often should they be charged? The main schools of thought are, charge whenever you have power available, or charge only when the battery dies or is low. I tend to subscribe to the second theory, on the principle that batteries are typically rated for a fixed number of charge/discharge cycles. My laptop has some built-in protection that limits how often it charges:

Batteries work through a chemical reaction between two reactants suspended in an electrolyte. Electrons pass between the reactants, creating a current and dissolving some of the reactants into the electrolyte. This is a bit oversimplified, but I am, after all a physicist, so that's how I like things. I wanted to see whether this model could back up my charging habits.

The setup I settled on was several electrodes, each surrounded by a block of reactant, and the whole thing surrounded by electrolyte. Then I put the system through several charge/discharge cycles. During each discharge step, we find all the reactant that's in contact with electrolyte, and dissolve it into electrolyte with some probability. During charging steps, we do the reverse: Find electrolyte in contact with either reactant or electrode, and precipitate reactant with some probability. We keep track of how many changes happen each cycle, which corresponds to the amount of current produced, and we vary the number of repeated discharge steps before switching to charging, and vice versa.

There's a lot of parameters to tune here (probability of state change, number of electrodes, amount of electrolyte), so I haven't come close to exploring the full space, but I'm still pretty happy with the results. This case used 200 steps for each discharge/charge cycle:

You can see we use up most of the reactant (yellow) on each cycle. If we switch to only 80 steps, things look a little more ragged:

We can measure how much reactant is around at the start of each discharge, and plot how it changes as we go through cycles for several different cycle lengths:

For all but the extreme 2-step case, these quickly reach an equilibrium max charge (plotted as a fraction of the initial). I was curious what was going on with 2-steps, so I plotted what it looks like at the end of the simulation:

Because of the way I set up the cycling between dissolution and precipitation, the system tends toward holding only as many as it adds on during charging – That's the source of the pattern in the max charge plot above, and not (as I initially thought) my belief about battery health. As result, I think I have to consider this sim inconclusive as far as charging habits. Maybe I'll do a followup later (which will of course be called "Re: Re: Re: Re: Charge")!