Boeing 737 Problem Explained
Denisha Cerniglia
This is a Microsoft / Asobo issue and is not an issue with the Thrustmaster Throttle. Having said that, I suspect that other MSFS users using different throttles, could also experience similar issues.
The first signal comes from the physical throttle movement from the Thrustmaster HOTAS Warthog throttle and the second signal (the one that causes the erratic behaviour) comes from the simulator itself as it tries to override the users physical throttle settings.
Hopefully, this message will assist others who are having the same issues that I have experienced and, for goodness sake Microsoft, set this flag back to off on the next update and document it so that others can make a value judgement on whether or not this option is useful to them or, as in my case, a massive overhead.
I had - had the issue with my throttle control for months on end. I had tried everything and actually changed the throttle as I thought it was faulty. The problem persisted even with the change of hardware and that meant it had to be something with the FS2020 settings. It took a few hours of resetting default settings until I switched all of the AI settings off and suddenly everything worked as it should. I went through the AI settings setting them back on one at a time until I found the setting that was causing the issue.
After that, I contacted Microsoft again and explained that I had identified the cause and how to overcome it and nothing happened. I watched 2 upgrades of FS2020 go through and the AI settings remained as they were so, on the basis that I thought this could affect others, I posted the fix on this forum.
Hi there
That sounds like exactly how my problem with the Thrustmaster Throttle started. I was getting really eratic behavior with the throttle. As I opened the Warthog throttle physically, the screen showed the throttle moving all over the place and ditto the joystick. I finally tracked my problem down to the assisted settings. I had applied a mandatory asobo update and this set the assisted settings to on. This conflicted with the Thrustmaster Wathog Throttle and Joystick. The fix that worked for me was:
I played around with some more settings, unmapped any power control settings from the keyboard, and that solved most of my problems. I continue to have the problem with the Cirrus SR22, but further research has determined that that is the way the propeller speed is tied to a constant prop governor and keeps the rpms at 2500 even though the throttle is reduced.
The Boeing 737 Max has been in the news because of two crashes, practically back to back and involving brand new airplanes. In an industry that relies more than anything on the appearance of total control, total safety, these two crashes pose as close to an existential risk as you can get. Though airliner passenger death rates have fallen over the decades, that achievement is no reason for complacency.
Various hacks (as we would call them in the software industry) were developed. One of the most noticeable to the public was changing the shape of the engine intakes from circular to oval, the better to clear the ground.
Worse still, because the engine nacelles were so far in front of the wing and so large, a power increase will cause them to actually produce lift, particularly at high angles of attack. So the nacelles make a bad problem worse.
Pitch changes with power changes are common in aircraft. Even my little Cessna pitches up a bit when power is applied. Pilots train for this problem and are used to it. Nevertheless, there are limits to what safety regulators will allow and to what pilots will put up with.
Everyone in the aviation community wants an airplane that flies as simply and as naturally as possible. That means that conditions should not change markedly, there should be no significant roll, no significant pitch change, no nothing when the pilot is adding power, lowering the flaps, or extending the landing gear.
The airframe, the hardware, should get it right the first time and not need a lot of added bells and whistles to fly predictably. This has been an aviation canon from the day the Wright brothers first flew at Kitty Hawk.
MCAS is certainly much less expensive than extensively modifying the airframe to accommodate the larger engines. Such an airframe modification would have meant things like longer landing gear (which might not then fit in the fuselage when retracted), more wing dihedral (upward bend), and so forth. All of those hardware changes would be horribly expensive.
As I explained, you can do your own angle-of-attack experiments just by putting your hand out a car door window and rotating it. It turns out that sophisticated aircraft have what is essentially the mechanical equivalent of a hand out the window: the angle-of-attack sensor.
Indeed, not letting the pilot regain control by pulling back on the column was an explicit design decision. Because if the pilots could pull up the nose when MCAS said it should go down, why have MCAS at all?
MCAS is implemented in the flight management computer, even at times when the autopilot is turned off, when the pilots think they are flying the plane. In a fight between the flight management computer and human pilots over who is in charge, the computer will bite humans until they give up and (literally) die.
Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not.
It gets even worse. There are several other instruments that can be used to determine things like angle of attack, either directly or indirectly, such as the pitot tubes, the artificial horizons, etc. All of these things would be cross-checked by a human pilot to quickly diagnose a faulty angle-of-attack sensor.
In the MCAS system, the flight management computer is blind to any other evidence that it is wrong, including what the pilot sees with his own eyes and what he does when he desperately tries to pull back on the robotic control columns that are biting him, and his passengers, to death.
In the old days, the FAA had armies of aviation engineers in its employ. Those FAA employees worked side by side with the airplane manufacturers to determine that an airplane was safe and could be certified as airworthy.
My autopilot also includes electric pitch trim. That means it can make the same types of configuration changes to my 172 that the flight computers and MCAS system make to the 737 Max. During the installation, after the first 737 Max crash, I remember remarking to a friend that it was not lost on me that I was potentially adding a hazard similar to the one that brought down the Lion Air crash.
In addition to now carrying a new (supplemental) aircraft-type certificate (and certification), my 172 required a very large amount of new paperwork to be carried in the plane, in the form of revisions and addenda to the aircraft operating manual. As you can guess, most of those addenda revolved around the autopilot system.
Of particular note in that documentation, which must be studied and understood by anyone who flies the plane, are various explanations of the autopilot system, including its command of the trim control system and its envelope protections.
There are instructions on how to detect when the system malfunctions and how to disable the system, immediately. Disabling the system means pulling the autopilot circuit breaker; instructions on how to do that are strewn throughout the documentation, repeatedly. Every pilot who flies my plane becomes intimately aware that it is not the same as any other 172.
Back in the 1990s, I wrote an article comparing the relative complexity of the Pentium processors of that era, expressed as the number of transistors on the chip, to the complexity of the Windows operating system, expressed as the number of lines of code. I found that the complexity of the Pentium processors and the contemporaneous Windows operating system was roughly equal.
That was the time when early Pentiums were affected by what was known as the FDIV bug. It affected only a tiny fraction of Pentium users. Windows was also affected by similar defects, also affecting only fractions of its users.
For the life of me, I do not know why those two basic aviation design considerations, bedrocks of a mind-set that has served the industry so well until now, were not part of the original MCAS design. And, when they were not, I do not know or understand what part of the DER process failed to catch the fundamental design defect.
Nowhere is this problem more acutely felt than in systems designed to augment or improve safety. Every increment, every increase in complexity, ultimately leads to decreasing rates of return and, finally, to negative returns. Trying to patch and then repatch such a system in an attempt to make it safer can end up making it less safe.
Gregory Travis is a writer, a software executive, a pilot, and an aircraft owner. In 1977, at the age of 13, he wrote Note, one of the first social media platforms, and he has logged more than 2,000 hours of flying time, ranging from gliders to a Boeing 757 (as a full-motion simulator).
This is a great article bringing together insight and understanding from multiple areas of expertise. I am surprised to see so few comments nearly 5 years later as this aircraft remains in the news. Your comment about "I don't know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this mistake."really hits home for me as a software engineer. Some companies attempt fully open and blameless incident reviews. Too bad the aerospace industry has nothing to gain form that openness and probably a lot to lose from a legal perspective. Without hearing from someone on the inside testifying or leaking we will never know the explanation for this entirely preventable negative outcome.There is a non-zero chance the cause relates to a culture prioritizing authoritative hierarchy over engineering truth. That is often paired with a bureaucratic compartmentalization of work intentionally severing lines of communication between teams. Either or both of these create an environment suppressing understanding of risk and blocking mitigation attempts.
64591212e2