Hi @cwong!
In the case in your screenshot I wonder if it’s a case of Arc just not having enough samples within the Timeline Item to get a useful classifier result. You can check this by tapping the ellipsis button then going into “Edit Individual Segments”. On the segments view, each segment has a number in brackets for how many samples it contains, eg “Walking (43)” would be a contiguous segment of 43 samples classified as walking.
It’s common for the first few samples at the start of a trip to be very hard for the classifier to make sense of, due to the “warm up” stage where Arc’s recording engine comes out of Sleep Mode. In sleep mode it checks every 6-60 seconds to see if the location has changed sufficient enough to justify starting active recording, and if so it then turns on the other sensors (pedometer and accelerometer), and starts feeding their data into the recording/processing engine along with the incoming location data. But it can take a little bit for those sensors to start providing data, and along with the samples at the start of the trip that were recorded before starting those sensors, the first few samples tend to have only location data (and low quality location data at that), so the classifier can’t make sense of them. You can spot this as a fairly predictable stationary segment at the start of any trip after being stationary for more than a few minutes (ie long enough for the recording engine to go into Sleep Mode).
If however there are enough samples in that short trip (it’s typically only the first 1-4 samples that are data deficient), then we’re best to look for the problem elsewhere.
The elsewhere in this case being whether the CD2 models are up to date (CD2 = neighbourhood size Core ML models, built on device from your confirms/corrects). You can see this in Arc Mini’s System Debug Info view. Ideally the “CD2 models pending update” should be only 1 or 2, or 0 if you haven’t made any confirms/corrects since the background task last ran. If it’s much higher, it means there’s a backlog, and probably some models that haven’t even had their first build yet. That would make the classifier results in those CD2 regions pretty crap.
You can check when the model update task last ran by scrolling down on the System Debug Info view and looking for “coreMLModelUpdates”. Ideally that shouldn’t be overdue by more than a day. For extra detail you can tap on that row to see when iOS last started the task, and other sometimes useful bits and pieces.
If the CD2 models aren’t backlogged, then the next thing I’d look for is the Classifier Debug Info view in Arc Mini. The top section in there lists the classifiers being used right now, for the neighbourhood region you’re in now. Ideally the CD2 model at the top would be built from at least a few thousand samples (that’s the first number on the right - you can ignore the C and A numbers). And ideally the GD2 model (that’s the server provided model for the same geographic region) would have tens of thousands of samples.
The CD2 and GD2 do the bulk of the work. The GD1 is a country sized model that helps as a fallback for when there’s only limited local data and the user’s CD2 hasn’t got much data yet either. The GD0 is a single global model, and something you’d hope never to have the classifier tree have to fall back to, but could be the last line of defence out on the sea or in a desert or forest or some such.
), but in one of the recent Arc updates I changed it so that it no longer reclassifies old data, which should fix the problem of old data sometimes needing reconfirmation.