Closed alhassanreem closed 3 weeks ago
PolygonGeofencingService has absolutely nothing to do with your problem. I will remove that log message so you don’t see it.
Show me a screenshot of your problem with locations displayed on a map,
If you’re not monitoring polygon geofences, the PokygonGeofencingService, which receives every recorded location, does nothing. Red herring
this is a map of the route with all the geo points we received for that trip
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
Btw, here's me driving all over France for 2.5 weeks this summer using the demo app (iPhone 15 Pro, Google Pixel 6.)
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
If the data exists in the logs, but not on your map, then you have a problem in your JavaScript / http / socket.
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
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.
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.
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)
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.
showsBackgroundLocationIndicator: false,
I suggest you test with that set to true
My last 7 days of tracking:
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
showsBackgroundLocationIndicator: false,
I suggest you test with that set to
true
We can test that, will share logs once we have them
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.
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:
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
``` javascript
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…]()
I’m out walking, as I often do, right now.
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?
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
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
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.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Your Environment
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