Blog Post

How Saga bypassed GPS to log your life without killing your battery

Last year around this time, A.R.O. Co-founder and CEO Andy Hickl thought he had built killer app for location data in Saga. The premise was simple: constantly track users’ locations, learn their routines down to a micro-level, and eventually offer them advices on, for example, places they might want to go or faster ways to get from Point A to Point B. I was impressed enough with the vision to write about it.

There was only one problem: “We ran smack dab into a buzzsaw,” Hickl said, “and that buzzsaw was battery.” No matter how much people liked the product, that didn’t outweigh their anger over the fact that regularly pinging the GPS satellites was killing users’ batteries.

A.R.O. had a tough choice to make. It could reduce the frequency of GPS communications and make the app less useful in the process, or it could make a much more difficult decision. It chose the latter: “We put our tail between our legs and pulled the app from the store,” Hickl said.

Now, Saga is back and it’s not killing batteries. While resting, it’s burning less than 1 percent of battery life per hour, and only a little more while in use. I can vouch: I’ve been using Saga for a week, and not only does it work well, but I just checked my battery usage and Saga didn’t even register. Twitter, at 2 percent, is as low as it goes.

The trick was finding a data source that could act as a proxy for GPS without sucking so much power. So the Saga team started looking at smartphones’ other sensors and realized the answer to its problem. If the app can use other, lower-power inputs to predict accurately whether or not you’ve moved, it can save those GPS pings for when it really needs them.

For example, Hickl explained, if your phone is outside your pocket, the camera’s light sensor can be a good indicator of whether you’re inside or outside. The microphone can capture ambient noise and tell whether you’re still in your office or if you’ve moved to Starbucks. “On devices that have a barometer,” he said, “you can tell difference between indoors and outdoors.”

And the more Saga learns about users’ routines, the better decisions it can make about which sensors to go to first. “Where it really gets the big savings is being able to know when you’re asleep,” Hickl explained, or when you’re probably going to be at the office for 9 or 10 hours. If you’re always at the same plaza in the morning, but at the hacienda on weekends and grabbing coffee at the 7-11 on weekdays, Saga should be able to choose the right sensor to verify that.

Figuring out the battery — and therefore being able to check location more frequently — means Saga (or, conceivably, any app using similar methods) can do a lot more things. It can know that you’re on your daily jog, for example, not just that you’re at the park. It can understand that you have a meeting from 1:00 to 2:00 every afternoon and probably don’t want to receive notifications during this time.

The bigger picture is that the next-generation of wearable devices could get even smarter and retain a charge even longer than they do now. “Right now we’re in this world where wearables are akin to pieces of jewelry,” Hickl said. “The wearables we’ll see in the next 18 months are going to be more like … the Dick Tracy watches.”

Saga is on phones right now because they’re a relatively easy place to build an app and have access to sensors and computing power, he said. But it’s conceivable some of Saga’s functionality could make its way into devices like Nike Fuel bands or the Jawbone Up should they become more powerful. What’s more, your collection of wearable devices and an app like Saga could become their own life-logging ecosystem, each sharing data and filling in the blanks where others left off or if you forgot to wear one on any given day.

“The reason we couldn’t do it before,” Hickl said, “is we were just running into that battery wall.”

… and if you don’t feel like re-inventing (Saga’s) wheel, there is an SDK and API for that: http://www.newaer.com/ location and proximity API at less than 1% battery drain per hour. and server-side actions, if you choose to do so.

This is approach is pretty trivial and not really new – anyone who wants to do a product that does background location and sensing has to do some sort of smarter control over the sensing and fuse multiple signals. Its been done many times by companies and in academia, so nothing really exciting here…