Passive location points aren't in order with normal network/satellite location points

[BorderCounter8812]

Quick question:

I recently noticed that all my programs show a longer distance on gpx files from GPSLOGGER than on those from other apps.

i looked at the gpx file once. i noticed that there are "fused" and "gps.
The order of the time is very confused.

Where does "fused" come from and where does "gps" come from?
Can I disable fused or gps?

[mendhak]

Fused is a proprietary GPS location provider made by Google, which combines network location, satellite location and Wifi/celltower based location. GPS is just using the satellites as received by the device's GPS receiver.

This app doesn't work with the fused provider, because it's closed source, and that's not allowed on F-Droid. I cannot say why you are seeing 'fused' except it could be that you have passive logging enabled? That might be how some of the fused is appearing.

The GPS location listener can be disabled under performance menu.

[ainquel]

Hello, I'm also facing issues with the time reported by different location providers.

For the context, I'm using gpslogger on roadtrips to take my gps location (using gps provider) every minutes but
I also want to record my location by listening to other apps I use like google maps or hike apps which in general ask for it every seconds.

So in my configuration I have Log GPS/GNSS locations on as well as Log passive locations.

By doing that I have a mix of gps and fused location in my data which is not a problem
in term of accuracy thanks to your filter !

The problem is on the time reported by Location.getTime() which depends on the provider.
According to the documentation, gps uses satellites time, but network and fused use whatever they want like the device time.

Here is a sample of what I can see in my data:

src=fused, time=2023-05-29T20:16:14.419Z, lat=47.7741112, long=6.7775407
src=gps, time=2023-05-29T20:16:12.999Z, lat=47.77411067860298, long=6.77754263987173
src=fused, time=2023-05-29T20:16:15.419Z, lat=47.7741105, long=6.7775428
src=gps, time=2023-05-29T20:16:13.999Z, lat=47.774110857991644, long=6.777542876936809

FWIW a solution I can think of would be to add an option to generate a (less precise) time
inside gpslogger somewhere it is safe to assume locations are "queued".

Would GpsLoggingService.onLocationChanged be safe for this ? I've also seen some queuing in the file loggers code ?

Do you have any better ideas ?

(thank you for your work on this great application !)

[mendhak]

Since the passive location could come from 'anywhere', it would be more confusing to give it a different time than the one assigned. This is because the fused or network location provider can (and do) also provide cached locations. So the safest option would be to compare the newest point's time with the previous point's time and discard the newest one if it isn't greater.

So the problem could be related to this block, where if it's a passive location, the time-elapsed comparison is being skipped.

gpslogger/gpslogger/src/main/java/com/mendhak/gpslogger/GpsLoggingService.java

Lines 831 to 837 in de3ead4

	// Don't log a point until the user-defined time has elapsed
	// However, if user has set an annotation, just log the point, disregard time and distance filters
	// However, if it's a passive location, disregard the time filter
	if (!isPassiveLocation && !session.hasDescription() && !session.isSinglePointMode() && (currentTimeStamp - session.getLatestTimeStamp()) < (preferenceHelper.getMinimumLoggingInterval() * 1000)) {
	LOG.debug("Received location, but minimum logging interval has not passed. Ignoring.");
	return;
	}

This block was added as part of #720 and #735, but what I could try instead is, instead of measuring elapsed time matching the user's expected time (eg 60 seconds), only compare if the location's time is greater than the previous point's time. It could mean there will probably be fewer passive locations accepted but at least the points ought to be in order.

[mendhak]

If anyone wants to test, I have placed a prerelease APK here: https://github.com/mendhak/gpslogger/releases/tag/v128-rc1

This APK is not compatible with the F-Droid version, so if you install this you will lose all your previous GPSLogger settings/files etc.

[ainquel]

I agree that adding an internal time wouldn't work, in a few use cases I've seen with cached location returned by "fused".
I've had "fused" provider returning 30 to 60 accurate location points, in less than a second, but with a time, 30s in the past compared to "gps" provider

something like:

# simplified for the example, time in seconds
time=100  src=gps
time=52   src=fused
time=53   src=fused
...
time=99   src=fused
time=100  src=fused
time=101  src=gps

So the solution you've implemented will correctly handle this scenario.

I'll give a try to the rc and will post results if I have any (it doesn't happen every time)

Thank you !

[ainquel]

I've tested the rc version and it filters correctly points that are in the past.
I end up with more coherent gpx tracks.

However, it revealed that fused and gps points are not precisely coherent.

When gpslogger receives gps only points from my hiking app, I can see a straight track but when another application
wakes up and uses fused location, it isn't.

You can see below how it renders, locations from fused or gps are coherent with themselves but they are mixed together which creates a somewhat chaotic track

(the distance between points from fused and gps on the left of the image is around 10 meters)

So after thinking about this, what I would like in my case, is to be able to choose which providers the passive listener is logging location from, so I can listen to gps only locations.
Exactly like I can choose providers for "active" logging.

[mendhak]

v130 is now on FDroid and the releases.

The new option uses the time period to pick the best location it can find. I didn't want to make it complicated by having a range, as there is already a lot going on in there. This should help with jumpy lines and make things smoother at the expense of time. So you'll probably want to experiment here, eg, don't make the duration too long, maybe 5-10s will give it a better chance of getting a good point.