RF Proximity Spikes

StickNFind, Gimbal, and RedBearLab beacons use Bluetooth LE technology to detect the proximity of a mobile device.

For more than a year I've been scoping out potential devices I could use for RF proximity sensing, a technology that is becoming increasingly mainstream since Apple embraced it with their Bluetooth LE-based iBeacon spec and developer API (subtly introduced in iOS 7 last summer). The basic premise is that a very small device (a 'beacon') with a radio frequency antenna can periodically emit a signal that broadcasts a unique identifier assigned to the device, and a mobile device such as an iPhone may then detect that signal when it is within range. By gauging the signal strength, the mobile device can estimate how close it is to the beacon. The Bluetooth LE specification is well suited for this type of application, and several manufacturers had already started bringing their devices to market before Apple formally released their proprietary iBeacon specification earlier this year. 

One of the earliest devices in this space was the StickNFind beacon, released commercially over a year ago with the targeted use case of finding lost objects. The company quickly began offering developer support in the form of an iOS SDK and a developer forum. I purchased 10 StickNFind beacons in bulk, for $15 per unit, last summer and began trying out their SDK shortly thereafter. Overall, I found their developer support left much to be desired: new versions of the SKD were released infrequently and via email rather than through a hosted web site. I found the signal strength of the beacons to undergo rather wide fluctuations, which made it difficult to use to detect proximity. After several months I gave up on their platform.

By the end of 2013, Qualcomm unveiled their Gimbal proximity beacon platform with full iOS and Android developer support. Upon registration to their developer program, they shipped three of their beacon devices for free to help get started. So I began experimenting with their devices and feature-rich SDK earlier this year. I found the iOS-facing API to be well architected and easy to use. In particular, the key ingredient for my use case is the ability to continuously monitor the signal strength of the beacon when the app is backgrounded, which they provide a call-back method for. Once they made the devices available for purchase, at an astonishingly low cost of $5 per unit, I obtained enough to actually start to deploy in my home for testing. I'm not yet fully committed to Gimbal, but so far it seems like the most promising option.

Another strong contender in this space that I've only recently begun to explore is the offering by RedBearLab. These devices were quite a bit more pricey at $25 per unit (prices vary based on purchase size), but what I find compelling is that they've made their platform open, and they support the iBeacon spec. I believe this would allow more under-the-hood customization than offered by Gimbal, but with the obvious downside of requiring more up-front investment in building out the API.  

Hopefully I'll find time to explore these devices so I can commit to one or the other and move to the next stage of my project.

WorldLine Project

A visualization of daily activity data taken with a prototype iPhone app I built called HabStats.

For some time I've been fascinated with the notion of recording my daily activities. I recall in 2001 as a postdoc in Toronto installing a time tracking app on my Palm Pilot (something like this), and using it vigilantly to keep track of how I was making use of my time. I felt empowered to actually have hard data, which often contradicted my subjective sense of time. I also realized that the act of recording what I was doing increased my in-the-moment awareness, but at the same time was tedious. After a month or so I eventually abandoned the practice.

Years later, after the iPhone had been released upon the world, my interest in time tracking was rekindled, and I began to devise what such a re-envisioned time tracking app would look like on the iPhone. I eventually purchased an iPhone in 2009, and an Apple developer account, largely driven by my desire to build this tool. So, in my spare time, I learned Objective C and taught myself how to use the iPhone SDK. It took a couple of years of starts and stops, but eventually I had a working app I called HabStats, with plans to release to the App Store. However, after using the app to  continuously track my activities for a week in March of 2012, I became discouraged by the tediousness and intrusiveness of having to interact with my phone throughout the day. I put my project aside once again, later giving a summary of it as a show and tell presentation at the Chicago Quantified Self meetup.

The project never died, but has pivoted in a new direction. To alleviate the insurmountable tediousness of having to manually record activities, I began exploring the possibility of using GPS, motion sensors, and RF proximity sensors to build up a data set that could be cultivated for human activity information. This is becoming an increasingly crowded problem space. There already exist mobile apps, such as Moves, that track your movements using GPS. Coupled with Apple's iBeacon platform, and motion trackers like the Fitbit, I think it will be possible to pinpoint one's activities fairly accurately. This is what I'm currently working on, rechristening the project WorldLine. Hopefully I'll be able to make progress in the coming months.

The Quantified Car

The Automatic device plugs into the diagnostics port of your car to track your driving habits by monitoring your trips, and gives you visual and audio feedback through the accompanying mobile app.

Earlier this month I began an offsite project at work, which means I'll be spending an hour commuting to and from work every day. I decided to finally get rid of my `99 VW Beetle, and replaced it with a new Subaru Crosstrek, which I'd had my eyes on for over a year. That very same day, I drove to the Apple Store to pick up an Automatic device to track my driving habits. It plugs into the diagnostics port of your car (typically located on the driver's side under the dashboard). The device interfaces with your car's onboard computer system, and can record data such as speed, gas mileage, hard breaking and hard acceleration. They provide a beautifully designed mobile app that shows you a summary of data for every trip alongside a map showing you the route obtained using the GPS in your phone.

The primary use of the device is to improve your fuel efficiency. Driving at speeds higher than around 60 MPH, as well as hard breaking and accelerating, all have a negative impact on the fuel efficiency of your car. So, by monitoring these parameters, and alerting you when you operate outside the optimal range, you can adapt your driving habits to better optimize your car's fuel consumption.  That's pretty cool, but for me personally, being a data nerd, I'm excited to be collecting this data (which should be accessible through their API) and look forward to playing with it down the road, so to speak.