On Sunday my partner and I launched our new product Hone on Kickstarter and we've been getting a lot of great feedback and questions. I wanted to address some here with more technical information than is appropriate for Kickstarter, and discuss some of the underlying technology.
What is Bluetooth Low Energy
Bluetooth Low Energy, or BLE, is a new technology designed for low data rate wireless applications. It enables smart devices to run for months on small batteries. Despite the name, it isn't a slight modification to Bluetooth, but rather a completely new protocol with all-new radio hardware. A Bluetooth 4.0 chipset is basically a Bluetooth 3.0 chipset and a BLE chipset stapled together.
BLE was the enabling technology that made Hone possible. Recharging a key fob every few days means you probably won't have power when you need to actually find it.
Deciding on BLE limited us to support for iPhone 4S and the new iPad. We've been getting requests to support older iPhones and iPod Touch, which we can't do with BLE; we came down on the side of battery life over legacy compatibility. Given every new Apple design supports BLE, we think it's the right choice for Hone.
In addition to questions about other iOS devices, we've seen a lot of interest from people wanting Hone to work with Android. We are iOS users, but we aren't ideological about it and if a viable market for our product exists, we want to support it. Unfortunately we can't support Android at this time. The simple reason why is fragmentation.
When people talk about Android fragmentation they usually mean supporting multiple releases of Android and different screen resolutions. All of that is a lot of work, but it is tractable if the expected sales are high enough. In the case of BLE, Android is in much worse shape. Google has yet to include a BLE stack as of Ice Cream Sandwich. That has not prevented a number of vendors from shipping Bluetooth 4.0 capable hardware in their phones, but the situation is a mess. Some vendors turn off their BLE radios and simply label the devices as BT 3.0. Motorola shipped their own BLE implementations. Some vendors may be using BLE implementations provided by their chipset suppliers, such as Broadcom.
That leaves us in a horrible position. We don't even know how to describe to consumers which Android phones would work short of explicitly listing the models and in some cases the specific OS releases running on those models. We'd have to implement and test two full sets of BLE code to support the limited percentage of Android phones we could work with, and probably a third set if and when Google adds support in the base Android distribution. We would not be able to drop support for the legacy stacks even after Google releases an official one, as there would still be a lot of deployed devices that either won't or can't be upgraded.
This is a problem that may resolve itself if we wait. Hopefully Google will add support for BLE in the base Android distribution, maybe for Jelly Bean. At that point we could use the default implementation and only support Bluetooth 4.0 capable handsets running that release. This is something we intend to actively re-evaluate with each Android release - hopefully at some point in the future it makes sense.
Integrating with other devices
Now, having just gone through why we are not going to provide an Android app at this time, I want to make it clear we want to integrating with other devices where supporting them makes sense. We are very interested in integrating with Pebble, for example, and have discussed it with them.
We also intend to publish enough details about how Hone works that anyone who has a device that acts as a "BLE central" can write software to use Hone. Hone uses a custom UUID and advertising packet, but otherwise it employs standard BLE pairing and publishes Immediate Alert Service and Battery Service. We'll publish more specific details before we start shipping, once the firmware is final.
One of the other features people have really taken an interest in is our proximity detection. We think it's cool too, but there are misconceptions about what it can and cannot do.
One request we had was from an engineer who wanted to have his computer start and stop playing music when he enters his office. While we are not going to support it, it should be doable using the information we're going to publish. All he should need to do is write a daemon for his computer that watches for Hone's broadcast packets, which contain information about the strength they were broadcast at, compare it to the apparent strength of the incoming signal and use that to estimate distance. Tuning the exact numbers for general usage is tricky, but for a single fixed setup it should be easy enough to figure out by trial and error.
The most important thing to remember about this is that it isn't geofencing. If you place Hone on your dog's collar we can't tell when it has left your yard unless your yard is circular, has no obstructions, and you place your iPhone in the middle of it. Also, unless you keep the Hone app running we can't prevent it from being evicted from memory on an iPhone if your foreground apps need the memory. That would result in the leash randomly failing to notify users, which defeats the purpose. Again, if users want to try to make it work with the technical information we provide then we think it is really cool, but since we cannot make it work simply and reliably we are not going to do it.
We're very excited about our project and the response it's generated so far. We're also really excited about BLE in general and other devices using it, such as Pebble and Find My Car Smarter. Our goal is to keep Hone simple and easy to use, which means passing up some neat ideas. We think providing information for hackers is a reasonable compromise for now, but keep sending us your ideas - just because we haven't figured out how to do a feature in our initial release doesn't mean we won't in the future, especially if there's a lot of demand for it.