737MAX Stab Trim architecture
Thread Starter
737MAX Stab Trim architecture
Post a schematic of the Horizontal Stabilizer TRIM architecture?
Bluntly, I am looking for function and response to Auto/Manual Trim commands.
An image of the AoA Vane installation would be helpful as well.
Possible MCAS operated as designed, that the signal offset from AoA sensor was Mx related.
If I’m a FCC, and I see two AoA values from the sensors, I am looking at two separate vane results. I don’t speak AoA, so I consider both values. The two are different, but only in absolute value. They are tracking in the airstream identically.
Was I programmed to average the two? If so, I might not think anything is wrong. What if humans consider malfunction of vanes only as aberrant behaviour? One smoothly tracking, the other jerky jerky! What if I don’t grok “Similar but different”?
What if one vane “thought” zero was zero, the other “thought” twenty degrees up was zero? Fine by me, I’m looking for herky jerky, not two lines with the same shape?
Not MY job to calibrate the silly things.
One other thing. If I was programmed to sum (average) the two vanes, and the average was less than Stall AoA, why would I trip the Stall Warning? I might still consider Nose Down Trim, in spite of Dave.
Hal
AI. Not long now.
Last edited by Concours77; 23rd Nov 2018 at 18:41.
STS/trim architecture
Salute!
I have an old FCOM, but no substitute for actual mechanical and electrical diagrams. And "code" of the black boxes wuld be even more valuable.
As you know, I am a fighter pilot that flew two very smart planes, then did system engineering for another 13 or 14 years in the weapon control and human interface aspects of military planes. I do not know anything about Councourse, as the public profile is scant, but from previous posts suspect technical savvy pilot or engineer of some sort.
+++++++++++++++++++++++++++++++++++++++++
- I found a pic of the AoA sensor on a 737, and the pilot side is below the cockpit and just behind the radome. Another contributor has verified my suspicion that removing the radome could influence the AoA "plumbing". That was an early post on the main thread. From our very own Dave;
Yes - specifically the LH ADM needs to have the pitot input disconnected to gain access to the radar.
GOL nearly lost a B738 seven years ago. Fresh from the factory, a radar failure required a software reload. When the technician reconnected the pitot hose, the connector was engaged, but not twisted in the bayonet fitting to lock it. The result was intermittent UAS, with vertical excursions even more extreme than the Lion Air.
That the crew and pax survived to tell the tale was, according to the report, largely due to a deadheading captain on the jumpseat who exhorted the PF (and the check captain in the RH seat) to "fly the d*mn airplane" (or words to that effect in Portuguese).
In the Viper, we used AoA for a few things. a) when gear up, AoA versus gee limit function, whereby 25 deg +/- was max AoA at 1 gee and 15 deg at 9 gees b) leading edge flap scheduling, which was a funcion of mach and AoA and c) gear down, AoA bias applied to the basic gee command and a warning horn above 15 deg AoA.
Three sources: two cones and one hemispherical probe that was used for many functions. It used middle value, not an average. As with the gee and rate sensors in our system, it used the most benign value when down to two sensors. Not sure of all the failure criteria, but I think we had to go down to one sensor and then system went to standby gains. My tech data is unclear about the criteria. But the plane flew well with no AoA inputs if you were gentle, and the rate sensors helped a lot in that situation.
1) I see some overlap in the STS and MCAS and even the "feel" implementation, and will have to look again at the FCOM. So we have three systems that might be using AoA, and the MCAS for sure. Tink STS uses only CA, is a poor man's speed stability system.
2) I will look back at the FCOM I have re: 'feel" implementation, which appears to use independent AoA and other air data and does not physically move the stab or elevators.
2) I do not like either MCAS or STS moving the stab the way it is described. I would use the Airbus implementation where elevator command is the driver, and use the 737 "feel" system to help pilots realize they needed trim ( like all the old planes did when we were taught to trim out the pressures we were holding). I don't like aerodynamically influencing the plane just to provide speed stability or the sense of speed stability unless you go whole hog fly by wire with a mechanical backup.
Gotta go, but will check back later.
Gums sends...
I have an old FCOM, but no substitute for actual mechanical and electrical diagrams. And "code" of the black boxes wuld be even more valuable.
As you know, I am a fighter pilot that flew two very smart planes, then did system engineering for another 13 or 14 years in the weapon control and human interface aspects of military planes. I do not know anything about Councourse, as the public profile is scant, but from previous posts suspect technical savvy pilot or engineer of some sort.
+++++++++++++++++++++++++++++++++++++++++
- I found a pic of the AoA sensor on a 737, and the pilot side is below the cockpit and just behind the radome. Another contributor has verified my suspicion that removing the radome could influence the AoA "plumbing". That was an early post on the main thread. From our very own Dave;
Quote:
Originally Posted by gums 
The air data sensors appear to be just behind the radome and access panels for the radar. There's possibility of contamination or even a "loose" pnematic line depending upon the actual configuration of the air data sensors.
The air data sensors appear to be just behind the radome and access panels for the radar. There's possibility of contamination or even a "loose" pnematic line depending upon the actual configuration of the air data sensors.GOL nearly lost a B738 seven years ago. Fresh from the factory, a radar failure required a software reload. When the technician reconnected the pitot hose, the connector was engaged, but not twisted in the bayonet fitting to lock it. The result was intermittent UAS, with vertical excursions even more extreme than the Lion Air.
That the crew and pax survived to tell the tale was, according to the report, largely due to a deadheading captain on the jumpseat who exhorted the PF (and the check captain in the RH seat) to "fly the d*mn airplane" (or words to that effect in Portuguese).
Three sources: two cones and one hemispherical probe that was used for many functions. It used middle value, not an average. As with the gee and rate sensors in our system, it used the most benign value when down to two sensors. Not sure of all the failure criteria, but I think we had to go down to one sensor and then system went to standby gains. My tech data is unclear about the criteria. But the plane flew well with no AoA inputs if you were gentle, and the rate sensors helped a lot in that situation.
1) I see some overlap in the STS and MCAS and even the "feel" implementation, and will have to look again at the FCOM. So we have three systems that might be using AoA, and the MCAS for sure. Tink STS uses only CA, is a poor man's speed stability system.
2) I will look back at the FCOM I have re: 'feel" implementation, which appears to use independent AoA and other air data and does not physically move the stab or elevators.
2) I do not like either MCAS or STS moving the stab the way it is described. I would use the Airbus implementation where elevator command is the driver, and use the 737 "feel" system to help pilots realize they needed trim ( like all the old planes did when we were taught to trim out the pressures we were holding). I don't like aerodynamically influencing the plane just to provide speed stability or the sense of speed stability unless you go whole hog fly by wire with a mechanical backup.
Gotta go, but will check back later.
Gums sends...
Join Date: Sep 2016
Location: USA
Posts: 803
Likes: 0
Received 0 Likes
on
0 Posts
I was also wondering why they would use the trim instead of elevator feel to tailor the elevator forces, and FCeng made a post with a pretty good answer, in the STS thread. https://www.pprune.org/showthread.php?p=10303995
Salute!
I don't see eye to eye with FC about this issue My comments in red:
Gums sends,,,,
I don't see eye to eye with FC about this issue My comments in red:
First, if the unaugmented airplane were neutrally speed stable it would not require any steady elevator for a speed change and thus stiffening the column feel would not help as none would be needed to fly faster or slower. [dat's how Airbus and Viper work. 'bus is gee cmd like Viper, and speed stability is there due to aero design, so they use power for speed, best can tell. Viper was negative static stability until above 0.9M and had zero speed stability. Pitch was gee cmd only, unlike 'bus which corrected the gee cmd for pitch angle and bank angle] Further, if the unaugmented airplane were actually unstable with regard to speed it would require a push force to keep the nose from rising after slowing down and a pull force to keep the nose from falling after speeding up. [ very true. but the 737 is normal and reducing speed results in descending and increasing speed makes it climb. So STS moves the stab the "wrong" way to make the pilot trim the "right" way. GASP. That's what Mana saya over on the other tech thread, and he just trimmed the way he wanted/needed to, heh heh] These are clearly not the desired situation. Stiffening the column feel in that event would actually make the speed stability handling characteristics worse. [ I do not agree. Let the plane's normal aero speed stability work unless it is not aerodynamically stable. I expect the damn thing to nose over if I pull off power! I want it to keep my last trimmed speed/AoA]
AI. Not long now.
Join Date: Mar 2014
Location: WA STATE
Age: 78
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
http://www.eaton.com/ecm/idcplg?IdcService=GET_FILE&allowInterrupt=1&RevisionSelectio nMethod=LatestReleased&Rendition=Primary&&dDocName=PCT_20101 9
Which gives a pdf file DS400-1A_B737 Stab Trim Upgrade.pdf
Eaton’s new Model 6355C Stabilizer Trim Motor features:
• Brushless three phase mo-tor design
• Low loss power bridge with IGBT switches
• Processor based motor commutation and velocity control
• Dual current limit (torque) control circuits
• Power up built-in test
• Continuous fault monitoring
• Fault storage (non-volatile memory)
• RS-232 test/maintenance interface
• Investment cast housing
• Two stage spur gear train
• Modular, bottom up assembly — two electronic sub-assemblies, motor, housing with gear train
• Brushless three phase mo-tor design
• Low loss power bridge with IGBT switches
• Processor based motor commutation and velocity control
• Dual current limit (torque) control circuits
• Power up built-in test
• Continuous fault monitoring
• Fault storage (non-volatile memory)
• RS-232 test/maintenance interface
• Investment cast housing
• Two stage spur gear train
• Modular, bottom up assembly — two electronic sub-assemblies, motor, housing with gear train
Eaton’s Stabilizer Trim Motors
(STM) Model 6355B0001-02 and -03 have been used on Boeing’s 737-600/700/800/900 aircraft, starting with Line #1423, delivered in December 2003. The “B” model has been
superseded by Model 6355C, and replacement parts for the “B” model will be available for a limited time only — estimated at 3 years, based on usage. Parts scheduled for future obsolescence include:
• EMI FIlter Assembly
• Brushless DC Motor Assembly
• Voltage Reference
• Control Board Assemblies
• Isolated Drive Transmitter
• Isolated FET Driver
(STM) Model 6355B0001-02 and -03 have been used on Boeing’s 737-600/700/800/900 aircraft, starting with Line #1423, delivered in December 2003. The “B” model has been
superseded by Model 6355C, and replacement parts for the “B” model will be available for a limited time only — estimated at 3 years, based on usage. Parts scheduled for future obsolescence include:
• EMI FIlter Assembly
• Brushless DC Motor Assembly
• Voltage Reference
• Control Board Assemblies
• Isolated Drive Transmitter
• Isolated FET Driver
Thread Starter
Maybe, but take note of the argument here: “sole source data”. Trying to simplify and economize reduced data. More data would “fix” the problem. The reliance on computed data is not harmed by this accident. The human element, Boeing v. Pilots is at center stage. There will always be deflected responsibility. The march continues to eliminate the “fragile human element....” Human decisions created human failing. AI avoids that problem. For good or evil, no?
Salute all!
Wow. Looks like a quorum of folks that wanna discuss the tragedy and "contribute". You never know when a regulator type or investigator or airline type digests our theories and such, but it might help to prevent another tragedy.
=================================================
You all know my background from the public profile, but too many "pruners" are "cute" with location and profile, including some here, so I always question some comments and assertions and opinions and..... The AF447 tech discussion was extremely technical and most contributors had extensive aviation and even "a/c type" background.
I was the lowly light puke that had flown the first fully FBW plane in service that had zero mechanical back up, had negative static stablity, and extreme body rates, AoA and gee values seen on almost every flight. But the heavy folks accepted me as well as Machinbird, and we got along fine.
I also worked with the human interfaces of the U.S. military platforms as a system engineer for about 14 years, so many of my opinions are based on "what would I do?", "How can I go back to a known condition?" , etc. And 99% of my control and display work was to prepare, target and launch a weapon. So I had to take into account many aspects of the process to ensure safety and reliability at the same time. With two no **** combat tours and only getting "shot down" once ( semi-crash landing with no power), and approx 4,000 hours in 5 warplanes plus some trainers, I was blessed to see many aero principles in action and all the "gotchya's". So with my location and bio out there on the Pprune profile and this missal, you all know where I come from.
++++++++++++++++++++++++++++++++++++++=
Present views/opinons on next post.
Gums presents...
Wow. Looks like a quorum of folks that wanna discuss the tragedy and "contribute". You never know when a regulator type or investigator or airline type digests our theories and such, but it might help to prevent another tragedy.
=================================================
You all know my background from the public profile, but too many "pruners" are "cute" with location and profile, including some here, so I always question some comments and assertions and opinions and..... The AF447 tech discussion was extremely technical and most contributors had extensive aviation and even "a/c type" background.
I was the lowly light puke that had flown the first fully FBW plane in service that had zero mechanical back up, had negative static stablity, and extreme body rates, AoA and gee values seen on almost every flight. But the heavy folks accepted me as well as Machinbird, and we got along fine.
I also worked with the human interfaces of the U.S. military platforms as a system engineer for about 14 years, so many of my opinions are based on "what would I do?", "How can I go back to a known condition?" , etc. And 99% of my control and display work was to prepare, target and launch a weapon. So I had to take into account many aspects of the process to ensure safety and reliability at the same time. With two no **** combat tours and only getting "shot down" once ( semi-crash landing with no power), and approx 4,000 hours in 5 warplanes plus some trainers, I was blessed to see many aero principles in action and all the "gotchya's". So with my location and bio out there on the Pprune profile and this missal, you all know where I come from.
++++++++++++++++++++++++++++++++++++++=
Present views/opinons on next post.
Gums presents...
@gums: salute!
I'll be sparse on comments as my core competency in pilot training, and in training systems for new models and new mods, is hampered by not knowing this system, and thus grasping the differences, well enough. I have discovered from those in the industry that training is viewed somewhat differently within the industry, and within each company, and within each corporate culture. Things that I had assumed are 'true' generically for pilot training, and crew training, may not be.
If you the pilot don't know what it(the bird) can and will do, what do you as a pilot do when it's doing that thing you don't know about?
(The test pilots I have worked with usually answer that with "get it back on the ground and don't go outside of known parameters on the way back" as often as not. )
Addressing that hole in the cheese is what draws me to the technical discussion.
Salute!
Concourse has raised a very important legal point for this discussion on the main thread, and I agree 100%, but my personal preference here is to keep the legal aspects "legal" and concentrate on understanding what happened and identifying whatever it takes to keep this from happening again or another incident that could have been prevented.
Some here may even be flying the type and could use some "education".
++++++++++++++++++++++++++++++++++++++++++++++=
Being a pilot on my accident boards, I mostly look for causal and contributing factors that were out of human control at the time or prevented the human from overcoming the problem. So my interest in sfwe and hdwe is a large part of my personal investigation. I have seen out-and-out pilot judgement/skill crashes, basic smoking holes, but also one serious loss that involved "little understood" aspects of our autopilot implementation. So this MCAS brings back some sad memories.
+++++++++++++++++++++++++++++++++++++++++++++++
The trim gearbox is of more interest to me now than my poor opinion of the decision to move large control surfaces to "help" the pilot and not tell the pilot That gearbox is the last mechanical connection in the chain, right? And the control surface it moves has more pitch authority than the elevators. So I start there and work back to the first input to the doofer, whether from a human input or Hal input or combination.
How did the STS logic fail to provide up trim cmds as speed increased when I only see down cmds to the gearbox. Maybe the AoA prevented that, but I did not see a direct input to STS from AoA. Seems like STS uses speed data from the ADIRU and not raw "q" from the probes. So if the ADIRU logic asserts airspeed is FUBAR due to AoA problems, then what does the STS do? Inquiring minds want to know before my next flight.
A poster not so far back thot we may have seen the result of a cascade of events that had deliterious effects not allowed for or imagined. i.e. a single point failure that by itself should have only been an irritant, but other systems that used the output of that "module" reacted as designed and the chain of events created control surface movement that was not required and, indeed, was unsafe and could not be mitigated by the crew. In other words, the crew did not recognize what the problem was and kept trimming because every time they trimmed, the plane seemed to return to "normal".
The crew actions, even without knowing about MCAS, are an important part of this tragedy, but if things didn't break, they would not have had the opportunity to diagnose a new malfunction. So second to last flight did not identify the real problem because the "runaway trim" procedure seemed to have allowed a successful flight and a writeup. The accident flight would have been the same, and maybe next hop would be the tragedy.
Gotta go, and forgive my sermons.
Gums....
Concourse has raised a very important legal point for this discussion on the main thread, and I agree 100%, but my personal preference here is to keep the legal aspects "legal" and concentrate on understanding what happened and identifying whatever it takes to keep this from happening again or another incident that could have been prevented.
Some here may even be flying the type and could use some "education".
++++++++++++++++++++++++++++++++++++++++++++++=
Being a pilot on my accident boards, I mostly look for causal and contributing factors that were out of human control at the time or prevented the human from overcoming the problem. So my interest in sfwe and hdwe is a large part of my personal investigation. I have seen out-and-out pilot judgement/skill crashes, basic smoking holes, but also one serious loss that involved "little understood" aspects of our autopilot implementation. So this MCAS brings back some sad memories.
+++++++++++++++++++++++++++++++++++++++++++++++
The trim gearbox is of more interest to me now than my poor opinion of the decision to move large control surfaces to "help" the pilot and not tell the pilot That gearbox is the last mechanical connection in the chain, right? And the control surface it moves has more pitch authority than the elevators. So I start there and work back to the first input to the doofer, whether from a human input or Hal input or combination.
How did the STS logic fail to provide up trim cmds as speed increased when I only see down cmds to the gearbox. Maybe the AoA prevented that, but I did not see a direct input to STS from AoA. Seems like STS uses speed data from the ADIRU and not raw "q" from the probes. So if the ADIRU logic asserts airspeed is FUBAR due to AoA problems, then what does the STS do? Inquiring minds want to know before my next flight.
A poster not so far back thot we may have seen the result of a cascade of events that had deliterious effects not allowed for or imagined. i.e. a single point failure that by itself should have only been an irritant, but other systems that used the output of that "module" reacted as designed and the chain of events created control surface movement that was not required and, indeed, was unsafe and could not be mitigated by the crew. In other words, the crew did not recognize what the problem was and kept trimming because every time they trimmed, the plane seemed to return to "normal".
The crew actions, even without knowing about MCAS, are an important part of this tragedy, but if things didn't break, they would not have had the opportunity to diagnose a new malfunction. So second to last flight did not identify the real problem because the "runaway trim" procedure seemed to have allowed a successful flight and a writeup. The accident flight would have been the same, and maybe next hop would be the tragedy.
Gotta go, and forgive my sermons.
Gums....
The crew actions, even without knowing about MCAS, are an important part of this tragedy, but if things didn't break, they would not have had the opportunity to diagnose a new malfunction.
Diagnosing malfunctions is, when a problem has persisted for flight after flight, something for a post maintenance check flight. (IMO) not a revenue flight. (Hence my question about MEL?)
So second to last flight did not identify the real problem because the "runaway trim" procedure seemed to have allowed a successful flight and a writeup.
The accident flight would have been the same, and maybe next hop would be the tragedy.
Salute Wolf!
Here's my rationale for my opinion/theory/whatever regarding the AoA sensor and its influence on various aircraft systems.
The cascading failures or unexpected operations of several systems seems evident once you start with the AoA that appears up to 20 degrees different than the other AoA sensor. So let us see the flow chart/system diagram.[AoA data to the air data black boxes and the crew sees unreliable airspeed. Bad AoA flag might not help here if crew does not understand the MCAS, but relation with stick shaker would prolly be recognized by 99% of the crews ]
- At start of the data, one AoA shows about 10 - 12 degrees higher than the other. After liftoff the delta increases to maybe 20 degrees and tracks the other AoA sensor perfectly.
- the overall system fault monitoring system does not flag the AoA disagreement as such [after takeoff. It shows the crew unreliable airspeed once pitot speed is above "x" and AoA data is bad, like 20 degrees delta. ]
- At liftoff we see several trim inputs from the "system", which seems from STS, and they look like STS is doing its job. i.e. trim up to maintain the trimmed speed. But stick shaker is now active.
- flaps are now fully retracted, stick shaker continues because AoA from one vane is very high and the circus starts.
- Hal trims down, gums trims up a bit because we are climbing like normal, increasing speed and that crazy STS is wired backwards.
- Nose down trim geting really strong, but trim switch on yoke seems to be working, But after I let off for 5 seconds I see nose down trim again. This ain't STS, I think.
Somewhere in the scenario the "feel" system is acting on the control yoke, and I do not have the personal flight experience to comment on how it feels and not sure about how it is supposed to work in concert with the other sub-systems and their logic/specs when they go south.
Meanwhile, pilot and MCAS are commanding up trim and down trim for 5 or 10 second intervals until something big happens and we see lotta power commanded and a divergent control pressure for each yoke.
Gums...
Here's my rationale for my opinion/theory/whatever regarding the AoA sensor and its influence on various aircraft systems.
The cascading failures or unexpected operations of several systems seems evident once you start with the AoA that appears up to 20 degrees different than the other AoA sensor. So let us see the flow chart/system diagram.[AoA data to the air data black boxes and the crew sees unreliable airspeed. Bad AoA flag might not help here if crew does not understand the MCAS, but relation with stick shaker would prolly be recognized by 99% of the crews ]
- At start of the data, one AoA shows about 10 - 12 degrees higher than the other. After liftoff the delta increases to maybe 20 degrees and tracks the other AoA sensor perfectly.
- the overall system fault monitoring system does not flag the AoA disagreement as such [after takeoff. It shows the crew unreliable airspeed once pitot speed is above "x" and AoA data is bad, like 20 degrees delta. ]
- At liftoff we see several trim inputs from the "system", which seems from STS, and they look like STS is doing its job. i.e. trim up to maintain the trimmed speed. But stick shaker is now active.
- flaps are now fully retracted, stick shaker continues because AoA from one vane is very high and the circus starts.
- Hal trims down, gums trims up a bit because we are climbing like normal, increasing speed and that crazy STS is wired backwards.
- Nose down trim geting really strong, but trim switch on yoke seems to be working, But after I let off for 5 seconds I see nose down trim again. This ain't STS, I think.
Somewhere in the scenario the "feel" system is acting on the control yoke, and I do not have the personal flight experience to comment on how it feels and not sure about how it is supposed to work in concert with the other sub-systems and their logic/specs when they go south.
Meanwhile, pilot and MCAS are commanding up trim and down trim for 5 or 10 second intervals until something big happens and we see lotta power commanded and a divergent control pressure for each yoke.
Gums...
Last edited by gums; 26th Nov 2018 at 19:27. Reason: correctiions
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
I'm not sure. In effect the aircraft was repeatedly trimming against them, now I've read some of the archived discussions on Speed Trim/ STS both here and elsewhere and there are plenty of comments saying (paraphrased) "it keeps trimming against me", and plenty of replies saying "that's what it is designed to do". So this could easily be misidentified as STS simply being more enthusiastic than usual.
We may know now that this was MCAS, but that is knowledge the pilots didn't have. What they did have (on previous flight) was UAS, which might reasonably be expected to cause odd behaviour from the speed trim system, plus stick shaker. So UAS is what got written up and "fixed".
If the pilots had the AOA disagree (an optional item they apparently didn't have) then maybe that would get written up, if they had known about MCAS maybe they would have suggested that as a cause and AOA would have been identified from that.
We don't know if the probe broke or was mis-fitted or why the previous probe was replaced. All we know is the the recorded value was 20deg out. I think these are analog signals so could even be a wiring fault?
Agree on check flight - but easy with benefit of hindsight. MELs and AMMs possibly unlikely to be helpful when the system showing the symptoms is undocumented and the sensor that is (maybe) broken gives no disagree error because the values are never shown to the pilots.
We may know now that this was MCAS, but that is knowledge the pilots didn't have. What they did have (on previous flight) was UAS, which might reasonably be expected to cause odd behaviour from the speed trim system, plus stick shaker. So UAS is what got written up and "fixed".
If the pilots had the AOA disagree (an optional item they apparently didn't have) then maybe that would get written up, if they had known about MCAS maybe they would have suggested that as a cause and AOA would have been identified from that.
What besides (maybe) an AoA probe 'broke' in this case? Still unclear to me.
Diagnosing malfunctions is, when a problem has persisted for flight after flight, something for a post maintenance check flight. (IMO) not a revenue flight. (Hence my question about MEL?)
But not an actual repair, it seems. So what is going on here: throwing parts in a problem, and hoping that fixes it? I'd hope the trouble shooting trees in the maintenance manuals would be a bit more expansive than that.
Maybe. depends on what actually broke.
But not an actual repair, it seems. So what is going on here: throwing parts in a problem, and hoping that fixes it? I'd hope the trouble shooting trees in the maintenance manuals would be a bit more expansive than that.
Maybe. depends on what actually broke.
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
And of course the NG doesn't have MCAS. It does have (very lightly documented) a similar sounding function, which is not named, which gives ND trim on the STS trim output (which is also the autopilot trim output) from the FCC. So in the NG case, no wiring changes, only software changes in FCC. Max is probably the same except at the column switch module (column position cutouts) and the cutouts on the console. And the software.
Unfortunately MAX AMMs are not likely to be out in the wild yet as the aircraft is in service in only a few places. Would be very interesting to compare one though (chapter 22)...
gums, Lonewolf, et al, may I direct you to the questions at https://www.pprune.org/rumours-news/614857-indonesian-aircraft-missing-off-jakarta.html#post10319901
How much is actually known about MCAS or the integrity of AoA ?
Also see Indonesian aircraft missing off Jakarta #1675
How much is actually known about MCAS or the integrity of AoA ?
Also see Indonesian aircraft missing off Jakarta #1675