Empowering Intuitive Interactions through Bluetooth

The problem that caught our eye

We have all seen too many instances of folks riding a two-wheeler with only one hand on the bike while the other hand answers a call, or they balance the phone uncomfortably. Not a good sight. 

Thus, developing a safer way to control music and answer calls on a two-wheeler, was a problem we’d been looking to tackle for a while. But honestly, the technical challenge involved was more enticing. Our dashboard is essentially an Android tablet, which has to work in sync with two other devices, the ‘rider's mobile’ and their ‘headset’. This is a unique challenge because the typical interaction between a vehicle and its rider/driver begins and ends with maneuvering the vehicle.

The challenge is even better when the vehicle in question is a scooter, and an electric one at that. In a car, we have a ‘mic + speaker’ infotainment system. The usage is very direct - the driver connects to the infotainment system via Bluetooth Classic (BT). This interaction is the same as it is between a mobile phone and a BT headset. Audio information/control is transmitted to and from the Infotainment system using Bluetooth Classic channels or Profiles(BT nomenclature). Such channels are multiple and varied, each with a specific use-case, like some are for audio streaming(A2DP Profile), while some are for answering/ending incoming calls (Headset/Hands-Free Profile), and some enable voice assistants or help control media(AVRCP Profile) on the mobile phone.

Why couldn't we use this same approach to solve for the Ather 450X - Rider interaction? 

The use cases for the bikes are inherently different and difficult given the complexity of not having speakers or a microphone on the dashboard. This is where things get interesting. The Bluetooth Classic connection in cars allows for only two devices to work in sync, not three. Our use case requires three different devices - an Android tablet (the dashboard), the rider's mobile, and their headset! We also ran into other issues because the mobile would not recognize our dashboard as a peripheral device (like the infotainment system), because it runs on Android. The dashboard is essentially recognized as another mobile/tablet and not as a headset! 

How were we to solve this? And how would we get an Android device to work well with an iOS environment? They are NOT compatible.

We took a look at how different two-wheeler OEMs tackled the same problems. Two-wheeler infotainment systems today are very simple and almost all of them do not run on Android, they have some MCU-level chip that runs seven-segment displays. The few that do have BT capabilities, work with the Bluetooth Classic connection. These vehicles use a Bluetooth Classic profile called HID (Human Interface Device). Your mobile phone recognises these bikes as a keyboard. Buttons on these bikes equate to "Play/Pause/Next Track/Previous Track". Android mobiles work well with these for the most part. However, iOS mostly recognizes that these are not real keyboards, and so music-related functionalities work with iOS, but call control does not. So, the solution some OEMs came up with was to build an app for iOS to work with. This iOS app translates the data sent through the HID Profile, and handles music and calls. 

There are some pitfalls to this approach though. We can’t reliably send ‘call and music' information to the vehicle.

Typically, once a problem like this presents itself, we scout for the skill sets required to tackle it. We needed software developers strong in Android Application Development, iOS Application development, and someone with a good understanding of the Android Open Source System (AOSP) (we build our own android OS, yeah we are cool like that). We also needed a System Engineer who got how the Bluetooth stack works on Android. This was a steep ask but luckily Ather tends to attract these weird, energetic engineers obsessed with problem-solving. And then, we got to work. 

Modern problems require modern solutions

We adopted a different approach to this problem. We didn't want to use the HID profile because we could not customize it. We wanted to do more than enable call and music control, so HID wouldn’t suffice. Unsurprisingly, Apple's approach to working with external peripherals gave us a good idea on how to tackle the problem. Apple, using Bluetooth Low Energy/Bluetooth Smart (BLE), has two services running on iOS. Apple Notification Center Service (ANCS) and Apple Media Service (AMS). ANCS deals exclusively with notifications, while AMS deals exclusively with media. BLE was comparatively new to the scene. Invented in 2006 by Nokia, BLE is slowly taking over most of the BT functionalities. BLE is being used with a wide range of applications from automotive to medical to home automation. 

BLE was the best choice for multiple reasons. It consumed less power, had more range, and offered us more capabilities. We created two BLE libraries. One for the vehicle and one for the Android mobile phone. The library on the 450X works with iPhones using ANCS and AMS. The iPhone recognizes the 450X as a hardware peripheral that uses a standard set designed by Apple itself. This way, there is an almost seamless connection between the 450X and the iPhone. We didn't even need to integrate a BT flow into our iPhone App, iOS by itself, took care of the service without any addition or intervention. The rider only needs to pair with the Ather 450X, just like he/she would connect with headphones. The one drawback here was that the AMS could not pass album art for songs. 

For Android phones, our library on 450X requires a library on the phone, which we incorporated into our Android app. The connection here also emulates ANCS and AMS like services. But since such connections are not native to Android applications, we need this BLE library service to run continuously on the dashboard. This service helps the Android phone recognize the Ather 450X as a legitimate peripheral. Android also mandates that if our service runs continuously, we need to request background location permissions. This is because a phone can connect to multiple BLE peripherals, but it has no way of knowing if the peripheral has GPS capabilities that can be used to track the user. Hence, even though we don't track the user through the mobile app when it's running in the background, this particular permission is mandated by Google. 

Another issue we ran into was that the BLE layer on the Android OS was modified by every phone OEM. This meant we had to adjust the behavior of the libraries to accommodate every phone. Our BLE connection works flawlessly on some phones, is acceptable on most phones, but there is a set of Android phones that does not work well. This is an ongoing problem for us and we have folks working around the clock to tackle issues that pop up with regards to these specific phones. 

This article contains 6 months’ worth of my team’s blood, sweat, and tears. The journey was brilliant and engaging, and what we have learned while implementing these 2-3 “simple” features is invaluable. This has set the stage for our next BLE-powered features like Keyless Entry, Voice Assistant, etc. I don't want to give away too much of what's in our pipeline, and if you want to get more involved, check out the open positions on our careers page to join us www.atherenergy.com/careers 

We realized that while this journey was rewarding, we don't want other folks to go through all the pain and struggle to replicate something that we’ve already built. Your time should be spent on pushing boundaries and exploring new avenues with BLE and automobiles. We will soon be inviting the tech community to improve these functionalities better. Stay tuned!