Originally Posted by
VicMel
In which case the software in the ADRIUs *has* to be different, one side has to add the correction, the other has to subtract it. I can well believe from bitter experience that the software team did not know enough about the hardware subtlety to appreciate that the ADIRU software has to have a L and a R version. This would explain why testing and peer reviewing did not spot anything wrong, the software met its spec!
A correction table would also explain the different offsets. I would expect the table to be a 'look-up' table using air speed as the selector. As the airspeed went up it would reach a point where the next value in the table has to be used, so there would be a step change in the correction. So, I would expect the first value in the correction table to be about 6 deg (to give a 12 deg offset), the next value to be about 8 deg and the final value to be about 11 deg.
The basic (left/right) tables have to be correct since in normal operation the AOA values do match. The tables are likely fine grained and probably interpolated so doubt there is a visible step in correction. Only the tables would change for L/R, the rest of the code would be common.
I agree that a 'stuck bit' does not seem to fit the data since there would be discontinuities as the data crossed the point where the stuck bit should change, especially true since there are 2 A to D converters, one each for SIN and COS. Easily ruled out if we had access to the raw data.
Mention has been made of the AOA analog signals being connected to 2 boxes, this opens a possibility that an electrical fault in one box could cause an offset for both.