Originally Posted by
VicMel
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.