[kop316]

"The final bit of information is interesting. It shows a positive rate of climb – 120 feet per minute to be exact, which for a jet airliner, is very slow. For reference, at takeoff the vertical speed is most often +1500 feet per minute. Another interesting bit of information is the aircraft’s airspeed; 85 kts – for a Boeing 777 that is (and I’m guessing here) probably way below stall speed."

That is actually expected. It is called the flare just before touchdown:

https://en.wikipedia.org/wiki/Landing_flare

[momavujisic]

In a landing flare, you want to raise your negative V/S to near zero. A positive vertical speed means you're no longer descending, but ascending. Having a positive vertical speed during the landing flair is something you don't want to have as you're basically floating (and possibly climbing) above the runway and bleeding your airspeed which, in a couple seconds will most likely end in a hard landing as you've stalled while floating over the runway.

The positive rate of climb to me, indicates that they attempted to climb (go-around) but their low airspeed resulted in a stall.

It's important to remember that this data was pulled off Flightware which is basically aggregated data. and not from an accurate source such as the FDR. So my guess could be totally wrong.

[lukecampbell]

I've never flown a B777 or any heavy aircraft so I can't comment on their typical flares, but in a Cessna 172 the flare doesn't induce a positive rate of climb, it simply slows the vertical descent speed to something manageable for touch down, a positive vertical speed seems counterintuitive to me as a good flare. What I want to know is what his IAS (indicated air-speed) at the decision altitude.

Again the only thing I've flown are parachutes and some hours in a C172 and a C182.

[VLM]

It gives a pretty good estimate of the error involved in the descent rate reporting. Probably accurate +/- 200 FPM or so.

The airspeed encoder is probably from the same system that displays the pilot instruments, indicated airspeed IAS. I thought it odd that the analysis of conditions didn't think 125 and 98 were ridiculously low airspeeds, but claimed that an approach around 130 knots was a "fast approach". However what little I know about the 777 from the flightsim and real pilot community is that a typical approach is around 150-something slowing to a bit above 130 at flare. I've read some claims from actual heavy pilots that under really light conditions a Vref below 120 is theoretically possible.

None of us know the weight and balance calcs so its impossible to determine if the pilots were doing the correct thing, although it is possible to determine they were flying a flight path implying they thought they were very light indeed. Now why? Who knows. Maybe because they were right, they were light. Maybe because they were low-ish on fuel. Maybe they didn't trust their IAS instrument. Maybe their IAS was actually broken and comparing their visual approach with instruments, well, its just a really strong headwind today. Maybe they made a math error. Somebody overcontrolled?

He could have found this info by violating the copyright of numerous google-able flight sim forums, and forums with real genuine 777 pilots talking about their experience with the 777. Instead he violates the copyright of a picture which we've all already seen, oh well.

[momavujisic]

About the speed, you're correct – 130 kts for a 777 is not fast, I was mistaken. In fact the NTSB just said the target approach given by the pilots was to be 137 kts. I should have chose one of the higher airspeeds given but I did not want to give a high estimate. I am not familiar with 777 speeds and should of done some more research in that regard. I did however, write that I found the sub-100 speeds to be extremely slow, even suggesting that it's most likely below stall speed – which seems to be correct as the NTSB says the stick shaker went off some 4 seconds before impact.

[VLM]

I read sometimes you can get a Vref under 120, great density altitude, sea level, winter, no pax cargo and low on fuel, but yeah when the IAS is reporting 98 you're pretty much screwed under any conditions. Maybe it was already on the ground at that point, if it wasn't.. it going to be on the ground real soon...

I would imagine some of the flightsim people I know are flying the approach under identical conditions right now. Would be interesting to hear at what point they found it unrecoverable. 98 kts is unrecoverable, but I wonder when it went unrecoverable. One problem with sims is if you know how its supposed to turn out, that screws up your actual reaction if you sim it 20 times trying different things. All you need is a cockpit distraction to totally screw up an approach. Maybe a false alarm of some type at just the wrong moment.

[trothamel]

I'm not sure we can believe the last data point - it's possible that's a real ascent, or it's possible it's caused by failing hardware as the plane crashes.

[mikeash]

It's been said, but I want to add weight to it: this is not at all expected. You never climb during a normal landing.

I'd wager that 120fpm climb reading to be due to a measurement error of some kind, not actually something that really happened.

[phire]

Looking at the GPS coordinates, the second to last reading was ~200m before the seawall, while the last reading was around halfway down the runway.

The plane is far outside it's normal operating conditions by this point, it's possible the plane instruments actually experienced a brief moment of 'climb' while the plane was crashing, or it could be equipment malfunction.

However, from what I can tell, the plane never reached that far down the runway. And the gps coordinates have actually snapped to the middle of runway 19L, near where it intercepts 28L, suggesting that flight radar 24 are doing some post-processing to make the planes stick to runways better.

I wouldn't trust that last data-point at all, as it's definitely post-seawall.

[mikeash]

Looking at the data, it's obvious that the vertical velocity figures are not anywhere near as accurate as "120" would indicate.

The data points are in the neighborhood of 15 seconds apart. There are 4 points labeled 2:25PM, 3 points labeled 2:26PM, and 5 points labeled 2:27PM.

The altitude data is all rounded to the nearest 100ft. Obviously this is coming from transponder data. The mode C transponder carried by an airliner reports pressure altitude back to the interrogating radar at 100ft intervals.

Vertical velocity is all multiples of 60fpm. I have no idea where that would be coming from. As far as I know, vertical velocity is not transmitted by either radar transponders nor the newer ADS-B position broadcasting equipment. Simply taking the derivative of reported altitude wouldn't produce these results, because with 100ft altitude intervals and 15s reporting intervals, that gives you a vertical velocity resolution of only 400fpm.

Let's skip that question for the moment. The raw altitude data does show an increase from 100ft to 200ft at the end. But what conclusion can we draw from this? Essentially nothing. Because the altitude is so quantized, this could in theory indicate anything between a 0ft and 200ft increase in altitude, non-inclusive. Of course, the instruments are not that precise, so in practice the range is even larger. This is especially true given that the instrument was in the middle of a fairly violent plane crash when it gave that last reading. From the video of the crash, it's clear the plane never got very high above the runway. Since the runway is only 13ft above sea level, and the plane didn't crash into the ocean, the amount of climb possible is very much limited. The transponder may well have increased in altitude a bit for this last reading, but if so, the alignment with the reported altitude increase is pretty much just coincidental.

Now back to the vertical velocity. Where did it come from? I can only speculate that they're applying some kind of curve-fitting or smoothing to transform the coarse altitude data into smoother vertical velocity figures. These numbers are therefore even less reliable than the altitude figures, and can probably just be ignored.

Just to briefly support that last bit, there are some obvious numerical anomalies in the vertical velocity figures earlier in the flight. At 9:38AM, the data source briefly switches from "FlightAware Transoceanic" to "Oakland Oceanic" and then back again. The two Oakland data points show an altitude of 37,000ft, while the FlightAware data shows 34,000ft. The vertical velocity for these four points is shown as 2280fpm, 9960fpm, -4320fpm, and -1800fpm. These changes obviously didn't actually happen (otherwise we'd have heard about people being flung about the cabin in mid-flight!) and are just some sort of reporting anomaly. The ridiculous vertical velocity figures (nearly 10,000fpm climb accompanied by a minor increase in horizontal speed!) are obviously just some sort of post-processing going crazy trying to fit the bad altitude data.