Instruments

For the first part of this chapter, I'm going to focus on the Instruments, since I think that area will 
take the longest for me to nail down (read ahead and you'll see why!)  And for organizations sake, I'm 
breaking down the Instrument section into four areas:

1. Flight Instruments
2. Engine Instruments
3. Navigational Instruments
4. Communication Radios and Transponder

Flight Instruments

Before I get into this subject, let me preface this section with the statement that something(s) that I 
have on this web page are most assuredly WRONG, and I'm sure that I will cause some dissension 
with my opinions (hint: IF you are offended, press the Back Button NOW...further engagement may 
only offend you more!)

First I will state that I am not intending to use a vacuum pump; I push electrons for a living, so I am 
much more comfortable designing failsafe and redundant systems with wire than with air.  I know the 
systems have been around FOREVER and are "reliable", but I still have a few problems with them:

1. Ever notice the number of IFR airplanes that fall out of the sky due to a Vacuum Pump Failure?
   (Have a look at the NTSB reports if you're curious.)
2. Many Vacuum Instruments don't have a Vacuum-Failure Flag
   (I know you can find some with flags, but most affordable ones don't.)
3. You always need to cross-check the function of your 'steam' gauges with the suction gauge.

I want to reduce my workload, not increase it in the name of "safety".  If the instrument fails, I want to 
know immediately that the instrument failed and have a backup.  If an electrical supply fails, again I 
want to know immediately and have an automatic backup.  I don't want to be second-guessing my 
instruments!

I also want the instrument to blank it's display after it has failed; I don't want the instrument-scan habit 
to fool me into accidentally believing a dead-instrument (I do wonder how many of those IFR death-
spirals were because the pilot reverted to a scan-habit under the pressure of an emergency...)

So, all instruments (with the exception of pitot-static, will be electric with redundant power sources 
(yes, that means two batteries, possibly two alternators).

One Big-Fat-Happy Panel?

Also, let me state (and this is sure to get me Flamed) that I am not a fan of the all-in-one EFIS, 
Engine, and Navigation Panel Displays; mostly because if there is a problem with your Panel, that 
is a lot of information to lose all at once (although I do like the failure mode of a blank display...it will 
by its main mode of failure force your brain to look elsewhere for information.)  My problem is that, 
again, its a lot of information to lose all at once.  To be strictly fair to the all-in-one EFIS designers, 
every one that I have seen states the you should always have backup flight instruments.  

But shouldn't there be a more graceful degradation of instrument failures?

How about instead of one big panel, you have a number of smaller panels (maybe 3.8"?), each with 
the ability to switch their display from one function to another.  In this case, if your Attitude-Gyro-Display 
fails, you can switch another panel to the 'Attitude-Gyro' mode to replace it.

This would require instead of dedicated sensors going to dedicated instruments, that you have an 
avionics bus to share the information.  (Can some of you EE's see where I'm going with this?)  I'm 
planning on using a CAN (Controller-Area-Network) Bus to implement this sensor sharing.

CAN-BUS? We don't need no stinking CAN-BUS!

Maybe I don't NEED a CAN-Bus, but it solves a lot of sensor sharing issues and it offers a level of 
redundancy that is a good fit for avionics displays.  For example, a CAN-Bus is made up of two 
signals (CAN-High and CAN-Low) that are differentially driven.  Due to the nature of the CAN 
Receivers, either signal can be shorted to the power, ground or the other CAN signal, and the bus 
will still work.  Power can be made redundant at each CAN node with diodes to the two power 
sources.  And if a message gets garbled, it not a problem since CAN-nodes continuously re-
supply their data to the bus.

I can also wire the CAN Bus in a Ring topology so that if the Ring gets broken, data will still flow 
down both sides to the point of the break.  (Note: if I do this, I will probably come up with a way to 
indicate this so that the problem can be corrected.)

So now I am envisioning several smaller panels with one or two larger navigation panels (easier 
to read, and if I implement something like a Windows-CE Panel I can use TeleType or ControlVision  
Navigation Software).  I am leaning towards having two navigation panels so that if one fails, I can 
switch to the other.  I may use a PocketPC for backup instead; if I run out of panel space.

I am also planning on having multiple sensor modules for safety critical sensors (such as Flight 
Instruments), so that if one module fails, then a backup will be available.

Now for the individual Instruments:

Roscoe-Style Artificial Horizon

My plan is to design a "Roscoe-Style Artificial Horizon" that replaces the Attitude-Gyro, Turn 
Coordinator, and possibly the Vertical Speed Indicator.  The idea is to provide all the above 
information in a simple intuitive, one-display format (similar to what a number of commercial 
and military glass-panels do.)  Again, the aim here is to reduce pilot workload, not increase it.  
I still plan on having a backup, electrical Attitude-Gyro (just in case of a complete CAN-Bus 
Failure.)

By the way, I'm calling this instrument the "Roscoe-Style Artificial Horizon" after some articles 
by Dr. Stanley N. Roscoe of AERO INNOVATION.  Since Dr. Roscoe doesn't really give this 
style of instrument a name, I'll just call it the "Roscoe-Style Artificial Horizon"

This type of Artificial Horizon has several advantages over a typical attitude gyro.  In the above 
example, the gray bar is the Flight-Path Predictor, the Vertical Black Lines are the rate of Turn 
Scale (the gray Flight-Path Predictor indicates the Rate of Turn in standard minutes by where 
it intersects the vertical black bars.)  And the horizontal white bars show the pitch of the aircraft 
(via the white aircraft symbol in the center) and the Vertical Speed (by where the gray Flight-
Path Predictor intersects the white bars). 

Currently I am thinking that each white tick should represent 250FPM, but that may be too 
sensitive.  I'll have to do some simulation runs to see what the best scale gradient may be.

Update January 2nd, 2004:

Test Platforms

Since I have a bit of time before I will need these Instruments, I have been experimenting with
a sample 3.8" panel that I designed to allow me to test software before committing to a
platform architecture (albeit, not at a very quick pace).

Based on some of my experiments in this area, I am now looking at the following spec for
each 3.8" Panel.

Based on some other Glass Panel Enthusiasts (Chad Robinson), I may be supplying this as
a Platform for other builders to implement their own displays.  Check back for updates, but
it will probably be a year or two before I produce anything useful to others.

Chad Robinson and I have been discussing various aspects of such a CAN-Bus distributed
system, so if you would like to enter the discussion, please feel free to email me or Chad.