Mailing List flyrotary@lancaironline.net Message #36915
From: Al Gietzen <ALVentures@cox.net>
Subject: RE: [FlyRotary] Re: EC2 question
Date: Thu, 10 May 2007 09:31:30 -0800
To: 'Rotary motors in aircraft' <flyrotary@lancaironline.net>

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
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster