X-Virus-Scanned: clean according to Sophos on Logan.com Return-Path: Received: from fed1rmmtao105.cox.net ([68.230.241.41] verified) by logan.com (CommuniGate Pro SMTP 5.1.10) with ESMTP id 2156526 for flyrotary@lancaironline.net; Tue, 03 Jul 2007 18:41:45 -0400 Received-SPF: none receiver=logan.com; client-ip=68.230.241.41; envelope-from=alventures@cox.net Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070703224107.UTEP11062.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net> for ; Tue, 3 Jul 2007 18:41:07 -0400 Received: from BigAl ([72.192.132.90]) by fed1rmimpo02.cox.net with bizsmtp id KAh71X0041xAn3c0000000; Tue, 03 Jul 2007 18:41:07 -0400 From: "Al Gietzen" To: "'Rotary motors in aircraft'" Subject: MAP pressure sensors Date: Tue, 3 Jul 2007 15:42:08 -0800 Message-ID: <000001c7bdcb$c513fa20$6400a8c0@BigAl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C7BD88.B6F30410" 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.3138 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C7BD88.B6F30410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The same approx. output indicates to me that the pressure transducers appear to be doing identical functions with changing altitude/ambient pressure. So I would normally say the problem has to be down stream of = the pressure transducer output, but I'm sure Tracy has chased that rabbit. = It is a puzzle=20 =20 Al, =20 How did you go about measuring the output at different altitudes? Did = you actually have wires running to some sort of ohmmeter while in flight? = Or did you use a pressure chamber? If pressure (vacuum) chamber did you = have a separate vacuum source on the manifold lines? Otherwise, you would not = have simulated altitude accurately.=20 David; What I said: ". . . even though the measured output from the A and B sensors are the = same when the unit is powered up (out of the plane) at different altitudes (measured at 1400' and 5300')." was not very clear. The output measured at Ramona (1400') was = consistent; and that measured at Boulder, CO (5300') was also - within less than a milivolt. So this would suggest that the output response is the same, = or IOW, at WOT, at different altitudes, A and B should be the same. The = sensor on A also appeared to be in fine shape in all respects. It is true that this is not the same as pulling a vacuum on the ports to say, 20" Hg = with both at the same altitude. That test seemed more difficult than buying = a new sensor. I should know next week whether that solves the problem. =20 In replacing the sensor, and further studying the circuit, my son says " = I installed the new MAP sensor, and added a ground lead from the sensor to = the processor (I think the lack of a good ground return=20 was the source of the RF and other problems). He has remarked before = that his opinion is that the ground circuits on the board are not = particularly resistant to RF issues. =20 With the diodes possibly causing interference, did you run a trial = jumper across the diodes and did that in fact fix the problem? Otherwise you = could be barking up a long and tangled tree... =20 The thought that the power isolation diodes COULD be a source of the = problem did not come to light until we were well down the road to a solution, = and the additional filtering was added. So that test was never done. It is speculation based on that feature being unique to my installation, and = that I seemed to be the only one with the data settings corruption problem. =20 Al ------=_NextPart_000_0001_01C7BD88.B6F30410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 The same approx. = output indicates to me that the pressure transducers appear to be doing = identical functions with changing altitude/ambient pressure.  So I would = normally say the problem has to be down stream of the pressure transducer output, = but I'm sure Tracy has chased that = rabbit.  It is a puzzle

 

Al,

 

How did you go about measuring the output at = different altitudes?  Did you actually have wires running to some sort of = ohmmeter while in flight?  Or did you use a pressure chamber?  If = pressure (vacuum) chamber did you have a separate vacuum source on the = manifold lines? Otherwise, you would not have simulated altitude accurately. =

David;

What I said:

“. . . even though the = measured output from the A and B sensors are the same when the unit is powered up (out of the plane) at = different altitudes (measured at 1400’ and = 5300’).”

was not very clear.  The = output measured at Ramona (1400’) was consistent; and that measured at = Boulder, = CO (5300’) = was also – within less than a milivolt.  So this would suggest that = the output response is the same, or IOW, at WOT, at different altitudes, A and B should be = the same. The sensor = on A also appeared to be in fine shape in all respects.  It is true that this = is not the same as pulling a vacuum on the ports to say, 20” Hg with = both at the same altitude.  That test seemed more difficult than = buying a new sensor.  I should know next week whether that solves the = problem.

 

In replacing the sensor, and further studying the circuit, my son says = “ I = installed the new MAP sensor, and added a ground lead from the sensor to the processor = (I think the lack of a good ground return

was the source of the RF = and other problems).  He = has remarked before that his opinion is that the ground circuits on the = board are not particularly resistant to RF issues.

 

With the diodes possibly causing = interference, did you run a trial jumper across the diodes and did that in fact fix the problem?  Otherwise you could be barking up a long and tangled = tree...

 

The thought that the power = isolation diodes COULD be a source of the problem did not come to light until we = were well down the road to a solution, and the additional filtering was = added.  So that test was never done. It is speculation based on that feature = being unique to my installation, and that I seemed to be the only one with the = data settings corruption problem.

 

Al

------=_NextPart_000_0001_01C7BD88.B6F30410--