Originally Posted by Centaurus
(Post 10305367)
Here is another point of view. There is evidence the aircraft was diving steeply before impact with the water. Regardless what caused the stabilizer to have moved fully forward, there is no doubt the pilots would have been trying to pull out of the dive by pulling hard on the elevator. Extreme air loads caused by high speed would have been working against them. The significant forward position of the stabilizer would be in direct opposition to the elevator position during the attempted recovery; thereby severely limiting the effectiveness of the elevator.
Under the heading Manual Stabilizer Trim, (Boeing 737 FCTM Non Normal Section), the following advice is offered: "Excessive air loads on the stabilizer may require effort by both pilots to correct mis-trim. In extreme cases it may be necessary to aerodynamically relieve the airloads to allow manual trimming." To relieve airloads, the crew must momentarily release all backward pressure on the elevator then rapidly wind the stabilizer trim backwards manually or electrically. In turn, this allows more effective elevator control. In other words, a yo-yo manoeuvre. The crew needed to react instantly and correctly to relieve air loads in this manner. Unfortunately, the Lion Air crew did not have the altitude to successfully recover before impact. |
I can only see more and more such incidents occurring.
The telemetry including stick-shaking that the pilots get is mostly interpreted meaning that you do not feel the plane itself in your hands, but a computer has decided what to tell you, and so you .... really are up against it. In order to correctly comprehend the situation, you have to engage the subconscious animal (who understands physical reality), and integrate it with your conscious mind's training of normal functioning of the instruments, and add to that .... your behind the scenes understanding of how the computer works in x number of situations that you have been warned about. And you have to integrate these three systems of consciousness, into a correct response in a number of seconds whilst the aircraft is falling into the sea. The chances that you can do that are very slim. Sullenberger, when he saved his place, reverted to the subconscious animal (who feels physical reality) and had had deep training in the military, he then cut off any routes that had a low chance of success, and was left with a single option, that his well trained animal executed. Within himself, he reverted to one reliable well trained system. And it would be best for pilots if they could in such a situation, cut the s***, and revert to basic operation in seconds. I believe that trying to "solve" the problem is the problem, far too complex. Probably what the airlines will eventually do is teach pilots a handful of typical loc situations with workarounds. But I don't think pilots will anymore be able to understand what is happening in a new loc situation. They will simply try to relate the new loc situation to one of the dozen they have learnt about, if they get a match then they have a workaround, if not .... there is no answer. Of course if you were raised on a farm, you might have the idea to pull the circuit breakers and fly it like a cropduster, but you will never been trained to do that because it goes against the future cost savings of the airlines, and frankly you would have to be a very unusual kind of person to do that. In any case, a lifeboat (emergency procedure) is only a lifeboat if it is well maintained and used regularly, otherwise you may as well not have one. In fact on the previous 4 runs the flight had problems, but they kept going and thought they would solve it in the air. And the maintenance crew thought changing the sensor would fix things - but did they take the plane up to see if it did. It's not good. There is a lot of financial pressure and insincerity to be frank. If I was a pilot, in such a situation, I would (a) try to relate it to a known issue or workaround, if not (b) 45 seconds limit to comprehend the new situation, if not (c) pull the circuit breakers and fly it manually ... on this aircraft some system are not fully manual so know that as well, and this must be trained so you have certainty about it. ... but the airline would be unlikely to train you for (c) because it smells of panic. |
Back in 2008 there was a very similar incident with a Qantas A330, except in that event the Pilots regained control and managed to land. https://www.atsb.gov.au/publications...r/ao-2008-070/ |
Originally Posted by SLFinAZ
(Post 10305545)
I've got a fairly basic question, my understanding is that a fundamental concept in aircraft design is that a control surface should never be able to be neutralized let alone over ridden by it's trim tab(s). Yet from some of what I've read on this thread it seems that that it's actually possible with the 737 for the force of the trim tab to exceed the capability of the main control surface?? That makes no sense to me at all...
Someone else already gave you the wiki page. On most "newer' big aircraft there is a moving horizontal stabilizer. If you trim, or the auto-trim works, it sets the movable horizontal stabilizer so that you don't have to push or pull on the elevator. there is no trim tab. The stabilizer is a lot bigger than the elevator, so if something goes wrong with the setting of the stabilizer, like a runaway trim due to an air data/aoa failure it could overpower the capabilty of the elevator/pilot input. Normally the emergency checklist would direct you to do something to switch the auto-trim off and regain manual control (on the B737 elevator cutout switches). |
If the PM is actioning the QRH and doesn’t realize that the forward-moving trim wheel is NOT being moved by the PF, I can see a situation developing whereby a breakdown in communication could lead to a massive out-of-trim condition with the PF waiting for some sort of QRH-led solution to be forthcoming. I can see this scenario happening...quite easily...and quickly. Many are pontificating the need to cut out the stabiliser trim and run the stab trim runaway items...that’s easy to say in an armchair when not faced with multiple, confusing sensory inputs. The idea that this STS system can continue in action after faulty AOA-data driven miscompares, is odd. IMO |
Originally Posted by hans brinker
(Post 10305652)
Maybe it is me getting grouchy in my old age, but the whole salute, sends, opines and such really takes away from the message....
BTW, thank you for your service, Gums! |
Originally Posted by B744IRE
(Post 10305573)
For less than $1500 a GA pilot can buy a portable EFIS giving GPS Artificial Horizon, GPS Groundspeed, GPS Vertical Speed and GPS Track with a 4 hour rechargeable battery.
Yet new commercial aircraft are still produced with standby instruments fed from a pitot-static system and a standby compass with a compass card...WHY? All of the accidents over the years caused by blocked or faulty pitot probes/static source/instruments could have been prevented by GPS instruments totally independent of any aircraft system. Instead of one standby instrument(s) on the Captain's side, each pilot could have standby instruments for minimal cost. You understand that the current prevailing understanding of the accident is that a trim system on the airplane was introducing pitch changes that the pilots weren't able to overcome, right? Rhetorical question, it seems not. |
@hans No problem, man. I can take it, as my call sign was assigned to me and I did not choose it. I opine when not having reams of data, testimony or having been the principal pilot in the incident. So will continue to designate opinion and theory versus asserting facts or lecturing the newbies and non-pilots, as some here do. We have the Tech Log for education as well as opinion and theories. I have never told a poster “if you had read.......”. I have never brought up the ethnic or religious background of a crew in an accident, and I will bet I have taught more pilots to fly from more countries than you! So there! I got personal, but back to analysis and opinion and experience in these matters to hope we have no more like this one. out, |
After the replacement, however, pilots that flew a Denpasar-Jakarta flight still found a 20° difference on the left-hand angle-of-attack sensor. During this flight, the pilots implemented "a number of procedures" to rectify the issues, and the jet subsequently landed in Jakarta safely. |
Originally Posted by DaveReidUK
(Post 10304595)
Except that the author of the quoted post took pains to stress that both airspeed and groundspeed values are affected by unreliable AoA, in fact GS was mentioned twice in that context:
I look forward to learning how so. |
Originally Posted by sAx_R54
(Post 10305766)
Would have thought thus far you have learned plenty!
|
The circumstances around this discussion are making me feel glad for the trim cutout buttons being on the yokes on my plane instead of somewhere else you have to reach....
|
Any information on the search for the CVR? |
Originally Posted by Flutter speed
(Post 10305474)
A trim runaway condition should be quite identifiable on a 737, these clunky trim wheels leave no misunderstanding of the direction and speed of trim at least. However, if the AOA disagree warning was triggered, ...
|
Originally Posted by Derfred
(Post 10305068)
Despite the outcry from some posters above in the light of the Boeing bulletin and FAA directive, the fact remains that existing procedures should have brought this aircraft safely back to ground. The bulletin and the AD both say this. It appears that maintenance and training are the major contributors to this tragic accident. Maintenance: a maintenance culture that allows an aircraft to fly 4 successive sectors with a known issue affecting air data is completely unacceptable, and it certainly wouldn’t happen in any airline with a proper attitude towards maintenance and safety. Training: given the above was allowed to occur, a well trained crew should still have been able to handle it. In the absence of well trained crew, an accident was simply a matter of time. There is no such thing as pilot-error in an airline, only a poor training system which allows poorly trained pilots to operate. |
No Way To Train This Specific Failure....
I keep seeing references to "training" and a procedure for runaway trim, both of which are obviously real things, and training for runaway trim is also real.
However, training for the particular failure suspected here may NOT be possible, at least not in any MAX simulator. The current breed of simulators for the majority of 'new' aircraft are built around a "binary" supplied by the aircraft manufacturer, which is now part of the data package. The binary is essentially the aircraft avionics software and any other systems models, packaged for use in a realtime computing architecture. The malfunction list for the data package is fixed and is intended to include any of the anticipated failures that the crew may experience. Adding a specific malfunction is something that requires the binary to be updated. Sitting here, I don't have access to the list of supported failures included with the current release MAX binary, but my strong suspicion is there is no malfunction support for AOA sensor failure (or stuck or similar), meaning any crew encountering this would have no possibility of seeing this exact failure and problem cascade in the simulator. Maybe some with better access to a MAX sim can confirm? - GY |
Originally Posted by sAx_R54
(Post 10305825)
It must take remarkable fortitude to ignore what has now appeared in plain sight, suggesting the previous sectors were somewhat operational beta-tests of an inherent and unknown programming defect. What is completely unacceptable is that this was not exposed in the commissioning flight tests!
That said, an "inherent and unknown programming defect" (in any software environment, not just aerospace) by definition requires a specific, unforeseen combination of factors (possibly including other defects) in order to trigger it. It's entirely possible that the required combination of factors never emerged during the certification process. If there had been precursors to this issue, while we might not have heard about them prior to the crash, they would undoubtedly have emerged in the last 10 days. AFAIK, none have. |
Originally Posted by JPJP
(Post 10305746)
I found the underlined quote from the article curious. Either they have an AOA Indicator on the PFD, or they were able to get into the Maintenance side of the FMS, or a maintenance person on the flight deck plugged into the Mx port. An AOA Indicator is an option and it does read up to a maximum value of + 21 degrees. That would seem to be an extreme value to see inflight after the aircraft was just returned to service (‘fixed’). His reply was: "[T]here was no standalone AoA indicator in the cockpit" on JT610. So perhaps prior to the incident flight, as JPJP suggests, "they were able to get into the Maintenance side of the FMS, or a maintenance person on the flight deck plugged into the Mx port." That seems like a valid inference if the information in the flightglobal article is correct. This isn't my contact's first time covering an Indonesian air disaster, and he's got a very good track record. So take this data point for what it's worth. |
Whatever happened to the ol ' three sensors, at least two of three to agree concept for data to be used ?
|
Originally Posted by Ken V
I agree this note in the manual is likely not related to this accident. All the data available indicates the accident aircraft was well above stall airspeed for the pressure altitude they were operating in and thus there was plenty of elevator authority available.
Originally Posted by Ken V
Agreed, this is unrelated to this accident. All the available data indicate the accident aircraft was well above 1G stall for the pressure altitude and thus they had plenty of elevator authority. Further, that same data does not indicate the engines were at a "high power" setting.
|
All times are GMT. The time now is 02:26. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.