Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

Ethiopian airliner down in Africa

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

Ethiopian airliner down in Africa

Old 29th Mar 2019, 09:48
  #2721 (permalink)  
 
Join Date: Apr 2002
Location: the edge of madness
Posts: 485
From Bjorn Fehrm of Leeham today:

This week Boeing presented how they plan to get the 737 MAX back in the air again. MCAS has a fix.We look at what the fix tells us about the first implementation and the rationale behind its implementation.



Figure 1. The improved Pilot’s Primary Flight Display presented Wednesday. Source: Boeing.
Boeing’s MCAS fix casts light on the original implementation
Boeing presented its fix for the MCAS problems Wednesday. By it, it spotlights what was wrong with the original implementation.
The reliance on a single triggering signal for MCAS
A lot has been written about the MCAS system relying on a single Angle of Attack input. This is unusual for systems involved in the flight control of aircraft. Normally you have three inputs so a voting procedure can sort out one of them if it has a problem (two singling out the third as faulty).

The 737 has only two Angle of Attack sensors, so no voting can be set up between them. Instead, the system relying on the sensors can be switched off if the sensors disagree and the pilot informed about the missing function.

This is the route chosen for the improved MCAS. It will now be disconnected when the sensed Angle of Attack difference is beyond 5.5 degrees when MCAS activates and over 10 degrees for over 10s when the system is in use.

The wide allowed difference shows what I have written about before. The aerodynamics around these sensor vanes, placed at the nose sides, is dependent on how the aircraft is flown. If there is a sideslip the airflow passing the sensors will be affected and the sensor values will differ.

The actual sensor value is also higher than the wing Angle of Attack (the airflow around a fuselage nose is curving upward), therefore a correction table is used to calculate the wing’s Angle of Attack. It’s the wing’s Angle of Attack which determines how close to stall the aircraft is.

Was the use of only one signal OK to trigger the original MCAS? No, it wasn’t. But at least there was a rationale for this decision, whatever one might think about the rationale. A deactivation of MCAS was not an acceptable solution as it would trigger a need for an MCAS not available signal and this would mean more difference training for the Pilots migrating from 737ng to MAX.
The design of the original MCAS function
While the reliance on a single sensor is highly questionable, the architecture and implementation of the original MCAS function in inexcusable.

If you have a flight control function which is triggered by a single sensor, it means the likelihood it being incorrectly activated is there. Then you implement a nonhazardous augmentation function!

You make sure it only injects the minimum correction necessary and you limit its total authority to not jeopardize the safe flight of the aircraft.

Where others focus on a single trigger signal, my biggest problem is with the function itself. If you have a weak trigger architecture, you limit the authority of what you trigger!

There was no need for the authority MCAS got. We know this today as the software fix only trims once for each elevated Angle of Attack event and limits the total trim amount to a safe level. This is regardless of the sensors being wrong or the function running wild.

It was just a very, very bad function design, and there was no need for it.
Designed to not show, it became the centerpiece of attention
MCAS was a function put there to cater for a very remote case. The pilot needs to maneuver close to the limits of the aircraft and way beyond normal flying practice, to save the aircraft from some emergency. Then MCAS kicked in to make the aircraft easy to fly close to its limits.

In the life of a commercial 737 MAX pilot he should never experience an MCAS augmentation, its use case was so remote. Instead, it became the most known and explained function of all on the 737 MAX. And for the wrong, very sad reasons.

There are only a few airliner OEMs in the world. There is a reason for this. It’s a challenging product to get right and the stakes are very high for any mistakes. In today’s very safe air transport system mistakes of this scale are non-acceptable.
Torquelink is offline  
Old 29th Mar 2019, 09:59
  #2722 (permalink)  
 
Join Date: Apr 2008
Location: back of beyond
Posts: 95
Originally Posted by EDLB View Post
...... However without the redundancy and thorough safety analysis required for flight control surface operations.
This cavalier approach has killed people before - Amsterdam 2009 comes to mind. There Boeing had a clear warning of the dangers of a single unmonitored sensor making flight-critical inputs, but chose to ignore it on the mitigating factor of the poor crew response to the problem (familiar?)
fizz57 is offline  
Old 29th Mar 2019, 10:49
  #2723 (permalink)  
 
Join Date: Jan 2013
Location: UK
Age: 58
Posts: 26
Originally Posted by Torquelink View Post
From Bjorn Fehrm of Leeham today:

If you have a flight control function which is triggered by a single sensor, it means the likelihood it being incorrectly activated is there. Then you implement a nonhazardous augmentation function!
.
This all comes back to a proper hazard/failure analysis and that the analysis needs to include the possibiity of all failures including software failures. If safety relies on SW to ensure that the augmentation function is non-hazardous then the risk of that SW failing needs to be controlled appropriately. In this case the MCAS SW even after the fix clearly has a level of at least hazardous and needs to be developed to at least DO-178 - level B. Was/is this the case for MCAS? If it is not then the fix should not be accepted.

It is important that looking at the root cause of this accident that the investigation does nots stop at the pilots actions and the poor design of MCAS but is pursued as far back as possible into why the design error occured, why it was not picke dup as a problem in development and why the aircraft was certified despite having a design error which could cause a hazardous situation to arise so easily.
PiggyBack is offline  
Old 29th Mar 2019, 10:50
  #2724 (permalink)  
 
Join Date: Apr 2015
Location: Yorktown Heights
Posts: 3
Originally Posted by yanrair View Post

The 737-Max can of course be flown in total manual mode. It’s about the only series of models that can- all 737s can.
You can even lose ALL hydraulic and all AC POWER and it still flies.
Yanair,

Thank you for your reply. This illustrates the point I am trying to make. I've learned a great deal about the 737 max from following the posts on this long thread, and have learned that the 737 is one of the few airliners that can be flown completely manually. I've also learned, correct me if I'm wrong, that manual recovery from from a seriously out of trim situation involves turning a jackscrew 10's of times to move the horozontal stabilizer back to neutral against strong aerodynamic forces.

What I learned as well was that horizontal stabilizer fulcrum is at the back of the stabilizer, and the jack screw moves the front edge. This means that aerodynamic forces push the stabilizer harder to extreme up or down positions the further it is from neutral and the higher the airspeed. The scenario has been discussed (forgive me if I can't find it in this long thread) where the pilot desperately accellerates to try to gain altitude resulting in a situation where the forces are too great to recover the trim manually.

Consider the situation if the pilot has the option of maintaining power to the trim, and other control surfaces, while shutting off other automated functions. Firstly he/she has a much easier decision than going completely manual and, once taken, will be able to make trim corrections much more quickly and against a much larger force.

Consider, also an option with a higher level of automation, but still using the most reliable and time tested components and software, where, upon activation by the pilot, sets the ac controls to best obtain level and stable flight. The 'panic' button. This way the pilot can start recovery more easily and from a known state.

These options do not absolve the manufacturer from culpability, but make it much easier to recover from higher level automation errors which inevitably will occur as aircraft automation gets more and more complex.

My question again is: Is this all or nothing choice unique to Boeing? Does Airbus offer a more graduated approach?
concernedengineer is offline  
Old 29th Mar 2019, 10:59
  #2725 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 767
Originally Posted by PEI_3721 View Post
The point being made relates to an existing issue discussed in the thread Boeing advice on "aerodynamically relieving airloads" using manual stabilizer trim which refers to the separate problem of ‘runaway’ trim.
I think this may be right, but that it may also or instead be referring to the "stabilizer trim limit switches", note that "There are different limits for manual, autopilot, and for flaps up and flaps down." - well at least for the NG.

The trim wheels in contrast will run the jack screw to the physical stops, I believe (if you can get there against the aero loads, which the other thread covers). MCAS may also be only limited by the physical stop (singular, since it only runs one way, well should only run one way).

However, this is very relevant to the accident discussion because of the accumulated incremental trim change due to MCAS malfunction can result in the same trim condition.
To my mind it also blows a hole in the reported design assumptions for the MCAS "reset". MCAS design apparently assumed that if the pilots touched the trim switches, they would get the aircraft back in trim and therefore the total mis-trim due to MCAS was limited. This assumption was clearly wrong on pilot behaviour, but it seems possible it was also more fundamentally wrong in that (as I read it) there are known areas of the flight envelope where it is not possible to get the a/c in-trim with the switches. This means the "reset" assumption was never valid, even before it was tested with real pilots.
infrequentflyer789 is offline  
Old 29th Mar 2019, 11:27
  #2726 (permalink)  
 
Join Date: Jun 2008
Location: London
Age: 63
Posts: 290
Please can we stop conflating Boeing's MCAS and Airbus' ALPHA PROT? The latter is part of an envelope protection system, whereas MCAS addresses handling characteristics (stick forces) at or near the stall.
Fortissimo is offline  
Old 29th Mar 2019, 11:29
  #2727 (permalink)  
 
Join Date: Dec 2014
Location: Schiphol
Posts: 331
Sincerely, .. there is something deeply worrying .. and if it continues (and I am afraid it will, as such things have a momentum of their own), will become deeply disturbing. The following may sound a bit abstract, but it has real, deeply, and widely ranging consequences.

Simplified and compressed, this worry is based on when you rank the growth level of an organization on a scale of: failing - bad - normal - good(objectively factbased&datadriven) - best(culture).

What sets the aerospace industry apart from all others is that over a period of many years it has established a safety culture. And it should be very clear that “culture” is on a level above “factbased and datadriven”. Some subordinate examples: In compliance ‘cultural compliance’ standing above ‘tick-box compliance’. In legal the ‘intent of the law’ standing above ‘the letter of the law’. Etc, etc,..

So when a person uses ‘factbased and datadriven’ in a conversation on aviation safety, I read that as driving a level down from where we are. When he or she repeats that a number of times, then it suggests systemic issues. And the higher ranked a person is, the more serious it gets and the more persistent it will be.

Take the March 27th, 2019, Senate Appropriations Hearing on the 2020 Budget for the Transportation Department. The Secretary of Transportation using the words (when discussing the 737 MAX events and developments): .. “the FAA is professional and fact based” .. “they [FAA] are very fact based” .. and .. “on Wednesday March 13th .. [flight data on] the first 3 minutes of flight [became available] that showed similarity [with the Lion Air crash data] .. physical evidence .. [together this] was the first factual evidence”..

Take the March 27th, 2019, Senate Subcomittee Hearing on Airline Safety. The (Acting) Administrator of the FAA (in this hearing triggered by 737 MAX events) using the words: ... “[FAA’s] fact based data driven approach” .. “data driven” .. “data based” ..

You could use the sketched ranking approach yourself, to reflect on a number of issues that still await an answer.

The FAA administrator was asked on the grounding of the 737 MAX why the FAA was “lagging and not leading”, as most other authorities, countries and airlines had grounded the MAX [days] before, and the administrator holding the FAA as the ‘Golden Standard of safety in aviation’. He answered that the FAA operates “fact based” and that the facts only obtained on the 13th were required before ‘ordering’ a grounding. So the question here is, and we need more information to answer that clearly, is if these other international parties were basing their decisions on cultural grounds or on factbased & datadriven grounds.

The FAA administrator pointed to the 57,000 flights of the 737 MAX in the USA till now. These flights did not provide [any] data that gave them [the FAA, but as he stated also Boeing and three US major airline pilot associations] [any] worries on the 737 MAX. [This implies that AoA vane, or AoA data, or outputs based on AoA data, gave them no worries . A question in quite a few PPRuNe posts. It does not answer the PPRuNe questions if there was any activation of MCAS. And writing this I wonder if MCAS activation would be FDR/QAR recorded at all or would be a derived parameter]. Interesting of course is, considering the global effect of FAA decisions, if FAA decisions should be based on US data alone !! This might turn into a fundamental question. It puts my own question on (non-US) ‘launch airline’ capabilities in a new perspective.

The FAA administrator pointed out, when asked about ‘non-positive’ pilot and engineers statements quoted in newspapers on issues and problems, that there were no reports in [any] ‘ASRS’ or ‘whistleblower reporting system’ that pointed to something. He could not answer the question if Boeing had an ODA whistleblower reporting system and if and how that functioned. So a question to be answered is, if the FAA data capture has been wide enough (nationally and internationally).
A0283 is offline  
Old 29th Mar 2019, 11:55
  #2728 (permalink)  
 
Join Date: Jun 2009
Location: Dorset
Posts: 30
Originally Posted by wiedehopf View Post
I've attached the FDR readout from the first pdf report that was available on the Lion Air crash (with some annotations):


In this graph only the left side altitude readout is plotted, in the preliminary report you can see the difference to the side with working AoA:
https://www.flightradar24.com/blog/w...ary-Report.pdf
Thank you wiedehopf, your annotations have helped me a lot to make sense of the preliminary report.

I have worked for years on the software for aircraft ‘black boxes’ and spent many long days trying to diagnose ‘why is the system doing that??’, usually in a test rig environment, but also post test flight. For what its worth, my diagnostic based on your information is as follows:-
1) There is nothing wrong with the AoA vane in itself. After the left stick shaker kicks in, both sides match perfectly (apart, obviously, the fixed offset), every little blip occurs on both L & R AoA – neither vane is bent/ frozen/ dirty.
2) Looking at a picture of the AoA module, I am presuming that the A to D convertor is in the body, and it is of the ‘rotary’ kind, i.e. the A to D converts the rotated position of the vane shaft into a digital signal. Most of the A to Ds I worked on were typically 12 bit parallel output, I suspect that more modern ones would be a serial output. Either way the signal would be very noisy, responding to every vibration that the vane felt.
3) The offset is not due to a ‘stuck bit’. The offset in AoA as the aircraft first started to move is about 12 deg, increases to about 17 deg and then settles on about 22 deg. A stuck bit would be 22.5, or 11.25, or 5.625; to get 17 deg would take two ‘stuck’ bits. Besides which serial buses of themselves (e.g. ARINC 429) do not have ‘stuck’ bits, they have multi bit corruption, usually recognised as a ‘bad message’ and rejected.
4) The AoA digital signal goes into the applicable ADIRU for further processing. Part of this processing *should have been* to reject any invalid input!! Another part will be to smooth the data to get rid of the noise, but this is the same software in both ADIRUs, so would not give an offset.
5) ‘Light bulb’ moment -
Originally Posted by Torquelink View Post
From Bjorn Fehrm of Leeham today:

This week Boeing presented how they plan to get the 737 MAX back in the air again. MCAS has a fix.We look at what the fix tells us about the first implementation and the rationale behind its implementation.

The actual sensor value is also higher than the wing Angle of Attack (the airflow around a fuselage nose is curving upward), therefore a correction table is used to calculate the wing’s Angle of Attack. It’s the wing’s Angle of Attack which determines how close to stall the aircraft is.
The software in the two ADRIUs is different, it has to allow for the fact that the two vanes are on opposite sides of the cockpit, so I believe they probably use different correction tables, or the algorithm to apply to them is subtly different, possibly something as simple as using a wrong sign.

I know which bit of code I would be diving into now!


VicMel is offline  
Old 29th Mar 2019, 11:57
  #2729 (permalink)  
 
Join Date: Jun 2008
Location: London
Age: 63
Posts: 290
You would expect Boeing to be gathering data from its global fleet as part of its normal product safety activities because it is core to any airworthiness assurance process. It follows that the FAA, as the lead regulator for MAX certification and continuous airworthiness, should be kept informed about the global picture by the manufacturer. As a hypothetical example, it would be madness for the FAA not to be involved in the issue of a service bulletin that only fixed problems with the left inboard spoiler for aircraft based in Europe because that is where all the occurrences had been reported.

The MAX fleet is still small, it is still very early in its service life, and it should not be a surprise that (possibly) the only 2 known failures of the system have occurred outside the USA. But if the Administrator is taking the view that 'it hasn't happened here so it doesn't count', confidence in the CAW process is going to take an even bigger hit.
Fortissimo is offline  
Old 29th Mar 2019, 12:34
  #2730 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,074
A0283, #2743
I agree about the general concerns and risk of escalation.

Meanwhile this forum should ‘cut the design engineers some slack’. These are people doing their normal day job, doing their best given the circumstances at the time.
We, alternatively, with enormous hindsight after two accidents and many months of ‘wisdom from the crowds’ might identify aspects which should previously have been considered.
This, for everyone is ‘the human condition’; beware of our biases.

Some posts have referred to a management ‘Go, go, go’ mentality in developing a new variant; imagine what mentalities might exist after the entire fleet has been grounded.
Consider our posts carefully so as not to add further pressure on these people in the design and test front line, either as unjustified speculative comment, ‘fuel’ for tabloid media, or inaccuracies to be used by those in government.

Last edited by alf5071h; 29th Mar 2019 at 13:04. Reason: ‘unjustified’ speculative comment
alf5071h is offline  
Old 29th Mar 2019, 12:47
  #2731 (permalink)  
 
Join Date: Jan 2008
Location: LONDON
Posts: 27
Originally Posted by VicMel View Post
The software in the two ADRIUs is different, it has to allow for the fact that the two vanes are on opposite sides of the cockpit, so I believe they probably use different correction tables, or the algorithm to apply to them is subtly different, possibly something as simple as using a wrong sign.
I'd assumed that the two vanes are on opposite sides of the cockpit to avoid(through symmetry) the need to use different correction tables. Having used up all available axes of symmetry, adding a third vane would likely require different correction parameters.[/QUOTE]


netstruggler is offline  
Old 29th Mar 2019, 12:58
  #2732 (permalink)  
 
Join Date: Apr 2014
Location: Korea
Posts: 59
Originally Posted by VicMel View Post
The software in the two ADRIUs [sic] is different, it has to allow for the fact that the two vanes are on opposite sides of the cockpit
That analysis is both intriguing, and very scary.
Is it easy to explain in more detail why and how the software should behave differently between treating left and right AoA sensor data?
It seems that no matter how the ADIRU software might possibly be different, it ought to take a fairly simple comparison analysis to detect an inconsistency, such as a flipped sign or a logical error.

Euclideanplane is offline  
Old 29th Mar 2019, 13:04
  #2733 (permalink)  
 
Join Date: Mar 2006
Location: Vance, Belgium
Age: 57
Posts: 164
Originally Posted by VicMel View Post
...
2) Looking at a picture of the AoA module, I am presuming that the A to D convertor is in the body, and it is of the ‘rotary’ kind, i.e. the A to D converts the rotated position of the vane shaft into a digital signal. Most of the A to Ds I worked on were typically 12 bit parallel output, I suspect that more modern ones would be a serial output. Either way the signal would be very noisy, responding to every vibration that the vane felt.
VicMel,
it looks as though, at least for the NG, the AOA sensor provides an analog output to both the ADIRU and the SMYD box.
I couldn't find a diagram of the ADIRU Analog interfaces, but here is the SMYD Analog Interfaces diagram.
The three AOA sensor wires are labeled "SIN", "COS", "COM", whose meanings are obvious.
[img]https://3.bp.********.com/-qCwEtMS3-yU/W-xF4QyEZLI/AAAAAAAAFCo/mpLqB83Yau4ph1pPKUjgqSKBFmPoYOWugCLcBGAs/s640/Screen%2BShot%2B2018-11-14%2Bat%2B7.56.25%2BAM.png

Edit: somehow PPRuNe replace "b l o g s p o t" with "********". If you want to see the diagram, you have to retype "b l o g s p o t" (without spaces) after clicking the link.

Last edited by Luc Lion; 29th Mar 2019 at 13:37.
Luc Lion is offline  
Old 29th Mar 2019, 13:16
  #2734 (permalink)  
 
Join Date: Mar 2019
Location: Bristol, UK
Posts: 1
I think VicMel's analysis is compelling. The AoA vanes are probably conforming to spec and the fault is further down the chain. It is possible that there is a fault in the nose to wing conversions as described. But these faults are reasonably easy to prevent through peer review processes such as code walkthrough and also module testing. What is more difficult is if an event causes some other subsystem to write garbage into the working space of the AoA handler, and that event is low probability. This sort of thing is really difficult to find in real-time systems.
Jan Window is offline  
Old 29th Mar 2019, 13:19
  #2735 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,653
Originally Posted by VicMel View Post
The software in the two ADRIUs is different, it has to allow for the fact that the two vanes are on opposite sides of the cockpit, so I believe they probably use different correction tables, or the algorithm to apply to them is subtly different, possibly something as simple as using a wrong sign.
Yes, the L and R AoA sensors on the 737 are interchangeable, so for a given AoA they will generate rotational signals in the opposite sense to each other. At the very least, the ADIRUs will have to resolve that.

DaveReidUK is offline  
Old 29th Mar 2019, 13:30
  #2736 (permalink)  
 
Join Date: Nov 2018
Location: Vancouver
Posts: 52
Originally Posted by Luc Lion View Post
Originally Posted by VicMel View Post
...
2) Looking at a picture of the AoA module, I am presuming that the A to D convertor is in the body, and it is of the ‘rotary’ kind, i.e. the A to D converts the rotated position of the vane shaft into a digital signal. Most of the A to Ds I worked on were typically 12 bit parallel output, I suspect that more modern ones would be a serial output. Either way the signal would be very noisy, responding to every vibration that the vane felt....
VicMel,
it looks as though, at least for the NG, the AOA sensor provides an analog output to both the ADIRU and the SMYD box.
I couldn't find a diagram of the ADIRU Analog interfaces, but here is the SMYD Analog Interfaces diagram.
The three AOA sensor wires are labeled "SIN", "COS", "COM", whose meanings are obvious.
[img]https://3.bp.%62%6C%6F%67%73%70%6F%74.com/-qCwEtMS3-yU/W-xF4QyEZLI/AAAAAAAAFCo/mpLqB83Yau4ph1pPKUjgqSKBFmPoYOWugCLcBGAs/s640/Screen%2BShot%2B2018-11-14%2Bat%2B7.56.25%2BAM.png
Helping Luc with his diagram...
patplan is offline  
Old 29th Mar 2019, 13:32
  #2737 (permalink)  
 
Join Date: Oct 2007
Location: Here
Posts: 624
Originally Posted by VicMel View Post
3) The offset is not due to a ‘stuck bit’. The offset in AoA as the aircraft first started to move is about 12 deg, increases to about 17 deg and then settles on about 22 deg. A stuck bit would be 22.5, or 11.25, or 5.625; to get 17 deg would take two ‘stuck’ bits. Besides which serial buses of themselves (e.g. ARINC 429) do not have ‘stuck’ bits, they have multi bit corruption, usually recognised as a ‘bad message’ and rejected.
4) The AoA digital signal goes into the applicable ADIRU for further processing. Part of this processing *should have been* to reject any invalid input!! Another part will be to smooth the data to get rid of the noise, but this is the same software in both ADIRUs, so would not give an offset.

5) ‘Light bulb’ moment -
The software in the two ADRIUs is different, it has to allow for the fact that the two vanes are on opposite sides of the cockpit, so I believe they probably use different correction tables, or the algorithm to apply to them is subtly different, possibly something as simple as using a wrong sign.
I know which bit of code I would be diving into now!
Hmm!

The AoA disagree is pretty close to 22 degrees from half way down the runway onwards. I suspect that at low speeds, say during taxi, the AoA vane does not respond to the airflow accurately.

I still quite like the One Bad Bit explanation although I agree that it could be a software issue. As you clearly will know it is quite common for software (in general, not in necessarily in aviation) to set a memory Bit to store a status. Perhaps the wrong bit got changed?

Do these computers have hardware memory protection such that one "process" cannot interfere with another? I suspect that they will not have such protection but I am not sure. I read somewhere that they were 80286 based . The 286 does not have integrated hardware memory protection although I suspect that an addition Memory Management Unit might be able to provide it.
jimjim1 is offline  
Old 29th Mar 2019, 13:38
  #2738 (permalink)  
 
Join Date: Jul 2013
Location: Norway
Age: 52
Posts: 116
Originally Posted by DaveReidUK View Post
Yes, the L and R AoA sensors on the 737 are interchangeable, so for a given AoA they will generate rotational signals in the opposite sense to each other. At the very least, the ADIRUs will have to resolve that.
I have no knowledge of this position system. But could it be so simple as to swap the cos and sin wires and then the output would be in the other direction? So no need for different software in the ADIRU?
SteinarN is offline  
Old 29th Mar 2019, 14:01
  #2739 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,653
Originally Posted by SteinarN View Post
But could it be so simple as to swap the cos and sin wires and then the output would be in the other direction?
That sounds neither simple nor reliable.

DaveReidUK is offline  
Old 29th Mar 2019, 14:14
  #2740 (permalink)  
 
Join Date: Aug 2005
Location: EDLB
Posts: 172
SIN and COS tend to be a resolver type of angle “encoding”. A very robust passive type of design. You need an excitation AC signal and you get two AC signals back, one with the SIN of your angle and the other with the COS of your angle signal. Typical those signals are differential and isolated from GND, because they come out of a transformer style winding. That makes them robust against noise on the harness. A possible scenario, where you might get wrong or offset values if there is a short between harness lines either the output or the excitation line which is not detected. That might tell us, why exchanging the sensor did not improve the problem.

For Boeing it should be easy to make some tests on the ground to determine what harness failure can create a 22 degree error in their “normal” flight orientation.
EDLB is offline  

Thread Tools
Search this Thread

Contact Us Archive Advertising Cookie Policy Privacy Statement Terms of Service

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