@ FrequentSLF


FR24 is an amateur system, with limitations on data accuracy. I do not profess to be an expert, but my understanding is that the way the system works is it receives simultaneous data from a number of receivers in well covered areas, and retains data which match from a number of sources and drops the one that disagrees. In areas of sparse coverage this is not possible, and any data received from a single source is taken as valid. Errors may be introduced to the data for several reasons, especially if the receiver is near the range limit. Single spikes (like in this case) are almost always attributable to some data error, while constant data (no change whatsoever) is a sign of extrapolation.

Forget the video and look at the initial adsb data from Flightradar that has been posted on the aviation safety networks webpage:

Graphic - Aviation Safety Network

A stall, recovery and then a second stall

Spot on.... Sticking to facts on a rumour network would make the site totallu unworkable.....

"A plane has crashed in xxxxx this thread is now closed until the official accident report is out" ....... Six months later "the report can be found at www.xxxxxxxxxx.c*m , this thread is now closed"

(RT.com)
Any NOTAM updates while at it?

The vs data being linked shows 6000 down to 8000 up in 3 seconds. Them are some G's, or the static source was experiencing changing values.

tubby linton, I wonder, what if we considered that at/after 06:12:57Z in the ASN image of the "vertical speed", (in quotes, because, as I think you know, this isn't data from the SSFDR), that the ADSB flight data might not be what actually occurred?

Such data is often wrong, flightradar have a history of releasing this type of questionable data (both for accident and non-accident flights) and, quite frankly, I wish they'd behave a bit more responsibly.

It's worth pointing out that the data track shown there is for the last minute of recording, with the variations in about 30 seconds of a time frame.

Stall recover and enter a second stall in under 30 seconds, in an A321?

Flightradar have published a csv file of the data which can be found here. Obviously this will not be as accurate as the fdr data, but it does show trends of what may have happened.
Crash of Metrojet Flight 7K9268 | Flightradar24 Blog
The recorded ground speed goes from 404 to 246 , increases and then falls to a last recorded value of 62.

Ground based terrorism?

Both Lufthansa and Air France have announced that they will not fly over the Sinai until further notice.

Have they received further information/briefings.

Knee jerk reaction?


And now BA are avoiding the area. It does raise the question, have security services briefed airlines and if so the reason would be rather obvious.

Just a rudimentary run through that data. you can see at some points a heading variation of 25 deg in a second. compare that to standard rate turn and we can get some idea of what forces were in play to the airframe, and indeed those contained within it following the cause of the departure.

stuckgear;
I agree with your implied conclusion...no, I don't think this is a stall/secondary stall. We might say this could be "spurious data"...

tubby linton;
No, and we don't know how FL24 creates the vertical speed data. If it is derived from P.Alt then it is only as good as the P.Alt parameter. A typical data frame on an A321 will have both inertial, recorded and perhaps GPS VSI parameters, (older data frames such as those installed on the B737 Classics derive vertical speed from P.Alt).
It may or may not, depending upon other, corroborating parameters which FL24 is incapable of presenting because ADSB doesn't have them. I would like to know what the cabin pressure and cabin rate-of-climb parameters have to say, for example.

Comparison of a more reliable MANPADS shootdown. AN30 in this case. Significantly different.

https://youtu.be/5Z7BCUEWQCg

Once again, you are assuming that the FR24 data is accurate. Prior experience suggests that this is often not the case. Sometimes this is because FR24 fudges the data, more often it's because bad data is transmitted.

Graphic
 

They've used an algorithm to fit their curve to those points, but essentially you've got 8 sec of VS approaching -6,000; then 6 sec of VS approaching +4,000; then 8 sec of VS approaching -7,000; then 5 sec of VS approaching +8,000; and the data ends.

In that last oscillation the VS changes neg to pos by about 15,000 fpm (250 feet per sec) in 6 seconds.

A G-meter would show oscillations between about -.5 and +2.5 under those circumstances.

Indeed. and an explosive event would of course produce a pressure wave in its propogation, which would be recorded by pressure reading instrumentation.

Given the credibility of the Egyptian (Egyptair 990) and Russian (MH 370) air investigation teams, it may well be that the most authoritative facts and interpretations appear on this site or others like it. At this stage it is not possible to separate useless from useful speculation.

It seems to me that posts here after any major civilian crash fall into one of two groups: speculators, most of them well-meaning, trying to piece together an understanding of what happened as information becomes available; and scolders, who criticize the speculators for jumping to unjustified conclusions and ask them to stop doing so. Is it just me, or does the second group not sound like a bunch of Peeping Toms lecturing everybody else to put their clothes back on and pull the curtains?

Vertical speed data will be from the ADIRU.
Does anybody know the projected sector time for this flight?

Seeing as the aircraft, as an asset, was owned by significant major lessor in the market, i have no reason to doubt that.

A prerequisite of lessors is that the aircraft residual value is protected by maintenance demands as set forth in the lessor terms.

Do they extrapolate? A line showing heading is displayed but the data used is of two types. The data actually transmitted by the aircraft and a position triangulated from several receiving points of the aircraft's radio transmissions.

Moreover, FR24 data is not synchronous, it's subject to whatever latency exists in the Internet connection between the enthusiast's receiver and the server.

That's particularly apparent in this instance, where the published data comes from 3 separate receivers, presumably in 3 different locations (see column 13 in the CSV file). Those clearly aren't time-synchronised, which is why we see wild variations of parameter values within the same second.

In other words, trying to construct a time-series with the data is fraught with problems. I'm very disappointed that ASN appears to have fallen into that trap with their dodgy graph.

A metrojet A321 has just taken off from SSH and appears to be following a more westerly routing, followed by an EZY.

The data just looks weird. How do you want to get from -7000fpm to +8000fpm at a GS of between 132 and 93kts (means roughly between 60 and 85kts IAS) ?
The data does not seem plausible at all.
Horizontal deceleration is also excessively high. From 400kts to 60kts in 22s.
Especially the initial deceleration from 400 to 340kts in just about two seconds without a clear trend in altitude change does not make much sense. At FL300 this is pretty surely still far above the stall (bar insane tailwind which I wouldn't expect in that area and flight direction).
From my armchair I have difficulties to fathom a force that would decelerate an airliner at that rate while matching the presented data.
Looking at this altogether I would consider the data spurious for whatever reason and don't think any conclusion can be really drawn from it.

Its now reported that the Egyption Aviation Minister has said that the crew did not report any technical issues despite earlier reports and nor did he request help or declare an emergency.

For what its worth , data from the Planeplotter network shows slightly different information than the web based plotters , however in situations such as this we never publish it , but always secure the data and submit it directly to the AAIB to pass on to the relevant country's investigators.


PP support , formerly uksatcomuk

henra;
Agreed.

I would be examining the pressure bulkhead, first.

Mention has been made of a previous tail strike.

This is the wiki report of the mid-air break-up of a China Airlines 747 in 2002. Described as the deadliest air disaster in Taiwanese history, the cause of which was metal fatigue consequent upon an inadequate repair following tailstrike damage which occurred 22 years earlier. The repair was not carried out in accordance with the Boeing Structural Repair Manual.

The break-up of the Boeing occurred some 20 minutes after take off whilst the aircraft was believed to be climbing to FL350.

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

henra: Regarding Ground Speed, imagine a full loop; your ground speed will approach zero as your angle of travel with respect to the ground approaches vertical.

But as has been pointed out, there are many flaws in this data.

Just how effective is security at SSH?

Indonesia Air Asia QZ8501?

What a load of BS. You clearly have absolutely no understanding how the system works.

The only instance where FR24 extrapolates the data is if you have the option active in your browser, it will do so for you, but that's it.
The data they posted is the data one or more of their receivers received. It's the RAW data, as broadcasted by the airplane.
If there is an error in the data, it's because the airplane was broadcasting erroneous data, not because FR24 extrapolated anything.

The "initial data" in this report reminded me of last year's crash of the A320 AirAsia flight in Indonesia, in which the "initial data" suggested 6,000 fpm, sudden climb, sudden descent, etc… although weather was a big factor in the case of AirAsia. But the two seem eerily similar in that they were fairly soon after reaching cruise or near-cruise altitude, then sudden high rates of descent, etc.., then uncontrolled descent and impact without explanation.

something in the pitch control system of that airplane broke and rendered it uncontrollable...THS jackscrew maybe? Tail strike repair?..

I have a FR24 supplied receiver and a program to see the raw data it receives.

AFAIK, The aircraft transmits GPS position, groundspeed, heading, bank angle and an altitude, every second. Software calculates VS. FR receive all this data but only plot every 30sec or minute on the webpage.

Obviously bank angle isn't shown on FR24 but I can clearly see it on raw data analysis.

The wreckage looks to be consistent with a flat stall/spin scenario.

This is consistent with the failure of some- or all flight control surfaces during cruise flight, including failure of the hydraulics. This has occurred in the past as a result of bulkhead failures /depressurization.

How do you pull a loop with more or less constant altitude?

It would seem to match China Airlines Flight 611 profile would it not? Which **could** mean potentially same cause? A repair failure badly disrupting your aerodynamic cross-section can turn into a ballistic trajectory quickly (but not always - see JAL 123).

But the time on the data is that added when it was transmitted, not when it was received or sent by the server.

COAA also calculate position by triangulation when they do have the positionless data fromby the aircraft but I am fairly sure it is still timecoded. People using that method have to have their computers synchronised to a time standard and it is rejected if their PC clock is not correct.

I have supplied ship's AIS data to the authorities a few times, it has similarities to that from aircraft and can be used by them to reconstruct what happened.