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