In order to build our app, we needed phones to be able to provide a highly accurate location with low battery drain and had to discover and engineer some creative solutions in order to make that happen.
And even once we tackled that problem so we could tell where our users were without killing their battery, we were still only able to resolve a latitude/longitude. But human beings don’t want to see or read coordinates, they want to know real-world physical contextual information.
Rather than “Christian is at 38.875166, -77.000844″ real people want to see “Christian is at the BlueJacket Brewery in the Navy Yard in Washington, DC and he’s there with your friends Susan and Kristin”
Shot of the interior of the awesome BlueJacket Brewery in Washington, DC
In setting out to solve these problems, we developed some state of the art technology, backend systems, and algorithms for making these experiences possible, and we are making all of that available to developers in an SDK that we are calling LocationKit which has now been freely available publicly for a few months now.
We are able to do this by utilizing sensors other than the GPS on the device and pairing it with our venue database and some proprietary algorithms to clean up the raw GPS points supplied by Apple’s Location Manager and exclude outliers.
Getting GPS data directly from Apple is like drinking from a firehose at times and getting a raw, unfiltered stream of locations and acting on them within your app can lead to inconsistencies which degrade experience for your users. By using LocationKit in your app, you can have a greater confidence in the locations for your app without having to maintain a team of location experts in-house.
As an illustrative example, the GPS will often drift, even when the user is not moving. It will sometimes give more accurate points and sometimes less accurate points. LocationKit will monitor and intelligently filter out a lot of the bad data from this GPS drift. If we notice the accelerometer and compass are unmoved yet the GPS thinks the device moved 100 feet away, we know it’s likely suspect and will filter that point out, making sure your app doesn’t get that crazy outlier.
As another example, it is very difficult to ascertain the user location, particularly in an urban environment as the GPS signal tends to be attenuated by buildings and will often bounce off them as well. We see this a lot around our office in downtown Washington, D.C.
Using only the raw GPS feed you are very likely to end up with a bogus location for your user. LocationKit will automatically monitor not only the GPS data, but also the compass and accelerometer so it knows that the user didn’t just teleport across the street, it is likely there is a GPS reflection off the nearby buildings. LocationKit will know, from the compass data that the user took a left turn into this building, which we have in our extensive proprietary venue database so we know which building the user entered even though their GPS chip alone may point them as across the street due to reflection.
Suffice it to say there is a lot we do too in order to supply a higher accuracy location.
By using LocationKit in your app, you put all the expertise of our location experts without having to think about it. Your location data will be more accurate resulting in a better experience for your users.
Low Battery Drain
When we first released the SocialRadar app in our private beta almost 2 years ago, it worked to provide location updates like we desired, but the battery drain was rouuuuuugh.
I can’t remember specifics, but I think we were averaging ~10-15% battery drain per hour for our app. This was entirely unacceptable. I had close friends and family using the beta who apologetically uninstalled it saying that they couldn’t bear the intense battery drain we were putting their phones through.
After that rough experience, we set out to make sure we could deliver best of breed location while keeping battery drain low and boy did we learn some tricks. We fed them into LocationKit and learned some more.
We take battery drain very seriously and have gone to great strides to reduce it whenever possible.
In order to provide the kind of always-on background location updates that LocationKit does, we have to keep the GPS active all of the time. So how then do we ensure that the user’s battery isn’t dead within the hour?
So, we keep the GPS running constantly, but we throttle it up and down intelligently to provide maximum accuracy with minimal battery drain.
We do tricks like monitor the accelerometer to notice when the user is not moving and throttle the GPS down while they are stationary, then throttle it back up once they start moving.
This means that our battery drain while their phone is on their night stand is ultra minimal but we can still resolve with good accuracy when they walk outside and into the pizza joint around the corner.
We throttle the GPS down when the user is (driving data gathered while cruising at 55 MPH is unlikely to yield useful results when figuring out which venues the user visits) and back up when they park their car and start walking.
This is the default behavior, a mode we refer to internally as “Best for venue detection” which is our lowest battery possible drain while maintaining a very high rate of accuracy on detecting venue visits, but a new feature we just rolled out is that developers can override our default setting with their own custom profile if they want LocationKit to behave a little differently.
A photo of one of our our battery testing rigs, Arduino and all
I’ll do another full blog post on how we measure, tweak, and quantify our low battery drain (it involves a fun project by one of our summer interns involving an Arduino!) at a later date.
Victor Quinn is VP of engineering and a software architect that specializes in creating amazing Android and iOS SDKs focused on geolocation apps, location accuracy, and reducing battery drain on mobile devices.