I’m still experiencing an issue where Arc seems to have samples with plausible locations but with the wrong time. This pulls the track momentarily back to where I was earlier in the day creating the kinds of tracks shown in these screenshots. I’m finding it hard / impossible to fix these artefacts. This issue only happens periodically.
I am running an iPhone 13 with iOS 18.x (I’m not sure what it was at the time of this issue).
Well that’s super weird! But then, most dodgy location data problems are weird 
One way I could imagine this happening is if either Arc Timeline or Arc Recorder (or Arc Mini if you’re still using that) is being given low quality location data while the other one is being given high quality data. Then if for some reason the active recorder role switches between them, you could get this mix of accurate data and inaccurate data muddled together.
That kind of situation is pretty rare - I haven’t seen it in quite a while myself, and don’t hear many reports of it. But it has happened at times in the past.
Oh, if you’re still using Arc Mini, I recommend uninstalling it and just using Arc Timeline and Arc Recorder. Those two work well together. Arc Mini should still work well with the other two, but it’s not getting updated any more, and there’s been several reports recently of it not doing a great job anymore. I’ll be removing it from the App Store soon, as it’s no longer needed or useful.
But yeah, going back to the high quality / low quality data scenario… for that to happen there’d also need to be a reason for the apps to change over which one is the active recorder, which means one of them was terminated. That shouldn’t be happening frequently, if at all, but if it were happening it could be evidence in support of this theory.
I think the best fix will be to identify the dodgy samples and split them out as bogus type in the Segment Split view. Which will be fiddly work, but will at least allow you to isolate the bad data and remove it from the trip paths and distance calculations and so forth.
So yeah, concrete recommendations:
Hi,
Firstly, I uninstalled Arc Mini some time ago so we can eliminate that.
Secondly, I’ve just checked and both Arc Timeline and Arc Recorder are set to Always and Precise Location.
Finally, on the day in question I was travelling from Switzerland to Italy via the alps by train. Some of the trains seemed to badly impact the GPS signal, in my experience they sometimes have solar glazing film which turns them into Faraday cages. Also, the route involved tunnels and steep-sided alpine valleys which also impact the GPS signal.
Does this help?
Aah, yes that does help! That is one other case where I’ve seen reports of similar behaviour. Specifically train tunnels in the alps, causing patterns of weirdness like what you saw. I should’ve remembered that, given the locations in your screenshots, but it didn’t come to mind.
Curiously, I haven’t ever seen similar patterns from train tunnels in other regions in the world. Though it could potentially be happening and I’m just not hearing reports of it.
So we have identified a pattern! But unfortunately it’s one that I don’t have a good intuition for, for why it might be happening in the particular way that it is. It seems to be that what we’re seeing is possibly new location data coming in, perhaps after exiting a tunnel and the device rediscovering GPS/GNSS satellites, but that then incorrectly jumps the location to back before the tunnel, and reporting it as having high accuracy (thus the algorithms trust it). Then presumably it quickly self corrects back to where it should be. That’s not something to easily detect and filter out.
You can still clean it up by finding and splitting out the offending samples, using the Split Segment view, and marking them as bogus. But ideally there’d be a way to auto detect this kind of pattern and stop it from happening. Which is a much bigger challenge.
There’s a bunch of various scenarios like this that can produce nonsense location data that also gets reported as being high accuracy, which the filtering/smoothing algorithms can’t work their way around - they’ve been told it’s good data, so they have to trust it.
I’m hopeful that the more advanced Kalman filter in Arc Recorder (and the upcoming Arc Editor app) will cope with it better. But that remains to be seen.
Bit of an aside, but that’s very similar to what happens in Boeing airplanes. Though weirdly, doesn’t happen anywhere near as much in Airbus airplanes. Some curious materials difference there.
Another train signal blocking effect I’ve observed, that I thought rather humorous, is above ground inner city trains that get reasonably clear GNSS line of sight and decent accuracy when the train is empty, but terrible results when the train is full during peak hours - lots of fleshy signal blockers in the way
For both cases, the best “fix” is to have the phone as near to a window as possible. Though in the case of Boeing airplanes I’ve found that even that often doesn’t solve it.
There’s no fix for the tunnels though. We basically just have to accept that those are zero data periods. Though the weird “jump back in time/location” effect on exiting tunnels is something that we shouldn’t have to accept. Again, I’m looking forward to seeing how the new Kalman filter in the new apps manages in those cases.
The aeroplane insight is interesting, I flew back from this journey on a couple of Embraers and got good GPS signal on both legs.
As you say, there seems to be issues where a bit of data has a plausible location but with a timestamp that is later than plausible. I’ve seen this occasionally in the UK while travelling by train / car over the past few months but I’ve not seen it recently so it feels like that variation of the issue has gone away.
My last flight a week ago was on a Boeing, but I got stuck in the middle, away from the windows, and got effectively no data for the entire flight. Frustrating!
I’ve also seen that happen with one of my workout recording apps on my watch (Dawn Patrol, for recording surfing). Often the first location it records is a location that matches up with somewhere tens of minutes previous, but gets logged as having a current time. Makes a slight mess when I import those workouts into Arc.
