Helios Bars was a promising Kickstarter project that satisfied many needs of the the cycling enthusiast, and introduced a few truly unique ideas to boot. It provided a built-in LED headlamp and multi-color LEDs at the bar ends. The latter could be used in an “ambient mode” or as a speed indicator. And of course the bar end lights could be triggered to indicate turns.

Based on those features alone the Helios Bars grabbed a great deal of attention. The feature that I really liked was a shortening of turn signal cadence as the cyclist nears the next turn. The closer you rode to your turn point, the faster that the bar end light would blink. It was this feature that made me curious to see how the Helios Bars dealt with changes in distance and speed – as that would have an effect on how each bar end LED was updated through the sequence. But there was an additional feature layer that made the design truly compelling. The housing included an embedded Arduino project board with GPS, motion sensors and a SIM controller piggy-backed to the processing unit. This meant that the Helios Bars could be programmed to communicate with the outside world through SMS. I would tackle those options (and issues) after I had solved the first problem, which was geting the bars to work with Android. Getting to that point also had its own series of fits and starts.

Similar to other Kickstarter projects, production hit several setbacks. When the Helios Bars launched many months after the original promised date, an iOS companion app was released at the same time. However, the Android app was still “in the works”. After several more months it was apparent that the team who made the iOS app would not build the sibling companion app for Android. When their original vendor reneged on creating the Android app, I stepped in to fill in the gap.

Bluetooth LE and Android

bluetooth_iconOne of the (many) wrinkles in implementing Bluetooth LE connectivity for Android is the varying support of different Android API versions. There was some hand-wringing around how and whether to support “older” versions of Android. An informal survey of backers showed that most project backers that used Android phones had a more recent device. Even though the overall adoption of more recent Android OS versions is relatively small, people that support this type of Kickstarter project also tend to use up-to-date mobile devices. Since most of those devices supported the more recent implementation of Bluetooth, it was decided to move forward and leave the legacy implementation off the table.

Because I had worked with Google APIs before, I decided to focus on the interactions with the Helios Bars BLE implementation. The reason for this surround a major “wrinkle” in developing interaction between BLE and Android. The topic is best described here, but boils down to confusion that developers have (myself included, initially) when looking at BLE specs for Android. The BLE API reads as though it’s a garden-variety asynchronous implementation, however, GATT endpoints are synchronous by nature. So, a command queue must be implemented in order to handle the transactions with GATT endpoints and notification services. This was the first task I had to tackle in order to understand two issues:

  1. The behavior of Android with multiple threads interacting between the BLE device and the app, and
  2. The response of the Helios Bars, which had both interactive and one-way notifications “up” to the device.

The app I detail below is a preliminary step which simulates functions like location, speed and direction – sending that information as though it was coming from the Location Services API. The key was ensuring that the Helios Bars were responding to commands in a timely manner and not choking on the deluge of data streaming in from the command queue.

A Preliminary Step

This wasn’t my first time working with Google Location APIs, so I opted to focus on the “unknown unknowns” – interacting directly with the Helios Bars through Bluetooth LE. Between the interactivity and the “listening” portion of the app, there were enough variables to justify the effort. As you can see in the screen shot, there are both notification status indicators as well as UI elements that take user input. Some of the inputs, such as those in the “Headlamp” row, simply transmit commands directly to the device. Others, such as the Distance Simulator, simulate the action of location services sending updates on distance to the next turn. All of those out-bound commands are placed in the command queue and on the other end the Arduino processor handles them as they arrive through the Bluetooth assembly. The value of this preliminary app is in verifying that all commands are processed in a reasonable time frame – and this would be done by connecting to my Helios Bars and exercising the various options in real time.

On the next page I show an excerpt from my code that simulates the Location Services updates, and will follow with a few video clips that show how the Helios Bars deal with the variety of inputs that are transmitted to it from the Android app’s command queue.