Originally Posted by
wiedehopf
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
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!