Testing of my Job Tracker app continues in earnest and, I’m pleased to say, it is becoming a useful tool that my brother is beginning to integrate into his day.
While this is all very positive, there is a new issue that reared its head yesterday and it’s a doozie! One of the functions of the app is to capture the user’s location at appropriate times. The app will then analyse this location and take action using this information. One of the actions it takes is determining whether or not the user’s van has moved in between and entry and exit event (getting in and out of the van). It does this by comparing the current position (exit) with the last known position (entry). If the distance is greater than 100m, we assume the van has moved.
Yesterday, whilst on a job, the app determined the van had moved, in spite of the fact it hadn’t. It recorded two positions:
I then check the logging provided by the device (I use my own HTTP Logging module that sends the logs directly to an Azure web application). The first block of logs show the position being recorded.
It clearly indicates the position has an accuracy of 36.0m and an age of 34 seconds, which is within the 50m /1min tolerance defined by the application. I read this as meaning that they are 36m from this position, at the very most. The user then returns to the van to get something and, as they walk away, an exit event is triggered and the application determines their location again.
This position has an accuracy of 26m and an age of 24 seconds, which is an slight improvement over the first and to be expected as the FusedLocationAPI gets better with time.
When I compare the actual distance between those locations, I get 0.11km, a distance of 110m. This is outside the 100m allowance and the system therefore creates a new record. This behaviour is throwing a spanner in the works!
Given the two accuracies of 36m and 26m, I believe the theoretical max distance between these two positions is 52m, well within the 100m. I just cannot see how they are 110m apart. I realise that the distance was 10% greater than the allowance, which isn’t really that much in GPS terms (10m is nothing!), but it’s enough to reduce the usefulness of this app, because the arrival and departure times are wrong.
I am going to reduce the location filter from 50m to 40m and see what effect that has. Lowering this could cause greater battery drain as the GPS radio needs to be on for a little longer, but I need to see what effect it will have.
Do you have any experience with Android and the FusedLocationAPI’s accuracy? If you’ve done anything in this space, I’d like to hear your experience.
Tomas McGuinness 