RI830

Check out tree tops on the left side of the video. Heck of a breeze blowing to land in at 3:45am when you're exhausted.

itsphysics

Correct on two accounts... FR24 data however is consistent with this latest video just posted by RI830. GA initiated at 03:45:00 on the video time code, impact at 03:46:02, 62 seconds later. Matches the FR24 data deduced timeline in my post above exactly.

But I also agree with you that human factors almost certainly will have played a major role here, as has become evident through various statements from FZ crew past and present.

ATCBob

Well, not really. Where did FR24 get their data? Did you derive that velocity and acceleration or is the climb rate from the actual Mode S data (and if so why would it be only at 5-6 second intervals)? If you derived the vertical velocity, those data intervals are consistent anyway with a traditional radar feed and mode C altitudes, so you would already have a minimum +/- 15m accuracy in the altitude, plus even more depending how the radar processor corrects for atmospheric pressure (maybe up to another 5-10m or so). That means each of your data points in your "vertical rate" graph would have to be about +/5 of where you show it, right? (2 * 15 change in position divided by 6 second change in time).

You're then trying to make conclusions based on wobbles in the data that are all within that margin of error. Your conclusion about large oscillations in climb rate is as valid as "once they achieved a climb rate somewhere between 3000 and 4000 fpm, they remained there in a rock-steady climb until the final upset" which is also supported by your data.

Then you take another derivative from that already derivative of sparse, noisy data and try to draw more conclusions? Why stop at a second derivative? How about take one more and conclude the pilots must have been violently fighting for control in the climb because my derivation of a derivation of a derivation of noisy data shows the yoke was somewhere between all the way forward and all the way back (well, either that, or everything was calm and the yoke barely moved the whole time).

Your original data is just too sparse and imprecise to make those conclusions, I think. Even if the altitude source is ADS-based, there's still significant enough margins of error to not be able to conclude anything except the final plunge was sudden.

Toasty

You may be referring to this: https://youtu.be/-4m0FcsLnEg?t=1m36s
ATC tell Fly Dubai "on final, severe turbulence and moderate windshear".

Then at 2:22 she says "meteorological report. Not reported about windshear on the runway".

itsphysics

ATCBob, thank you for asking some very relevant questions, I'll try to clarify them:

FR24 gets their data (in this particular case) from a distributed network of ADS-B receivers. The messages received by these "volunteer" receivers are compiled and transmitted to the FR24 servers in 5 second intervals, hence the 5-6 second time resolution.

The content of these "ADS-B Messages" transmitted on 1090 MHz are the Mode S Extended Squitters (Airborne Position squitter, Airborne Velocity squitter, Surface Position squitter, etc.) and they are described in ICAO Doc 9871, and Appendix A of the RTCA DO-260B (the latter being the reference documentation I have used to implement my own ADS-B decoding software several years ago). This documentation specifies several important points:

1. The data source for the altitude Mode S ES data is the barometric altitude supplied from one of the air data computers, usually ADC1. Technically, this "altitude" is a flight level as it is always given to barometric reference of 1013 hPa. This is relevant when trying to find altitude above ground, but when comparing data points taken within close time proximity to each other (and deriving climb rates this way) not correcting for the atmospheric pressure at the time is not relevant.

2. The Extended Squitter Airborne Position (Register 5_16) maximum update interval is 0.2s. The minimum update rate 2s. In practice, 5_16 messages are transmitted between 1-3 times per second. The barometric altitude is encoded according to RTCA DO-181E 2.2.13.1.2, which states that for aircraft capable of 25ft altitude resolution, the altitude shall be reported in 25ft steps. Given the aircraft in question was RVSM approved, the barometric altitudes in the FR24 data will therefore be within 25ft of the true barometric altitudes, and no older than 2 seconds (otherwise the data would have to be zeroed as per the RTCA specifications).

3. Source data integrity is ascertained by the data validity flag which is implemented and verified correctly in the FR24 receiver software which is based on the publicly available dump1090 source code, check it out on github if you would like to see for yourself.

So from the above, we can state that the altitudes reported by FR24 are at the very most 2s out of date, but each point is precise to within 25ft. Further taking into account that physics is at work (i.e. climb rates on 5 second timescales are always smooth functions, there are no steps in them), this lends further credibility to the data presented.

While I agree with you that one must always question the provenance and accuracy of data (and calculate errors where appropriate), in this case the data appears of reasonably good quality to make the observations I have made.

No, the margin of error is much smaller than you state. It's 25ft vertical (7.6m) and 2s in time but: while technically correct, in my vast experience with ADS-B receivers 5_16 altitude messages are never out by more than half a second. Thus calculating errors for the most extreme climb rate found, you find that the data with error would be 4700fpm +/- 500fpm, so could be 5200fpm, or 4200fpm.

No, the margin of error is smaller as I have just shown above.

I make no claim as to "oscillations", but the climb rate was well above 4000fpm even by the most optimistic estimate (4200fpm), 4700fpm being the plausible value based on the data. The only claim I make regards the onset of the problem from the go around: The lengthy and continued increase in vertical speed acceleration is probably where the upset initiated. This hints at a thrust initiated pitch moment that remained uncompensated for, either due to insufficient elevator efficiency, out of trim, or a combination of the two.

Well yes, that's how physics is done: Taking derivatives of velocities is the standard procedure to obtain accelerations. This doesn't make the data "noisier". The data has errors associated with it. Those errors are not noise. They are a) time delay and b) 7.6m altitude reporting discrete steps. The errors are also are much smaller than you suggested.

I hope I have provided enough evidence to convince you otherwise!

ATCBob

That's just the error from how Mode S is encoded. I didn't even mention the errors and tolerances allowed in the altimeter itself, and corresponding analog-to-digital conversion the avionics is doing when it reports its altitude to the Mode S system. Those are on top of the allowable Mode S error. With an RVSM-certified altimeter that they most certainly had, it's an additional 25m error allowed -- and that's a mean error, with occasional errors allowed up to as much as 60m. (See this FAA document, slide #24).

Errors of that magnitude are probably common in practice, as it allows digital altimeters to smooth things out and show and report "35000" during light and moderate chop, even though the actual altitude may be bouncing around.

That would mean the actual Mode S reported altitude error from actual aircraft position is very likely in the region I stated, even ignoring the additional +/- 7.6m error allowed on top of that by Mode S itself.

Then you didn't say where you're getting your vertical speed data from. Mode S may transmit climb rate, but that doesn't mean FR24 is archiving it. On their "playback" tool I didn't see it, I can only see reported altitude. Are you deriving climb rate from change in altitude over time? If so, you still need to show and account for that 25-30m error tolerance, which you don't. Your vertical speed graph should show both low and high values at each of your data points to show the allowed error tolerance (even if you're using reported aircraft climb rates, which have similar tolerances). Otherwise you're just picking out one of very many curves that also fit those points, some of which would lead to completely different "conclusions."

Rubbish. You're back to making conclusions off a derivative of a derivative of very noisy data.

And yes, it is noise. Each time you deal with a derivative you are decreasing the signal-noise ratio. Altitudes +/- 25m at 5 second intervals would mean your 20m/s derived velocity is +/- 10m/s (50% variance), and your further derived acceleration points are 2.0 m/s^2 +/- 4 m/s^2 (200% swing). See how the error increases exponentially with further derivatives? Then rereading I see you actually did talk about control column position (another derivative beyond that even, again all from just avionics-reported altitude data at 5 second intervals). Rubbish.

No, Newtonian physics as discussed here is based on continuous functions. This is a very small, sparse set of discrete data points. At the speeds here it's almost a half nautical mile between points and there are a whole lot of possible realistic curves to get from one to the next. You're just showing one possible curve on your graph which is dishonest, then further drawing conclusions off your one graph.

Same!

itsphysics

No Bob: The altimeter error is of no relevance as we are not comparing between altimeters. The data source remains the same, as such, the altimeter induced error is constant for our intents and purposes and cancels out when forming the difference between adjacent data points. This is how I have derived the climb rates (by taking the difference between altitude points and their respective time stamps).

The only two errors that require consideration in this case are the ones you haven't thought of in your initial critique: The time error (delay between measurement and reception of the altitude) and the Mode S bit truncation induced error (the 25ft "rounding").

Bob, noise is a qualifier for sound. Measurement data with errors is not "noisy", it is data with a known error. While colloquially used, the term "noise" is wrong and not useful in describing measurement set errors.

Either way, I have accounted for the errors: The altimeter measurement error cancels under the valid assumption that the instruments error time constant is longer than the measurement period (which it is). And because the errors have cancelled, they do not propagate through the calculation like you are proposing.

Think of it this way: If your assumption on error behaviour were true, an RVSM certified aircraft's altimeter would randomly fluctuate in rapid fashion by up to 200ft, which it does not. Of course you will see an offset between the altimeters, as they have different errors. But one altimeter system will not rapidly fluctuate by 3 sigma around its mean!

ATCBob

And "No..." right back to you.

How about we wait until the final report and actual flight data is released, then one of us can come back to this thread and say "I told you so"?

itsphysics

I have no particular desire to "told you so", it is your prerogative to do so of course once we know. I simply look at the available data and draw my own conclusions, presented here for others to consider (and reject, if they wish so, of course).

Waldorf

So after Mr. physics and atc bob have figured out the math, its a GA for 30 seconds followed by a plunge into the ground. Gotcha. Or some derivative thereof followed by the normal or abnormal deviations with GA =1/2 BS squared.