Posts about: "FlightRadar24" [Posts: 75 Pages: 4]

I suggest to read this blog by Flightradar24. It does show the receiver(s) picked up signal after rotation of the aircraft.

https://www.flightradar24.com/blog/f...rom-ahmedabad/

Flightradar24 published the CSV with all received data. It had EIGHT datapoints of the aircraft after its rotation showing its altitude. https://www.flightradar24.com/blog/f...rom-ahmedabad/

I've been 'watching' flights take off from Ahmedabad on FR24. Assuming that the bold dots on the track are where FR24 gets some real transponder data, it looks as if flights become visible at take-off, then FR24 interpolates the track until roughly 800m/1km from the end of the runway when it gets the next 'real' data block. So all we can conclude is that the transponder stopped transmitting somewhere in the 8 - 10 seconds between take-off and 1km.

The image here of the comparison flight paths is interesting as (with the caveat of this data being low resolution etc) it would show two things:

1) that the data stopped around about time of peak AGL - we knew this already.
2) that the flight path was much shallower *before* whatever event caused the data to stop (note that this data should be accurate in comparison even if not in absolute).

The second point would presumably imply whatever the issue was, it wasn't solely something that happened instantaneously once the decline began, but rather at least two events (presumably not independent) - one that impaired flight, and one that stopped the data transmission (and also likely impaired flight further).

No, you can't generalise from that.

For everyday flights, FR24 displays enough plot points to produce a reasonably smooth track, with plots typically at 6-8 second intervals, while suppressing intermediate points to save bandwidth. That's why the initial download for the accident flight only had 4 plot points.

The supplementary "granular" data (FR24's description) contains plots towards the end of the takeoff roll at roughly 0.5 second intervals. So we can reasonably conclude that the aircraft's transponder stopped squittering within a second (probably less) of the final plot point.

Please stop posting information from this commercial aircraft spotter site. It is frequently inaccurate. ADS-B site free to use and more accurate IMHO.

Data from the various flight trackers may vary in coverage or granularity, but there is no reason in this instance to believe that airborne position/altitude data published by FR24 is less accurate than that from any other flight tracker, whether commercial or not.

What don't you believe in the published data?

No evidence of engine failure - Not true. No engine noise on video where you would expect TO or TOGA power to be in use. Mayday call stating No Power

No evidence of RAT deployment from a poor image . - You can argue Not from the Image but...: 2 independent audio analysis of the video audio shows the sound comes from a deployed RAT plus JB's video. Plus the guys who live in SEA having heard 100's of RATs deployed during test flight have stated that the sound is a RAT.

No evidence of electrical failure . - Not true. Reported cabin emergency lights going off, FR24 feed stopped just as in the 737 South Korea incident in December. APU intake door partially open at crash scene, suggesting an APU autostart.

Now you can call into question the above evidence but to state there is none, is simply not true.

No, they did not climb that high. Latest FR24 ADS-B report was indeed 625 ft, but that is based on 1013 (STD). With the local QNH being 1000, that 625ft becomes roughly 300ft MSL. Corrected for airport elevation, this is just above 100ft. The last recorded altitude of the aircraft was roughly 100ft AGL, which does not mean it didn\x92t climb a bit higher, but the aircraft reaching 400ft is pure speculation.

Flightradar24 (I know, I know) has a short blog on the (very minimal) ADS-B data available. There's only around 4s of useful data available from 21ft o 71ft altitude (last packet received 0.8s later), But: it's odd seeing the speed DROPPING shortly after takeoff. Even if you calculate total energy (kinetic + potential) it's falling, i.e. the engines aren't producing thrust. (In fairness reported speed doesn't match my calculated speeds, but even with mine I don't see power). Also: if you assumed no thrust from 71ft AGL @ 172kt you'd reach 250ft at 160kt. Isn't that roughly where they ended up? Noisy data, but this suggests the engines stopped producing power almost as soon as the wheels left the ground. (If someone could download a CSV of another similar flight and send to me I can do a compare and contrast of Total Energy)

If you wanted to an analyse this further:
1. You might mathematically start at TE=0 at start of takeoff-roll, and treat drag as minimal until rotation.
2. Typically rotation will be to say 15deg nose up, but flight path will be much less (5deg? for heavy hot 787). Once that rotation is complete, aircraft will stop accelerating. Therefore engine thrust (energy gain) equals gain in PE - drag x time.
3. This might give a better insight into where energy gain/loss became unusual?

Looking at the raw data in your post, and given the speeds are likely IAS based i.e. can be affected by wind, I don't see the IAS loss as equating to dual engine failure i.e. zero thrust - but could be wrong. Once a heavy airliner gets to lift off the acceleration is reduced (drag) and the decays to zero as PE gain kicks in.

Ditto a time / distance to the crash site might give some energy info? Looks like the crash site is 50' (?) below the airfield (Google Earth will give more).

I think you are doing an interesting study on the absence of other info

I think this is as interesting a line of inquiry as I've seen recently. The problem is getting the data and theory close enough to be meaningful.

For instance, what about induced drag (admittedly much complicated, I imagine, by varying ground effect) once rotation begins? A comparison with another 787-8 flight from the same runway and under similar conditions (meteorological, load, etc.) might be ideal.

Are there not tools accessible to ordinary users for making detailed such simulations, rather than a back of the envelope calculation? I daresay Boeing has made such simulations already, and have a pretty good idea of whether and when thrust loss might have occurred.

well I stopped reading the referenced article when ...

IMO, I don't know if that is trustworthy - the FR24 ADSB data seems to show that the aircraft was at 21ft AGL between the 1500ft and 2000ft markers from the end of the runway.

https://www.flightradar24.com/blog/f...rom-ahmedabad/

I don't know if I'm allowed to post pictures - my last post with a picture didn't show up, so I'll try adding it separately from this one. It's basically an overlay of the FR24 blogpost map on a google maps satellite view of VAAH.

The 787 in particular has a system that is fully automated for takeoff calculation. That includes Takeoff Distance, all relevant airspeeds, etc and uses combined sensor data to make pilot error in calculations exceedingly unlikely.

In addition the valid settings for takeoff flaps simply begin at 5\xb0, so anything less isn't even offered. The corresponding alarms will thus always trigger if you don't have at least 5\xb0 flaps set upon setting takeoff thrust, possibly requiring a higher setting depending on the calculated takeoff configuration. As mentioned before in this thread the loading of the accident aircraft should have been far below its maximums, so a 5\xb0 flaps takeoff is quite ordinary, and the aircraft left the runway well short of its end.

Also the aircraft used the entire runway after backtracking along it since there are no taxiways going that far. This information has been corrected by FR24 a while ago and stems from the incomplete GPS positional data that is inherent in ADS-B tracking, especially on the ground.

The 787 in particular has a system that is fully automated for takeoff calculation. That includes Takeoff Distance, all relevant airspeeds, etc and uses combined sensor data to make pilot error in calculations exceedingly unlikely.

In addition the valid settings for takeoff flaps simply begin at 5\xb0, so anything less isn't even offered. The corresponding alarms will thus always trigger if you don't have at least 5\xb0 flaps set upon setting takeoff thrust, possibly requiring a higher setting depending on the calculated takeoff configuration. As mentioned before in this thread the loading of the accident aircraft should have been far below its maximums, so a 5\xb0 flaps takeoff is quite ordinary, and the aircraft left the runway well short of its end.

Also the aircraft used the entire runway after backtracking along it since there are no taxiways going that far. This information has been corrected by FR24 a while ago and stems from the incomplete GPS positional data that is inherent in ADS-B tracking, especially on the ground.

Looking at the detailed ADS-B data released by FR24 and the June 10 AI171 data, I noticed that the two flights show the following data at similar points in the takeoff phase
Height :575ft
Speed :182kts
Even though it is impossible that the takeoff weight and outside air conditions are the same on the two flights, we guess that there was nothing wrong at this moment.

Quote:

Originally Posted by Squawk7700

Perhaps?

Some questions, if I may:
When is the crew expected to do this? Wouldn't it be armed prior to commencing the takeoff so that it (one or the other) would engage automatically?

How does the 787 "manage thrust" after takeoff? The jet has only just left the ground; surely the throttles would be at maximum power and pitch would be used to attain and maintain V2 until the end of the second segment.

Are you saying the pilot( s ) just sat there while the ATS reduced the thrust (because is all it could have done, as it was at maximum for the actual takeoff).

Fixed on what? Or did it "decay" because the PF pulled the throttles back?

There is no evidence the jet climbed too steeply; I assume you saw the granular FR24 plot (from FR24 itself) which showed the initial flight path of this one was in the middle of the range, and the video clearly shows a normal initial climb and deck angle before "the @#$% dropped out of it".

So BOTH pilots just sat there, didn't pull the gear up, did nothing else and crashed it (pretty well, I might add, with superb pitch control right to the last second).

Interesting but totally irrelevant as the jet never got above 200ft.

You're clearly implying a complete ballsup by the crew, making multiple serious mistakes or errors of omission.

Have a look at the latest data from FR24 (from post 439 in the previous thread).

https://www.flightradar24.com/blog/f...rom-ahmedabad/

In the CSV data set that can be downloaded from that link the first point with altitude data is 1630 ft short of the departure threshold. That point is 575. The highest alt recorded in the data set is 625. All the points with altitude data overlay the departure runway. I do not understand how anyone is using this data set to determine the maximum altitude which was way past the departure end.




Edit to add - I have made no attempt to correct the raw ADS-B altitude data. There is no need to make any correction to see altitude gain.