Today's Message Index:
----------------------
1. 12:12 AM - Please Read - Who is "Matt Dralle" and What are "The Lists"...? (Matt Dralle)
2. 05:47 AM - Re: Interest in new EFIS/EMS (Doerr, Ray R [NTK])
3. 11:41 PM - Re: Interest in new EFIS/EMS (Dan Charrois)
Message 1
| INDEX | Back to Main INDEX |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Please Read - Who is "Matt Dralle" and What are "The Lists"...? |
--> Avionics-List message posted by: Matt Dralle <dralle@matronics.com>
Dear Listers,
Who is Matt Dralle and what exactly are these Lists? Well, I've been working in
the information technology industry for over 20 years primarily in computer
networking design and implementation. I've also had a rather extensive background
in web development and CGI design during this period.
I started the Matronics Email Lists back in 1990 with about 30 fellow RV builders
from around the world. Since that time, I have added 50 other kinds of aircraft
related Lists to the line up and numerous other List related services such
as the Archives and Search Engine just to name a few.
For the upmost in flexibility and reliability, I have chosen to run all of my own
servers here locally. Other support systems include a 1 Gigabit, fully switched
network infrastructure, a commercial-grade Netscreen firewall, a Barracuda
spam filter, a local T1 Internet router, and a commercial business T1 Internet
connection with static addressing.
The computer servers found here include two, dual processor Xeon Linux systems
dedicated to the email and web functions respectfully, and another P4 Linux system
serving as a remote storage disk farm for the archives, databases, and for
an on-line, hard drive-based backup system with 3.2 Terabytes of storage. This
entire system is protected by multiple commercial-grade uninterrupted power
supply (UPS) systems that assure the Lists are available even during a local
power outage!
I recently upgraded all of the computer racking infrastructure including new power
feeds and dedicated air conditioning for the room that serves as the Computer
Center for the Matronics Email Lists. Here's a new composite photo of the
List Computer Center following this Summer's upgrades!
http://www.matronics.com/MattDralle-ListComputerCenter.jpg
As you can see, I take running these Lists very seriously and I am dedicated to
providing an always-on, 24x7x365 experience for each and every Lister.
But building and running this system isn't cheap. As I've stated before, I don't
support any of these systems with commercial advertising on the Lists. It
is supported 100% through List member Contributions! That means you... and you...
and YOU!
To that end, I hold a List Fund Raiser each November and ask that members make
a small Contribution to support the continued operation and upgrade of this ever-expanding
system. Its solely YOUR Contributions that keep it running!
Please make a Contribution today to support these Lists!
http://www.matronics.com/contribution
Thank you!
Matt Dralle
Matronics Email List Administrator
Matt G Dralle | Matronics | PO Box 347 | Livermore | CA | 94551
925-606-1001 V | 925-606-6281 F | dralle@matronics.com Email
http://www.matronics.com/ WWW | Featuring Products For Aircraft
do not archive
Message 2
| INDEX | Back to Main INDEX |
| PREVIOUS | Skip to PREVIOUS Message |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Interest in new EFIS/EMS |
--> Avionics-List message posted by: "Doerr, Ray R [NTK]" <Ray.R.Doerr@sprint.com>
May I suggest a CAN bus for remote communications. I have developed a
Trim controller board that connects to the stick grip sensors and then
controls the trim and flap motors. I use the CAN bus to communicate
between the pilot side and co-pilot side controller. This info is then
transmitted on the bus. This way you could display the elevator, ailron
and flap positions with simply 2 wires. This is also a great way to
interconnect the remote sensor modules that could be positioned on the
firewall side for engine monitoring.
Thank You
Ray Doerr
CDNI Principal Engineer
Sprint PCS
16020 West 113th Street
Lenexa, KS 66219
Mailstop KSLNXK0101
(913) 859-1414 (Office)
(913) 226-0106 (Pcs)
(913) 859-1234 (Fax)
Ray.R.Doerr@sprint.com
-----Original Message-----
From: owner-avionics-list-server@matronics.com
[mailto:owner-avionics-list-server@matronics.com] On Behalf Of Dan
Charrois
Subject: Avionics-List: Interest in new EFIS/EMS
--> Avionics-List message posted by: Dan Charrois <danlist@syz.com>
Hi everyone. First of all, let me say that this is still years away
from happening. But I thought I'd put a bit of a feeler out now anyway.
I'm thinking of developing an "all-in-one" glass cockpit. You'd
probably wonder when I'd bother when there are already other good
options available for EFIS / Engine Management Systems, etc. It's
for the same reason we build planes when there are already good ones
available commercially - there is a great sense of satisfaction in
developing something yourself. And besides, that way you can ensure
that it does exactly what *you* want.
First, my background - I have a Bachelor of Science in Electrical
Engineering, Computing Stream, and have spent the past 10 or so years
developing hardened, reliable hardware and software systems. More
recently, I became a private pilot (VFR only at the moment, but that
may change), and even more recently than that, an RV-10 builder. I
also have the luxury of owning my own company (which develops the
aforementioned hardware and software), so I can work on pretty much
whatever project I like. As a result, the decision to develop my own
EFIS/EMS was pretty much made right from the get-go. Though I plan
on doing so for 1. The sheer enjoyment of it, and 2. To make it do
exactly what I'd like it to do, I thought I'd post a note here to see
if there are any others who may be interested in something like this
as well. Not that I expect to get rich from doing so, but if there
is more than one person who can benefit from what I'll be working on,
so much the better. Of course, remember this is years away - I want
to finish the plane I'm currently building first so I'll have
something to test and develop it in. And hardware is going to
continue improve in the meantime, so nothing is set in stone.
So here are the specs of what I'm hoping to accomplish. It won't be
cheap, but then very little in aviation is...:
- A good sunlight-readable display is paramount - perhaps a
transreflective display (or whatever technology is appropriate by
then). Likely 10 inch.
- The processing equipment will be housed in a separate box from the
display
- For stability, reliability, and performance, it won't be running
anything like Windows. Probably a variant of BSD customized for the
purpose, flash memory based (no moving hard drives or something
similar to fail)
- An external watchdog timer would be implemented to automatically
restart the system if it were to fail for any reason
- An internal rechargeable battery would power the unit (and attached
sensors) if desired when the avionics bus is off, or if there is a
power system failure on the aircraft
- CPU and associated hardware would be a ruggedized embedded system/
single board computer with extended temperature operating range (-40
Celsius to +50 Celsius)
- GPS (perhaps with RAIM) would be integrated into the unit
- flight display would include airspeed, altitude, VSI, attitude,
gyro-stabilized magnetic compass, turn coordinator, angle of attack,
G meter, clock, timer, moving map (with various displays, including
high resolution terrain and associated warnings, engine out glide
cones, etc), nearest airport lists, etc. Will be able to
automatically determine things like density altitude, pressure
altitude, TAS, true wind vectors, etc.)
- ability to control com/nav units that provide compatibility through
a serial port.
- engine management capabilities would include tachometer, manifold
pressure, voltmeter, ammeter, oil pressure, oil temperature, fuel
pressure, fuel flow and quantity (with range calculation), CHT, and EGT.
- sensors would include solid state gyros for attitude and
accelerometers mounted in the processing unit, and an external
magnetometer.
- would have serial, analog, and digital ports for interfacing with
other devices, and USB port for upgrades. You could connect it to
lots of external sensors (switches to sense cabin door positions,
gear up or down, flap position, etc.) to be able to display the
status of the aircraft at a glance, and allow the unit to alert you
if anything is wrong. Where possible and practical, opto-isolation
or current limiting devices would be used to isolate external sensing
circuitry so that something like a short in the wires to one sensor
doesn't cause problems for the unit as a whole.
- Would provide altitude encoder output for transponders.
- would be capable of other "non-flight" features, like weight and
balance calculations, "smart" user-definable checklists (appropriate
checklists would be quickly accessible based on the condition the
system considers the aircraft to currently be in), etc.
- ability to set green, yellow, and red "zones" for acceptable values
for any parameter, with or without audio cues. For example, the unit
could be set to pop up warnings (visually and/or auditory) if oil
pressure drops too low, or if you are inadvertently deviating from an
assigned altitude. The limits, as well as the parameters to monitor
in this way would be defined by the pilot
- it has to have a simple user interface that just "makes sense",
trying to be as "intuitive" as possible based on the conditions of
the plane as to the sorts of things you are likely to want to do.
- external ports for pitot and static lines, as well as GPS antenna,
It would also provide serial ports for control of compatible radios,
transponder, etc.
- the system would be continually determining position, velocity, and
acceleration in the 3 linear, as well as the 3 rotational axes. If
anything doesn't pass sanity checks (traveling too fast, too slow, or
too high for your plane's capabilities, if there are sudden
discontinuities in position or velocity, etc, or if pitot/static
sensing doesn't match GPS or gyro and accelerometer calculations
within a reasonable percentage, it would flag a warning to alert you
of the potential unreliability. The good thing is that with three
methods of sensing critical things like altitude and airspeed (pilot/
static, GPS, and accelerometer/gyros), the system in many cases
should be able to determine which components have failed and fall
back on the remaining two methods to continue to operate).
- since the screen is large enough, the pilot could switch from
several customized displays, showing different elements individually
or partitioned off into different virtual windows (of course, if
there was a failure or anomaly in any system, or exceeding limits in
a sensor, it would show a special pop-up display of the problem until
it's fixed or the alert dismissed)
And if that weren't enough, I intend on bundling two separate
computers in the same chassis (both tied into the same set of
sensors), with separate A/D converters, etc. They would communicate
state of the aircraft information continually between each other,
each independently (hopefully) arriving at a similar result. If they
disagreed with one another by more than a certain tolerance level (or
if their companion stops working and no longer is transmitting status
data), again, a warning would be displayed to that effect. The
capability would be there to switch the display to show the output
from either computer if one starts to act up for any reason. And the
side benefit is that with two completely redundant machines, it would
be trivial to drive two independent displays in the cockpit, so you
could have, for example, the primary flight display on the pilot's
side, with engine instruments and moving map on the copilot's side,
or whatever you like. Of course, a second display would be optional
- but the capability would be there.
In short, I want it all :-) I know it sounds like a Christmas wish
list ('tis getting to be the season :-), but since I'll be building
this myself I can make it do whatever seems useful or interesting to
do. As I said, I'm years away from having anything to show for my
plans, but I thought I'd put a (very) early word out. As I said, I'd
be primarily developing this for my own use, but does anyone else out
there think they might be interested in such a system? Obviously, I
don't assume anyone would be committing to anything (I wouldn't even
myself until it got much closer to fruition). But if there is an
interest, and I've missed on something that someone would find
useful, I'm all ears - this is the perfect time. And perhaps more to
the point, if this thing turns out to be as great as I'm planning,
how much would you be willing to pay for one?
Thanks for indulging in this description of my long term project.
Dan
--
Syzygy Research & Technology
Box 83, Legal, AB T0G 1L0 Canada
Phone: 780-961-2213
Message 3
| INDEX | Back to Main INDEX |
| PREVIOUS | Skip to PREVIOUS Message |
| NEXT | Skip to NEXT Message |
| LIST | Reply to LIST Regarding this Message |
| SENDER | Reply to SENDER Regarding this Message |
|
| Subject: | Re: Interest in new EFIS/EMS |
--> Avionics-List message posted by: Dan Charrois <danlist@syz.com>
Thanks, everyone, for your suggestions and great feedback you've sent
with regards to my planned project to develop my own EFIS. Since
this project seems to have generated a fair bit of interest (both
through private emails and postings back to the list), I thought I'd
expand upon some of the suggestions and ideas brought up.. To avoid
my replying to each of the messages individually on the list (and
resulting in tons of messages all from me), I thought I'd write this
single "reply" to everyone who contacted me.
Though I only have a VFR rating at the moment, I agree that there may
be a significant interest among IFR pilots. I have no idea what the
requirements would be to develop a system for legal IFR, but I
suspect it may be fairly intimidating. However, even if it can't be
used as a primary system, I'm sure that a bit of IFR experience sure
wouldn't hurt when developing the system to make it a useful
secondary resource at the very least. As I mentioned, I'm years away
from getting anything on the market, so I may well have an IFR rating
by then. It's something I'm interested in, at any rate.
Though I've done a lot of browsing to see what's currently available
hardware-wise, I haven't done any shopping for hardware yet, nor will
I likely do so until I'm ready to start the project (after my plane
is completed), despite the fact that I'm anxious to get started.
This is simply because hardware capabilities change so quickly. I'm
quite used to hardware being semi-outdated by the time I'm finished a
large software project, but I'd rather that it wasn't outdated even
before I started :-) Of course, I don't expect I'll be overly taxing
even today's hardware, but at the very least, future systems with
similar capability should be either less expensive, or less power
hungry (or both).
At the moment, I'm leaning towards a PC104 architecture for its
relative ruggedness, but again that may change if something better
pops up.
As Mickey Coggins suggested, I definitely intend on decoupling the
display from the rest of the system so that the inevitable changes
that will happen don't require a complete system redesign. Plus, it
would give more options for the end user in the size, style, and cost
of the display.
Some have questioned whether an external watchdog timer and dual
redundant systems are really necessary. Despite best efforts,
unfortunately even systems that are "supposed" to be totally reliable
sometimes crash. It could be everything from faulty software (which
is usually the case) to faulty hardware (which sometimes does happen
- particularly memory). Implementing a watchdog is easy and
inexpensive, so there's really no reason not to. At the very least,
it will prevent a locked up system from misleading the pilot into
thinking his attitude isn't changing when it could be doing so quite
drastically :-)
My desire to implement completely redundant systems stems from my own
personal situation. Though not a licensed pilot herself, my wife is
almost as enthusiastic as I am about flying, and she's interested in
having access to the same set of information from the co-pilot's side
as the pilot's side, though possibly displaying different details. I
could design a single system with two video outputs to minimize the
hardware, but it would by necessity result in a more complex (and
error-prone) system. Since single board computers themselves are
relatively inexpensive (especially when compared to the rest of the
hardware like displays and sensors), the easiest solution is to just
provide two identical single-display computers (with separate A/D
converters, etc.) with the same software on them, taking their input
from the same set of sensors. And if there are two computers in the
box, it's fairly trivial to get them to compare information and pop
up a warning if there is a disagreement. Of course, this redundancy
all stems from my own requirement of having two independent displays
in the cockpit, but if the result ends up going commercial, I'm sure
it could be made an optional component.
Making provision for multiple voltmeters and ammeters is a good idea,
and something I hadn't considered.
I agree that doing things like W&B calculations are usually done
before getting into the aircraft, but since it's a rather simple
software thing, there's really no reason not to include it.
There was another great suggestion by John Rippengal to use a remote
box in the engine compartment to measure and consolidate the readings
from the engine sensors before passing the data along to the main
processing box. It would definitely improve on the potential for a
real rat's nest, and keep the firewall penetration substantially
simpler. That's a perfect job for a simple microcontroller.
John Schroeder mentioned the possibilities of the plane being perhaps
more difficult to sell down the road with such a "customized" panel
that there may only end up being one of in the world. That's a
really good point, and I definitely realize that unless what I build
really takes off, the resale value just won't be there. After all,
if it's a "one of a kind" and something significant dies, there's
nothing that a future owner could do to fix it short of throwing it
away and buying something else. Of course, I'm not planning on
selling the plane (if I was, I wouldn't be building in the first
place), but it's something to keep in mind.
Throughout the design process, I definitely don't want to develop
things in a bubble. I'm hoping to draw upon the expertise of people
on this list and others who may have the use for such a device to
make sure that I don't start to move off towards a tangent that will
ultimately prove useless to anyone, and keep as much as possible to
"mainline" ideas.
John mentioned the example of providing a mini keyboard for entering
data instead of twirling concentric knobs. I agree that twirling
knobs is a lousy interface, and would definitely like to see a
keyboard option myself. Of course, I've flown in turbulence (as I'm
sure we all have) strong enough to make dealing with a mini keyboard
rather tough, so I don't see any reason not to allow both types of
devices for input. At least, with a twirling knob, you can hang on
to it while turning it so your hand isn't bouncing all over the
place. Plus, there are some situations (like scrolling through a
list) where a twirling knob is more intuitive than pressing arrow keys.
Thanks to everyone who mentioned similar projects they've been
working on - I'll try and contact some of you personally. I am
definitely interested to see what others have done here. As Tom
Brusehaver mentioned, openefis.org and autopilot.sourceforge.net
don't seem to be in operation at the moment. Hopefully they're
resurrected at some point so I can have a peek as to what they've
accomplished..
Using standards whereever possible, such as a CAN bus as suggested by
Ray Doerr, makes great sense. A CAN bus has a lot of great features
such as noise rejection that are critically important n a system like
this.
I also appreciate the suggestion from several people to check out the
Glass Panel Yahoo mailing list. I'll definitely do that.
Again, thanks everyone for your great suggestions.
Dan
--
Syzygy Research & Technology
Box 83, Legal, AB T0G 1L0 Canada
Phone: 780-961-2213
Other Matronics Email List Services
These Email List Services are sponsored solely by Matronics and through the generous Contributions of its members.
-- Please support this service by making your Contribution today! --
|