X-Virus-Scanned: clean according to Sophos on Logan.com X-SpamCatcher-Score: 73 [XX] (34%) SPAM DICTIONARY WORDS: low count (23%) URL: contains host with port number (23%) SPAMTRICK: obfuscated phone number (-21%) URL: weird port adjustment Return-Path: Received: from fed1rmmtao107.cox.net ([68.230.241.39] verified) by logan.com (CommuniGate Pro SMTP 5.1.8) with ESMTP id 2036292 for flyrotary@lancaironline.net; Thu, 10 May 2007 13:32:02 -0400 Received-SPF: none receiver=logan.com; client-ip=68.230.241.39; envelope-from=alventures@cox.net Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao107.cox.net (InterMail vM.7.05.02.00 201-2174-114-20060621) with ESMTP id <20070510173124.UYEG13903.fed1rmmtao107.cox.net@fed1rmimpo02.cox.net> for ; Thu, 10 May 2007 13:31:24 -0400 Received: from BigAl ([72.192.132.90]) by fed1rmimpo02.cox.net with bizsmtp id xVXN1W00q1xAn3c0000000; Thu, 10 May 2007 13:31:23 -0400 From: "Al Gietzen" To: "'Rotary motors in aircraft'" Subject: RE: [FlyRotary] Re: EC2 question Date: Thu, 10 May 2007 09:31:30 -0800 Message-ID: <000001c79329$0c21ea80$6400a8c0@BigAl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C792E5.FDFEAA80" 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.3028 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C792E5.FDFEAA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marv; =20 Yeah; I think you're right. On further review I realize that what we = have is likely 8-bit parallel data feed to the VF screen; so that part is not easy. Could be relatively easy to get the serial feed info from the = EC2; rpm, MAP, fuel flow; but that's about it. =20 Regarding the auto-tune; I think it is a nice feature; but not = essential. You have to rough things in with mode 1 anyway; and then manually = stepping the mixture in Mode 9 isn't so different from the EM2 stepping it automatically. Maybe just after innumerable re-tunings of the engine = over the 5 years, or whatever, that I've had the EC2 I've gotten used to it. When I first got it there was no mode 9. To me the more important thing = is the ability to display the table (and other settings), and make changes = to the table from the EM2. =20 BTW; preliminary results indicate that the issue I've had with the spontaneous changes of settings has been resolved. =20 Al "Al Gietzen" wrote: """ I think the right answer is to use the EM2; and to get Tracy to give us = the info needed (data format, baud rate, which leads, etc) to feed a = converter that allows displaying the data on the GRT screen. I can get the = converter made if I can get the needed input. I have raised the issue with Tracy = but haven't pressed - maybe if we both do. Tracy? (Pressure, pressure). It's not urgent; I don't think it is that tough; but I'm just guessing. """ Back when I was doing the systems integration on that Lancair IVP with = the Eagle 540 V8 engine we wanted to do essentially the same thing you are suggesting.... pull the data that the ECU was collecting and using to = opeate the engine, convert it to something readable by the Chelton EAU (nothing more than a GRT EIS) and squirt it into the appropriate pins on the EIS = to display engine data. We aproached Greg at GRT and the guy who built the computer for the engine, discussed what we wanted to do at great length = with both and discovered that we were probably talking about $20k+ worth of hardware and software engineering with no real guarantee that we would actually pull it off in the end. Big disappointment. WIth that info in hand we decided to install discrete sensors for everything that the EIS required and probably spent $1000-1500 getting that job done, not = counting labor.=20 Another note on sharing signals... that airplane has an EI (Electronics International) fuel totalizer in it, which included the pair of = transducers to read flow both to the fuel rails and from the regulator, as well as = an outboard black box they call an FFDM-1 (Fuel Flow Differential Module) = that took the two signals, deducted the return from the feed and sent the = result to the instrument as actual fuel flow being consumed. The GRT EIS does = that differential math internally, so we wanted to share the flow = transducers' signals between the EI and GRT since they both used the same input data stream. I again spoke with Greg (GRT) and the guy at EI who engineered their fuel instrument about what we wanted to do and they both said that = all I needed to do was parallel the signal wires from the xducers to both instruments and that would be that. (Sounded simple enough... the flow tansducers each had 3 wires, +12, -ground, signal) and so that's what I = did. Started testing and found that the EIS was displaying flow, but it was = way off (like an order of magnitude) and the EI instrument wouldn't show any flow at all. Multiple phone calls to both companies resulted in many suggestions... add a resistor, add a pair of resistors, add an r-c = network, round and round.... until finally I dragged my oscilloscope into the cockpit, hooked it into the signal wires, setup a conference call = between mysefl, GRT and EI engineers, and by explaining the patterns I'm seeing = on the scope physically build a circuit on a breadboard with transistors, resistors, capacitors, etc, according to their ongoing directions that ultimately took the signals coming from the xducers and split them into = the "parallel" outputs but isolated them from the xducers through this new circuitry. The simple pair of parallel wires messed with the bias = circuits in the xducers, this isolator solved the problem. Once the breadboard version was proven I built a new circuit board, duplicated the circuitry = and piggybacked it into the FFDM unit. Sorry for the long story, but my = point is that what started out as "easy, just parallel the signal wires" from = both companies turned into this ordeal that consumed most of several days and required several trips to the surplus electronic store and Radio Shack = for components, etc. =20 The moral of the story? Few things are ever as simple as they would = first appear.... that Murphy guy is everywhere. -- =20 Homepage: http://www.flyrotary.com/ =20 Archive and UnSub: http://mail.lancaironline.net:81/lists/flyrotary/List.html ------=_NextPart_000_0001_01C792E5.FDFEAA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marv;

 

Yeah; I think you’re = right.  On further review I realize that what we have is likely 8-bit parallel = data feed to the VF screen; so that part is not easy.  Could be = relatively easy to get the serial feed info from the EC2; rpm, MAP, fuel flow; but = that’s about it.

 

Regarding the auto-tune; I think = it is a nice feature; but not essential.  You have to rough things in with = mode 1 anyway; and then manually stepping the mixture in Mode 9 isn’t so different from the EM2 stepping it automatically.  Maybe just after = innumerable re-tunings of the engine over the 5 years, or whatever, that I’ve = had the EC2 I’ve gotten used to it.  When I first got it there was no = mode 9.  To me the more important thing is the ability to display the = table (and other settings), and make changes to the table from the = EM2.

 

BTW; preliminary results indicate = that the issue I’ve had with the spontaneous changes of settings has = been resolved.

 

Al

 "Al Gietzen" <ALVentures@cox.net> wrote:
"""
I think the right answer is to use the EM2; and to get = Tracy to give us the
info needed (data format, baud rate, which leads, etc) to feed a = converter
that allows displaying the data on the GRT screen. I can get the = converter
made if I can get the needed input. I have raised the issue with = Tracy but
haven't pressed - maybe if we both do. Tracy? = (Pressure, pressure). It's
not urgent; I don't think it is that tough; but I'm just guessing.
"""

Back when I was doing the systems integration on that Lancair IVP with = the Eagle 540 V8 engine we wanted to do essentially the same thing you are suggesting.... pull the data that the ECU was collecting and using to = opeate the engine, convert it to something readable by the Chelton EAU (nothing = more than a GRT EIS) and squirt it into the appropriate pins on the EIS to = display engine data.  We aproached Greg at GRT and the guy who built the = computer for the engine, discussed what we wanted to do at great length with both = and discovered that we were probably talking about $20k+ worth of hardware and software engineering with no real guarantee that we would actually pull it off in = the end.  Big disappointment.  WIth that info in hand we decided = to install discrete sensors for everything that the EIS required and = probably spent $1000-1500 getting that job done, not counting labor.

Another note on sharing signals... that airplane has an EI (Electronics International) fuel totalizer in it, which included the pair of = transducers to read flow both to the fuel rails and from the regulator, as well as an = outboard black box they call an FFDM-1 (Fuel Flow Differential Module) that took = the two signals, deducted the return from the feed and sent the result to the instrument as actual fuel flow being consumed.  The GRT EIS does = that differential math internally, so we wanted to share the flow = transducers' signals between the EI and GRT since they both used the same input data stream.  I again spoke with Greg (GRT) and the guy at EI who = engineered their fuel instrument about what we wanted to do and they both said that = all I needed to do was parallel the signal wires from the xducers to both = instruments and that would be that.  (Sounded simple enough... the flow = tansducers each had 3 wires, +12, -ground, signal) and so that's what I did.  = Started testing and found that the EIS was displaying flow, but it was way off = (like an order of magnitude) and the EI instrument wouldn't show any flow at = all.  Multiple phone calls to both companies resulted in many suggestions... = add a resistor, add a pair of resistors, add an r-c network, round and = round.... until finally I dragged my oscilloscope into the cockpit, hooked it into = the signal wires, setup a conference call between mysefl, GRT and EI = engineers, and by explaining the patterns I'm seeing on the scope physically build a = circuit on a breadboard with transistors, resistors, capacitors, etc, according = to their ongoing directions that ultimately took the signals coming from = the xducers and split them into the "parallel" outputs but = isolated them from the xducers through this new circuitry.  The simple pair of = parallel wires messed with the bias circuits in the xducers, this isolator solved = the problem.  Once the breadboard version was proven I built a new = circuit board, duplicated the circuitry and piggybacked it into the FFDM = unit.  Sorry for the long story, but my point is that what started out as = "easy, just parallel the signal wires" from both companies turned into = this ordeal that consumed most of several days and required several trips to = the surplus electronic store and Radio Shack for components, etc. 

The moral of the story?  Few things are ever as simple as they = would first appear.... that Murphy guy is everywhere.

   <Marv>


--
 
Homepage:  =
http://www.flyrotary.com/
 
Archive and UnSub:   =
http://mail.lancaironline.net:81/lists/flyrotary/List.html<=
/pre>
------=_NextPart_000_0001_01C792E5.FDFEAA80--