Lemberg collaborates with agencies that provide location tracking solutions to their customers. One of the most popular areas of using our expertise is location tracking for skiing. This kind of solution requires an exceptional approach to QA and can’t be limited to application testing within your office walls.
Just to remind you, the primary focus of location tracking in skiing is calculation and measurement of coordinates, speed, distance, altitude and number of runs.
For analysing application success in accuracy of location tracking, the QA Team used a set number of routes. Every route let our QA Team understand how the application works on a particular landscape. They would then compare the testing results with previous results obtained on the same route. This helped them understand what exactly needs improvement.
One of our routes is located in the city and has the following known parameters:
Since we used different mobile devices for testing, the variety of results for one route was impressive. In this post, we will try to explain the why and how behind the differences in resulting data we got in the end.
What will go wrong in case of low GPS accuracy?
When testing mobile applications that track distance, altitude differences, and maximum speed, low GPS accuracy can lead to significant errors. The app may behave incorrectly in specific conditions where it was expected to change its state, switch to a different algorithm, ignore location data stream, etc.
Low accuracy corrupts the data gathered by your phone. Thus, the difference in results from different devices.
Measurement error accumulates and adds up, this can eventually distort the summary results. Therefore, the algorithms processing data from the GPS chip must be completely accurate. Ideally, the application algorithm should process all data correctly, but still it may not resolve all issues.
For those of you who are not familiar with the term GPS accuracy, here is a short outline “GPS Accuracy. A Complete Guide for Dummies”.
Tools
A bad workman always blames his tools. These are the tools that we used for testing, and the limitations that they have.
My Tracks (Android) My Tracks records your path, speed, distance, and elevation while you ride. While recording, you can view your data live, annotate your path, and hear periodic voice announcements of your progress. Using this app, we could compare the results with our app in real time. My Tracks uses the GPS sensor in your device to record geographic and velocity statistics. As aresult, user receives a KML file with recorded path. We later use this KML file in a different software further analysis. |  |
Google Earth (PC)
Google Earth is a virtual globe, map and geographical information programme. It can be used for visualisation of the KML file generated by MyTracks App. Google Earth recreates your path on the map, also showing a graph with key indexes of your track: time/ speed of movement/distance/altitude change. We use this precious tool to analyse the track and compare/contrast the results we got from My Track and our test app.
Below is an example of how we use Google Earth to analyse the track. It’s a graph that displays results of our test ride.
| Data | Description | |
| Length of runs (mi) | 1.68 | ~0.56x3= 1.68 (determine the distance of one run, multiply it by 3 - the number of runs) |
| Length of lifts (mi) | 1.11 | ~0.37x3=1.11 (determine the distance of 1 lift, multiply it by 3 - the number of lifts ) |
| Total Distance (mi) | 2.79 | 1.68+1.11=2.79 overall distance, a sum of all runs and lifts |
| Number of lifts | 3 | you can deduce that from the graph, by counting the number of drastic changes in the altitude (from 1036 ft to 935 ft) - the red line |
| Number of runs | 3 | you can deduce that from the graph, by counting the number of drastic changes in the altitude (from 1036 ft to 935 ft) - the red line |
| Altitude change (ft) | 303 | ~(1036-935)x3=101x3=303(altitude change is the difference calculated between highest and lowest altitude index) 1036-935=101, multiplied by the number of runs 101x3= 303 ft) |
| Top speed (mhp) | 28.9 | The blue line of the graph reaches its highest spot - during a run, of course |
Accuracy Check For Our Devices
Now we go to the test results. To check accuracy, we took into account the conditions below:
| Location | City |
| Housing density | High |
| Сloudy | Average |
| State of GPS module | On |
| State of WiFi module | Off |
| State of GSM module | Off |
| Speed range | 0 - 60 km/h |
The number of different Android devices just rolls over, each one using a different type of GPS receiver and having a different accuracy. Therefore, testing was conducted on the devices running on OS Android, iPhone will be saved for later.
The results are provided in the table below. The smaller accuracy value the better.
| Device | GLONASS | OS | Accuracy in city (Static position), m | Accuracy in city (walk outdoors), m | Accuracy in city (drive a car), m | |
| Google Nexus One | - | 2.3 | 10 | 10-15 | 15-15 | |
| Samsung Galaxy Nexus S | - | 4.1 | 10 | 10-15 | 10-15 | |
| Samsung Galaxy Nexus | - | 4.3 | 5 | 5-15 | 10-30 | |
| BEST | LG Nexus 4 | + | 4.3 | 3 | 3-4 | 6-11 |
| WORST | Samsung Galaxy SI | - | 2.2 | 10 | 10-15 | 10-30 |
| Samsung Galaxy SII | - | 4.2 | 5 | 5-15 | 10-30 | |
| Samsung Galaxy SIII | + | 4.2 | 5 | 6-8 | 8-16 | |
| Samsung Galaxy Note | + | 4.1 | 5 | 5-8 | 8-16 |
 Nexus 4: 11 satellites in use (best accuracy) 69-70: Glonass satellites |  Galaxy SI: 5 satellites in use (worst accuracy) |
- Samsung Galaxy SI
- Samsung Galaxy SII
- Samsung Galaxy Nexus
| Worst Tracking Results | Device’s GPS module description |
 | Manufacturer: Avago The Avago ALM-3012 is an ultra low-noise GNSS front-end module that combines a low noise amplifier with a GNSS FBAR post-LNA filter, supporting both GPS and GLONASS. Glonass: Supported (confirmed activated in software)
|
Summary
When using GPS on your phone to track your location, or even something more sophisticated like distance or altitude, you take the results for granted. But if you had two phones, each tracking your location (for example, one high-end and one less so), you would be surprised at the difference in results that you may get.
These differences are especially felt when a QA team are checking how a location tracking app works on different devices. Ideally, the app is supposed to show the best results on any device, but when it comes to the limitations of hardware, there is very little a software engineer can do to make up for it.
In any phone’s hardware set, the GPS chip is the primary influence factor.
The best device for GPS tracking from the set of our devices is Nexus 4 (At this moment we assume that should be Nexus 5, but our future tests have yet to prove this, so stay tuned)
All of the new high-end mobile phone chip-sets (and many of the low-end) support GNSS (Global Navigation Satellite System) which means they support both US NAVSTAR GPS satellites and Russian GLONASS satellites. This gives you a better choice of satellites to draw from when you are in the field.
SEE ALSO: