One benefit of working at Atomic Object is our bicycle commuter reimbursement program. Although the benefit’s origin is a 2008 tax law that is no longer in effect, Atomic has decided to continue the program. The gist is that for each month that you bike to work at least 10 days, you can be reimbursed for $20 of related expenses.
Although it’s a pretty awesome benefit, it’s a bit of a hassle to track. You have to remember to update a spreadsheet each day that you ride in to work. Sometimes, I forget.
Naturally, since I’m a software developer, I’ve been thinking about how I might use software to help me automate, or at least reduce the friction, of tracking the days I commute via bicycle. When I recently overheard some plans to recycle iBeacons that had outlived their original purpose, I jumped at the chance to run an experiment.
Although I’d never worked with iBeacon before, it isn’t new technology anymore; the protocol was developed by Apple in 2013. In case you’re unfamiliar, the concept is that you can install these beacons in physical spaces, and they will periodically broadcast a BLE signal with their identity.
iOS is designed to detect these signals quickly and notify any interested apps. The beacons themselves are unaware of who or what may be listening to their presence. The high-level goal is to be more accurate and use less energy than always-on GPS.
My hypothesis was that, if I could write an iOS app to detect the beacons’ presence, I could install them where I park my bicycle and never have to worry about tracking my commuting days again. I rarely go into the area where I park my bicycle on days that I don’t commute via bicycle, and on the occasions that I do, it’s usually in the middle of the day rather than at the beginning and end of the work day.
There were a few concerns I wanted to resolve before I felt it could really be a success, however. So, I hacked up an iOS application to prove it out. I used the Core Location framework to monitor the beacons and log into an SQLite db each time I came within range of the beacon and each time I left range of the beacon. It also displayed a local push notification for easy debugging.
I had several questions to answer:
1. How quickly can it detect the beacon?
I’m only going to be near the beacons for a very short time. In the fastest case, it may only take me 30 seconds to park and move on. If iOS fails to detect the beacons before I move on, then the whole concept would prove to be a failure.
Fortunately, it proved to be quite quick. Usually, my phone would be notified within a few seconds of entering the range of the beacon. This is more than quick enough.
It takes significantly longer to be notified when you leave a beacon’s area, however: roughly 20-30 seconds. While detecting the presence of the beacon’s advertisement definitively indicates that you are within range, failing to detect the advertisement could mean a few different things. This delay is not a problem for my purposes, though.
2. How well can I control the range?
The area where I park my bicycle isn’t all that far away from where I spend time at my desk. If the range is too far, and my phone is picking up the iBeacon signal while I’m at my desk, then it won’t be able to provide valuable data.
There happen to be two tools available for me to tweak this, however. First is that Core Location provides APIs for ranging the physical distance from a beacon. I didn’t have to actually implement any code to try this out because the beacons themselves are also capable of adjusting the power with which they broadcast their identity.
In practice, this turned out to not be a problem. As a bonus, I’ve got a few levers I can tweak to help me get better data. Tuning is definitely a bit of an art, however, and I will have to pay attention to this as I install multiple beacons around the parking area.
3. Will it affect my phone’s battery life?
If I notice the impact on the battery life of my phone, I’m not likely to use this as a long-term solution. Battery life is simply too important to me.
To analyze this, I simply turned to the battery analytics that iOS has built into the Settings app. Throughout all my testing, my spike app never had a measurable impact on battery life. By that, I mean that iOS wouldn’t even ascribe 1% usage to it over the last 24 hours. Subjectively, I also didn’t notice any difference at all.
4. Is it reliable over long periods of time?
For the sake of battery life, iOS places some aggressive restrictions on iOS apps. As an example, they are not allowed to run in the background without good cause, and, even with that permission, the OS aggressively limits the amount of time and processing power they are allowed.
The last concern that I had stems from the nature of this application. Ideally, I could install it on my phone and let it passively collect data. I probably won’t even look at it unless I’m preparing to submit an expense for reimbursement. If iOS decides that, because I’m not interacting with the app frequently enough, it will stop notifying it of iBeacon events, that would also destroy the feasibility of this concept.
After a couple of weeks of intentionally not opening the spike app, it was still reliably and quickly receiving notification from iOS about beacon events. This was a great relief.
iBeacon seems to tick all of the boxes. I’m confident that I can build this out into a real solution and share it with the other bicycle commuters around the office.
I’m really impressed with the speed, reliability, and low power usage of iBeacon. It’s obvious to me that these needs couldn’t be met in such a passive way without deep integration into the OS.
Now that I’ve proven out this approach, I’m excited to implement a real solution.