Still the best in-flight internet. When it connects.


a map of the united states

Last November I was on one of the very first flights JetBlue operated with their FlyFi in-flight internet service active. At the time the conclusion I drew about the product was it is, by far, the best offering flying. When it works. Last night I was on another FlyFi-equipped flight (the special FlyFi livery, no less!) and the experience was very, very similar. It was simply spectacular when it was working. But it also dropped out just over half way through the flight, leaving me offline for the last two-ish hours en route to Phoenix. Connectivity speeds during the first half of the flight were top-notch. My one test showed just over 19Mbit download speeds and I was able to get work done reliably. Unlike previous tests where I was mostly “playing” rather than working this flight had me connected via Remote Desktop Protocol to servers on the ground. RDP generally handles latency pretty well which is good for satellite-based connections and my experience was pretty much identical to sitting at home using the same services. It was significantly better than sitting in the food court area at JFK T5 prior to my flight (service in the terminal was better out by the gates).

a screenshot of a phone

So things were great for the first two hours of the flight. And then it became a bit strange, to say the least. As the plane approached the Kansas/Missouri border I got an alert that we were approaching the edge of the coverage area. I figured that was a bug of some sort given that the coverage map is basically all of the Continental USA and I was smack-dab in the middle of it. But, sure enough, the connection dropped. It briefly reappeared once after that but, for the most part, I remained off-line for the rest of the flight. Speaking with others on the plane it was clear that the dropped connection was not just me. And despite the system thinking that it reacquired the signal later on I was never able to connect off the aircraft after that point.

image

Looking at a couple maps and speaking with another friend on the plane we came up with a theory for why the dropped connection happened. This was our best guess: The system choked switching between satellites. Looking at the two images below, one showing the flight path from FlightAware and the other showing the spot beam locations for the ViaSat coverage it seems that the connection dropped as we switched from the ViaSat-1 coverage to the “augmented beams” which is the region covered by the Wild Blue satellite which pre-dates ViaSat-1.

image

Following the flight I reached out to some people to confirm my theory on the failure. Yes, I was mildly disappointed with losing the service half-way through but mostly I just wanted to know if I had solved the mystery. Fortunately I got a very detailed response back which includes a confirmation gave me all sorts of answers. I wasn’t exactly correct on the theory, but it was darn close. As part of those details I got this:

  • If the system loses connectivity for greater than 30 seconds, it is designed to automatically restart once connectivity is reacquired
  • This happened on your flight and we can see that all of the previously active sessions are restored relatively soon after the connectivity blip occurred
  • However, what we can also see is that after all these sessions were restored, there is practically no data transferred on any of them for the remainder of the flight

 

Separate from that I also got this bit of info: “Although there was a brief disconnect between the aircraft and our satellite on the flight in question, the beam/satellite handover had successfully completed several minutes earlier.” So it wasn’t the beam switch which caused the problem; that was just coincidental timing.

Yup, all that is true. I got a local signal back but no traffic made it off the plane. Turns out that this is a bug they’ve seen before and it is one they’ve already got a fix for on a test aircraft. So, yes, it wasn’t a perfect experience but they’ve called the service “beta” and they’re working out bugs like this one. I cannot help but appreciate that aspect of things. Plus there’s the part where it doesn’t happen all the time. Given the number of transcon flights with 100+ active connections on board I’d be very surprised to learn that such drops are systemic in the system versus occasional hiccups. And my flight hopped across several beams before dropping Still, in order to be a leader in the connectivity space the product needs to be rock-solid. And they’re not quite there yet.

When will then be now?

Invalid request error occurred.

Soon.

Related Posts:

Never miss another post: Sign up for email alerts and get only the content you want direct to your inbox.


Seth Miller

I'm Seth, also known as the Wandering Aramean. I was bit by the travel bug 30 years ago and there's no sign of a cure. I fly ~200,000 miles annually; these are my stories. You can connect with me on Twitter, Facebook, and LinkedIn.

7 Comments

    1. The latest announcement was that it will be free through June and I assume that’s also what they’re considering the “beta” period. We’ll see what actually happens once that’s done.

  1. Hey Seth,
    Any idea for this flight what the take rate (# of simultaneous users) was? I’m curious how they’re achieving such high speeds if many users are logged in, particularly as I’ve seen reports during the beta of 100+ simultaneous users on a flight (and which you allude to above).

    Thanks, appreciate the post!

    1. The take rate on this flight was just under 30 passengers (~18%). My very non-scientific scan of the cabin suggests many were sleeping as it is a relatively late departure from JFK headed west.

      As for how they achieve such high speeds, it is in the underlying satellite technology. It was designed from the get-go to support higher speeds than the other options on the market and they’re actually delivering on that promise. ViaSat claims 12 mbit/passenger and that they’re meeting that target 90% of the time. It is a bit of a fudged number as they basically only count when someone is making a request and whether they can deliver at that speed, not that they have 12*number of passengers of bandwidth, but if the end-user experience is sufficient then I cannot complain too much about marketing fun.

      And, based on a conversation I had with some engineers from ViaSat last September, they can up the bandwidth per plane from the ~25mbit today to ~75mbit through software changes only. That’s good news for future growth.

  2. Seth, recently on several FlyFi enabled flights and found a couple more hiccups and fixes I’d like to share.
    1. I couldn’t access any https/secure sites. Couldn’t access Gmail, Facebook, or any other site I had to sign in to.
    2. After flying through Canada/Michigan/Canada into Minnesota and then south, I had a hard time reconnecting as well. Issues very similar to the screenshots above.

    I think I’ve found a work-around for both of these problems. The solution is the same. In the first, I’d switched devices – used the same email address to log in to my phone and off of my MBA (I think this is important, because the guy next to me using windows didn’t have a problem switching between devices and logging into secure sites).

    My solution is simply to use a new email address to log back in. JetBlue doesn’t have a sign off button, but you can ‘kick yourself out’ by using the email on a different device. So, I log on to my phone with my gmail and use a different email on the MBA and worked in both cases. I don’t know if it would help in this scenario, but it does in the ones I mentioned above.

    Thanks for the great posts.

    On a side note, I saw you destroyed airchive’s analysis of Mint; you pointed out some great things they missed. Are you planning on doing one yourself (that’s actually why I’m browsing the site this morning)?

    Thanks!

Comments are closed.