If you’ve ever looked at the path drawn by your phone’s GPS you might have realized there are some inaccurate periods, usually when there are few or no cell towers around to help triangulate. This problem is exacerbated when out in the wilderness, where there can be dense foliage and little reception.
I first noticed this issue using Strava to track mountain biking routes. Out of three phones, none agreed on total distance traveled on the given route. Strava uses an algorithm to rectify the data once uploaded, using some amalgamation of position by other users who have submit data, or maybe even based on the original person who “originated” the route.
Under normal circumstances, GPS will eventually update and readjust your position, but in the middle of a thick forest the frequency of these updates dwindles, and huge inaccuracies develop should you try to smooth data between points, as seen below.
With this in mind I set out to try and increase positional accuracy using the other sensors on a phone — the accelerometer, magnetometer, gyroscope, etc. Depending on the phone, some of the sensors (linear acceleration, gravity, etc) are software implemented, meaning they are derived from other sensors and there is no way to tell without digging into the hardware of each particular phone. I tried to use those that would typically be hardware implemented in any modern phone, though I recorded data for all.
Regardless, I immediately ran into two problems:
- I couldn’t find any apps that recorded both GPS and other sensor data, so I’d have to run two apps simultaneously and have them compete to stay running in the background, a risky proposition.
- Of the sensor data recording apps I did find, I couldn’t guarantee they’d be recording at the highest frequency possible nor record all possible variables.
Recording directly into an SQLite3 database, I was able to guarantee maximum granularity of the data by cranking the polling frequency (or at least politely requesting android to).
To help in exploratory analyses and understanding the data, I created an ability to “mark” times. For example, I could “mark” after each 90 degree turn in a recording session and see what behavior that had in the input values.
To be continued in Part II.