In part 3, I explained the troubles I had reading microphone input through a USB adapter and how I eventually made progress by using a package to “listen” for sound.

## Part 4: Calculations & Sample Data

Since the Airdyne sends a sound with each revolution of the flywheel, the RPMs were easy. I did some averaging over a number of revolutions to get a stable number. I had found formulas in a spreadsheet shared on the Airdyne Erg Trending post, so it was easy to plug in the formulas for calories and watts (even though my model doesn’t display watts). Distance and speed go off one another, so I jumped on the bike to collect some data.

When the machine stops/pauses, it continues to cycle through the 5 pieces of information and keeps the last number there. So I pedaled for 10 seconds or so, stopped, waited, and then recorded the speed (distance would be too inaccurate in such a short period of time) and rpms. Reset the display and repeat going faster each time. Threw the numbers in a spreadsheet, got a ratio, did some averaging, and worked both ways backwards with the average.

Looking back, I think I went a little overboard with getting so many samples. Miles per hour came out to be the RPMs divided by 3 ⅓. With a formula for every piece of info, my program output to the command line so I could see it in action. I jumped on the Airdyne, and used the audio cable splitter so I would get output on both displays. The RPM, distance, and speed were fairly accurate right away, but the calories were not even close.

I looked over the formulas to make sure I didn’t make a mistake, but didn’t see anything. I went back to the blog post and finally realized I had a different Airdyne model. I don’t know how I overlooked that when he was mentioning watts, which mine doesn’t show, and he has a big picture of the display right in the post. Anyone who has used several different models of the Airdyne can tell you that calories are much easier or harder to rack up from model to model.

In his post, Preston mentioning using an Excel chart, to get a formula from a trendline. I had no idea what this magic was. I don’t have Excel, so I searched to see if Google Spreadsheets could do the same thing. I found something even better, Google Charts does it, so I could ~~write~~ copy/paste code. 😉

Now I needed sample calorie data that I could plot on a chart. I was back out to the garage and hopped on the Airdyne. This was tricky. Since my goal was to find out what different average RPMs for 1 second would equate to in calories, I tried to maintain a constant speed for 36 seconds. Had to do 36 because it takes 30 seconds to cycle through the display and another 6 to get back to calories. I adjusted my program to keep track of the RPMs and calculate an average over the 36 seconds. I recorded both numbers in a spreadsheet and repeated the process over many times, with increasing speeds.

After getting a calorie per second average I plotted the points on the chart and voila! I got a trendline and a formula. The calories were looking much better. Still not awesome, but I figured it could be due to how I was averaging out RPMs, how I was rounding, or how often I was calculating everything. I started building a graphical display because I was getting tired of looking at command line output. At some point I got in a 10 minute “workout” and recorded a sound file on my computer and kept track of the calories so that I could pipe that back through my app for testing. I wish I had written some kind of simulator to eat through the data and spit out numbers.

I kept going back to the formula though. It was bugging me. What was I doing wrong? Finally it dawned on me how to get perfect data out of the Airdyne. Feed it perfect data and take the human element out of it. I could use a metronome since all the computer cared about was hearing something! Back out to the garage. I already had MetroTimer on my iPhone, so I plugged it into the Airdyne computer and recorded new calorie data at different speeds. I had new chart points and a much better formula. Still not accurate enough, but at least I was confident it wasn’t a problem with my data.

In the next post, I’ll give you a look at version 1 of the app.

Really cool stuff, Nick. I’m really enjoying following along 🙂

I haven’t looked long enough at your gist to see how important it is that `everySecond` runs “precisely” every second, but I thought it worth mentioning that `setInterval`s are prone to drifting.

LikeLiked by 1 person

That’s a good point. I read Falsehoods programmers believe about time earlier today and didn’t even think of it. As far as the data, it’s not important other than it’s when the data gets updated on screen. All of the calculations are based on timestamps of when a revolution of the flywheel is detected. It does handle the stopwatch seconds though, so I should base those off of when the workout starts. Thanks!

LikeLiked by 1 person

I was wrong. Only the rpms use the spin timestamps. The other things are done on the interval with the assumption it’s calculating over 1 second of elapsed time. I’ve solved a lot of accuracy issues already but this might be the missing piece!

LikeLiked by 1 person