Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPS accuracy is worse after switched to FusedLocationProvider #2008

Closed
lognaturel opened this issue Mar 13, 2018 · 8 comments
Closed

GPS accuracy is worse after switched to FusedLocationProvider #2008

lognaturel opened this issue Mar 13, 2018 · 8 comments
Labels
bug high priority Should be looked at before other PRs/issues

Comments

@lognaturel
Copy link
Member

lognaturel commented Mar 13, 2018

Software and hardware versions

Collect v1.11+

LG G5: 7.0
Samsung Tab A: 5.0.2
Xiaomi Redmi 4 Prime: 7.0
Xiaomi Redmi 4A: 6.0.1

Problem description

https://forum.opendatakit.org/t/gps-accuracy-cannot-go-beyond-10m/12176

Location settings set to high accuracy on G5 and GPS, Wi-Fi and mobile network on Samsung SM-P355. I changed to different settings, the issue still exists.

Also my colleague on different location reporting the same issue using Xiaomi Redmi 4 Prime and Xiaomi Redmi 4A.

Steps to reproduce the problem

Confirmed on Moto G4, Galaxy Tab A with All Widgets form.

Expected behavior

GPS accuracy should be the same or better after the change.

Other information

Possibly related: https://forum.opendatakit.org/t/infinite-spinning-while-getting-location-with-bluetooth-gps-device/12156

@lognaturel lognaturel added needs reproduction bug high priority Should be looked at before other PRs/issues and removed needs reproduction labels Mar 13, 2018
@lognaturel
Copy link
Member Author

The devices I have are also not going under 10m in accuracy currently. I can get higher accuracy by forcing AndroidLocationClient in LocationClients. This is very puzzling because I am convinced I've gotten better accuracies than that recently. There's some evidence of that at #1336 but I don't have more recent proof. @mmarciniak90 is this part of your release testing? Can you please see what you're getting with your test devices?

Play Services versions are 11.9.75 and 12.2.18.

@lognaturel
Copy link
Member Author

I've tried a location demo app and am also seeing 10m as the best accuracy reported by the fused provider. The good news is that this probably means there's nothing wrong with the implementation and that users have been getting high-accuracy points, just not good accuracy values. The bad news is that fused provider probably isn't the right thing to use since users do want to get feedback on accuracy, especially when using an external device. There's a big difference between 1m and 10m accuracy.

I've posted a StackOverflow question about this here. The likely fix will be to go back to using the raw location manager. I've sent in #2021 so we can confirm that it does provide better accuracies with no visible negative side effects.

@mmarciniak90
Copy link
Contributor

@lognaturel As a part of release testing I check that location is determined. I will add a test to check accuracy and time needed to determine it.

@lognaturel
Copy link
Member Author

Closed for now by always using LocationManager

@lognaturel
Copy link
Member Author

Update on this! It's a real bug on Google's side -- we weren't going crazy: https://issuetracker.google.com/u/0/issues/79189573#comment20

Google claims the next Play Services release will address the issue. Since phones, especially in the field, do not get Play Services releases often, we'll need to think carefully about if and when we want to go back to the FusedLocationProvider. As we've seen with this episode, it's a source of risk because that library is not open source and subject to change at any moment.

I hesitate to add more settings, especially odd ones like this, but we may want to either give user some control over the provider or perhaps check for Play Services version.

CC @florianm since we were talking about this recently.

@florianm
Copy link

Update on devices:

Tested on Lenovo Tab 7 Essential (TB-7304F) and Lenovo Tab 3 7" (TB3-710F), ODK Collect 1.17.2:

With Android system settings > Location mode "high accuracy (WiFi, Bluetooth, GPS)":

  • Indoors (no GPS reception, WiFi reception), WiFi on: no Geolocation even after 20 mins in the ODK Geolocation widget
  • Outdoors (GPS reception, still WiFi reception), Wifi on: no GPS fix - I'd expect ODK to at least get a fix from WiFi.
  • Outdoors (GPS reception, no Wifi) need to test again

Location mode "Device only (GPS)":

  • Indoors: no GPS reception, no GPS fix
  • Outdoors: (GPS reception, WiFi reception), WiFi on: GPS fix
  • Outdoors: (GPS reception, WiFi reception), WiFi off: GPS fix

I'd expect to get a Geolocation from WiFi if no GPS is available.

As a suggestion, it would be great to see diagnostics on the Geolocation widget besides number of satellites (which itself is great): location mode (is GPS even on), which location provider is used (Wifi? GPS? others?). This would help diagnosing the "can't get a Geolocation" problems.

@florianm
Copy link

Update on inferring GPS from WiFi:
Testing from my home WiFi with location settings "Wifi+GPS", I'm getting a location fix indoors while connected to that WiFi.

Testing from my work WiFi, same SSID, same setup, from three offices 1500 kms apart, ODK gets no location from WiFi. I assume therefore that this is a problem with our particular WiFi configuration and not a bug in ODK. Confusing for less technically minded trainers/users nevertheless.

@lognaturel
Copy link
Member Author

I should have been clearer! There have been no changes to the code yet because the Google fix is not released. I'm not totally sure that what you've seen from home means that you got a read from wifi. I believe GPS has to be off for wifi to be used at the moment because we are using those older libraries.

I think your idea of adding more troubleshooting information is a good one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug high priority Should be looked at before other PRs/issues
Projects
None yet
Development

No branches or pull requests

3 participants