Missing Geo Points At Random Times

[alhassanreem]

Your Environment

• Plugin version: 4.17.1
• Platform: iOS
• OS version: 17.5.1
• Device manufacturer / model: iPhone 13 Pro
• React Native version: 0.71.19
• Plugin config

BackgroundGeolocation.ready({
      desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
      distanceFilter: 1,
      stopOnTerminate: false, 
      enableHeadless: true,
      showsBackgroundLocationIndicator: false,
      disableElasticity: true,
      desiredOdometerAccuracy: 10,
      logLevel: BackgroundGeolocation.LOG_LEVEL_VERBOSE,
      stationaryRadius: 5,
      stopDetectionDelay: 10,
      stopTimeout: 15,
      startOnBoot: true,
      maxRecordsToPersist: 0,
      backgroundPermissionRationale: {
        title: "Allow Solo to access to this device's location in the background?",
        message: t(TRACKING_MESSAGE),
        positiveAction: 'Change to {backgroundPermissionOptionLabel}',
        negativeAction: 'Cancel',
      },
    })

Expected Behavior

an uninterrupted stream of geo points that maps the entire route step by step

Actual Behavior

After upgrading from 4.14.4 to 4.17.1, we see some gaps in geo points at random times in every trip we've tested

Steps to Reproduce

Taking any trip that includes regular traffic delays, traffic light stops, parking lot exits/parking

Context

We are trying to understand what is causing the gap in geo points at times

Debug logs

background-geolocation (3).log

Logs

║ -[TSLocationManager locationManager:didUpdateLocations:] Enabled: 1 | isMoving: 1 | df: 1.0m | age: 51 ms
╚═══════════════════════════════════════════════════════════

2024-09-11 18:32:16.053 🔵-[TSLocationManager calculateMedianLocationAccuracy:] Median location accuracy: 4.8

2024-09-11 18:32:16.053 ℹ️-[TSConfig persist] 

2024-09-11 18:32:16.054 🔵-[TSConfig incrementOdometer:] 2551684.6

2024-09-11 18:32:16.054 ℹ️-[PolygonGeofencingService setLocation:] Already updating location <IGNORED>

2024-09-11 18:32:17.048 
📍<+47.60018076,-122.29715073> +/- 4.77m (speed 12.94 mps / course 13.18) @ 2024-09-11, 18:32:17 Pacific Daylight Saving Time

2024-09-11 18:32:17.048 
╔═══════════════════════════════════════════════════════════
║ -[TSLocationManager locationManager:didUpdateLocations:] Enabled: 1 | isMoving: 1 | df: 1.0m | age: 46 ms
╚═══════════════════════════════════════════════════════════

2024-09-11 18:32:17.048 🔵-[TSLocationManager calculateMedianLocationAccuracy:] Median location accuracy: 4.8

2024-09-11 18:32:17.048 ℹ️-[TSConfig persist] 

2024-09-11 18:32:17.049 🔵-[TSConfig incrementOdometer:] 2551697.9

2024-09-11 18:32:17.050 ℹ️-[PolygonGeofencingService setLocation:] Already updating location <IGNORED>

2024-09-11 18:34:48.147 ℹ️-[TSDBLogger db_save] Log committed

2024-09-11 18:34:48.152 
📍<+47.61387999,-122.28926545> +/- 3.90m (speed 11.52 mps / course 2.81) @ 2024-09-11, 18:34:48 Pacific Daylight Saving Time

2024-09-11 18:34:48.152 
╔═══════════════════════════════════════════════════════════
║ -[TSLocationManager locationManager:didUpdateLocations:] Enabled: 1 | isMoving: 1 | df: 1.0m | age: 122 ms
╚═══════════════════════════════════════════════════════════

2024-09-11 18:34:48.152 🔵-[TSLocationManager calculateMedianLocationAccuracy:] Median location accuracy: 4.8

2024-09-11 18:34:48.152 ℹ️-[TSConfig persist] 

2024-09-11 18:34:48.158 🔵-[TSConfig incrementOdometer:] 2553332.3

2024-09-11 18:34:48.159 ℹ️-[PolygonGeofencingService setLocation:] Already updating location <IGNORED>

2024-09-11 18:34:48.162 
╔═══════════════════════════════════════════════════════════
║ -[TSLocationManager createMotionTypeChangedHandler]_block_invoke | in_vehicle/100 | isMoving: 1
╚═══════════════════════════════════════════════════════════

2024-09-11 18:34:49.152 
📍<+47.61398782,-122.28926193> +/- 3.54m (speed 11.52 mps / course 1.41) @ 2024-09-11, 18:34:49 Pacific Daylight Saving Time

2024-09-11 18:34:49.152 
╔═══════════════════════════════════════════════════════════
║ -[TSLocationManager locationManager:didUpdateLocations:] Enabled: 1 | isMoving: 1 | df: 1.0m | age: 152 ms
╚═══════════════════════════════════════════════════════════

2024-09-11 18:34:49.152 🔵-[TSLocationManager calculateMedianLocationAccuracy:] Median location accuracy: 4.8

2024-09-11 18:34:49.153 ℹ️-[TSConfig persist] 

2024-09-11 18:34:49.156 🔵-[TSConfig incrementOdometer:] 2553344.3

2024-09-11 18:34:49.159 ℹ️-[PolygonGeofencingService setLocation:] Already updating location <IGNORED>

[christocracy]

PolygonGeofencingService has absolutely nothing to do with your problem. I will remove that log message so you don’t see it.

[christocracy]

Show me a screenshot of your problem with locations displayed on a map,

[christocracy]

If you’re not monitoring polygon geofences, the PokygonGeofencingService, which receives every recorded location, does nothing. Red herring

[alhassanreem]

this is a map of the route with all the geo points we received for that trip

[christocracy]

You're saying you experienced a loss of location-data at ~18:32:17?

I don't see that at all. I see a continuous stream of reported locations.

I see you're not using the plugin's built-in, pure native HTTP service and you've disabled the plugin from inserting recorded locations into its SQLite database. I don't trust HTTP requests through the react-native layer.

When you see this in the logs, the .onLocation event is 100% guaranteed to have fired.

2024-09-11 18:47:07.091 
📍<+47.68742524,-122.36700764> +/- 4.77m (speed 0.26 mps / course 155.07) @ 9/11/24, 6:47:06 PM Pacific Daylight Time

[christocracy]

Btw, here's me driving all over France for 2.5 weeks this summer using the demo app (iPhone 15 Pro, Google Pixel 6.)

https://www.transistorsoft.com/lab/france

[alhassanreem]

Correct, looking closely at the logs in particular I don't see a similar log to the one that indicates the .onLocation being fired during 2024-09-11 18:33 I see one fired before at 2024-09-11 18:32:17.048 and minute after at2024-09-11 18:34:48.152. Any idea what could of caused the logs to stop coming through between 2024-09-11 18:32:17.048 and 2024-09-11 18:34:48.152, I believe that is where we observe the jump in the map

[christocracy]

If the data exists in the logs, but not on your map, then you have a problem in your JavaScript / http / socket.

[alhassanreem]

I understand that part, but the issue is that I see no coordinates recorded in the logs for the time between 2024-09-11 18:32:17.048 and 2024-09-11 18:34:48.152

from the logs I see the following

Point 1

2024-09-11 18:32:17.048 
📍<+47.60018076,-122.29715073> +/- 4.77m (speed 12.94 mps / course 13.18) @ 2024-09-11, 18:32:17 Pacific Daylight Saving Time

and the very next one is Point 2

2024-09-11 18:34:48.152 
📍<+47.61387999,-122.28926545> +/- 3.90m (speed 11.52 mps / course 2.81) @ 2024-09-11, 18:34:48 Pacific Daylight Saving Time

[christocracy]

The native location api had no locations to provide during that period. This can happen in a dense downtown of a large city, where tall buildings and other large physical obstacles block GPS radio signals.

[christocracy]

I understand that part, but the issue is that I see no coordinates recorded in the logs for the time between 2024-09-11 18:32:17.048 and 2024-09-11 18:34:48.152

The logs you uploaded do not have these locations that you quote. If I search the logs for 18:32:17.048 or 18:34:48.152, those timestamps do not exist.

Please check the logs you sent me and search for those timestamps.

[christocracy]

[alhassanreem]

I can understand that. But the strange behaviour we are seeing on v 4.17.1 (the above logs) was not there on 4.14.4

Please try again, re-uploaded the logs (the wrong trip logs were uploaded earlier)

[christocracy]

But the strange behaviour we are seeing on v 4.17.1

You’re consistently reproducing this yourself? I’m field testing daily with my iPhone 15 Pro @ 17.5.1 — I’m not experiencing unusual behaviour on my daily walks / bike rides.

[christocracy]

showsBackgroundLocationIndicator: false,

I suggest you test with that set to true

[christocracy]

My last 7 days of tracking:

[alhassanreem]

Unfortunately, we are consistently seeing the same jump in geo points every trip we've tested. Here is a another set of logs for reference

Same Plugin config as mentioned above Plugin version: 4.17.1 Platform: iOS OS version: 17.5.1 Device manufacturer / model: iPhone 14 Pro React Native version: 0.71.19

seeing the jump between

2024-09-11 18:21:57.102 
📍<+47.59752654,-122.33156356> +/- 4.73m (speed 5.73 mps / course 0.77) @ 9/11/24, 6:21:57 PM Pacific Daylight Time

and

2024-09-11 18:24:12.839 
📍<+47.59457578,-122.33403727> +/- 137.67m (speed -1.00 mps / course -1.00) @ 9/11/24, 6:24:12 PM Pacific Daylight Time

background-geolocation (5) 3.log

[alhassanreem]

showsBackgroundLocationIndicator: false,

I suggest you test with that set to true

We can test that, will share logs once we have them

[christocracy]

There is no explanation for the delay between these two locations. The native location API is like a tap of water that drips locations according to your configured distanceFilter. The delay here is like the tap stopped dripping water.

2024-09-11 18:21:57.102 
📍<+47.59752654,-122.33156356> +/- 4.73m (speed 5.73 mps / course 0.77) @ 9/11/24, 6:21:57 PM Pacific Daylight Time
.
.
.
2024-09-11 18:24:12.839 
📍<+47.59457578,-122.33403727> +/- 137.67m (speed -1.00 mps / course -1.00) @ 9/11/24, 6:24:12 PM Pacific Daylight Time

One thing to note is that the accuracy of locations that finally started coming in after the delay were relatively poor:

- 137.67m
- 137.67m
- 137.67m
- 35.00m
- 59.86m
- 37.66m
- 34.62m
- 23.03m
- 20.35m
- 10.55m
- 7.80m
- 5.99m

Typical GPS accuracy is 5-10 meters. This sort of thing is indicative of the device losing access to GPS.

• going indoors / walking into a subway station
• driving into a tunnel.
• GPS obstruction by tall buildings.

[alhassanreem]

Yes, the logs seemingly going blank at times and picking right back up is a very strange behaviour especially that we don't see any action that suggests that a stop was detected or that the device was in a stationary state or anything that would explain why geo points weren't collected. Interesting to see the accuracy piece, I overlooked that part earlier. Again, the fact that we only see this behaviour of missing geo points at times on 4.17.1 but not 4.14.4 is why we are trying to understand what changed

More trips for reference: 1.

Device Details 

Plugin version: 4.17.1
Platform: iOS
OS version: 17.5.1
Device manufacturer / model: iPhone 13 Pro
React Native version: 0.71.19

Plugin config

BackgroundGeolocation.ready({
      desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
      stopOnTerminate: false,
      enableHeadless: true,
      logLevel: BackgroundGeolocation.LOG_LEVEL_VERBOSE,
      stationaryRadius: 1, 
      stopDetectionDelay: 10,
      stopTimeout: 15, 
      preventSuspend: true,
      disableElasticity: true,
      desiredOdometerAccuracy: 1,
      distanceFilter: 0,
      heartbeatInterval: 60,
      showsBackgroundLocationIndicator: true,
      startOnBoot: true,
      maxRecordsToPersist: 0, 
      backgroundPermissionRationale: {
        title: "Allow Solo to access to this device's location in the background?",
        message: t(TRACKING_MESSAGE),
        positiveAction: 'Change to {backgroundPermissionOptionLabel}',
        negativeAction: 'Cancel',
      },
    })
    

gap in geo points

2024-09-12 23:59:27.040 
📍<+47.61155355,-122.34142914> +/- 14.22m (speed 12.18 mps / course 131.21) @ 2024-09-12, 23:59:27 Pacific Daylight Saving Time
.
.
.
2024-09-13 00:03:35.168 
📍<+47.61404074,-122.32303471> +/- 14.25m (speed 8.61 mps / course 89.46) @ 2024-09-13, 00:03:35 Pacific Daylight Saving Time

Uploading background-geolocation (7).log…

[christocracy]

I’m out walking, as I often do, right now.

[doneill]

We are experiencing the same behavior in our production app with v4.16.3 on iOS.

E.g.

stationaryRadius: 1

We use 5 for this value, would lowering to 1 expect to reduce these gaps?

Is there a test app on iOS to compare against our production app?

[christocracy]

We use 5 for this value, would lowering to 1 expect to reduce these gaps?

No, it would make it worse. Imagine you're stopped at a red light with stopTimeout: 1. The plugin enters the stationary-state before the light turns green. Now you need to move at least 200 meters before the plugin enters the moving state again. Read the Wiki "Philosophy of Operation". Read the API docs Config.stationaryRadius

Is there a test app on iOS to compare against our production app?

Yes. It's linked in the README here

[doneill]

Read the Wiki "Philosophy of Operation". Read the API docs Config.stationaryRadius

I have read through these so many times ... I get what the library is trying to do. Noticed this user had that value set in their config and no mention of whether adjusting it would be prudent to assist with the issue they are reporting so thought I would highlight it.

Yes. It's linked in the README here

Right, have to build it, was interested in if you released it to App Store. Our production users can't be expected to build it and install on a real iOS device

[christocracy]

was interested in if you released it to App Store

Apple doesn't allow "demo apps" released publicly. You would have to release it yourself for testing and add up to 100 beta users.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.