X-Virus-Scanned: clean according to Sophos on Logan.com Return-Path: Received: from fed1rmmtao04.cox.net ([68.230.241.35] verified) by logan.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 1151258 for flyrotary@lancaironline.net; Mon, 12 Jun 2006 15:20:21 -0400 Received-SPF: none receiver=logan.com; client-ip=68.230.241.35; envelope-from=ALVentures@cox.net Received: from BigAl ([72.192.132.90]) by fed1rmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060612191933.QDPP15767.fed1rmmtao04.cox.net@BigAl> for ; Mon, 12 Jun 2006 15:19:33 -0400 From: "Al Gietzen" To: "'Rotary motors in aircraft'" Subject: RE: [FlyRotary] Re: Ignition Failure Date: Mon, 12 Jun 2006 12:19:48 -0700 Message-ID: <000001c68e55$2bd8a320$6400a8c0@BigAl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68E1A.7F79CB20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68E1A.7F79CB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps this is just too simple; but we should realize the wiring = failures are inevitably issues with the "connections". The first thing you do = with the stock CAS plug is to cut it off and throw it away. Then make a = quality soldered wire/wire connections to the shielded leads that runs all the = way to the ECU plug. One possible failure point eliminated. =20 Al G=20 =20 (Programming the mixture mapping on the EC2 yet again after I found on startup that the data in controller A was completely corrupted for = reasons that are entirely a mystery. Fortunately I had copied A to B a few days before. Apparently there is no way to copy B to A.) =20 =20 =20 On Sun, 11 Jun 2006 22:08:28 -0700 "Joe Hull" = writes: >> An ECU that was better at self diagnoses would have greatly reduced = your risk. On your car, it would be recognized immediately. =20 I know I've taken a little flack for my MicroTech computer.but on the = plus side it did tell me a couple of months ago that I had a "bad Crank = Sensor". Of course, it turned out to be a bad connector - the Mazda factory pig = tail coming out of the sensor had a bad connection in the plug. It must have been intermittent because the engine still ran fine for the most part - = just a little rough every now and again. =20 Good of you to share this Joe. Can save a life. =20 So here is what problem solving is all about.......but just a second, = some of you are going to have a hard time entertaining what follows. If so, = just hit delete, have a nice day. This is for the guys that responded to me privately..and others interested. =20 A) When we first heard of Johns failure, we need to force ourselves to entertain the idea that he crashed. Under slightly different = circumstances it would have happened. We do this to eliminate our natural tendency to = be complacent, to rationalize.=20 =20 B) We force ourselves to seek the OTHER causes. Because often it's the = other causes that can lead us to lasting permanent solutions. I'll explain = this better below. So the other causes I can think of are the 5 items I originally listed.=20 =20 C) We look outside our circle. We ask:"Well, how do the automotive guys handle this type of failure". "How do guys outside of the rotary group = do it? Etc. Now one of those solutions is absolutely PROFOUND. It has far reaching implications that greatly reduces risk of many historical = failures. Let's back up a little bit. Johns ECU saw the time interval between = crank pulses drop in half. Meaning the rpm went from 6000 to 3000 in 100 ms. Physically impossible. Only a crank sensor fault can cause this. Realistically, the ECU probably saw this weeks before his incident. = Maybe hours before. But it's the nature of most wiring faults to occur that = way. Not all of them, one of the crank sensor failures resulted in crash with almost no warning. There is a huge difference in flight risk if the ECU sees this fault, = tells you immediately. You land, you focus on the real cause, you don't have = to think "Maybe it's my muffler or mixture that gave me that little pop. = Maybe it's a spark plug". A key universal truth, is that risk is always reduced if you shorten the delay in notification. Each day Johns connection got a little worse and there was no way for him to know. =20 So we decide "I want the ECU to be smart enough to tell me when the = crank sensor develops blip." Our risk is reduced substantially. Then we think about it some more. Crap, you know that guy that had almost crashed a = few months ago due to loose buss connection? That was same failure pattern. = His airplane likely saw a momentary voltage drop minutes or hours before he headed to airport. So we say:"Hey, I want my EIS to respond to dips in voltage, so I get advance notice of those faults too. =20 So you put this solution in place, and you have made every plane less = risky. Even though some of the wiring faults will still occur. You've now = reduced flight risk. =20 -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 =20 =20 =20 =20 =20 -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 ------=_NextPart_000_0001_01C68E1A.7F79CB20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps this is just too simple; = but we should realize the wiring failures are inevitably issues with the = “connections”.  The first thing you do with the stock CAS plug is to cut it off and = throw it away.  Then make a quality soldered wire/wire connections to the = shielded leads that runs all the way to the ECU plug.  One possible failure point eliminated.

 

Al G

 

 (Programming the mixture = mapping on the EC2 yet again after I found on startup that the data in = controller A was completely corrupted for reasons that are entirely a mystery. = Fortunately I had copied A to B a few days before.  Apparently there is no way to = copy B to A.)

 

 

 

On Sun, 11 Jun = 2006 22:08:28 -0700 "Joe = Hull" <joeh@pilgrimtech.com> = writes:

>> An ECU that was better at self diagnoses would have greatly reduced your = risk. On your car, it would be recognized immediately.

 

I know = I’ve taken a little flack for my MicroTech computer…but on the plus side it did = tell me a couple of months ago that I had a “bad Crank Sensor”. =  Of course, it turned out to be a bad connector - the Mazda factory pig tail = coming out of the sensor had a bad connection in the plug.  It must have = been intermittent because the engine still ran fine for the most part – = just a little rough every now and again.

 

Good of you to share this Joe. Can save a life.

 

So here is what problem solving is all about.......but just a second, some of = you are going to have a hard time entertaining what follows. If so, just hit = delete, have a nice day. This is for the guys that responded to me = privately..and others interested.

 

A) When we first heard of Johns failure, we need to force ourselves to entertain = the idea that he crashed. Under slightly different circumstances it would = have happened. We do this to eliminate our natural tendency to be complacent, = to rationalize.

 

B) We force ourselves to seek the OTHER causes. Because often it's the other = causes that can lead us to lasting permanent solutions. I'll explain this = better below. So the other causes I can think of are the 5 items I originally = listed.

 

C) We look outside our circle. We ask:"Well, how do the automotive guys = handle this type of failure". "How do guys outside of the rotary = group do it? Etc. Now one of those solutions is absolutely PROFOUND. It has far = reaching implications that greatly reduces risk of many historical failures. =

Let's back up a little bit. Johns ECU saw the time interval between crank = pulses drop in half. Meaning the rpm went from 6000 to 3000 in 100 ms. Physically impossible. Only a crank sensor fault can cause this. Realistically, the = ECU probably saw this weeks before his incident. Maybe hours before. But = it's the nature of most wiring faults to occur that way. Not all of them, one of = the crank sensor failures resulted in crash with almost no = warning.

There is a huge difference in flight risk if the ECU sees this fault, tells you = immediately. You land, you focus on the real cause, you don't have to think = "Maybe it's my muffler or mixture that gave me that little pop. Maybe it's a spark plug".

A key universal truth, is that risk is always reduced if you shorten the delay = in notification. Each day Johns connection got a little worse and there was = no way for him to know.

 

So we decide "I want the ECU to be smart enough to tell me when the crank = sensor develops blip." Our risk is reduced substantially. Then we think = about it some more. Crap, you know that guy that had almost crashed a few months = ago due to loose buss connection? That was same failure pattern. His airplane = likely saw a momentary voltage drop minutes or hours before he headed to = airport. So we say:"Hey, I want my EIS to respond to dips in voltage, so I get = advance notice of those faults too.

 

So you put this solution in place, and you have made every plane less risky. = Even though some of the wiring faults will still occur. You've now reduced = flight risk.

 


-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:
htt= p://www.maddyhome.com/canardpages/pages/alwick/index.html

 

 

 

 

 


-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

------=_NextPart_000_0001_01C68E1A.7F79CB20--