mendhak
FR: Passive logging debounce
It seems that there are time when the scheduled GPSL location request causes another app to also request a location. If passive logging is set, then this causes two locations to be logged (and sent) very close together. Due to the accuracy differences, this plays havoc with reasonable location tracking. For example I see the following speeds logged:
The pairs of immediate logs cause those spikes. They are milliseconds apart.
I do not see these during high frequency logging, so it seems to be an issue with sporadic checks.
So the feature request is to ignore passive GPS requests when they occur within a certain time (eg 1s) of a successful scheduled log.
@LOVE2CMOL Actually on reviewing the code, I'm not sure if this would help the situation described in this issue. The problem isn't too frequent passive logs between other passive logs, but subsecond passive logs after a native GPS log.
Have I understood the functionality correctly? If the setting is set to 5s, will it ignore passive logs received within 5s of /any/ log or just the last passive log?
@LOVE2CMOL Actually on reviewing the code, I'm not sure if this would help the situation described in this issue. The problem isn't too frequent passive logs between other passive logs, but subsecond passive logs after a native GPS log.
Have I understood the functionality correctly? If the setting is set to 5s, will it ignore passive logs received within 5s of /any/ log or just the last passive log?
Basically with a 5s interval: record first data point → ignore everything for 5s → record next. Tried putting this in the passive listener's interval first, but it didn't work - that's why using the filter approach now.
One of the reasons I implemented this filter was actually the same issue you encountered.
For instance, the issue of location coordinates rapidly oscillating between two points within a short timeframe. This actually stems from Android's WorkManager submission mechanism, which in many cases doesn't guarantee execution order.
https://github.com/mendhak/gpslogger/issues/1201#issuecomment-2778771096
with a 5s interval: record first data point
This is irrespective of where it came from (eg GPS vs network vs passive)? If so that's exactly what I'd need. Unfortunately I'm still receiving logs in quick succession - set to 5s, I still have the same issue:
Thank you also for the WorkManager detail (helpful for something else I'm looking at).
with a 5s interval: record first data point
This is irrespective of where it came from (eg GPS vs network vs passive)? If so that's exactly what I'd need. Unfortunately I'm still receiving logs in quick succession - set to 5s, I still have the same issue:
Thank you also for the WorkManager detail (helpful for something else I'm looking at).
My implementation only throttles passive data - your case might involve other data submissions. The passive filter uses timestamp comparison and will block submissions to WorkManager if intervals are unsatisfied. Recommend checking gpslogger's internal logs for additional clues.
Yes, that was what I was asking above. In that case unfortunately your feature does not fix the issue I am experiencing[1], an a more general debounce might be useful.
[1] where GPS logs are immediately generating passive logs.