Arc classifying all sorts of movement as stationary plus Arc Mini backlog

I’ve noticed recently that I’m having to go back through and confirm items that I’ve confirmed before for past days/months.

In addition, Arc has been suggesting Stationary for all kinds of obvious movement that it has data for, eg this bike ride yesterday (where the top activity sample is car):

From another thread’s suggestions, I looked at Background App Refresh which is on for both Arc and Mini. And I took a look at the Mini’s system debug info which seems woefully behind. How would I go about giving it a kick in the behind to get processing?

I don’t know if this is related, but the Arc iCloud First backup shows up as incomplete though I’m pretty sure it was complete at some point in the years I’ve used Arc.

Wow, yeah, that really is far behind on scheduled daily tasks! iOS is not being helpful there.

To get the backup to complete, you can plug the phone in to power, put Arc in the foreground, and leave it in the foreground with screen lock disabled in iOS Settings app (Display & Brightness → Auto-Lock → Never). That will allow Arc to run the backups at full speed without interruption in the foreground, until completion.

With backups up to date, that’ll be one less daily scheduled task to do, so will make a bit of room in the limited time iOS is allowing, for getting other tasks completed.

Fortunately the CD2 and UD2 models can be updated very quickly in most cases, so once iOS does allow Arc to get working on those, the numbers should go down quickly. It’s just a matter of iOS actually allowing it to happen! Which is unfortunately out of our control (it’s a decision made entirely by iOS, with no way to influence it other than to make conditions perfect, ie plugged in to power and not using the phone).

That backlog of CD2 models will definitely explain the bad activity type classification results. In the other thread I can’t see any obvious cause for the bad results, but in this case it’s clear cut - the CD2 models (Core ML activity type models) will be missing, leaving the classifiers confused and inept.

Anyway, yeah, getting he backups finished first will help the rest along. Oh, and if you have daily auto export of GPX or JSON turned on in Arc’s export settings, I’d turn those off for now. Those tend to take up a lot of daily background processing time, leaving not much for the other tasks.

I’ve been having this issue too. A ton of my activities are getting classified as stationary even though car is the top activity with a registered speed of 17 mph.

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.

Here’s an extreme example of the Sleep Mode / pre sensor warmup samples:

The walking segment of 26 samples at the end of this visit:

Note the classifier is more convinced they’re stationary than walking:

Those samples are all effectively inside my condo, and were all recorded while Arc’s recording engine was still in Sleep Mode. It knew I was probably leaving soon, so it was doing sleep wakeup checks more frequently (maybe every 6 seconds), so it managed to record a decent number of samples for my walk from room to building’s bicycle stand, but the location data wasn’t convincing enough to justify leaving Sleep Mode and going into active recording. So each sample only has location data, no pedometer or accelerometer data.

Which means that the classifier doesn’t have much of anything to work with, and its best guess is still going to be “stationary”. Though to its credit its second guess is walking, probably because of a combination of time of day, location (ie somewhere in the building that isn’t my room), and possibly even direction. So it’s using other contextual clues to get walking as second best guess, but given the lack of pedometer and accelerometer it can’t have any confidence in walking and stationary wins.

My perfectionism forces me to extract that walking segment manually every day and split it out into a separate timeline item, so that I can have a clean timeline of “home → walking → bike parking → cycling”. But given the raw data available to Arc’s recording engine, it’s unlikely to figure that out itself.

If it were possible to run the pedometer and accelerometer 24/7, these stationary samples at the start of trips could be solved. But even now with iPhones having much better battery life than in Arc’s early years, I suspect iOS would still throw a fit if I tried leaving those sensors running. It would be nice to have someday though.

Ok! So Arc did catch up eventually with the updates after lots of leaving my phone plugged in and Arc in the foreground. It feels a bit like whack-a-mole though as I’m still having to go back and confirm things I’ve confirmed before, possibly multiple times. I finally just gave up and decided that the 2022 annual data that I see is what I’ll use. January is holding clear and confirmed so far though so fingers crossed it’ll stick.

I don’t think I mentioned it above (though even I don’t have the patience to read entirely through my absurdly long screeds :joy:), 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.

Ok, just double checking, looks like that change went live in Arc 3.8.2.

What Arc used to do is when you went back to view the timeline for days older than let’s say 12 months (I forget the exact timeframe) it would run the classifier over all the samples in the day that don’t have a confirmed type. The idea being that the classifier has probably been trained to be smarter since that data was recorded, so it will do a better job of classifying those samples second time round.

But in practice mostly what it ended up doing is marking timeline items as needing confirmation when previously they didn’t need it, because the confidence in the chosen type has dropped now that the classifier is aware of more activity types being used in that area. So the intention was good, but the result was more annoyance than anything else.

So since 3.8.2 it no longer does that. The samples with confirmed type stay as they are (as has always been the case), and the samples without confirmed type get left with the type they were first assigned at recording time. So the state those items were in on the day should stay the same into the future, with no new confirm/corrects necessary.

1 Like