Think about this folks, what Paul is doing with the PC solution is far
superior to any of the automotive units. He will potentially be providing
users with capability to interface all of the functions of the aircraft,
directly on the instrument panel, not just the engine, or monitoring flap
angle, airspeed, etc. But we would be able to use it to control
everything,
even flying the plane remotely, or with auto pilot operated from the PC
board; just on one of these small fast PC board setups. Imagine getting
into
your craft, turning on the ignition, and looking at a 15" computer monitor
that you built into your dash, and seeing hundreds of data streams on
display, access to pinhole mini cameras mounted in you cowling, or
anywhere
else! This is transformative, it is revolutionary to the experimental home
built industry. I truly hope some of you programmers join in with Paul to
make it a reality.

Ed Carver

Racing Beat sells and supports the Motec unit and it is a very good unit.
Price however is about $1,800.

Thanks Ed for your understanding on this issue. I might also point out
that
there are some very sophisticated moving map programs out there that will
run on the same type of PC mother board and hardware. Some show the
terrain
you are flying over in 3d with all obstructions shown so this is a

monumental advantage in low visibility conditions.
http://www.navzilla.com/

I wrote my first articles for Kitplanes on this subject back in 1988 1989.
The Home Built Glass Cockpit by Paul Lamar Kitplanes June 1988 page 69 The
future can be here now: electronic instrument displays in your homebuilt.
Glass Cockpit: Part II by Paul Lamar Kitplanes January 1989 page 66
Automatic position reporting could be helpful when pilot's hands and mind
are full.
Paul Lamar HEY PAUL!!!!!!


I just felt saying THANKS A LOT FOR LETTING THE REST OF TAG ALONG FOR A
GREAT RIDE!!!!!! [YOU'RE THE MAN!]
Gene Kahn

Here are some pictures of my late 1980's glass cockpit in the C182 with a
8088 mother board. Updated the map every second written in QB under DOS no
less. I would use QB again and DOS if it supported USB but it won't so
Linux
and C it is.

Paul Lamar

Paul,

1201 seems an odd squawk code!! I never had one that close to 1200 when
assigned by ATC. :-)

Bill Schertz

Yes I don't know what was going on there :) Judging by the altimeter
and throttle I was at 10,000 feet.

Paul Lamar


The big boys are actually doing this one right. Independent boxes for
each function. Dual (or more) displays which can select data from the
various boxes. Necessary inter-box communication could be handled via
Ethernet or similar. Fault tolerance designed-in. I don't want the
engine to quit if my GPS starts sending out unpredicted bogus data.


Matt-

Matt,


You don't want it to become a Toyota in other words? I suspect o2 sensors
have a part in their issues because of the way o2 sensors fail.

Bruce


Bruce?
Are you saying that a rich mixture caused by a failed O2 sensor
can cause unintended acceleration?


Paul Lamar


Paul,

It's hard to say without knowing how they programmed it and without knowing
the exact characteristics of the newer o2 sensor used but I had a case a
long time ago where I was doing some work as a consultant for an OIL company
in CA. They instructed me to program a steam generator with O2 mixture
control using full control. I argued that it should only be trim control, or
a narrow band not the full range due to the failsafe of the o2 sensor I had
to control off of.

They wouldn't give in so I quit. Later they had an
accident where the operator had lifted the heated top off the sensor causing
it to cool like it would if it failed, thus the signal went to low scale or
4 mA indicating high o2. It caused the controls to see the mixture as lean
or too much air to fuel. The gas flow was controlled by the operator
manually and remained the same whereas the computer controlled the air via
an air dampener so it closed the dampener all the way rather than a
percentage as I had argued. The operator seen the black smoke, panicked and
threw the top back on the o2 sensor which opened the air dampeners to the
full position with a load of hot natural gas waiting in the burner and the
generator exploded and injured or killed the operator. I heard about it
about a year later.

I understand in autos, they supposedly don't use o2
control in the warm up process until it's fully heated up, then they switch
to the signal or so I'm told. Depending on how they programmed the ECU, and
if they used full o2 control rather than limited or trim control, and if
they didn't consider safeguards and failsafes if the sensor fails or appears
to fail or loses signal (an open or a short), and depending on the action of
the controller and the medium that is being controlled, if they are
increasing throttle position rather than decreasing fuel to maintain
mixture, they may have programmed in a run away condition without knowing
about it.

Now I'm doing a lot of supposing and remembering here because I have never
studied the newer o2 sensors and which way the signal react but other than
cruise cruise control, I can only theorizing that they may have somehow used
mixture control for economy control at high speeds without taking into
consideration the o2 fail safe reactance.

The question is, when looking at the o2 sensor output of today, does an
increase in air (21% o2) give a high value/voltage or a low value/voltage.
What does zero volts represent as to o2 if you happen to know? On the old
units, zero or 4mA represented 21% o2. Low or no heat to the sensor causes
the sensor to appear as high o2 (21%). I hope I have this all correct, it's
been a long time but it was burned into my mind at the time to always double
check everything if doing any mixture control based on o2 sensor signal.

It's been a long time since that incident with the oil company and I'm not
sure if the o2 sensors have changed today but these had a reverse signal as
I recall. When the heater for the sensor failed or if the o2 sensor failed,
it also showed high o2 (low signal) rather than low o2 (high signal). When
we have a negative cofficient like this we always need to anticipate every
condition and every variable to be failsafe even to the point of using
double or tripple redundancy.

I'm not sure about the new automotive sensors and I'm not sure how they
programmed it, fuel or air, as the output control but I suspect since the
throttle is opening or appears to be opening, like cruise control calling
for more throttle, to maintain speed, I would be looking at cruise control,
or o2 control as a possible culprit. Not many things are connected to the
thottle on a car. Since Toyota apparently isn't finding their problem, it
could be they are not digging deep enough to look at failed sensors or cold
sensors (water maybe splashing on them perhaps) or something giving them an
intermittent failures that isn't being reproduced in testing. Just a thought
but often I see people take something simple for granted and assume the
signal is like most things or positive cofficient.

I could be totally wrong on this since the technology has changed a lot so I
wouldn't bet a ton of money on it. I'm going by info from a long time ago
trying to connect dots of today that I have no real info on.

What can you see in this, you may have some inside knowledge on the
Toyota ECU black box and how they control. It would be nice to know for
sure. I hope this makes sense.

Bruce

I was an expert consultant one time in a unintended acceleration case.
Turned out the block water temp sensor failed increasing the idle
speed. The driver jerked the shift lever into reverse and the
car took off backwards in a parking lot killing the person
walking behind the car.

Interesting you should bring up cruise control. I can see how a failure
in the cruise control can bring about unintended acceleration.

Of course anytime you have a computer controlling a system there
are a zillon possibilities for failure. Could be a bug. Could be an
alpha particle changing a bit in a memory location. One bit change in
any of a 8 gigabits of program memory could create havoc.

There is a device called a watch dog timer that resets the
computer in a run away program situation. The programmer is required
to insert the watch dog code in the main program loop. If a sub program
does not get back to the main loop in time the watch dog code
resets the computer. If the watch dog code or timer fails than anything
is possible. In an aircraft situation the pilot is instructed to
manually reset the computer in certain circumstances.

It is going to be interesting on what is causing this if it is real.

Paul Lamar