Robert writes:

<<Last week I flew  from Redmond to Sturgis MI for a paint job and when on final approach <snip>The
 displays reverted to the "blue screen of death" and I landed actually
 looking out the window.  The screens stayed blue for the next short hop,
 but after that they came up and ran fine to the completion of the
 flight. After the paint is complete and I am back in the air I'll be
 interested to see if this fall out repeats. >>

Robert,  you have a problem and you need to identify the source. You should start looking in the the most likely place, the installation. Yea, I know, the manufacturer always blames the installation and my airplane CAN'T be at fault, but the simple fact, backed by years of experience, is that the installation is overwhelmingly the most common source of problems with almost any piece of avionics.

The fact that the CFS ADAHRS passed the TSO testing, the fact that after over a hundred installations and tens of  thousands of flight hours there hasn't been ANY ADAHRS hardware failures and the fact that  there are a significant number of  installation related problems (~15% of the  new installations)  due to miswiring, miscalibration or incompatible software versions all  point to the installation as the likely source of your gremlins. Is an ADAHRS hardware possible? Of course it is. It just isn't very likely.  Just ask the colon dwelling flying primates.

In one recent case the builder was ABSOLUTELY, bet the farm, sure that the ADAHRS had a problem. The builder reported that they had swapped the ADAHRS in question with a known good unit and the problem disappeared. A replacement ADAHRS was sent and installed and guess what? The problem remained. As it turns out the avionics shop had been using an engineering prototype as a "Gold Standard" to test the wiring. The avionics shop had been warned that the flight code communication protocol had changed between prototype and production units and that the prototypes could not be used for flight.  When they first fired up the system it did not work so they replaced the ADAHRS with the prototype and it then started working. Someone remembered the software compatibility issue so they reinstalled the new ADAHRS and updated the IDU software. You should note that they broke the first rule of diagnostics which is "Change ONE thing at a time".  The  system did not work with the new ADAHRS and the new code and now did not work (as expected) with the prototype ADAHRS. Their conclusion was that the new ADAHRS was bad out of the box. When the replacement ADAHRS did not work, a technician was dispatched. After several hours of troubleshooting and wire tracing the facts of the situation started to emerge. As it turns out the prototype that the avionics shop was using as the gold standard was actually a loaner system from D2 that they considered a "gift" when D2 went under.  The fact that the prototype was a prototype was kept on the QT to minimize any questions about its ancestry.  The real cause of all the heartache was that the updated IDU code was corrupted turing download or transfer. Loading a fresh copy into the IDUs fixed the problem.

The moral of the story is that ALL the facts are needed to quickly and efficiently diagnose a problem. Builders tend to only report facts that they believe are relevant to the problem, frequently after having performed some troubleshooting themselves. The fact is that if you cannot fix the problem it is because you do not fully understand the problem and if you do not fully understand the problem you CANNOT judge what facts are important and what facts can be ignored.

Getting back to Robert's problem, the ADAHRS is actually several systems working in concert (AHRS, MSU,  ADC and OAT) where Air Data and OAT have separate warning flags so if Robert was getting an "Attitude Failure" it was likely related to the AHRS or MSU.  If you are getting an Attitude Failure alert it does not necessarily mean that the ADAHRS has failed. It does mean that the IDU is not receiving valid attitude information from the AHRS. This could be a message from the AHRS that says "Don't trust me", a corrupted message or no message at all. The LOG files will contain clues to what exactly is occurring. Also, most intermittent problems are wire termination related. In the past this problem has been due to a loose MSU connector, faulty ADAHRS heater supply current, cable shield to conductor shorts, broken conductors, poor crimping and poor grounding.

My strong recommendation is that Robert take steps to find and eliminate the source of the failure. The "wait and see" approach is unacceptable. If a fault happened then it happened for a reason and that reason, at a minimum, must be identified. Contact the avionics installer and  relate ALL information surrounding the fault. He should download and forward the log files to CFS for analysis.

The source of the problem is a fact that cannot be changed with attitude (npi). Attempting the resolve the problem with a biased view will only delay the inevitable. Fix the problem first then fix the blame. Start by identifying all possible sources and then eliminate them through testing until, as Doyle put it, whatever remains, however improbable, must be the truth.

You think you are good at diagnostics?  Here is an opportunity to demonstrate your alacrity. You will need some of all the materials and information listed. You have 27 Continental pistons that appear identical. Twenty six of the pistons weigh 623 grams and one piston weighs 624 grams. The pistons have a specific density of 0.09 pounds per cubic inch. You have a five gallon bucket of water, a four liter clear plastic container (that will accommodate one piston), a knife, two dimes, a penny, half a roll of duct tape, 3 feet of 0.020" safety wire and a simple balance beam scale that has a 50 Kg capacity and can indicate a 0.1 gram difference between the items placed on the pans.  What is the fewest number of measurements needed to identify the heavy piston with certainty?

Regards
Brent Regan