Flight details missing from timeline

[CJJ]

Hi,

I flew from Melbourne to Sydney yesterday and Arc didn’t record the flight correctly. Only the final 4.2km was captured, otherwise it’s just missing from the timeline (please see screenshots). My phone was powered on throughout and airplane mode was NOT active.

I’m wondering why this might have occurred? Is there anything I can do to correct the timeline now? And how might I prevent this happening in the future?

Any assistance much appreciated.

Thanks!

CJ.

Ps just tried to post this but was told only one piece of media can be attached for a new user… I had two screenshots to attach. Kinda frustrating.

[CJJ]

Other screenshot…

[Hutima]

Most planes are metal boxes and block gps which is a pretty weak signal, if your phone wasn’t actively stuck in the window, chances are you lose GPS and it stopped recording when you also lose cellphone triangulation, at least from my experience

[moo]

I came to ask an identical question (different airports but same problem). Usually it just fills in the gap and says “first you were at Place A and then I found you a couple of hours later at Place B” and then just joins them with a line which I usually have to confirm was an airplane.

That didn’t happen for me for the first time yesterday and I had your experience instead - not a connected sequence. I’ll be interested to learn the answer and why the behaviour is different to my previous experiences.

[matt]

Ok, so, airplanes are difficult! @Hutima is correct that many of them block GPS signal almost completely.

Boeing airplanes are the most problematic, in my experience (or perhaps it’s just the 787), while Airbus planes are much easier to maintain GPS in.

In an Airbus airplane as long as you’ve got the phone within 30-60 centimetres of the window it can usually hold a GPS signal and record the flight correctly. If you have your table out, keeping the phone on or above the table will usually get you a reliable recording throughout. If you have your phone below the table your odds of success diminish significantly. If your phone loses GPS signal it will be necessary to hold it near the window for a minute or so until it picks up enough satellites again.

On Boeing flights however I’ve had almost universal failure. Signal loss is almost permanent and unrecoverable, despite holding the phone right up against the window for extended periods.

Here’s examples of recent Airbus and Boeing flights:

Airbus A320

Boeing 787

In the Airbus recording you can see the speed data blipped a bunch of times, meaning that signal was lost, which would have been times when I put the phone down on my lap or on the empty middle seat away from the window. The signal would then have picked up again once I was handling the phone above my lap, near enough to the window.

In the Boeing recording it’s simply a 100% loss throughout, and nothing I did could save it. Something about the 787 really doesn’t work nicely with GPS.

@CJJ

My phone was powered on throughout and airplane mode was NOT active.

Airplane Mode won’t hurt recording, thankfully. Inside buildings on the ground, Airplane Mode will hinder location data accuracy, because when you’re inside buildings without line-of-sight out windows your phone will use cell tower triangulation to help it get a fix. But when inside an airplane cell towers are of no help, and likewise wifi hotspot triangulation is no use, so the phone has to rely purely on GPS/GNSS signal. That means it needs to be able to maintain constant line-of-sight to enough satellites, otherwise it will lose your location completely.

@CJJ

Is there anything I can do to correct the timeline now?

Unfortunately not. Though perhaps if some flight tracking service supports exporting of a specific flight’s tracking data to GPX or similar, it could be imported into Arc. But that would be quite a fiddly process.

@CJJ

And how might I prevent this happening in the future?

The two main takeaways: 1) Keep your phone close enough to the window, eg within 30-60 centimetres and without its view out the window blocked. 2) Avoid Boeing 787s.

[matt]

@CJJ

Ps just tried to post this but was told only one piece of media can be attached for a new user… I had two screenshots to attach. Kinda frustrating.

Oh, for this, that’ll just be a restriction for your first time posting. From now on you’ll be able to post with multiple images. The Discourse forum service does that to reduce spamming.

[matt]

Oh one point I should’ve made: Get a window seat! If you’re in the middle or aisle seat your chance of getting a usable recording, even in an Airbus, drops to near zero.

[matt]

@moo

That didn’t happen for me for the first time yesterday and I had your experience instead - not a connected sequence. I’ll be interested to learn the answer and why the behaviour is different to my previous experiences.

In this case, hard to know exactly what happened, but if there were multiple timeline items over the duration of the flight, with varying amounts of useful/useless data in them, then it could be the processing engine couldn’t see how to merge them - they were simply too messy/noisy for it to understand. Then once you manually corrected them to “airplane” the processing engine would’ve been able to see how to merge them.

If simply no useful data was recorded throughout the entire flight, then you’re likely to end up with just a single “Airport A → Airport B” timeline item with nothing of use in it, due to the phone picking up location before takeoff, then location again after landing, but nothing in between.

Aside: That’s basically what apps like Google Timeline do. They don’t even bother trying to pick up much of use during the flight (nor do they show you what they got), and instead simply show you an “Airport A → Airport B” trip. Arc instead sticks with its goal of attempting to get as high accuracy and detail as possible, then making a best attempt at processing that into something useful at the end (with varying levels of success, depending on how good the recorded data was).

[moo]

Here’s my experience. I was in the middle seat of an Airbus A330-300 (333) with my phone on the table / in my hand for the trip.

I am mainly confused by the data gap of 2 mins while the time difference between the points is 10 hours.

[matt]

Good old Suvarnabhumi Airport!

@moo

Here’s my experience. I was in the middle seat of an Airbus A330-300 (333) with my phone on the table / in my hand for the trip.

Ah yep. In an A330 in the middle seat, ie one seat away from the window, you might have some chance if the phone is above the table / above your lap, but I’d expect it to probably get no data for more than half the flight.

@moo

I am mainly confused by the data gap of 2 mins while the time difference between the points is 10 hours.

Hard to know without digging deeper into the samples. I’d guess that the 2 minute data gap would be both Arc App and Arc Mini getting terminated by iOS due to Reasons, upon landing. Then getting relaunched automatically (or by you opening one of them manually). It’s possible that something happened with the phone either when switching off Airplane Mode or switching carriers or some such, which caused iOS to briefly freak out and kill off a bunch of apps.

But with timezone changes thrown into the mix too, it’s hard to guess what the underlying data really looks like.

[moo]

Sounds like more airline travel is required to help you solve these issues. If you want to stay home and code the solution while paying for me to fly between countries for your testing purposes, I’m available for hire.

[matt]

@moo

If you want to stay home and code the solution while paying for me to fly between countries for your testing purposes, I’m available for hire.

I’ve actually been flying quite a lot this year! Finally back to travelling, after being grounded for the past few years, for obvious reasons.

I was paying close attention on my flight last week, in an A320, window seat, phone above the table the whole time. Frustratingly the location data still dropped out a bunch of times. It didn’t seem to have anything to do with cloud cover either - it was fairly clear skies the whole way

I just did a quick search, and looks like there’s a bunch of services providing APIs for live flight data, including latitude, longitude, and altitude - the key ingredients. It would be pretty cool to have a feature for importing flight data from one of these APIs. I’m not sure if there’d be enough demand/interest to justify the development effort, but it’d certainly get my vote. Recording flights is one of the most fun parts of Arc testing!

[moo]

It really is the fun part. Since you didn’t actually say no, I’ll just email you my receipts for my next trip, thanks.

[CJJ]

Thanks for the replies everyone. Big upvote for adding flight data from third party flight tracking services, that would be ideal. Or even just arc detecting you must be flying and drawing a straight line between the two points. I’m personally not too concerned about exactly recording the flight path that was flown. But it’s important to me that arc shows the flight occurred even if in appropriate terms.

On a side note, cheers Matt for all the ongoing work. I stopped using arc for about 12 months as the daily load of corrections required was just too extensive for my use case. But now I can happily report I’m needing half or less of the corrections that were required before. Good work!

Cale.

[moo]

+1 for not caring about the exact flight path. I’d rather see Airport 1 and Airport 2 connected with a straight line if required.

[matt]

@CJJ

Big upvote for adding flight data from third party flight tracking services, that would be ideal.

Agree. We’re already pushing the limits of what can be achieved with current location data technologies, so to achieve any significant improvement in flight recording it’ll likely have to be achieved with a third party flight tracking API.

@CJJ

Or even just arc detecting you must be flying and drawing a straight line between the two points.

If it manages to record at least something at both the start and the end of the flight (eg airplane taxiing on the runway before takeoff, then the same again at the other end, before it arrives at the terminal), then it should be able to piece it together as one contiguous airplane trip. Though it’ll probably require a couple of confirms/corrects, due to the processing engine not wanting to automatically merge over a long data gaps. (The processing engine will prefer to show “I didn’t get anything at all for these hours” rather than quietly smoothing over it and faking it like nothing went wrong).

But yeah, unfortunately if the phone loses location for an extended period, it’s probably going to be slower to pick up your location again at the end of the flight. Which can make the chances of getting something sensible recorded at the end less likely.

@CJJ

But now I can happily report I’m needing half or less of the corrections that were required before. Good work!

Thanks Cale!

The move to the Core ML activity type classifiers was a big improvement, that I’d been wanting to do for quite a while. But it was held back by Core ML not allowing models to be built on-device. You had to build the models off somewhere else then send them to the phone, which was a complete non-starter given Arc’s strict data privacy approach. But now it’s possible, and it’s been a really satisfying step up in accuracy!