Originally Posted by
deltafox44
I don't know if AoA value shown on the graph was value from the vane or value corrected by algorithms. I suppose both are recorded. Anyway, pitch rate correction cannot drive corrected value from +75° to -60° !
Back in the days when I was working on A320 software we were restricted on how much we could send to the FDR. We would have loved to send raw data as well as processed data for a parameter, it would have helped enormously with post flight diagnostics. So I am fairly certain the value on the FDR is the fully processed value that the ADIRU puts on the ARINC 429 bus for the FCC (and whatever else) to use in their own processing.The value can go from +75 to -60deg because (I believe) the 6 stage AoA correction computation (Pitch Rate possibly being the main one) is using garbage parameters and so producing a garbage output. I think the large negative Pitch Rate starting at 05:43:24 may have caused a change to which garbage parameter was picked up. However although the L AoA value is now dynamic, i.e. not stuck, it does not get anywhere near to being correct as it does not track the R AoA in the precise way that it did at the beginning of the flight.
Originally Posted by
safetypee
Thus what correction is being discussed; where is the computation done, and how is the output accessed by many other functions requiring AoA - MCAS one amongst many.
There are a number of conditioning/corrections going on. Starting with the description in #2857, the AoA sensor provides analogue voltages representing the Sine & Cosine of the shaft angle, with no corrections. The (simple) AoA sensor does not have access to the other parameters needed to do any more than provide raw measurements. These 2 analogue signals go to the ADIRU (and possibly to the SMYD); the ADIRU takes these signals into its A-To-D front end to turn into digital values, which are then made available to the ADIRU software. The software *should* then do a sine**2 + cosine**2 = 1 check; if that passes then it should calculate RawAoA as Atan (Sin(ShaftAngle) / Cos(ShaftAngle)) *checking* that Cos(ShaftAngle) is not so near 0 that an overflow would occur (see crash of first launch of Ariane 5 if you don’t!). The software *should* then check that RawAoA is within +/- valid limits and *should* check the rate of change from the last reading as plausible. A cross check on any other AoA *should/must* be done. Then the AoA *should* be smoothed to remove electrical or vibration noise. Now the 6 corrections (Pitch Rate, Mach No, etc) can be applied. Finally the WingAoA can be put out onto the ARINC 429 bus, as a fully validated, ready to use value for whoever needs it such as cockpit displays, FCC and possibly SMYD.
Vic