Received-SPF: pass
 receiver=logan.com; client-ip=205.152.59.66; envelope-from=ceengland@bellsouth.net
Message-ID: <42A494D5.3030206@bellsouth.net>
Date: Mon, 06 Jun 2005 13:24:21 -0500
From: Charlie England <ceengland@bellsouth.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: Rotary motors in aircraft <flyrotary@lancaironline.net>
Subject: Re: [FlyRotary] Re: EC2 problems - solved / rotary risks
References: <list-986188@logan.com>
In-Reply-To: <list-986188@logan.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Well, I'm 2 for 2, failing while driving. Actually, 3 for 3 if you count 
the one that failed shortly after selling the car. (3 different 
vehicles; none had been properly maintained.)

Who's sample is more representative of all timing belts? Does it make 
any difference who's is more valid if it's a single point of failure? Is 
there a backup timing belt on a Subaru?

Ya just gotta identify your risks (hopefully with unemotional & informed 
detachment), minimize risk where possible & then either accept the risks 
or stay home.

Al, is that not what you've done with your installation?

Charlie

Ian Dewhirst wrote:

> Hi Al,
>  
> The timing belt risk on your Subaru may be lower then you think, in my 
> experience timing belt failures occur at engine start 9 times out of 
> 10.  Most Japanese manufacturers recommend a replacement interval of 
> about 70,000 miles, if the oil seals are replaced at the same time and 
> the belt is re-tensioned after the first heat cycle you should be 
> quite safe. 
>  
> Ian
>  
> (Convinced that you are NOT flying the highest risk aircraft ever made ;-)
>
>     -----Original Message-----
>     From: Rotary motors in aircraft
>     [mailto:flyrotary@lancaironline.net]On Behalf Of al p wick
>     Sent: Monday, June 06, 2005 9:58 AM
>     To: Rotary motors in aircraft
>     Subject: [FlyRotary] Re: EC2 problems - solved / rotary risks
>
>     When we are pursuing a problem like Johns, we are eager to find
>     the cause. It's a great relief when we do. We say "Eureka!". We
>     did it! We did it! This sense of relief is a root cause for
>     failure. We are so eager to get the problem off our back, that we
>     don't take the next step....
>     Yes, I know you firmly believe this connector was the problem. But
>     if you can force yourself to pretend it WASN'T, then you can do this:
>     Is the cause logical? Like is that really the wire that causes
>     that effect? If I remove that wire, does it have the same effect?
>     What if I have two things causing the same thing? By pretending
>     that really wasn't the cause, then you will do some more testing,
>     looking around. Looking for similar connector issues, stuff like that.
>      
>     Now I have to admit, this really does sound like he found the
>     cause. But I've seen this scenario so often. So you use the
>     disciplines I suggest to reduce your risk. Logical cause? Can I
>     make it recur?
>     Repeat after me: "Al Wick is an idiot". "Al will jump to
>     conclusions". If you believe that, then you start finding ways to
>     prove your theory with facts instead of just accepting your first
>     conclusion. My best asset is that I know I'm an idiot.
>      
>     Yeah, yeah, I know, you guys already knew I was.
>      
>     We had a perfect example of this on Cozy list couple weeks ago.
>     Subaru engine slipped 2 teeth on timing belt. Would no longer
>     start. Keith talked to expert and the guy said:"You know, the
>     engine normally is never rotated backwards. But you've been
>     pushing your new prop backwards recently (installing new prop). I
>     think you relaxed the belt tensioner when going backwards and
>     caused it to skip tooth." So Keith said" Yes, all of that's true.
>     That has to be it."
>      
>     But then one of the guys looked into it, guess what? The direction
>     the belt slipped is the opposite of that theory. That could not
>     have caused it.
>     The lesson? Prove all aspects of the theory are logical. Prove
>     that all the various facts support the theory. Find a way to
>     convert your theory to facts!
>      
>     Oh, by the way, if you look at my analysis of my engine
>     risks....you will notice that timing belt is the highest risk item
>     on this engine. So we have exposed another root cause for his
>     problem. He didn't focus on the leading cause for all engine
>     failures. When we reviewed some facts he had, we found conclusive
>     evidence he had loose belt from day one! It was installed wrong.
>      
>     Regarding CAS risk. It's not just crank angle sensor that is the
>     risk item. Going to redundancy with the CAS will dramatically
>     reduce risk of all ECM causes. Like this connector risk. I'm not
>     always proponent of redundancy, but with my limited info on this
>     item, I SUSPECT it's significant, positive step.
>
>     -al wick
>     Artificial intelligence in cockpit, Cozy IV powered by stock
>     Subaru 2.5
>     N9032U 200+ hours on engine/airframe from Portland, Oregon
>     Prop construct, Subaru install, Risk assessment, Glass panel
>     design info:
>     http://www.maddyhome.com/canardpages/pages/alwick/index.html
>      
>      
>      
>     On Sun, 5 Jun 2005 21:44:00 -0400 "Tracy Crook" <lors01@msn.com
>     <mailto:lors01@msn.com>> writes:
>
>         Ahh..  Music to my ears John : )
>          
>         And this brings up the subject of risk (rotary & otherwise)
>         that Al W. (and every other builder I know) is concerned
>         with.  I agree with Al W. that getting to the major causes of
>         failures is a (hell, THE) key issue.  That is why I have not
>         spent much time on the crank angle sensor single point failure
>         question.  I have never seen or heard of a confirmed Mazda 13B
>         CAS failure.  Can it happen?  Of course.  I am in the process
>         of developing a dual CAS for the Renesis CAS but it is not a
>         'front burner' project.
>          
>         I'm reading between the lines of Al's posts but it seems that
>         he is emphasizing the importance of leaving the engine as
>         un-touched as possible.  I once wrote an article for Light
>         Plane World (EAA's ultralight magazine back in the late 80's)
>         and advocated the same thing after noting that many Rotax
>         failures  occurred soon after the owner opened up the engine
>         for maintenance.  Decarboning the piston ring grooves was
>         important but many builders were causing more problems than
>         they fixed when they went inside so I recommended some
>         products and procedures that would do the job without opening
>         the engine.  
>          
>          That was the basic gist anyway but I eventually decided this
>         was not a reasonable approach for builders who planned on
>         installing an alternative engine in 200 mph category
>         airplanes.  There were simply far too many areas where things
>         could go wrong in this process.  The root cause of the
>         problems had to be identified.   One of the names I gave to
>         the cause is a term I recently used on this list - Shopcraft
>         (or lack of).   This referred to the ability to identify the
>         quality or suitability of virtually everything that goes into
>         the plane.  Yes, I know this is a generality of the highest
>         order but if we are to get to the root cause of failures in
>         the field of alternative aircraft engines, this level of
>         abstraction is required. 
>          
>         It has been suggested that a collection of 'best practices'
>         might be a solution.  This may help but it is not a solution. 
>         There is an unlimited number of potential problem areas so a
>         list of them could never be compiled.   So, how do you learn
>         to recognize what is or is not a 'good thing'?   I'm getting
>         so frustrated just trying to describe the problem that there
>         may not be a solution, at least not one that can be spelled
>         out in something like an email message.   Damn, now I can't
>         even criticize Al W. for not spelling it out.
>          
>         The best I can do for now is to emphasize two things.  Pay
>         attention to every detail and admit to yourself when you don't
>         have the ability to execute something well.   Another version
>         of these rules was given to me long ago:
>          
>         1.  Rules are for those who are not smart enough to make up
>         their own.  (Author unknown)
>         2.  A man's got to know his own limitations.  (Dirty Harry)
>         3.  Always follow BOTH rules 1 & 2.
>          
>         Small details like the problem of soldering thermocouple wire
>         to a connector that Al Gietzen mentioned can be critically
>         important.  He was able to recognize the problem (he made a
>         lousy solder joint) and devise a solution (acid flux) even
>         though it violated one of the cardinal rules of electrical
>         wiring.  He recognized that too and took the steps necessary
>         to achieve satisfactory results (knowing when to make up his
>         own rules).
>          
>         Out of time, I'll stop blathering now.
>          
>         Tracy 
>          
>         Subject: [FlyRotary] EC2 problems - solved
>
>
>             Tracy and others.
>             Following more than 12 months of battling with EC2 issues
>             I'm pretty sure it's Eureka day!
>             After rewiring and testing for almost 4 weeks I plugged
>             the EC2 in last night, and got exactly the same symptoms
>             as before. NOP flashing indicating no communication. I
>             took the EC2 to Buly's plane and tried it in his
>             installation. Same NOP, so I was thinking I'd fried it
>             again. Before sending it back yet again I decided to
>             install it my plane one more time and see if there was a
>             spark.
>              
>             To my amazement it worked. No NOP, and I could bring up
>             the EC2 data. The only thing that changed overnight was
>             that I moved the cable to unplug it. I climbed in the back
>             and found that I could make the NOP flash, or stop
>             flashing, by moving the cable. I haven't taken the
>             connector apart yet, but I'm expecting to find a broken
>             wire inside the insulation, probably near a solder joint
>             at the pin. Whenever I bent the connector outward for
>             testing it made contact. When I bent it back to plug it
>             in, contact was lost.
>              
>             Bingo!
>             John
>              
>             Just guessing, but maybe the new EC2 can't communicate
>             with a pre-autotune EM2 like Buly's. ???
>
>          
>