In my earlier post RPMs to BPM, I demoed a fairly simple hall effect circuit that I used to control the playback speed of an audio file in Max. In the video, I wave a magnet in front of the sensor and used the resulting data to trigger a “bang” in max. This method worked fine in my demo as I could not trigger the sensor very quickly. When I hooked the sensor up to the bike, I realized that above a certain rotational speed, the software would “miss” rotations. [I have since switched to using the sensors in the hub motor, but they present the same issues]

Thus I realized I had a problem. Though the Arduino has no problem catching the incoming sensor data (it typically executes code in the range of microseconds (1 millionth of a second), I was running into trouble passing the data between the Arduino and Max. Without getting too technical, the data transfer speed was too slow.

As someone who tries to be primarily concerned with the realization of creative projects rather than elegant technical solutions, I will admit that I always aim for the simplest solution even if it isn’t the most efficient. Sometimes, as in this case, the simplest solution (handling all of my data calculations in Max) just isn’t going to work. I realized I was going to have to calculate RPMs using the Arduino and then transmit a running tally of the current RPMs to Max (along with data from the Force Sensing Resistors, as seen in this video). I knew that this could pose a large technical problem. I would need to calculate the RPMs by taking the triggers from the Hall effect sensors while at the SAME TIME I would need to be constantly updating the data from the Force Sensing Resistors. Typical Arduino sketches have one function–loop(), which runs over and over while the board is on. Pausing to wait for incoming data from the Hall effect sensors would delay the execution of my code and stop the data being sent to Max–I needed to do two things at once.

Fortunately in the world of open source technology, the solutions to many technical challenges lie online. This great example by Zitron shows how to use hardware interrupts to read in the data from the hall effect sensor outside of the loop() function.

The result is that I can just send a constantly updated stream of RPM data to Max. This turns out to be a much better solution, because if I miss a sensor trigger between the Arduino and MAX, the RPM data will be wrong (sometimes VERY wrong). If I miss one read of RPM data, it’s not a big problem because I am constantly sending the current number of RPMs.

The bigger lesson here is that the easiest solutions are always the best, but sometimes an easy solution just wont work. In that case you have to delve deeper. While you don’t want technical complexity to derail your project, sometimes more complex solutions end up being the most elegant.