X-Virus-Scanned: clean according to Sophos on Logan.com
Return-Path: <marv@lancaironline.net>
Sender: <marv@lancaironline.net>
To: lml@lancaironline.net
Date: Tue, 03 Jul 2007 15:17:30 -0400
Message-ID: <redirect-2156246@logan.com>
X-Original-Return-Path: <brent@regandesigns.com>
Received: from wind.imbris.com ([216.18.130.7] verified)
  by logan.com (CommuniGate Pro SMTP 5.1.10)
  with ESMTPS id 2156232 for lml@lancaironline.net; Tue, 03 Jul 2007 15:13:31 -0400
Received-SPF: none
 receiver=logan.com; client-ip=216.18.130.7; envelope-from=brent@regandesigns.com
Received: from [192.168.1.100] (cbl-238-80.conceptcable.com [207.170.238.80] (may be forged))
	(authenticated bits=0)
	by wind.imbris.com (8.12.11/8.12.11.S) with ESMTP id l63JCniq010402
	for <lml@lancaironline.net>; Tue, 3 Jul 2007 12:12:49 -0700 (PDT)
	(envelope-from brent@regandesigns.com)
X-Original-Message-ID: <468A9FB3.70902@regandesigns.com>
X-Original-Date: Tue, 03 Jul 2007 12:12:51 -0700
From: Brent Regan <brent@regandesigns.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
X-Original-To: Lancair Mailing List <lml@lancaironline.net>
Subject: Re: ADAHRS TSO
Content-Type: multipart/alternative;
 boundary="------------040205090902010707080001"

This is a multi-part message in MIME format.
--------------040205090902010707080001
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------040205090902010707080001
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">Robert writes:<br>
<br>
&lt;</font>&lt;Last week I flew&nbsp;
from Redmond to Sturgis MI for a paint job and when on final approach
&lt;snip&gt;The
<br>
&nbsp;displays reverted to the "blue screen of death" and I landed actually
<br>
&nbsp;looking out the window.&nbsp; The screens stayed blue for the next short
hop,
<br>
&nbsp;but after that they came up and ran fine to the completion of the
<br>
&nbsp;flight. After the paint is complete and I am back in the air I'll be
<br>
&nbsp;interested to see if this fall out repeats.
&gt;&gt;<br>
<br>
Robert,&nbsp; 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. <br>
<br>
The fact that the CFS ADAHRS passed the TSO testing, the fact that
after over a hundred installations and tens of&nbsp; thousands of flight
hours there hasn't been ANY ADAHRS hardware failures and the fact that&nbsp;
there are a significant number of&nbsp; installation related problems (~15%
of the&nbsp; new installations)&nbsp; due to miswiring, miscalibration or
incompatible software versions all&nbsp; 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.&nbsp; Just ask the colon dwelling
flying primates.<br>
<br>
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.&nbsp; 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".&nbsp; The&nbsp; 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.&nbsp; The fact that the prototype
was a prototype was kept on the QT to minimize any questions about its
ancestry.&nbsp; 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.<br>
<br>
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.<br>
<br>
Getting back to Robert's problem, the ADAHRS is actually several
systems working in concert (AHRS, MSU,&nbsp; 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.&nbsp; 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.<br>
<br>
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&nbsp; relate ALL information surrounding the fault. He should
download and forward the log files to CFS for analysis. <br>
<br>
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.<br>
<br>
You think you are good at diagnostics?&nbsp; 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.&nbsp;
What is the fewest number of measurements needed to identify the heavy
piston with certainty?<br>
<br>
Regards<br>
Brent Regan<br>
</body>
</html>

--------------040205090902010707080001--