improving geofencing

[PatGendre]

Hi, for the record even if for the moment I have not tested extensively : we miss many trips (at least on Android), which go undetected or very lately detected because geofence exit is not detected so the state remains "waiting for trip start".
Of course, GPS was on, and is_duty_cycling was true.
I didn't really test on iOS, is this geofence issue possibly also on iPhone?

I try to document as much as possible the proper transition from waiting for trip start to ongoing trip and back is quite essential for end users to trust the application, even before the pipeline is run, so even if of course it cannot be 100% accurate, the end user should understand what's happening and what can be done at his/her level.

When looking at : https://developer.android.com/training/location/geofencing#Troubleshooting
we see that geofencing works better if wifi is On and there is a data connexion.
Did you also note this behavior?
Shall we strongly recommend the user to leave wifi and data ON when using e-mission?

The geofencing doc page says the radius shall not be too small : I suppose 100m is , did you test other values?
The doc page talks about a latency from 2 to 6 minutes but may be more if the app is in the background (https://developer.android.com/about/versions/oreo/background-location-limits.html), but this seems to concern only Oreo+ phones?

Finally, this stackoverflow post https://stackoverflow.com/questions/23708655/how-to-make-geo-fencing-alert-more-accurate-in-android includes an advice "Poll the GPS hardware on an interval without doing anything with the result and you'll start getting more accurate geofences." Do you agree with it ?
Another advice is to test specifically the geofencing, with this lib https://github.com/bsautermeister/GeoFencer . Do you think we need to do this and test more extensively?

[PatGendre]

I cannot say for sure, but my impression is that in practice the user has to have wifi and data connection on for the geofence exit/entry to work properly, is that correct?
Also, I've read again this article presenting Itinerum :
https://doi.org/10.1016/j.softx.2019.04.002
" Both mobile applications perform battery management for the location service by running as high-priority when movement is detected and switching to its low-priority (and less power-intensive) mode when stops are detected. On Android, the appli-cation begins by requesting high-accuracy points at a one-second
interval and monitors a 100 m diameter ‘‘rolling’’ geofence from the first available location. As shown by Fig. 3, if the phone re-mains within this geofence for one minute, the LocationManager will switch the state to medium-priority which prefers WiFi and cellular tower positioning that polls location at an interval of 10 s. If the user remains within the geofence for another three minutes, the LocationManager will switch the state to low-priority mode which uses the same location sources as with medium-priority, but polls at an interval of 60 s. At this point the user is prompted with Administrator-defined prompt questions (typically about the latest trip). If the device leaves the geofence at any time, it switches to high-priority mode to request a new point and establish the new ‘‘rolling’’ geofence (see Fig. 4)."

I have not tested Itinerum, and I don't have any idea on the battery consumption, but the algorithm seems convincing, do we proceed similarly in e-mission, or can the way they do in Itinerum bring any improvement?
What's your opinion?

[shankari]

When looking at : https://developer.android.com/training/location/geofencing#Troubleshooting
we see that geofencing works better if wifi is On and there is a data connexion.
Did you also note this behavior?
Shall we strongly recommend the user to leave wifi and data ON when using e-mission?

Yes. Do you not have WiFi and data on? What do you use your phone for? 😃

In particular, I have noticed that you need both data to be on AND to have a data plan so that your phone is connected to the cell towers. For more details see
e-mission/e-mission-data-collection#166

This was also reported by the Swiss group.

Sometimes when internet is absent (no data mobile or wifi) e-missions do not track trips. [e.g. last Saturday I went to Italy, and I do not have roaming there, and my daily log is empty]

[shankari]

If the device leaves the geofence at any time, it switches to high-priority mode to request a new point and establish the new ‘‘rolling’’ geofence (see Fig. 4)."

From this, it looks like they are also using geofencing, and geofencing uses WiFi and cell towers. So does the medium/low accuracy sensing. So if you don't have WiFi and cell tower connections, you have to use high accuracy (GPS-based) sensing at all times.

As documented in e-mission/e-mission-data-collection#166 if there is a strong demand for a backup/alternative to geofencing, I would want to experiment with motion activity instead since that uses the accelerometers, which users can typically not turn on/off. There is even a new API for motion transitions https://developer.android.com/guide/topics/location/transitions that looks promising but I have not had time to experiment with it yet.

[shankari]

If you want to look at the power drain across different accuracies, here is some testing that I did in order to pick geofencing as the solution.
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-119.html

I have re-started the evaluation/benchmarking as part of the em-benchmark effort and it is interesting that the power curve for high accuracy sensing is now different - it looks like Google Play Services now automatically throttles data collection (see the sharp bend in the curve at around 2.5 hours).

That bend corresponds to the dip in the density of data collection below.

So we may not need as much duty cycling on android going forward.

Note that this with WiFi and data plan enabled. I have not tested the power drain or location quality with WiFi and data plan disabled, because I didn't think that it was an important use case. Let me know if you think otherwise.

Incidentally, you can explore the same curves by launching a binder at
https://github.com/e-mission/e-mission-eval-public-data
and using the parameters

DATASTORE_URL = "http://cardshark.cs.berkeley.edu"
AUTHOR_EMAIL = "[email protected]" # e.g. [email protected]
CURR_SPEC_ID = "sfba_calibration_only_1" # e.g. sfba_calibration_only_1
MAX_DURATION_VARIATION = 5 * 60 # seconds

in the calibration_template

[shankari]

actually, re-reading the documentation on Itinerum, it is not clear whether they are using the geofencing API, or whether they are re-implementing a "geofence" of their own. Regardless, medium accuracy/low accuracy sensing should use WiFi/cell tower for positioning...

the LocationManager will switch the state to medium-priority which prefers WiFi and cellular tower positioning that polls location at an interval of 10 s.

[PatGendre]

@shankari thank you so much for responding so much in detail to my quite naive question :-)
Yes I do (or did) stop data and wifi when not using the phone (like I switch off the light when I leave a room), I tried to find some figure of the share of people who do the same, but couldn't in 5 minutes, I will try to look up... I will ask to the few testers we have what they think, also.

Anyway it is enough to have confirmation that e-mission should definitely be used with wifi and data on in the current setup, it is sufficient to explain it to the end-users and not a big problem at all. The UI could maybe warn the user when either data or wifi is off, we'll see with Loïc if we can add this.
Issue 166 and feedback from the Swiss is convincing in that respect.

The update on your benchmarking is quite promising on the behaviour with newer phones, as is the activity transition API. We will have the opportunity to discuss about it, even if it is the top priority I guess.

[shankari]

Closing this issue for now since it seems to be related to the lack of data and WiFi.