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

location provider ping-pong? #1586

Open
tve opened this issue Jan 25, 2024 · 4 comments
Open

location provider ping-pong? #1586

tve opened this issue Jan 25, 2024 · 4 comments
Assignees
Labels
Milestone

Comments

@tve
Copy link

tve commented Jan 25, 2024

  • App build number: 2.4.12 installed from Google Play (would much prefer F-Droid!)
  • Android version: Android 14, degoogled version of AOSP, CalyxOS to be specific
  • Device: Pixel 7

I'm having an issue with what I would describe as location provider ping-pong. I have GPS enabled and I believe that in this location the wifi hotspot mapping is inaccurate. The result is that the device seems to jump back and forth between the locations. Here's a trace and notice how it periodically bounces between 32.499,-100.818 (GPS) and 32.50259,-100.81661 (presumably wifi/hotspot location mapping). (Note that I did change the integer part of the location for obfuscation.)

Obviously, the fact that the hotspot location is incorrect isn't owntracks fault, however, this seems like a fairly generic problem and it would be nice for owntracks to filter the updates and not use the less accurate hotspot location when it is getting GPS updates. Maybe this is not possible, I'm not that intimately familiar with the Android API.

Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:58:31 owntracks/tve/pixel7                t=  tid=l7 loc=32.49944,-100.81808 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:58:45 owntracks/tve/pixel7                t=  tid=l7 loc=32.49943,-100.81807 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:58:59 owntracks/tve/pixel7                t=  tid=l7 loc=32.49942,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:10 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:13 owntracks/tve/pixel7                t=  tid=l7 loc=32.49943,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:25 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:27 owntracks/tve/pixel7                t=  tid=l7 loc=32.49943,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:40 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:40 owntracks/tve/pixel7                t=  tid=l7 loc=32.49944,-100.81805 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 01:59:54 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:08 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:22 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:36 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81806 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:00:50 owntracks/tve/pixel7                t=  tid=l7 loc=32.49948,-100.81803 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:04 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81803 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:18 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81804 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:32 owntracks/tve/pixel7                t=  tid=l7 loc=32.49946,-100.81805 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:40 owntracks/tve/pixel7                t=  tid=l7 loc=32.50259,-100.81661 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:01:46 owntracks/tve/pixel7                t=  tid=l7 loc=32.49947,-100.81805 []  (...)
Jan 24 18:02:10 cloud ot-recorder[1440791]: * 02:02:00 owntracks/tve/pixel7                t=  tid=l7 loc=32.49945,-100.81808 []  (...)

This is how it looks like on the map:
image

@growse
Copy link
Collaborator

growse commented Jan 25, 2024

For the non-Google API, the current approach does subscribe to both GPS and non-GPS (network etc.) providers, and those locations arrive independently. Having something that can intelligently filter these is on the TODO list. I'm hoping this is partially fixed in the upcoming v2.5, but there's a number of challenges here that I think can only really be borne out through testing on different devices.

Is your non-GPS location coming with large accuracy value that can be filtered with the ignoreInaccurateLocations setting?

@growse growse added the bug label Jan 25, 2024
@tve
Copy link
Author

tve commented Jan 25, 2024

Sadly the accuracy is useless for filtering. Here is a summary of the positions reports truncated to three decimals over the past ~24 hrs. The position with lat=30.502 is the inaccurate one:

  count acc,lat,lon
    645 100.000,30.499,-110.818
    551 10.000,30.502,-110.816
    378 48.000,30.499,-110.818
     23 3.000,30.499,-110.818
     10 48.000,30.499,-110.817
      8 4.000,30.499,-110.818
      7 18.000,30.499,-110.818
      7 15.000,30.499,-110.818
      6 24.000,30.499,-110.818
      6 16.000,30.499,-110.818

The location provider stuff comes from micro-g, I've had everything enabled as shown in the screen shot below. I did disabled the Mozilla/hotspot sources and left only the two "remember from GPS" a bunch of hours ago and it seems to make no difference. Reboot coming...

@growse growse added this to the Backlog milestone Jan 26, 2024
@growse growse self-assigned this Jan 26, 2024
@growse
Copy link
Collaborator

growse commented Jan 26, 2024

Fair enough re: accuracy. That's annoying, I agree. Will work on a better solution for the future, probably will put the received locations through a kalman filter + some other sort of intelligence based on source and recent history.

@Intenos
Copy link

Intenos commented Oct 6, 2024

I experience the same issue with an Andoid phone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants