...

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