26 April - Evaluation of GPS Logger (Basic Air Data)
We are investigating the quality of GPS Logging that can be achieved by Android Apps, without using Gogle Location Services.
Basic Air Data GPS LOgger was of particular interest because it is Free Open Source Software.
https://play.google.com/store/apps/details?id=eu.basicairdata.graziano.gpslogger&hl=en
Permissions sought by the App
Same as Safe Paths: just location data + Storage to send data.
Data Accuracy
Self-reported accuracy varied from 3m to 214m, average of 8.4m. This includes a section in thick wood
I only had one phone this time, so not able to compare logs from different phones
Comparing the trail with a map, this appears to be spot-on accurate.
Tomorrow I will try to do the same route with 3 phones, to further validate the accuracy.
Timing of log generation
I configured for every 3 seconds (the max interval supported; it advises that 1 second give better accuracy). Logs were rock solid every 3 seconds exactly for the 45 minute logging period.
Battery performance
It used 2% of my battery over 45 minutes. Note that my phone has a hefty 5,000 mAh battery. So that’s 133mAh/hour of operation.
However, we would ought to be able to get away with 15 seconds or so of GPS activity every 5 minutes. So that’s the equivalent of 3 minutes/hour, or 72 minutes / day, which would use 160 mAh / day. That’s < 10% of the battery of a typical phone and probably acceptable.
For comparison, currently my phone reports that COVID Safe Paths has useed 4% of the battery over 8 hours - that’s 200 mAh over 6 hours, or 600 mAh/day.
Open Source License
The repository for the source code is here:
https://github.com/BasicAirData/GPSLogger
The code is licensed under GNU GPL. This means that we could not incorporate code directly into Safe Paths without the GNU GPL applying to Safe Paths as well, which is probably unacceptable.
Other Points
This point is recorded in the App Q&A. It could imply problems for Safe Paths - we may need to develop extensive user guidance for this issue, for many models of phone.
https://github.com/BasicAirData/GPSLogger/blob/master/readme.md
Q - The App sometimes stops recording when running in Background.
A - The App could be closed by the System during the Background Recording. To avoid it, as first step, go on the Android Settings and turn off all Battery Monitoring and Optimizations for GPS Logger. On Android 9 check also that the Application is NOT Background Restricted. Unfortunately any Device Brand implemented in a different Way the Settings to keep safe the Background Apps, so a small Research must be done. For example, for some brands you have to whitelist the background apps, whilst for some others you have to set the "high performances" power saving mode. Moreover some Anti-Viruses are very aggressive with long running Apps, and must be correctly set
I also noticed that while loggging GPS data, the App has a notification, which cannot be dismissed, reflecting what we see on Safe Paths: Git Hub #473. That suggests that perhaps this issue cannot be fixed.
Learnings
It is possible to get sufficiently accurate GPS data, using standard Android hardware and the same permissions that Safe Paths uses today - with an acceptable battery load.
We have not yet understood how this is achieved and how the algotihms of the GPS Logger tool differe from Safe Paths GPS recording algorithms, but this is a topic we can investgate further.
There may be some issues with battery optimizations disabling GPS, which may be challenging to avoid, and may need make/model-specific guidance for users.
Part 2 - Testing with multiple phones - 27 April
I did the same test as previously with 3 phones on a 40 minute walk. This chart shows the distances between the GPS positions reccorded by the 3 phones over the furst 20 minutes
Data Accuracy
Bear in mind that part of the walk was mostly in a wooded area - I think the two argest spikes correlate with that. Also note that all 3 phones were in pockets in my jeans (a realistic scenario).
GPS data points were taken every 3 seconds. There was a slight drift (no major jumps), such that by the end there was a 17 second gap in timestamps (betwen A & C; B was in between). I was walking at about 1m/second, but oddly this doesn’t seem to have made the accuracy any worse…
If we discount the periods where I was in the woods, the phones seem to agree to withn 20m on location almost all the time. This is definitely better than the Safe Paths App, but still some way off what
This chart shows the “self-reported accuracy” data (the max of any pair of self-reported accuracies). If the self-reported accuracy was correct, all the data would be below the black line. It mostly is, but not entirely.
For the 2nd part of the walk, which was more open, I had lost C (more on that later,
I rebased the A & B series to have a synchronized start time again (and they stayed sync’d throughout, suggesting that the drift was due to poor GPS signal in the woods.
In these better conditions, they stayed within 15m of each other almost all the time.
Reliability
Bringing in new phones exposed some interesting issues. Fortunately Basic Air Data has better error messages than Safe Paths, so I was able to identify some issues that would have gone unnoticed before.
On the Redmi 6A, I was warned that GPS was not enabled.
In settings, the phone offered 3 options for location detection
WiFi only (default)
GPS only
WiFi + GPS
For the test, I moved to the GPS setting, but all my Safe Paths testing previously must have been with WiFi.
Then, after about 20 minutes, it stopped recording. I didn’t notice until the end (since the phone was in my pocket), but there was a warning pop-up that said that the App had been killed during background recording by a battery saver process,
It advised me to check the phone battery settings.
This kind of problem will have been impacting Safe Paths as well, but we won’t notice it. I presume that there is no way for an App to address this directly, other than flashing warnings to the user.
Implications for Safe Paths
It should be possible to get GPS accuracy across multiple phones to ~20m in open good conditions, with spikes up to 30m in worse conditions (e.g. under tree cover). It is unlikely we can do much better than that.
Therefore our assumption that a “contact” should be determined by a GPS distance of 20m might be based on unreasonable assumptions about GPS accuracy.
Some phones have GPS disabled by default, and do location detection through WiFi only by default. It is posisble for an App to detect this and direct the user to change their settings. We should consider adding this function. We should also experiment with a range of popular phones to determine what the common sets of options & defaults are.
GPS background logging is frequently killed by battery saver options on phones. It is not possible for an App to stop this, but it is possible to detect that it has happened and warn the user. Again, we should consider adding this function, and testing with popular phones to determine what the common sets of options & defaults are.
Part 3 - Stationary Phone
FInal test was a stationary phone, WiFi off. I left it for 35 mins, indoors, with GPS pings every 3 seconds.
It never varied more than 2m away from the start point.
Compared to the wild variatons of 50m we were seeing with Safe Paths, this is a much much bettter performance.
With GPS + WiFi, we see slightly slower convergence; 5 data points / 15 seconds before the signal is fully trained (scattered at the top), and after that the signal is solid).
In any case, data is always within 6m.
Input from Graziano
I reached out to the author of Basic Air Data, Graziano for some advice - here’s the trail:
> Ciao Graziano,
>
> I'm a volunteer working on an Open Source, Privacy-first GPS-based
> digital contact tracing project, COVID Safe Paths.
>
> https://covidsafepaths.org/
>
> We are one of the few COVID contact tracing projects that are
> GPS-based. Most projects are focussing on Bluetooth due to privacy
> concerns around GPS. However, we are using techniques developed at MIT
> that enable GPS based contact tracing in a privacy-protecting way.
>
> (more details on the specific techniques here:
> https://arxiv.org/abs/2003.14412)
>
> I'm working in our testing team, and have been testing our GPS
> logging.
>
> We have been using your GPS logger as a reference, and it is clear
> from these tests that our App is not performing as well as it could,
> in terms of reliability and accuracy of GPS logs.
>
> We are a small team, with a lot to do, and while our engineers have
> some ideas for how to improve our GPS logging, I am concerned that we
> could spend a lot of time and effort to get to an acceptable level of
> reliability & accuracy.
>
> I was wondering whether you might be able to spare a bit of time to
> share some of the expertise that you have built up with GPS Logger, to
> help us to improve our accuracy?
>
> Particular areas of concern are:
> - Stabilizing a signal: if we want to record a GPS data point every 5
> minutes (which is the current design), what's the best way to get an
> accurate GPS data point, with minimal time & power consumption?
> - Dealing with battery optimizers that interfere with background GPS
> logging. It seems you have a lot of experience in the various problems
> here & how to detect them
>
> Please let me know if you might be interested in working with our team
> of developers. Even if you could only spare an hour or two of guidance
> in this area could be very helpful, as I am sure it would save us from
> making many costly mistakes.
>
> Warmest regards,
>
> Diarmid Mackenzie
Dear Diarmid,
We are a small group of people that share design, testing, and every
field experience regarding DIY air data instruments.
There is no money behind this open project, only passion, and desire to
do something useful.
Thus, first of all, I would like to thank you for your feedback about
GPS
Logger, one of our active tasks: we are glad to know that it is useful
for a good purpose.The Logger app is very simple, and it has been made to be informative
and didactic.
It is developed in Java, 100% opensource, GPL licensed and doesn't
contain any Google API dependency.In these days we look into the covidsafepaths GitHub repository, and we
thought about your questions in order to try to write an answer.Regarding the accuracy: when we start to develop the app we had to
choose between accuracy and power saving, and we chose the first one.
In fact, our app uses a short interval between FIXes in order to avoid
the switch-off of the GPS sensor. In general, the GPS sensor remains
active for 5 seconds; if you set a longer interval between fixes, the
GPS turns off and on, with a great impact on accuracy. Within our app
the user simply cannot set a FIX interval longer than 3 seconds. This is
the reason why GPS Logger is very accurate, and why We didn't deepen the
problems related to higher FIXes intervals.
A good way to obtain an accurate FIX is, to be concise, to keep active
the GPS for at least a couple of minutes before obtaining the desired
position.Regarding Battery Optimizations: we are fighting a battle lost in
advance because we need to have a background process that runs forever,
but every Android version and every Manufacturer implements different
and new ways to kill it. Internet is sadly full of "this or that app is
killed in background" complaints. The topic is a complete mess.We are currently using a Foreground Service to prevent Android from
killing the Application as soon as the system needs resources; We create
and bind the service when the app is in the foreground or is recording a
track in the background. Furthermore, we use WAKE_LOCKs to prevent the
the system from sleeping.But We think this is not your case, because maybe you need a
scheduled wake-up method instead, that execute a task every 5 minutes.
As far as We know Google offers a set of alarms (the AlarmManager class
for example) that you could use to schedule your periodic recording
task, but we don't deepened this topic.
Furthermore, Google is "pushing" the developers to migrate to Google
Cloud Messaging (Firebase) to perform periodic tasks.Unfortunately, your specifications are very different from ours, and
they
require a completely different approach.
Last but not least, unfortunately, none of us develops with the language
you are using to make covidsafepaths app.We think that a good Android app that is similar to your GPS
specifications could be this one: https://github.com/mendhak/gpslogger ;
it records with long intervals between fixes, it uses Google Fused API,
it is opensource and it implements some interesting solutions that could
fit your needs.
Best Regards.Graziano