We’ve recently acquired a Schwinn spin bike as a way to exercise during quarantine. Although I haven’t used it yet, I’ve taken on the role of adding some sort of feedback – namely speed and resistance. The bike doesn’t have this feedback natively, but can be upgraded for a mere $600. That’s too rich for my blood, so I figured I’d use some parts I had lying around and try to recreate the full spin experience.
Also the thought of having a nerdy embedded Linux project that is wife-approved doesn’t sound too bad.
The problem can be broken down three main parts. Each of these parts have nuances to them, but in general they are:
- Getting data out of the bike
- Getting data into a computer
- Getting data to the user
For step 1, we’ll need to start with the bike itself.
The Bike
The bike itself it a Schwinn Carbon Blue. It contains a main wheel with a star pattern on the front, and a knob that can be turned to adjust the resistance. These are the two things that can be monitored to provide full feedback. Speed (RPMs) can be measured by counting the wheel rotations. Power (as well as “calories”, and “distance”) can be measured by a combination of speed and resistance. We need to figure out a way to get these signals from the bike to a wire. Starting with what I’d consider the easier of the two tasks, I decided to try to grab RPM data.
My first attempt at measuring RPMs failed. I’d made the assumption that the star pattern was the secret sauce that was being used to measure speed.
The idea here being that the silver pattern in the middle of the wheel would be reflective to an LED, and the red pattern would not. This would translate to a 1 state and a 0 state – something that easily translates to a computer. Also, this hardware is fairly common, and cheap so I thought this would be a hole in one. I ordered some parts, hooked them up to a DMM and hoped to see a huge signal change between the red and silver state.
I was wrong. There was no noticeable difference between the two parts. I found that the sensor could distinguish black and white quite reliably, but not silver and red. I poked around a little more, but couldn’t find sensors I’d needed. I decided to take a step back and see if I could find any more information on how the system worked.
Enter: The Installation Manual.
This was definitely the most useful thing I’d found. When you look through the install instructions of the “RPM sensor,” step 19 tells you the answer:
“The sensor magnet that is embedded in the flywheel.” Interesting… I’d thought the manufacturing process of putting some sort of magnet would be cost-prohibitive. I must be wrong. Otherwise, manufacturers take note. This might be an opportunity to cut cost.
Ok, so there’s a magnet. Now we need a way to make our 0 or 1 states to be “are we near the magnet, or are we not”. Not being a mechanical sensors expert, I’d expected a hall-effect sensor or something similar. At this point I’m getting more concerned about mounting the sensor to the bike. Maybe there’s a way to solve the sensor issue and the mounting issue in one fell swoop.
Enter: More user manuals!
The second manual I’d found has an interesting piece of information: Part Numbers. With the part number of the sensor in place, a quick Google actually leads to a website that sells those replacement parts individually. It might be cheating, but I’m 100% on board. We ordered two of these (since I’ll probably eventually break one) and received them a few days later.
As it turns out, the electro-mechanics behind the sensor is actually a Reed Switch. I was expecting to have a three-wire interface to an active component (power, ground, and signal) but I’m glad to know that I only need two. As Forrest Gump would say: “That’s good. One less thing.”
So I installed the switch and tied leads to a DMM. Just testing for connectivity with the buzzer here, the system seemed to work very predictably:
From that video the behavior of the system can be deduced. The Reed Switch is connected (the beeping noise) once per revolution, and disconnected the rest of the time. Compared to my initial “reflectivity solution” method, this has lower resolution. It does a full transition cycle once per revolution whereas my initial design had four. There really isn’t much of a benefit in this case. The feedback loop of sensor > computer > screen > human > pedals isn’t sensitive enough to that level of precision.
At this point, step 1 is complete. We’re able to get speed data off the bike. Note that I’m ignoring the power data for now – that’ll be done in a later phase. We should be able to get the connected / disconnected signal into a computer. That data will directly lead to flywheel speed and the speed we’re interested in: the pedal speed.
Getting this into the a computer is where most of the time has been spent thus far, so that’s going to be a separate post.