Reverse Engineering Bike Speedometer

Background

Option 1: IMU/GPS Sensor Board A challenge with our capstone project was the question of how we were going to measure the bike speed. In our initial design, we wanted to implement a sensor board which would utilize an IMU and GPS module to determine the speed. The problem with this implementation was the time and cost associated with designing PCB, getting it fabricated, testing it, and making revisions as necessary. Another issue is the accumulation in error with an IMU/GPS combination; while a popular industry choice since position, speed and acceleration can be determined using two sensors. They are known to be error-prone since the drift in the IMU can cause the error to accumulate. With this implementation, there is also a need to develop a Kalman filter and while it's possible to find existing libraries that would make the implementation of a Kalman filter relatively easy, it's another level of complication that further stresses the limited resources we had to complete the project.

Option 2: Bike Speedometer One option is using a tachometer to count the rotations per minute (RPM) of the wheel to determine speed. An advantage of using a tachometer would be that the speed determined is absolute rather than relative as with using an IMU/GPS. The tachometer would be able to determine the speed from RPM rather than integrating acceleration as with the IMU or deriving speed from position as with the GPS. The error in this case would be relatively constant and would not accumulate with time as with the other configuration. Bike speedometers already exist so it's cheaper to buy one than to build the sensor board and we can be confident that speedometer works out of the box .

A disadvantage to the bike speedometer is that the sampling rate is now dependent on how fast the bike is moving. The rate of information from the sensor is fixed to how quickly the wheel rotates and passes the magnet in front of the sensor. For the control system, this means the CV data and speedometer data aren't at the same sampling rate and if the CV data is sampling at a faster rate than the RPM, the system then has to assume the current speed based on the previous speed measurement. Another major roadblock is that bike speedometers are sold as consumer products and don't have communication ports to query the speed of the bike. This means that the Raspberry Pi reading the bike speed from the speedometer is a gamble.

---

Reverse Engineering the Bike Computer

Within the bike speedometer kit, the bike computer acts as the microcontroller and calculates the speed of the bike based on the sensor input and the user-inputted wheel circumference. The bike computer includes a small LCD screen for the user to read the speed, two buttons to interface with the computer, and a backlight for use during poor light conditions. Some of these features are shown in the image below.

Opening the bike computer cover revealed the PCB and how the buttons interfaced with electronics.

Buttons

By probing the available pads, I was able to figure out how the buttons worked electrically. In order for the Raspberry Pi to control the bike computer, the right and left button pad are connected to an output pin on the Pi and by setting the pin high/low the bike computer can be electrically controlled. This allows the Pi to step through the bike computer's startup sequence in order to read the sensor data.

Sensor Data

By probing the available IC, I was able to determine which pin was the raw sensor data and which pin was outputting data for the MCU to calculate the speed. Assuming the IC is an op-amp which is taking the sensor signal and determining when the magnet has successfully pass the sensor, it outputs a short pulse on the pin labelled in the diagram below. By connecting the pin to an input pin on the Raspberry Pi, we can also calculate the speed of the bike. Below are the results from my investigation and the Saleae data from probing the IC.