PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Tech Log (https://www.pprune.org/tech-log-15/)
-   -   UPS cargo crash near Birmingham AL (https://www.pprune.org/tech-log/521370-ups-cargo-crash-near-birmingham-al.html)

PJ2 15th Aug 2013 17:06

Speed of Sound;

Not strictly true!

A number of people carried out 'reconstructions' after the Asiana 214 crash using published radar data for altitude and ground speed which turned out to be surprisingly accurate once the DFDR information was released. http://images.ibsrv.net/ibsrv/res/sr...lies/wink2.gif
Thanks for your response.

To my knowledge no one here has the DFDR data so we can't really say that. The comparison is with statements made about the data, not the data itself.

I realize I'm being fussy, but that's what this work is all about - second-hand information isn't good enough even from reliable sources.

For a number of reasons, the caution regarding the use of such unproven data is warranted and necessary. The risk is, as I'm sure you're aware, that people actually believe plots and animations made on such thin data and begin drawing conclusions, just like a lot of other behaviours based upon "internet knowledge".

I fully understand the capabilities of radar data plots (which are even used in formal reports at times), but the sample rate is too low to support assumptions of accuracy without confirmation with the aircraft recorders.

A Squared 15th Aug 2013 17:25


Originally Posted by Flying Guy
"just read the altimeter setting and it was not too far off standard, so I am thinking it wasn't altimetry...29.97 is close enough to 29.92 that it shouldn't have caused the crash... "

AHHH, I guess we should always keep our altimeters at standard - avoid many accidents.

Not sure where you come up with this inane comment. Nobody suggested anything of the sort. The point was pretty obvious and it's amazing that you need it explained, but as you obviously missed it, here's what was meant: For the actual conditions existing at the time of *this* particular incident, forgetting to reset altimeters to QNH thru transition would have resulted in an altimeter error of approximately 50 feet, which obviously far too small to have resulted in *this* accident. The suggestion that resetting altimeters to QNH on descent be done away with exists solely within your imagination.

DaveReidUK 15th Aug 2013 17:43


Not sure where you come up with this inane comment.
That'll teach Flying Guy not to use irony in his posts, lest they be taken literally. :O

A Squared 15th Aug 2013 17:50


That'll teach Flying Guy not to use irony in his posts, lest they be taken literally.
I understood completely his irony. That's kind of the point, he was sarcastically and ironically responding to a something which hadn't been hinted at. Not even a little bit.

DaveReidUK 15th Aug 2013 18:01

Second media briefing on the investigation to be held 4pm CDT today.

PEI_3721 15th Aug 2013 18:07

OK465. Thanks for the chart explanation (#132 / 135), although I am surprised by the accuracy difference between LOC (an angular system) and GPS RNAV (linear, RNP 0.3); I also note that BIDPE is a waypoint in the GPS procedure.
However, it still appears illogical for the RNAV approach to allow a descent to 2600ft (well below a constant-angle path), when such a relatively new procedure could have been constructed to help improve safety.

As Airbubber notes, most modern installations use the GPS receiver built into EGPWS; however this is not used for navigation. Other EGPWS configurations still depend on an external nav input, which even with GPS (used for nav) is only assumed to correctly represent the aircraft’s position, i.e. GPS drop out / error, the nav position could ‘slip’.
Depending on the aircraft’s nav installation, some of the early EGPWS installations could suffer map slip, which could falsely position the aircraft in the EGPWS safe area before the runway, and the in-parallel standard GPWS function would not warn of low terrain due to the landing configuration – gear and flap.
Thus what was the EGPWS nav configuration in this aircraft?

PilotsResearch 15th Aug 2013 18:11

Accuracy of inbound track
 
The FlightAware track shows, about 20 nm north, a jog to the right, presumably to get lined up for final. However, the new track didn't quite line up with RWY 18. Rather, it would have led them slightly east, crossing RWY 24 near its touchdown zone.

Any ideas on why this error? Is this measurement error in FlightAware data? (It does appear, however, to show the crash site accurately.)

olasek 15th Aug 2013 18:15


approach to allow a descent to 2600ft (well below a constant-angle path)
Again, you keep repeating this "well below descent path" like a broken record, it is your poor understanding of the approaches. Take any other say ILS approach and any point before the FAF will be for sure "below descent path" by obvious geometry, it is simply false to consider points before FAF as having anything to do with the descent profile. This is how great majority of the approaches in the US are constructed, it has nothing to do with safety. Grab some Canadian charts, you will also find similar examples there. Yes, it is absolutely OK to descend to 2600 at BIDPE and stay at 2600 until you reach the FAF, such interception of glide slope from "below" is perfectly routine.

Lonewolf_50 15th Aug 2013 18:38


I fully understand the capabilities of radar data plots (which are even used in formal reports at times), but the sample rate is too low to support assumptions of accuracy without confirmation with the aircraft recorders.
Restated for emphasis.

I have now had a chance to review the approach plate.

IAF at COLIG is 14.1 DME, which is 12.8 nm from MAP. Min Alt 3500 ft.
FAF is BASKN, 6 DME, 4.7 nm from MAP. The 3.28 degree glide slope depicted (suggested) is IIRC based on the idealized slope from FAF to touchdown, however, I'd need to look that up to refresh my memory.

In the lower left hand corner, FAF to MAP times are 1:53 at 150 kts GS, and 1:34 at 180 kts GS. This would tell me, as a pilot, that if I were flying a CAT C or D aircraft on this approach, I should be configured, and on approach speed well before the FAF, and have my estimated ROD figured out before I hit the FAF. If I had a tool in the cockpit that allowed me to create a 3.28 glide slope that keeps me above min altitudes before FAF, all the better.

It looks as though the approach need ~700 fpm ROD if GS is 180, ~580-600 FPM ROD if GS is 150.

It will be interesting to learn the actual speed they were flying once that data becomes available from the NTSB.

DaveReidUK 15th Aug 2013 18:47


Is this measurement error in FlightAware data? (It does appear, however, to show the crash site accurately.)
You are kidding, aren't you?

Flight Track Log ? UPS1354 ? 14-Aug-2013 ? KSDF - KBHM ? FlightAware

Have you tried putting FlightAware's supposed final position plot (33.5681 -86.7539) into Google Earth ?

Sorry Dog 15th Aug 2013 18:51


There has been discussion about Harold and Maude seeing the plane on fire or hearing sputtering, and I agree, you almost always get "witnesses" that say that. In this case, I think there may be some truth to the matter. As mentioned previously, the plane clipped the power lines (and trees) before impacting the hill. This could have ruptured a fuel tank and the impacted electrical lines could have ignited it. From the insulators I can see in the photos, it looks like that there is 12KV service in that area, so the arcing could have been significant.

I also think that the "sputtering engines" may have been the sound of high voltage arcing, spring fuses melting, or the utility recloser in operation....
Maybe...but I don't think the power line part is likely.

I drove by the accident 3 times and didn't see any power line that were hit directly by the plane. I think the power lines were damaged by tree brush being knocked down. The trees there are close to 70-80 feet in height. Also, one other thing I saw that seemed to stand out. From a saving it (or at least improving your crash circumstances) point of view, only the last tree looked large enough to cause significant structural damage, which would have only affected one side or one engine. I would think they would have gone to TOGA at least when they started to hit the smaller trees which were at a similar altitude to the impact at on the hill and about 1000 to 1200 feet before. That's only about 6 to 8 seconds. Also, in the overhead pictures it's hard to see how steep the hill is, but the impact angle was probably at least 20 degrees due to the slope of the hill. If they had 20 more feet of altitude, they would have had a much better chance of surviving.

I also think the comparisons to Asiana don't have much value at this point, since the conditions seem quite different.

Speed of Sound 15th Aug 2013 18:58


It will be interesting to learn the actual speed they were flying once that data becomes available from the NTSB.
Shouldn't be too long.

http://i1280.photobucket.com/albums/...ps4daa9162.jpg

Airbubba 15th Aug 2013 19:01


The 3.28 degree glide slope depicted (suggested) is IIRC based on the idealized slope from FAF to touchdown, however, I'd need to look that up to refresh my memory.

It looks as though the approach need ~700 fpm ROD if GS is 180, ~580-600 FPM ROD if GS is 150.
I'm just a driver, not a rocket scientist but you might want to re-check those numbers for a 3.28 degree glide path. :confused:

RCav8or 15th Aug 2013 19:48

Just a question from the peanut gallery.
Wouldn't, or shouldn't TCAS have given the crew ample warning of their situation?
Pete

Coagie 15th Aug 2013 19:57

I read through the thread. Maybe I overlooked it, but did the pilots let the tower know they were in trouble, or were they unaware of trouble or too busy keeping the plane aloft to radio? Thanks.

Huck 15th Aug 2013 19:59

From the Sooeet thingy....


The ground speeds shown on Figure 2 should be at most 4 knots above the indicated airspeeds that the crew of the accident aircraft would have seen on their cockpit instruments. This is due to the fact that the prevailing low level wind (a tailwind), was at most 4 knots.
Not unless you ignore the 2% per thousand difference in indicated versus true airspeed.

Which you can't.

Coagie 15th Aug 2013 20:44


I read through the thread. Maybe I overlooked it, but did the pilots let the tower know they were in trouble, or were they unaware of trouble or too busy keeping the plane aloft to radio? Thanks.
Answer to my own question. Found an article that said preliminary reports said there was no distress call. It was in an article pointing out that, maybe, the standard for pilot fatigue should be the same with freight and passenger carriers. I wonder if the pilot flying dozed off, after he lined up for the approach, and the other pilot was already taking a nap? Ex-NTSB chief: FAA should rethink pilot fatigue rules after Ala. crash | Al Jazeera America

Huck 15th Aug 2013 20:46

I would think it would be impossible to nod off while approaching a 7000' runway at night in a widebody, no ILS, hilly terrain, etc....

olasek 15th Aug 2013 20:54


The RNAV 18 approach loads from BIDPE at 2600A, COLIG is not loaded as part of the RNAV 18 approach procedure and it does not have to be flown from COLIG. COLIG is loaded as a transition if desired. There are 2 others.
It all depends how pilot chooses the approach to be loaded, if he loads it as "vector for final" then yes COLIG won't be there, but any other selection will load COLIG as all transitions pass through that point.

TangoBar 15th Aug 2013 21:05

Not to suggest it's a factor here or not, Huck, but I would say, as a longtime freightdog, that it's always possible if you're fatigued or dealing with a schedule flop.

If you're tired enough, you'll nod off on an ILS to minimums. At some point, fear and adrenaline aren't enough to stave off microsleep or full-on unconsciousness.

Again, not suggesting anything- we'll have to wait for the NTSB to pull the data off the boxes and present it.


All times are GMT. The time now is 03:26.


Copyright © 2018 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.