Location Updates After 2 Days in San Diego
Apple’s iOS operating system famously doesn’t allow applications to run in the background. It does, however, allow them to perform seven narrowly-defined background services such as audio streaming and receiving ‘significant location change’ updates. The significant change updates don’t use the iPhone’s highly accurate but power-hungry GPS in the interest of preserving battery life. Instead, the phone uses the relative signal strengths from nearby cellular towers to triangulate a rough approximation of the iPhone’s location. The phone’s baseband must continuously communicate with the carrier’s cellular towers when your phone is turned on anyway, so gathering location data from these communications should have a negligible effect on battery life.
So just how accurate are these triangulated data points, and what exactly constitutes a ‘significant’ location change to the iPhone’s iOS? The only information I could find comes from a developer who tested phones in Tokyo, Chicago, and Melbourne. He concluded that 2500m (approximately 1.5 miles) as measured by the phone’s own background location service, was enough to trigger location updates 95% of the time. Moving 750m triggered an update 50% of the time. Good information, but it doesn’t tell us anything about the accuracy of the background updates.
The problem seemed interesting enough, so I spent a Saturday morning putting together a small test suite. I created a simple iPhone app that registered with the iOS significant location change service and logged all updates in an SQLite database and CSV file. I also built a Ruby on Rails app to receive real-time location updates from the phone and pushed it to Heroku for some quick (and free) hosting. Finally, I made a point to record every time I got into or out of my car in my notes for a week so I could compare the background location results to my actual whereabouts.
1) False location change events occur randomly when the signal is weak – At my apartment where the cellular signal is strong, the background location service is generally within 1km of my actual location. When I’m at my office building, where signal strength is so bad we struggle to complete phone calls indoors, the phone will randomly register location events up to 10km away. Usually these events are triggered as I walk from one side of the building to another, but occasionally they will occur while I’m seated at my desk.
2) It doesn’t use nearby WiFi networks for location – The above problem could be mitigated somewhat if the OS would use nearby WiFi networks to aid in location. After all, the iPhone already queries a massive database of WiFi router locations to assist with GPS lookups, and I’ve used my GPS at home and my office enough for the phone to associate my WiFi router’s BSSID with a physical location. On the other hand, scanning for WiFi networks would provide some additional battery drain. Dealing with mobile hotspots like the MiFi would be problematic for a WiFi-assisted location scheme as well.
3) Location updates occur at regular intervals while moving, but not always – For my first test of my location tracking app, I drove 13 miles across town to a coffee shop. Upon arrival, there were exactly two pins on my map: my apartment and the coffee shop across town. I assumed the background location tracking waited until I stopped moving and my location stabilized to register a location change event. Clever. Then, on the drive home, my app diligently registered location events every few kilometers along the freeway until I was home. So much for that theory. Since then, I’ve received updates while moving more often than not, but very rarely I won’t see any location update events until I arrive at my location.
In the screenshot to the left, I ended up driving all of the visible freeway segments (yellow lines) over the course of two days. For the upper (I-80) and rightmost (I-215) segments, the application received location change updates at roughly the same location each time. The segment on the left (I-15) did not register any location events in this snapshot, but on other days driving the same I-15 segment would register location change events every 2-4 km.
The good news is that I always seemed to register a location change event when I arrived at my destination and parked the car. In some cases, these location change events were 15km apart. This only seems to happen when traffic isn’t present, allowing me to maintain a constant 65mph on the freeway.
4) If the application is terminated, background location services will restart it automatically – Once the app calls [[CLLocationManager sharedLocationManager] startMonitoringSignificantLocationChanges] the familiar location ‘compass’ arrow shows up in the taskbar, even though the GPS isn’t running. Terminating the application does not remove this arrow as I expected. Rather, the OS will launch the application again when the next significant location change event occurs. The only way to remove the compass arrow and stop location change events is to call [[CLLocationManager sharedLocationManager] stopMonitoringSignificantLocationChanges] from within your application. Unfortunately, there is no way to list which applications are monitoring your location. I can imagine frustrated users killing all of their applications one by one in an attempt to turn off location updates.
5) Activating the GPS will register a location change event, even if the phone hasn’t moved – Opening the Maps application, checking in on FourSquare, or any other activity which uses the actual GPS will trigger a significant location change event. These are easy to distinguish from background location events because they have real values for CLLocation.VerticalAccuracy, CLLocation.Altitude, and CLLocation.Speed, whereas background location updates have values of -1, 0, and -1 respectively.