X-Virus-Scanned: clean according to Sophos on Logan.com Return-Path: Received: from [64.4.51.78] (HELO hotmail.com) by logan.com (CommuniGate Pro SMTP 4.3.4) with ESMTP id 985717 for flyrotary@lancaironline.net; Sun, 05 Jun 2005 21:44:54 -0400 Received-SPF: pass receiver=logan.com; client-ip=64.4.51.78; envelope-from=lors01@msn.com Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Jun 2005 18:44:07 -0700 Message-ID: Received: from 64.4.51.220 by BAY107-DAV6.phx.gbl with DAV; Mon, 06 Jun 2005 01:44:05 +0000 X-Originating-IP: [64.4.51.220] X-Originating-Email: [lors01@msn.com] X-Sender: lors01@msn.com From: "Tracy Crook" To: "Rotary motors in aircraft" References: Subject: Re: [FlyRotary] EC2 problems - solved / rotary risks Date: Sun, 5 Jun 2005 21:44:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01C56A17.AF30CC10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: MSN 9 X-MimeOLE: Produced By MSN MimeOLE V9.10.0011.1703 Seal-Send-Time: Sun, 5 Jun 2005 21:44:00 -0400 X-OriginalArrivalTime: 06 Jun 2005 01:44:07.0407 (UTC) FILETIME=[3A5227F0:01C56A39] This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C56A17.AF30CC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. =20 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. =20 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.=20 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 =20 Subject: [FlyRotary] EC2 problems - solved Tracy and others.=20 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.=20 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.=20 Bingo! John Just guessing, but maybe the new EC2 can't communicate with a = pre-autotune EM2 like Buly's. ??? ------=_NextPart_000_00EE_01C56A17.AF30CC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ahh..  Music to my ears John : )
 
And this brings up the subject of risk (rotary & = otherwise)=20 that Al W. (and every other builder I know) is concerned with.  I = agree=20 with Al W. that getting to the major causes of failures is a (hell, THE) = key=20 issue.  That is why I have not spent much time on the crank angle = sensor=20 single point failure question.  I have never seen or heard of a = confirmed=20 Mazda 13B CAS failure.  Can it happen?  Of course.  I am = in the=20 process of developing a dual CAS for the Renesis CAS but it is not a = 'front=20 burner' project.
 
I'm reading between the lines of Al's posts but it seems = that he is=20 emphasizing the importance of leaving the engine as un-touched as=20 possible.  I once wrote an article for Light Plane World (EAA's = ultralight=20 magazine back in the late 80's) and advocated the same thing after = noting that=20 many Rotax failures  occurred soon after the owner opened up the = engine for=20 maintenance.  Decarboning the piston ring grooves was important but = many=20 builders were causing more problems than they fixed when they went = inside so I=20 recommended some products and procedures that would do the job without = opening=20 the engine.  
 
 That was the basic gist anyway but I eventually = decided this=20 was not a reasonable approach for builders who planned on installing an=20 alternative engine in 200 mph category airplanes.  There were = simply far=20 too many areas where things could go wrong in this process.  The = root cause=20 of the problems had to be identified.   One of the names I = gave to the=20 cause is a term I recently used on this list - Shopcraft (or lack=20 of).   This referred to the ability to identify the quality or = suitability of virtually everything that goes into the plane.  Yes, = I know=20 this is a generality of the highest order but if we are to get to = the root=20 cause of failures in the field of alternative aircraft engines, this = level of=20 abstraction is required. 
 
It has been suggested that a collection of 'best practices' = might=20 be a solution.  This may help but it is not a solution.  = There is=20 an unlimited number of potential problem areas so a list of them could = never be=20 compiled.   So, how do you learn to recognize what is or is = not a=20 'good thing'?   I'm getting so frustrated just trying to = describe the=20 problem that there may not be a solution, at least not one that can=20 be spelled out in something like an email = message.   Damn,=20 now I can't even criticize Al W. for not spelling it out.=20
 
The best I can do for now is to emphasize two things.  = Pay=20 attention to every detail and admit to yourself when you don't have the = ability=20 to execute something well.   Another version of these = rules was=20 given to me long ago:
 
1.  Rules are for those who are not smart enough to = make up=20 their own.  (Author unknown)
2.  A man's got to know his own limitations.  = (Dirty=20 Harry)
3.  Always follow BOTH rules 1 & 2.
 
Small details like the problem of soldering thermocouple = wire to a=20 connector that Al Gietzen mentioned can be critically = important.  He=20 was able to recognize the problem (he made a lousy solder joint) and = devise a=20 solution (acid flux) even though it violated one of the cardinal rules = of=20 electrical wiring.  He recognized that too and took the steps = necessary to=20 achieve satisfactory results (knowing when to make up his own=20 rules).
 
Out of time, I'll stop blathering now.
 
Tracy 
 
Subject: [FlyRotary] EC2 problems - solved

Tracy and=20 others.
Following more than 12 months of battling with = EC2 issues=20 I'm pretty sure it's Eureka day!
After=20 rewiring and testing for almost 4 weeks I plugged the EC2 in last = night, and=20 got exactly the same symptoms as before. NOP flashing indicating no=20 communication. I took the EC2 to Buly's plane and tried it in his=20 installation. Same NOP, so I was thinking I'd fried it again. Before = sending=20 it back yet again I decided to install it my plane one more time and = see if=20 there was a spark.
 
To my=20 amazement it worked. No NOP, and I could bring up the EC2 data. The = only thing=20 that changed overnight was that I moved the cable to unplug it. I = climbed in=20 the back and found that I could make the NOP flash, or stop flashing, = by=20 moving the cable. I haven't taken the connector apart yet, but = I'm=20 expecting to find a broken wire inside the insulation, probably near a = solder=20 joint at the pin. Whenever I bent the connector outward for = testing it=20 made contact. When I bent it back to plug it in, contact was lost.=20
 
Bingo!
John
 
Just guessing, but maybe the = new EC2=20 can't communicate with a pre-autotune EM2 like Buly's.=20 ???
------=_NextPart_000_00EE_01C56A17.AF30CC10--