Not sure if this is new or known, but today I experienced a whole day of data gap for Arc Timeline 4. The timeline data was accurate for the first five minutes of my commute and then it just stopped. This didn’t seem to happen before.
The debug logs show that the app wasn’t terminated by iOS, and the app kept logging this line:
[13:24:45.817] [LOCOMOTION] Wakeup timed out (raw/Kalman disagreement) — back to sleep
Followed by
--1–
In regular intervals of 30 seconds and 60 seconds.
This is a weird one @trackerminerfs! For this to happen there has to be a fairly implausible combination of conditions. Though not impossible conditions, just not ones I’ve seen before, and not ones we thought possible enough to consider in the code.
I think first debug steps here will be two:
First let’s have a look at your log file. Email that to matt@bigpaua.com. Thanks! Though from what you describe so far, I’m not expecting any discoveries there. But still, I should eyeball it just to be complete about it.
And second, have a look inside the all-day visit’s samples. Presumably it’s got one massive stationary segment, but if you go into that segment in the segment edit view it’ll show on the map as a path line.
When LocoKit2 is doing wakeup checks it’s still recording samples. So all of those “raw/Kalman disagreement” moments will still be present in the timeline. The location of those samples will be telling. A screenshot of that would be super helpful!
And that might also offer you some path to cleaning up the mistake. You should be able to split out some of those to make some vague sense of the timeline for the day. Perhaps not a pleasing shape, but… there should at least still have been data recorded throughout.
On the hypothesis side: What’s happened here is that the Kalman filtered samples weren’t escaping the sleep mode geofence, all day. Which is … wild, given the maximum geofence radius is 100 metres. But yeah, as far as we can see from the code, somehow the raw data → filtered data couldn’t escape that 100 metre radius.
As to how that happened… I’ve got two theories in mind. The first being that the phone for some reason was providing low quality data, with perhaps invalid velocity or very high horizontalAccuracy values (eg reporting it as being only accurate to 1km or some such). Though for that to happen all day, that’s quite a stretch, even in a built up city area.
The second theory I have in mind is that the Drift Profiles system (the replacement for the old Trust Factor system) was overly aggressive in its distrust. That system essentially spots what looks like random drift data and says “nah bro, i don’t trust ya. you’re saying 5 metres accuracy but last time you gave me drifty data in this direction it was complete nonsense, so I’m treating this as 50 metres accuracy”.
It could be that the drift profile spotted what looked like a drift, and drifts in that direction have in the past been really bad, so it too aggressively inflated the reported accuracy.
Though again, for that to happen all day is a wild stretch. So none of these theories feel particularly strong yet.
So I did go into the individual segments view. Instead of one massive stationary segment, it actually has a massive Metro segment. Since I was commuting by metro, it seems correct that the segment type is Metro. However if I use the split segment tool, I can see that most of it is stationary but at the wrong location. From the split segment view when I use the nudge buttons I can see that the segment is split in a very slow way; it seems that each minute it thinks I’m moving by a few steps.
It’s very weird. It’s happened only once so feel free to make this a low priority issue.
Got your email with log and screenshot. Thanks!
Piecing through the log data and looking at the screenshot, yeah this does look like a freak occurrence, the phone providing sustained low value / low accuracy location data, that LocoKit2 couldn’t really do much of value with.
Though there is the BIG-150 work scheduled for this/next week (“Test and improve underground train trip recording”) while I’m in Bangkok. That work could improve this kind of situation, or at least that’s the hope. If iOS gets into a rut, providing sustained low value data, it might be possible for either LocoKit2 to do something better with that data, or to snap iOS out of its malaise.