Avionics-Archive.digest.vol-aa
September 12, 1999 - November 24, 1999
________________________________________________________________________________
| From: | dralle(at)matronics.com (Matt Dralle) |
| Subject: | Welcome to the New Avionics-List Email List at Matronics! |
Welcome to the New Avionics-List Email List at Matronics!
Matt Dralle
Matronics Email List Admin
--
Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551
925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email
http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft
________________________________________________________________________________
| From: | dralle(at)matronics.com (Matt Dralle) |
| Subject: | Two MORE Email Lists at Matronics... |
Dear Listers,
At the request of a couple of members, I have added two more Email Lists to
the Servers here at Matronics. These include:
avionics-list(at)matronics.com
Aircraft Avionics related topics such as Radios, GPSs, VSIs, DMEs, etc.
engines-list(at)matronics.com
Aircraft Engine related topics such as Lycomings, Auto conversions, etc.
As usual, the new lists have full archive searching and browsing capabilities.
You may subscribe to the new lists by using the Web-Based subscription form
at the following URL:
http://www.matronics.com/subscribe
Best regards,
Matt Dralle
Matronics Email List Admin.
--
Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551
925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email
http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft
________________________________________________________________________________
| From: | "Mitch Williams" <mitchw(at)tanet.net> |
| Subject: | Hey ist this Avionics-List active? |
Hey, is this an active list?
I have a '57 C172. A retired local avionics guy said he has a Narco Mark
16, with GS and indicator that he'd warrant and sell me for cheap to replace
my old mark 12A. Supposedly the mark 16 is an analog electronic navcom from
the '70's. Would this be adequate to for IFR instruction. Does anyone have
experience with the mark 16?
I know the mark 16 doesn't meet transmit bandwidth rules. I have a Val 760
as my primary com, and would label the mark 16 as "receive only".
mitch.
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Hey ist this Avionics-List active? |
>
>Hey, is this an active list?
Well, it is new so, who knows.
>I have a '57 C172. A retired local avionics guy said he has a Narco Mark
>16, with GS and indicator that he'd warrant and sell me for cheap to replace
>my old mark 12A. Supposedly the mark 16 is an analog electronic navcom from
>the '70's. Would this be adequate to for IFR instruction. Does anyone have
>experience with the mark 16?
They use to work OK. Frankly, I would give Narco a call and ask these
questions. I have sent radios back to them for upgrades and alignment.
They are pretty reasonable about giving good answers.
>I know the mark 16 doesn't meet transmit bandwidth rules. I have a Val 760
>as my primary com, and would label the mark 16 as "receive only".
I would talk to Narco. They may have an oscilator mod that will let it
meet the transmitter frequency accuracy specs. If so, it would meet the
new specs and you wouldn't have to mark it "receive only."
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Chuck Deiterich <cfd(at)tstar.net> |
| Subject: | Inexpensive raidio |
I read an article in the April Kitplanes that the FCC outlawed radios
like the Escort 110 or Alpha 200 can be used for listening in the
hanger. They are supposed to be worth $25 to $40. I have tried to find
one but have had no luck, does anyone have any ideas where I can get
one? I'd appreciate it.
Chuck Deiterich
cfd(at)tstar.net
________________________________________________________________________________
| From: | Chuck Deiterich <cfd(at)tstar.net> |
| Subject: | Power Requirements |
Folks,
Does anyone have the current requirements (amperage) for the following
equipment operating on 12 volts:
electric turn and bank,
tach,
temp guages,
fuel guages,
radios (COM/GPS) are about 1.1 amp listen to 6 amps transmit,
dual flash strobes are about 2.5 amps,
nav lites about 1 to 1.5 amps each,
Hobbs meter,
etc.
Chuck Deiterich
________________________________________________________________________________
| From: | "Mitch Williams" <mitchw(at)tanet.net> |
| Subject: | Inexpensive raidio - listening in the hangar |
For listening in the hangar ( and at home, and for Weather) I use a unidyne
bearcat scanner, 800XL i think. I bought it years ago for $140. The
advantages are: 1) you don't have to rig up a 14 or 28 VDC power supply,
2) you don't have to rig up an antenna, 3) scans multiple frequencies if
desired, 4) has a Weather scan build in (real similar to AWOS), 5) somewhat
portable ( I use it at home during tornado season).
Just make sure it cover the frequencies for aircraft.
mitch - 7155A
> I read an article in the April Kitplanes that the FCC outlawed radios
> like the Escort 110 or Alpha 200 can be used for listening in the
> hanger. They are supposed to be worth $25 to $40. I have tried to find
> one but have had no luck, does anyone have any ideas where I can get
> one? I'd appreciate it.
> Chuck Deiterich
> cfd(at)tstar.net
>
________________________________________________________________________________
| From: | Chuck Deiterich <cfd(at)tstar.net> |
Does anyone know how much current (amperage) a 12 volt turn indicator
draws?
Thanks
Chuck Deiterich
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Turn and bank |
>
>Does anyone know how much current (amperage) a 12 volt turn indicator
>draws?
It depends on which one you are using. Typically they run at about 500 ma
with a startup current in the 1-1.5A range. The best thing to do is to
measure yours. Just stick an ammeter in series with the T&B and the buss.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | "Tim Lewis" <timrv6a(at)earthlink.net> |
| Subject: | Re: RV-List: AOA/LRI - Brian Lloyd |
On 11 Oct 99, at 20:48, Jim Huntington wrote:
> Imagine my shock when I read your first post yesterday, Brian, tearing
> apart my company and making accusations about me
Nonsense. Brian raised technical concerns and asked you for data,
and once again you evaded. I've received off-list emails indicating at
least one other list member has had similar experiences with you, and
numerous others have commented on this behavior on-list. The
issues can't be resolved by emotion, Mr Huntington, but they can be
resolved by ANSWERS and DATA.
I publicly challenge you to answer Brian's questions, and to back up
your answers with credible data:
1. What effect do gear and flap deployment have on the accuracy of
the LRI?
2. If there is an effect, how great it is and in what direction?
3. Are the LRI indications accurate and consistent at G loadings
significantly greater than 1 G?
4. As you get farther away from critical AoA, how does the
calibration of the LRI hold up?
Question 3 is especially important, as it has a direct bearing on safety.
As Peter Bennett pointed out a year ago (see attached email text from
the RV list), it appears that at heavy G loading and/or weight, the LRI
will indicate that you have more "lift reserve" than you really have.
That would be dangerous. We need DATA to understand the
limitations of the LRI, and the risks inherent in using the LRI.
Data means credible flight test numbers showing LRI indication vs
airspeed (and preferably angle of attack) for a variety of flight
conditions - stall, Vx, Vy, - at various G loading and A/C gross weight.
Do you have data Mr Huntington? Will you supply it for all to see
here on the RV-list?
Sincerely,
Tim Lewis
RV-6A Painting (base color done, two stripes to go)
On 25 Nov 98, at 22:10, pbennett(at)zip.com.au wrote:
> --> RV-List message posted by: pbennett(at)zip.com.au
>
> This is a longish post involving some math. Delete now if you find it
> tiresome already.
>
> > I can understand that the LRI/AOA thread may be getting
tiresome to
> > some. But to me it is getting more interesting all the time.
>
> I was going to keep quiet on this but George's comment encourages
me to
> say why I believe the LRI suffers much the same problems as an ASI
and may
> lull into a false sense of security those who use it as an AOA. I
would
> welcome correction by those with more fluid dynamics,
aerodynamics and
> math ability than me.
>
> As I understand it, the LRI has two pitot style ports at different
> angles to the airstream. It measures differential ram air pressure and
> displays it on a gauge. The bottom line is that such a setup will
> indicate zero lift margin (ie a stall) at different positions on the
> panel indicator depending on aircraft weight.
>
> For a normal pitot,
> Ram air pressure = (d . V*2)/2
> where d = air density
> v = airspeed
>
> If the ports are inclined to the airstream at angles a and b
> respectively for ports 1 and 2, then
>
> Port 1 pressure p1 =( d . (Vcos a)*2)/2
> Port 2 pressure p2 = (d . (Vcos b)*2)/2
>
> The differential pressure which is indicated is
>
> p1 - p2 = (d.V*2((cos a)*2 - (cos b)*2)/2
>
> If we consider only the stall condition, this will always happen at the
> same angle of attack, regardless of weight. Therfore a and b are
> constant at the stall for all aircraft weights, as of course is air
> density d. Therefore differential pressure at the stall is a function
> of only velocity squared.
>
> However the velocity at stall is a function of G loading or weight,
> whichever you prefer. Therefore the differential pressure at stall is a
> function of weight, which means that "zero lift reserve" will shift on
> the dial depending on fuel, pax and baggage.
>
> How significant is the shift? Single pilot stall is typically around 45
> mph, and gross weight stall 55 mph, a 22% increase. Because of the
square
> law relationship, the indication at stall will increase by 10.5% over
> the same weight range.
>
> If you always dogfight at the same weight, the LRI will do what you
> want, but if you then load up the wife and baggage and fly into short
> strips, take care.
>
> Peter
>
>
******
Tim Lewis
timrv6a(at)iname.com
N47TD RV-6A, painting
Springfield VA
http://home.earthlink.net/~timrv6a
http://home.earthlink.net/~timrv6a/jpi.html - No JPI stuff in my airplane
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
Has everyone seen the Sierra Flight Systems glass cockpit EFIS-2000? Way
cool! Check out http://www.sierraflightsystems.com and download their demo.
This device is incredibly expensive, tho (~$40K+ for the full version). I'm
wondering how hard it could be to actually build something like this myself.
I'd like to get a team of qualified people together to seriously ponder what
it would take to do this and determine if it's feasible and make a group
project if we decide it can be done.
I have some hardware and software skills and feel that this is not an
outrageous idea. I don't have the engineering skills to do a true analysis
and requirements, and am not familiar enough with FAA regulations to
determine how acceptable any homebuilt instruments are in homebuilt (or
certified) aircraft.
If anyone is interested in investigating this idea further and seriously
pursuing this, please email me.
-Matt
________________________________________________________________________________
| Subject: | Re: Glass Cockpits |
In a message dated Mon, 8 Nov 1999 4:16:34 PM Eastern Standard Time, "Matthew
Mucker" writes:
>
> Has everyone seen the Sierra Flight Systems glass cockpit EFIS-2000?
> wondering how hard it could be to actually build something like this myself.
> I'd like to get a team of qualified people together to seriously ponder what
> it would take to do this and determine if it's feasible and make a group
>
> pursuing this, please email me.
>
> -Matt,
I have been looking into something like this also. The problem is it is very complex.
Some of the hardware I have found that may work and is aviable at a cost
I can afford.
Single board computer with b&w LCD and touch screen from www.tern.com
mag compass w/digital output. www.precisionnav.com
Pezio rate gyros are aviable from hobby stores. model heli use them for yaw control.
pressure transducers for alt and airspeed are avialable from Digi-key and others.
As for a full IFR panel the TSO process will make the $40K look cheap. But VFR
for homebuilt does not require TSO.
For now I plan to finish the plane with steem gages and do a new panel later.
Hope this helps
Alan Kritzman
RV-8 on the gear
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Hi Matt and Alan,
Well, it seems there are at least three of us who are intrigued by this
idea. I've seen the Sierra box and it is very impressive and very expensive.
It's a very nice piece of work but my best guess is that a lot of that high
price is profit and recapture of R&D costs. A lot (but not all) of the
hardware technology is basic laptop computer stuff. Their primary value
added, IMHO, is some very well designed software.
I think something like this could be done as a group project, but it would
be a LOT of work. Sort of like building an airplane in your garage. I
have a background in embedded computer system design. That is to say I've
been designing various black boxes with microprocessors inside them since
about 1970. I'm more or less retired now. There are big chunks of a project
like this that I would feel right at home with.
There is a do-it-yourself electronic fuel injection project running
currently (see http://efi332.eng.ohio-state.edu/efi332/) that is a fairly
good model for how this kind of project can be managed. They have, for
instance, designed their own circuit boards and organized a group purchase
to have them fabricated. Whether that model could be extended to a group
fund to get the thing TSO'ed is a major open question.
Some random thoughts:
I think the reason for the major price difference between the EFIS-1000 and
EFIS-2000 is the cost of the inertial nav unit that they buy from (IIRC)
British Aerospace. That would be the hardest part to duplicate, I think.
According to the SFS guy I talked to at Copperstate, they are not using
peizo rate gyros as they found them to not be stable enough.
See http://www.iijnet.or.jp/murata/products/english/catalog/s42e2.pdf for an
example of the guts of the hobby store gyros.
It looks to me like everything else can be built with off the shelf parts.
Later,
Jeff
-----Original Messages-----
Has everyone seen the Sierra Flight Systems glass cockpit EFIS-2000? Way
cool! Check out http://www.sierraflightsystems.com and download their demo.
This device is incredibly expensive, tho (~$40K+ for the full version). I'm
wondering how hard it could be to actually build something like this myself.
I'd like to get a team of qualified people together to seriously ponder what
it would take to do this and determine if it's feasible and make a group
project if we decide it can be done.
I have some hardware and software skills and feel that this is not an
outrageous idea. I don't have the engineering skills to do a true analysis
and requirements, and am not familiar enough with FAA regulations to
determine how acceptable any homebuilt instruments are in homebuilt (or
certified) aircraft.
If anyone is interested in investigating this idea further and seriously
pursuing this, please email me.
-Matt
I have been looking into something like this also. The problem is it is
very complex. Some of the hardware I have found that may work and is
aviable at a cost I can afford.
Single board computer with b&w LCD and touch screen from www.tern.com
mag compass w/digital output. www.precisionnav.com
Pezio rate gyros are aviable from hobby stores. model heli use them for yaw
control.
pressure transducers for alt and airspeed are avialable from Digi-key and
others.
As for a full IFR panel the TSO process will make the $40K look cheap. But
VFR for homebuilt does not require TSO.
For now I plan to finish the plane with steem gages and do a new panel
later.
Hope this helps
Alan Kritzman
RV-8 on the gear
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
A small update; I just came across this:
http://www.base-usa.com/sensor/vsg.htm
Contains the phrase: "low unit price". We need someone who really
understands gyros.
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
Jeff,
Thanks for the input!
My comments:
>It's a very nice piece of work but my best guess is that a lot of that high
>price is profit and recapture of R&D costs. A lot (but not all) of the
>hardware technology is basic laptop computer stuff. Their primary value
>added, IMHO, is some very well designed software.
My thoughts exactly.
>I have a background in embedded computer system design. That is to say I've
>been designing various black boxes with microprocessors inside them since
>about 1970. I'm more or less retired now. There are big chunks of a project
>like this that I would feel right at home with.
My thoughts are PC-104 machines. I still haven't found out if we could coax
one of these machines to drive 3 independent LCD displays. Do you know if
it can be done?
>I think the reason for the major price difference between the EFIS-1000 and
>EFIS-2000 is the cost of the inertial nav unit that they buy from (IIRC)
>British Aerospace. That would be the hardest part to duplicate, I think.
Definitely. We'd have to buy the inertial sensors. I have no idea what
they cost. Umm.... what's (IIRC) mean? What kinds of sensors are on the
market that could give pitch, roll, and heading information, and which are
most appropriate for our intended use, and how much do they cost?
>According to the SFS guy I talked to at Copperstate, they are not using
>peizo rate gyros as they found them to not be stable enough.
Do you know what kind of sensors would be needed to get roll, pitch, and
heading information? And how much they cost?
>See http://www.iijnet.or.jp/murata/products/english/catalog/s42e2.pdf for
an
>example of the guts of the hobby store gyros.
Eep! That's an angular velocity sensor. To go from that to absolute angle,
we'd have to integrate velocity over time, right? Yikes! I don't know that
I have the skills to do that... couldn't a sensor be purchased that gives
absolute angle of rotation information?
>It looks to me like everything else can be built with off the shelf parts.
I'd go so far as to say it could ALL be bought off the shelf... the attitude
sensors are probably going to have to come from an expensive shelf, though!
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
Here's a sensor that sounds like exactly what we need. In fact, the product
description matches what Sierra says their sensor does. I'm betting this is
the sensor they use!
http://www.primenet.com/~watgyro/products/ahrs.html
-Matt
________________________________________________________________________________
According to the SFS guy I talked to at Copperstate, they are not using
>peizo rate gyros as they found them to not be stable enough.
This is true if you use them over a long period of time. But even machanical gyros
have a bios weight to correct them over time. If you stay in a 30 degree
bank long enough the gyro will tell you your not turning any more. This could
be done with a pendulim, or like the big boys do and use altitude to determine
if your climing over a long period and magnetic heading to tell if your turning.
There are also fiber optic gyros aviable that do a better job but cost in the $5k
to $6k range just for the rate sensor.
More food for thought
Alan Kritzman
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Very interesting. It sounds exactly like the missing piece of the puzzle.
I'm downloading the manual as I type. I wonder what they mean by "Low Cost".
-----Original Message-----
Here's a sensor that sounds like exactly what we need. In fact, the product
description matches what Sierra says their sensor does. I'm betting this is
the sensor they use!
http://www.primenet.com/~watgyro/products/ahrs.html
-Matt
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
Ah, what goes around comes around. We spent a lot of time on this some
time ago and a couple of us spent time on this a couple of years ago.
For gyros you can't really use the Murata units for the following reasons:
1. their drift rates are too high to do anything useful (longer
term than 10 seconds or so);
2. Murata will hang up on you if you mention the word "airplane."
If you want piezo gyros, check out Systron Donner. That is what Collins
is using in their new AHRS box. I suspect that just about everyone is
using these as they have good long-term drift figures and are relatively
cheap (only about $6K for three axes of angular rate and three axes of
acceleration).
The Crossbow folks have a very insteresting system with some [relatively]
inexpensive iFOGs. The problem is, their AHRS box uses something else
and not their iFOG technology. Go figure.
Of course the PC-104 world is where you find processing modules.
Now, how do you tie it all together? We were considering using dual
redundant ethernet. 10Mbps beats the snot out of anything you can do
over a traditional serial port and ethernet it cheap. The only problem
is that most of the process control uPs, e.g. the PIC, have async serial
built in and don't have ethernet.
We got busy doing other things so it didn't get built.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Hi again,
IIRC = if I remember correctly
AFAIK = as far as I know
AFAIK all the so called solid state gyros are rate sensors not position
sensors. The code to integrate the rate to yield position is no big deal.
The hard part is compensating for thermal drift, filtering out noise, etc.
There are a wide range of CPUs available on various PC-104 boards so would
think one could be found that would drive 3 displays. I doubt that would be
a cost effective approach, though. My experience says CPUs are cheap, use
lots of them. I would go with at least one CPU per display. The LCDs will
cost a lot more than a CPU chip.
-----Original Message-----
My thoughts are PC-104 machines. I still haven't found out if we could coax
one of these machines to drive 3 independent LCD displays. Do you know if
it can be done?
Definitely. We'd have to buy the inertial sensors. I have no idea what
they cost. Umm.... what's (IIRC) mean? What kinds of sensors are on the
market that could give pitch, roll, and heading information, and which are
most appropriate for our intended use, and how much do they cost?
Do you know what kind of sensors would be needed to get roll, pitch, and
heading information? And how much they cost?
Eep! That's an angular velocity sensor. To go from that to absolute angle,
we'd have to integrate velocity over time, right? Yikes! I don't know that
I have the skills to do that... couldn't a sensor be purchased that gives
absolute angle of rotation information?
>It looks to me like everything else can be built with off the shelf parts.
I'd go so far as to say it could ALL be bought off the shelf... the attitude
sensors are probably going to have to come from an expensive shelf, though!
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Thanks for a few more data points. If we keep this up a picture may emerge.
Are there archives of this work? How can we pick your brain?
I was just using the Murata units as an example of what's out there. I know
they won't get the job done.
My vote for tying it together would be CAN. It's fast, robust, and built in
to several processors. (There's even a CAN/PIC in the works). It's used in
industrial control and automotive applications.
-----Original Message-----
Ah, what goes around comes around. We spent a lot of time on this some
time ago and a couple of us spent time on this a couple of years ago.
For gyros you can't really use the Murata units for the following reasons:
1. their drift rates are too high to do anything useful (longer
term than 10 seconds or so);
2. Murata will hang up on you if you mention the word "airplane."
If you want piezo gyros, check out Systron Donner. That is what Collins
is using in their new AHRS box. I suspect that just about everyone is
using these as they have good long-term drift figures and are relatively
cheap (only about $6K for three axes of angular rate and three axes of
acceleration).
The Crossbow folks have a very insteresting system with some [relatively]
inexpensive iFOGs. The problem is, their AHRS box uses something else
and not their iFOG technology. Go figure.
Of course the PC-104 world is where you find processing modules.
Now, how do you tie it all together? We were considering using dual
redundant ethernet. 10Mbps beats the snot out of anything you can do
over a traditional serial port and ethernet it cheap. The only problem
is that most of the process control uPs, e.g. the PIC, have async serial
built in and don't have ethernet.
We got busy doing other things so it didn't get built.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Matt,
I've been reading up on this Watson box. I agree, I bet it's what Sierra is
using. I wonder what it costs. This is starting to sound do-able!
Jeff
-----Original Message-----
Here's a sensor that sounds like exactly what we need. In fact, the product
description matches what Sierra says their sensor does. I'm betting this is
the sensor they use!
http://www.primenet.com/~watgyro/products/ahrs.html
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Glass cockpit |
Scratch that idea folks... that thingy is a cool ten grand. Yes, that's in
U.S. dollars.
-Matt
-----Original Message-----
From: Matthew Mucker <mmucker(at)airmail.net>
Date: Tuesday, November 09, 1999 5:09 PM
Subject: Avionics-List: Glass cockpit
>
>Here's a sensor that sounds like exactly what we need. In fact, the
product
>description matches what Sierra says their sensor does. I'm betting this
is
>the sensor they use!
>
>http://www.primenet.com/~watgyro/products/ahrs.html
>
>-Matt
>
>
________________________________________________________________________________
their drift rates are too high to do anything useful (longer term than 10 seconds
or so)
My thought was since I plan to do a VFR panel with no gyros for attitude, design
a 1/4 vga LCD with air speed, altitude, ROC, heading and a set of turn coordinator
wing in the middle. The TC is a rate gyro giving rate of roll and rate
of turn, so a simple piezo gyro will work if the drift is not to large.
I will probably try to make a turn coordinator using model helicopter gyro driving
a servo to see if the drift is acceptable. The helicopter guys in the area
say the new gyros are getting very good, and even have heading hold mode that
will keep the nose pointed in the same direction while they do loops, rolls,
and fly sideways for up to 10 minutes. The heading hold may be able to be used
for a simple wing leveler. Just my thoughts.
Alan Kritzman
RV-8 gota get back to building or I'm never going to fly.
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
All,
Well, after determining that Watson Industry's $10,000 AHRS sensor was too
expensive, I took their salesman's advice and called one of their
competitors, Crossbow.
Crossbow has an AHRS unit that sells for $6500. They also have a VGX unit
that is essentially the same thing minus heading for $4000.
These prices are still expensive, but starting to seem more reasonable for a
glass cockpit for a homebuilt aircraft.
Crossbow does not publish the same list of specifications that Watson
publishes on their web site. In fact, there's very little information there
and the salesman I spoke to did not offer any additional information.
(Whaddaya expect when ya tell the guy you're a hobbyist?)
So, check out Crossbow's site at http://www.xbow.com/html/product.htm and
let's start this brainstorming all over again.
Questions:
-what specifications do we need to set for an instrument that will measure
roll, pitch, and heading? I don't know that either of these units is
appropriate for our needs, and that begs the question: what exactly ARE our
needs?
-do we need heading in this sensor, or could we build a separate heading
sensor for less than the $1500 price difference between these two products?
This message cross-posted to Crossbow's sales email address. Let's see if
they have any input for us! (Crossbow: archives of this thread can be found
at
http://www.matronics.com/archive/archive-get.cgi?Avionics-Archive.digest.vol
-aa. Private emails were sent that are not in the archive.)
-Matt
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit |
>Well, after determining that Watson Industry's $10,000 AHRS sensor
>was too expensive, I took their salesman's advice and called one of
>their competitors, Crossbow.
>
>Crossbow has an AHRS unit that sells for $6500. They also have a
>VGX unit that is essentially the same thing minus heading for $4000.
>
>These prices are still expensive, but starting to seem more reasonable
>for a glass cockpit for a homebuilt aircraft.
Perhaps if we get together an order of a half dozen or more of these
things, the price may go down.
Also, designing a system around their product will further benefit
Crossbow for additional sales down the road. I would presume that the
results of this project would be left out in the public domain,
considering that it appears that a number of us want to get involved in
its development... people who use this design will probably use the
hardware which works with the software...
>Crossbow does not publish the same list of specifications that
>Watson publishes on their web site. In fact, there's very little
>information there and the salesman I spoke to did not offer any
>additional information. (Whaddaya expect when ya tell the guy
>you're a hobbyist?)
Not just a hobbyist, but a group hobbyists, each with enough money to
build his own aircraft with a glass cockpit? I would not take that too
lightly.
See prior paragraph... again, having the buying power of a group of
individuals now, and the potential for others to use our design later may
improve our position.
>So, check out Crossbow's site at http://www.xbow.com/html/product.htm
>and let's start this brainstorming all over again.
Looks great.
People have mentioned that an archive would be nice... anyone started
doing this yet? If not, I could start getting some of this information
together, with links, etc., and create a site for the project... ???
>Questions:
>-do we need heading in this sensor, or could we build a separate
>heading sensor for less than the $1500 price difference between
>these two products?
Have the software capable of doing both... then the "users" can decide
which options they would like to have. Another question: Will the unit
itself report a trappable error when you query the heading feature on the
VGX unit? If so, "our" software could then automatically adjust
accordingly.
Steve
http://www.tzogon.com/~steve/stolch801
Steven J. Devine, President, Consultant
TZOGON Enterprises Incorporated
steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
Okay, I said earlier that there were references to how military and airliner
jets use EFIS systems and their symbology.
That statement was made on speculation. Does anyone know of any good
references that describe the symbology on any of the EFIS systems in current
production aircraft?
Thanks,
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | glass cockpit requirements |
Okay: the first stage of building a product is defining the requirements,
right?
Here are my ideas for the requirements of our glass cockpit. These are my
"ideals" with no consideration as to the practicality of any of the ideas.
Send further ideas to me and I'll add 'em to our "dream cockpit machine".
- have 3 displays: one for flight instruments, one for engine instruments,
and one for moving map and other displays (such as data entry, probably).
- replace the following flight instruments: airspeed indicator, artificial
horizon, altimeter, turn and bank indicator, directional gyroscope, vertical
speed indicator, and magnetic compass. (In order to do this, the instrument
will need both a magnetic compass unit and a heading gyro, and we can
'slave' the gyro to the magnetic compass through software.)
- replace the following engine instruments: tachometer, oil temperature and
pressure, manifold pressure, CHT and EGT, fuel pressure, fuel flow, fuel
quantity guages (3 of 'em)
- replace the following miscellaneous instruments: voltmeter, ammeter, OAT,
G meter... and anything else I can think of.
- contain an integral GPS receiver and be capable of moving map display
- provide an interface to NAV radios so the display could be used instead of
an omnihead.
- be software upgradeable in the aircaft. (Probably a PCMCIA slot, but
floppy and CD-ROM are possibilities as well.)
- act as a flight data recorder and cockpit voice recorder. Supply a
program that will run on an IBM-PC computer to do playback of recorded
flight and voice data.
- have an interface for in-flight weather and traffic data for any
information systems that might exist. (I know of none.) Draw these items
on the moving map.
- have an interface for lightning detection systems. Draw these items on
the moving map.
- have an interface for a radar altimeter
-provide audible and visual alerts for alarm conditions. Use voice
recordings for the aural warnings.
- be affordable to the homebuilder. (How do we define affordable?)
- the goal of the project is to build a prototype of such a unit, test it
and become satisfied with its operation, and provide full disclosure to any
interested party that will allow them to build an identical unit from the
disclosed information. All software used to power the unit, including
source code, is included in the disclosure.
All of these can be clarified and defined in more detail, but that would be
one helluva cockpit!
Really, most of this stuff is really not as hard to do as it sounds.
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
>-do we need heading in this sensor, or could we build a separate
>heading sensor for less than the $1500 price difference between
>these two products?
Have the software capable of doing both... then the "users" can decide
which options they would like to have. Another question: Will the unit
itself report a trappable error when you query the heading feature on the
VGX unit? If so, "our" software could then automatically adjust
accordingly.
It appears that the unit sends a constant data stream (if it behaves like
the Watson unit) without being queried. So if the user puts in the
non-heading unit, the heading information won't be in the data stream.
I wonder if we could get an eval unit? Actually, I think that we can table
the sensor issue for a while and concentrate first on the graphical display,
because we can model that with no additional tools (just a PC running Flight
Simulator). Once we're all happy with the visuals, we can then start
building sensors and run the demo instrument on a standalone PC, sending
some data from Flight Simulator and other data from real sensors as we build
'em.
If we need a web site for this project, I have a personal domain. I haven't
put my web server back online since I moved. Maybe this is the motivation I
need to do so. And my web server is in my house, so I have complete control
over it.
-Matt
________________________________________________________________________________
| From: | Warren Gretz <gretz_aero(at)h2net.net> |
Greetings,
I have a limited supply of tie wrap string in 500yd spools I would be
interested in selling. It is the flat braded, coated type that will not
come untied easily. I will sell it for $12 a spool shipping included. If
you are interested, contact me off list. I also have other products I
offer. If you provide your US Postal mail address I will send you a set
of my flyers.
Warren Gretz
Gretz Aero
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit |
>>Have the software capable of doing both... then the "users" can decide
>>which options they would like to have. Another question: Will the unit
>>itself report a trappable error when you query the heading feature on the
>>VGX unit? If so, "our" software could then automatically adjust
>>accordingly.
>
>It appears that the unit sends a constant data stream (if it behaves like
>the Watson unit) without being queried. So if the user puts in the
>non-heading unit, the heading information won't be in the data stream.
But then why are there both Tx data AND Rx data lines on the unit?
>I wonder if we could get an eval unit?
The thought has crossed my mind...
>If we need a web site for this project, I have a personal domain. I
>haven't put my web server back online since I moved. Maybe this
>is the motivation I need to do so. And my web server is in my house,
>so I have complete control over it.
So do I... it's sitting right next to me... except mine is already on-line.
:)
Steve
http://www.tzogon.com/~steve/stolch801
Steven J. Devine, President, Consultant
TZOGON Enterprises Incorporated
steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com
________________________________________________________________________________
| From: | "Robert Day" <robday(at)gte.net> |
| Subject: | Re: glass cockpit requirements |
If this system replaces everything, we need to have more than one of them
for redundancy.
________________________________________________________________________________
| From: | "Robert Day" <robday(at)gte.net> |
Hello-
Forgive the ignorance, but what is involved with a slaved DG? What type of
mag compass has an output? Is the cost huge?
Thanks,
Rob Day
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit |
On Wed, 10 Nov 1999, Steven J. Devine wrote:
> >It appears that the unit sends a constant data stream (if it behaves like
> >the Watson unit) without being queried. So if the user puts in the
> >non-heading unit, the heading information won't be in the data stream.
>
> But then why are there both Tx data AND Rx data lines on the unit?
Because no one has made a transmit-only or receive-only UART. Eventually
someone will want to talk to the box if for no other reason than to
reconfigure it.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Glass cockpit |
>Because no one has made a transmit-only or receive-only UART. Eventually
>someone will want to talk to the box if for no other reason than to
>reconfigure it.
Or calibrate it. Or change the baud rate, stop bits, parity, data format,
etc. Really, I have no idea how this unit works, but the Watson unit has a
downloadable manual and it says that it coninually sends info.
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit |
>> >It appears that the unit sends a constant data stream (if it
>> >behaves like the Watson unit) without being queried. So if
>> >the user puts in the non-heading unit, the heading information
>> >won't be in the data stream.
>>
>> But then why are there both Tx data AND Rx data lines on the
>> unit?
>
>Because no one has made a transmit-only or receive-only UART.
>Eventually someone will want to talk to the box if for no other reason
>than to reconfigure it.
Well, by definition a UART is two way... Universal Asynchronous
Receiver/Transmitter... :)
What I was pondering was the point that some amount of two-way
communication was occurring, given the fact that the sensor can output
three different packet types with different data content... presumably,
the data sent *TO* the sensor would indicate the requested packet type...
Now, this data could either be either be provided on request, or a
constant data stream comes out once the mode is set... who's to say which
it is without detailed device specs?
Steve
Starting a (very) rough "glass cockpit" design document at:
http://www.tzogon.com/~steve/glass_cockpit
Zenith 801 project page at:
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit xbow data packets |
>It appears that the unit sends a constant data stream (if it
>behaves like the Watson unit) without being queried. So if the
>user puts in the non-heading unit, the heading information
>won't be in the data stream.
Well, I would guess that the two different units would send different data
packets, considering the fact that they provide different data elements.
Even the AHRS unit has three different data packet formats for its three
modes of operation...
Also, there is nothing in the data packets (at least for the AHRS unit)
which indicates *WHICH* data packet is being sent... this implies that the
receiving system already knows what to expect (by either direct data
request or initialization of the device).
Steve
http://www.tzogon.com/~steve/stolch801
*NEW* http://www.tzogon.com/~steve/glass_cockpit *NEW*
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit xbow data packets |
Also, there is nothing in the data packets (at least for the AHRS unit)
which indicates *WHICH* data packet is being sent... this implies that the
receiving system already knows what to expect (by either direct data
request or initialization of the device).
Yeah, I'm curious about that, too. It would be nice if we could see a
manual, but the salesman I talked to wasn't too helpful in that arena. I
even asked about it and either he didn't know anything about it, or wasn't
inclined to let me have one.
-Matt
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit xbow data packets |
>>Also, there is nothing in the data packets (at least for the AHRS unit)
>>which indicates *WHICH* data packet is being sent... this implies that
>>the receiving system already knows what to expect (by either direct
>>data request or initialization of the device).
>
>Yeah, I'm curious about that, too. It would be nice if we could see a
>manual, but the salesman I talked to wasn't too helpful in that arena. I
>even asked about it and either he didn't know anything about it, or
>wasn't inclined to let me have one.
This leads me to believe that it *MAY* be a direct response situation... I
would presume that the single byte header would be followed by a record
type ID or something otherwise, but that is not the case.
I will see about getting more data and sharing it with the group (via the
web page)...
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
Steve
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Matt & Steve,
Have a look at:
http://www.microsensors.com/
http://www.sigem.ca/ (OEM GPS receivers)
http://www.thomasregister.com/olc/bei/bei6.htm (scroll down and look at
"MOTION PAK")
http://www.base-usa.com/sensor/vsg.htm (the guts of the Watson box?)
http://www.precisionnavigation.com/index3.html (electronic compass modules)
-----Original Message-----
All,
Well, after determining that Watson Industry's $10,000 AHRS sensor was too
expensive, I took their salesman's advice and called one of their
competitors, Crossbow.
Crossbow has an AHRS unit that sells for $6500. They also have a VGX unit
that is essentially the same thing minus heading for $4000.
These prices are still expensive, but starting to seem more reasonable for a
glass cockpit for a homebuilt aircraft.
Crossbow does not publish the same list of specifications that Watson
publishes on their web site. In fact, there's very little information there
and the salesman I spoke to did not offer any additional information.
(Whaddaya expect when ya tell the guy you're a hobbyist?)
So, check out Crossbow's site at http://www.xbow.com/html/product.htm and
let's start this brainstorming all over again.
Questions:
-what specifications do we need to set for an instrument that will measure
roll, pitch, and heading? I don't know that either of these units is
appropriate for our needs, and that begs the question: what exactly ARE our
needs?
-do we need heading in this sensor, or could we build a separate heading
sensor for less than the $1500 price difference between these two products?
This message cross-posted to Crossbow's sales email address. Let's see if
they have any input for us! (Crossbow: archives of this thread can be found
at
http://www.matronics.com/archive/archive-get.cgi?Avionics-Archive.digest.vol
-aa. Private emails were sent that are not in the archive.)
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
Jeff,
Thanks for the links!
I just got off the phone with Peter at Sigem (http://www.sigem.ca). Their
GPS products are VERY affordable. The entire receiver unit (12 sattelites!)
costs about $135 in small quantities. The wiring diagram is a builder's
dream! Coax connector for antenna is soldered on the board. Then there's a
10 pin header for power and data, and the data is already formatted in NMEA
0183 format.
Peter also mentioned that there is a firmware update in the works for WAAS
interface that requires no additional hardware. As I understand it, WAAS is
ground-transmitted correction information to correct for selective
availability. I like the "no additional hardware" part!
I'm really liking this company. Peter was very friendly and helpful even
though I told him I was a hobbyist buying in onesies. They have a eval kit
for $299 that includes additional hardware for interfacing with a host PC.
-Matt
________________________________________________________________________________
| From: | "Chris Atkinson" <chris-atkinson(at)home.com> |
Hi Matt, carrying on from our thread from the zenith list, here're some
points regarding my own "glass cockpit" project. ...any thoughts or
suggestions would be greatly appreciated.
I'm implementing in four phases: 1 Navigation, 2 basic flight, 3 situational
awareness and 4 attitude awareness. I'm presently working on software for
phase one and planning to order hardware in a month or so.
The whole system is intended for reducing workload and adding to safety for
VFR only. I am not planning to bet anyone's life on the system, so
"redundant" instruments will be onboard and internal system robustness will
not be super critical. These design parameters had a fundemental influence
on my implementation strategies as you'll see below.
The computer hardware will be a single re-packaged desktop style win/NT
computer. I went through the industrial computer/laptop/palmtop thought
process & circled back to this for the following reasons: Weight will not be
excessive if new equipment is used; Hardware is cheaper; Room for lot's of
serial ports; Availability of lot's of good moving map and other software
components; Acceptable performance; Acceptable reliability for target
purpose.
I'm using the uEncoder and uMonitor from Rocky Mountain as two of my main
data sources. I considered integrating my own a/d streams directly into the
computer, but this seemed to expand the project scope immensely...mostly cuz
of the time needed to locate & pick good sensors and then implement good
calibration software. The uMonitor has some sort of parallel interface, but
I am leaving this one alone for a while...the uMonitor has a good visual
interface, so I am just going to let it handle the engine monitoring by
itself for the time being.
I'm using the Garmin III+ for gps input. I have used one stand-alone for a
while now and it seems to have better than average ability to track and
lock. Data interface is very well documented and reasonably easy to
understand. I have an ActiveX control almost done that encapsulates all the
ugly low and mid-level protocols. The garmin will be mounted in a visible
location for backup puposes.
Phase 2, basic flight info, uses the output of the uEncoder and the GPS
track & speed info. I have prototyped some transparent activex controls
that should make for some interesting super-imposed visuals on the MFD. It
will look a lot like a head-up display except a map will be in the
background.
Speaking of the MFD, check out www.flat-panel.com. I'm planning to use a
touch screen with 500 nit brightness. I have read that 200 nit is
considered daylight readable and 500 nit is considered sunlight readable.
They also have 1200 nit units, but they are pricey. I am still wondering
what the real definition of nit is.
Phase 3 (situational awareness) is loosely defined at the moment. But it
will include some form of the following: A glideslope indicator based on GPS
position, airport elevation and altitude from the uEncoder; A database of
"ideal" circuit tracks; A home-made database of aerodrome info; Internet
access to weather info. ...the latter will only be usable on the ground due
to transmitter-in-the-air regs, unfortunately. But it will still be useful
to download metars & images prior to departure.
Phase 4 (attitude awareness) is a can-o-worms. I looked into the watson-like
boxes and solid state gyros like you guys did and found them to be either
more than I want to spend or not stable enough. The Auto-PC is supposedly
about to become popular this winter...so hopefully it will push the cost of
the stabler solid state gyros down some more. I think the problems can be
overcome by using two or more gyros for each axis and canceling out the
error.
One product I have not checked into well enough is the "gyromouse". You can
read about it at
http://web-e7.zdnet.com/products/stories/reviews/0,4161,150403,00.html if
you want. At $100, it would be an amusing experiment at least.
I'm also going to look into a cheap accelerometer that I saw on a "speed
vision" show the other day...again as an error correction source. The
accelerometer will also enable a g-meter, which would be good to have and
also enable some sort of stall warning calculation.
One thing I have determined is that the only instrument that's hard to do
via inference is the attitude indicator. The function of the directional
gyro is easily replaced with GPS heading. The turn coordinator is easy to
do with a little simple arithmetic on the rate of change of heading and a
digital inclinometer. The latter part being made from a dead mouse and a
magnetically damped pendulum.
...maybe we should try a using dead cat for the attitude indicator. It
won't work, but at least there'll be one less cat. ;-)
Chris
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
Barlow
Sent: Thursday, November 11, 1999 11:55 AM
Subject: RE: Avionics-List: Glass cockpit
Matt & Steve,
Have a look at:
http://www.microsensors.com/
http://www.sigem.ca/ (OEM GPS receivers)
http://www.thomasregister.com/olc/bei/bei6.htm (scroll down and look at
"MOTION PAK")
http://www.base-usa.com/sensor/vsg.htm (the guts of the Watson box?)
http://www.precisionnavigation.com/index3.html (electronic compass modules)
-----Original Message-----
All,
Well, after determining that Watson Industry's $10,000 AHRS sensor was too
expensive, I took their salesman's advice and called one of their
competitors, Crossbow.
Crossbow has an AHRS unit that sells for $6500. They also have a VGX unit
that is essentially the same thing minus heading for $4000.
These prices are still expensive, but starting to seem more reasonable for a
glass cockpit for a homebuilt aircraft.
Crossbow does not publish the same list of specifications that Watson
publishes on their web site. In fact, there's very little information there
and the salesman I spoke to did not offer any additional information.
(Whaddaya expect when ya tell the guy you're a hobbyist?)
So, check out Crossbow's site at http://www.xbow.com/html/product.htm and
let's start this brainstorming all over again.
Questions:
-what specifications do we need to set for an instrument that will measure
roll, pitch, and heading? I don't know that either of these units is
appropriate for our needs, and that begs the question: what exactly ARE our
needs?
-do we need heading in this sensor, or could we build a separate heading
sensor for less than the $1500 price difference between these two products?
This message cross-posted to Crossbow's sales email address. Let's see if
they have any input for us! (Crossbow: archives of this thread can be found
at
http://www.matronics.com/archive/archive-get.cgi?Avionics-Archive.digest.vol
-aa. Private emails were sent that are not in the archive.)
-Matt
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit xbow data packets |
On Thu, 11 Nov 1999, Steven J. Devine wrote:
> Also, there is nothing in the data packets (at least for the AHRS unit)
> which indicates *WHICH* data packet is being sent... this implies that the
> receiving system already knows what to expect (by either direct data
> request or initialization of the device).
All of this gets into the concept of the cockpit data buss. I have news
for you; having lots of incompatible devices all using their own protocols
to talk to some central device using 8-bit async data at 9600 bps, loses.
The big guys use a common data buss for everything. If one is going to
start from scratch, one can come up with a data buss specification and a
set of messages. ARINC has buss specifications and message specifications
too. I strongly recommend that you go look at that stuff. If you conform
to the ARINC specs, you will be (theoretically) interoperable with other
"standard" devices.
How about a list of data sources and data sinks.
Sources:
AHRS
air data computer (IAS, palt, mag hdg)
GPS nav sensor
LORAN nav sensor
DGPS receiver
VOR nav sensor
DME nav sensor
LOC nav sensor
GS nav sensor
engine data collection sensor
general purpose CPU module (gpu)
Sinks:
general purpose CPU
display system (may be part of gpu)
nav sensors (frequency selection, etc)
So you define the system components, protocols, and messages, and then
start talking about building something. I have seen too many one-off
systems with no thought given to communications protocols so there is no
way to make all the components interoperate as a system.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | glass cockpit requirements |
Ah, it's the wish list. My comments are marked "+++" below.
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
Mucker
Sent: Wednesday, November 10, 1999 2:40 PM
Subject: Avionics-List: glass cockpit requirements
Okay: the first stage of building a product is defining the requirements,
right?
+++ Sounds right to me.
Here are my ideas for the requirements of our glass cockpit. These are my
"ideals" with no consideration as to the practicality of any of the ideas.
Send further ideas to me and I'll add 'em to our "dream cockpit machine".
- have 3 displays: one for flight instruments, one for engine instruments,
and one for moving map and other displays (such as data entry, probably).
+++ How about 1 to n identical displays, each of which can do all of the
above. This is what Sierra has done. Obvious redundancy benefits if done
right.
- replace the following flight instruments: airspeed indicator, artificial
horizon, altimeter, turn and bank indicator, directional gyroscope, vertical
speed indicator, and magnetic compass. (In order to do this, the instrument
will need both a magnetic compass unit and a heading gyro, and we can
'slave' the gyro to the magnetic compass through software.)
+++ This will be the fun part.
- replace the following engine instruments: tachometer, oil temperature and
pressure, manifold pressure, CHT and EGT, fuel pressure, fuel flow, fuel
quantity guages (3 of 'em)
+++ I'm also looking at doing electronic engine control (fuel injection and
ignition). Of course I would want it to talk to the engine display. I want
to be able control engine/drive parameters (mixture, timing, turbo boost,
prop pitch, etc.) from the engine display user interface. Also, don't forget
water temp for all us auto engine conversion folks.
- replace the following miscellaneous instruments: voltmeter, ammeter, OAT,
G meter... and anything else I can think of.
+++ Another way to put this is that we want a flexible, modular architecture
that can accept an arbitrary number of analog or digital inputs and display
them in a manner that is unique to each installation. In addition I would
like each display module to implement a generalized two way user interface.
As an example, we could control electric trim servos from the flight
instrument display.
- contain an integral GPS receiver and be capable of moving map display
+++ Someone will need to look into where we get the map data. The topo stuff
we can get from USGS and/or NOAA. I don't know how we get Jeppesen to sell
us the sectional chart stuff, though.
- provide an interface to NAV radios so the display could be used instead of
an omnihead.
+++ Also it would be nice to extract the Comm & Nav radio frequencies from
the Jeppesen data base and automagicaly stuff them into the radios like
Garmin does on their Nav/Comm/GPS units. Technically easy, but there may be
legal obstacles to modifying the radios.
- be software upgradeable in the aircaft. (Probably a PCMCIA slot, but
floppy and CD-ROM are possibilities as well.)
+++ I agree, but this could be a major can of worms. I want to avoid any
form of rotating memory. Also, one of the corollaries of Murphy's law says
"any memory that can be erased, will be erased at the worst possible time".
For example, I have seen EEPROM (Flash) scrambled by power glitches.
- act as a flight data recorder and cockpit voice recorder. Supply a
program that will run on an IBM-PC computer to do playback of recorded
flight and voice data.
- have an interface for in-flight weather and traffic data for any
information systems that might exist. (I know of none.) Draw these items
on the moving map.
- have an interface for lightning detection systems. Draw these items on
the moving map.
- have an interface for a radar altimeter
+++ All this "have an interface" stuff is, I think, subsumed by my
"flexible, modular architecture" comment, above. That is, we need to have a
generalized way to add all kinds of interfaces that we haven't thought of
yet.
-provide audible and visual alerts for alarm conditions. Use voice
recordings for the aural warnings.
- be affordable to the homebuilder. (How do we define affordable?)
+++ Ok, I'm going to harp on the "flexible, modular architecture" theme
again. If we do it right, someone could build as much or as little of the
system as they can afford.
- the goal of the project is to build a prototype of such a unit, test it
and become satisfied with its operation, and provide full disclosure to any
interested party that will allow them to build an identical unit from the
disclosed information. All software used to power the unit, including
source code, is included in the disclosure.
+++ I fully agree. Follow the GNU/Linix model.
All of these can be clarified and defined in more detail, but that would be
one helluva cockpit!
Really, most of this stuff is really not as hard to do as it sounds.
+++ Well... I agree that each of the goals set out above is reachable by a
small, dedicated band of crazies (such as ourselves ). But please keep in
mind that getting the whole thing done will be one hell of a lot of work.
-Matt
+++Jeff
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
On Wed, 10 Nov 1999, Robert Day wrote:
> Forgive the ignorance, but what is involved with a slaved DG? What type of
> mag compass has an output? Is the cost huge?
It isn't just a special compass. You need a whole system that includes a
compass (usually a flux-gate compass), a slaving amp, a slaved DG, and an
indicator. The latter two are sometimes in the same box. Remote
compasses can be had cheaply (relatively) but slaved DGs tend to be
expensive.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
Well Chris, I wish you luck. I think you are going to need it. I predict you
will be disappointed with the reliability of your system. I've been
designing this stuff most of my life and there's a huge difference between
avionics and a PC. I don't mean to belittle your efforts, just save you from
some frustration and disappointment. I hope I don't come off as too
arrogant, but I've learned a lot of this stuff the hard way. If you think
I'm just some old fart who's trying to rain on your parade, feel free to
ignore me. If you want to hear the reasons behind my opinions, feel free to
ask.
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
Atkinson
Sent: Thursday, November 11, 1999 10:21 AM
Subject: RE: Avionics-List: Glass cockpit
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass cockpit xbow data packets |
I couldn't agree more. Please see my "flexible, modular architecture"
rantings in my message: "RE: Avionics-List: glass cockpit requirements".
I was thinking of using the CAN buss for this but I'll go refresh my memory
re ARINC. CAN is just a buss spec and so we would still need a message
protocol anyway. I'll ponder this and report back.
This area (interprocessor communication, etc.) is one I have more or less
specialized in for much of my career. As such it's probably where I have the
most to contribute to the cause.
-----Original Message-----
All of this gets into the concept of the cockpit data buss. I have news
for you; having lots of incompatible devices all using their own protocols
to talk to some central device using 8-bit async data at 9600 bps, loses.
The big guys use a common data buss for everything. If one is going to
start from scratch, one can come up with a data buss specification and a
set of messages. ARINC has buss specifications and message specifications
too. I strongly recommend that you go look at that stuff. If you conform
to the ARINC specs, you will be (theoretically) interoperable with other
"standard" devices.
How about a list of data sources and data sinks.
Sources:
AHRS
air data computer (IAS, palt, mag hdg)
GPS nav sensor
LORAN nav sensor
DGPS receiver
VOR nav sensor
DME nav sensor
LOC nav sensor
GS nav sensor
engine data collection sensor
general purpose CPU module (gpu)
Sinks:
general purpose CPU
display system (may be part of gpu)
nav sensors (frequency selection, etc)
So you define the system components, protocols, and messages, and then
start talking about building something. I have seen too many one-off
systems with no thought given to communications protocols so there is no
way to make all the components interoperate as a system.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | glass cockpit requirements |
All this "modular and extensible" stuff is all good and well.
BUT...
...making a system that is so extensible that you can plug in any sensor you
want and have it automagically show up on the display is not trivial.
...defining a 'data buss' standard takes quite a bit of forethought and
would add to the expense, IMO. Each sensor would have to be connected to a
small computer which could translate its information into the buss standard,
and then transmit that information on the buss. On the other hand, it
certainly does have it's good points. (RS485 is starting to sound good!
Its multidrop and cheap!)
====
+++ How about 1 to n identical displays, each of which can do all of the
above. This is what Sierra has done. Obvious redundancy benefits if done
right.
Yeah, I like this idea. I guess I hadn't articulated it, but that was my
vision as well.
- replace the following flight instruments: airspeed indicator, artificial
horizon, altimeter, turn and bank indicator, directional gyroscope, vertical
speed indicator, and magnetic compass. (In order to do this, the instrument
will need both a magnetic compass unit and a heading gyro, and we can
'slave' the gyro to the magnetic compass through software.)
+++ This will be the fun part.
Yup!
- replace the following engine instruments: tachometer, oil temperature and
pressure, manifold pressure, CHT and EGT, fuel pressure, fuel flow, fuel
quantity guages (3 of 'em)
+++ I'm also looking at doing electronic engine control (fuel injection and
ignition). Of course I would want it to talk to the engine display. I want
to be able control engine/drive parameters (mixture, timing, turbo boost,
prop pitch, etc.) from the engine display user interface. Also, don't forget
water temp for all us auto engine conversion folks.
+++ Another way to put this is that we want a flexible, modular architecture
that can accept an arbitrary number of analog or digital inputs and display
them in a manner that is unique to each installation. In addition I would
like each display module to implement a generalized two way user interface.
As an example, we could control electric trim servos from the flight
instrument display.
- contain an integral GPS receiver and be capable of moving map display
+++ Someone will need to look into where we get the map data. The topo stuff
we can get from USGS and/or NOAA. I don't know how we get Jeppesen to sell
us the sectional chart stuff, though.
Answer: MONEY!
- be software upgradeable in the aircaft. (Probably a PCMCIA slot, but
floppy and CD-ROM are possibilities as well.)
+++ I agree, but this could be a major can of worms. I want to avoid any
form of rotating memory. Also, one of the corollaries of Murphy's law says
"any memory that can be erased, will be erased at the worst possible time".
For example, I have seen EEPROM (Flash) scrambled by power glitches.
Good counterpoint. But there's GOT to be a way to update the software...
+++ All this "have an interface" stuff is, I think, subsumed by my
"flexible, modular architecture" comment, above. That is, we need to have a
generalized way to add all kinds of interfaces that we haven't thought of
yet.
+++ Ok, I'm going to harp on the "flexible, modular architecture" theme
again. If we do it right, someone could build as much or as little of the
system as they can afford.
===
Much of this also ties into the platform we choose. Windows CE, NT, or
95/98 all would make development quite easy. AND, there are embedded
versions (!) of these operating systems that could be put on a PC/104
computer (I think). However, you can't go down to the local Computer Hut
and buy a copy of embedded NT.
On the other hand, a robust operating system such as Windows would make for
easier integration and modular functionality. We could design a sensor
along with a program that reads the data and converts it to useful
information, and then ship that with an ActiveX control that does the
display work. If we choose that kind of path, then additional gauges could
be added with comparative ease-- just have a 'screen designer' mode where
the user selects which gauges s/he wants on a display, and their locations
and sizes, and ActiveX does the rest. In theory. Also, ActiveX controls
can be written in a variety of languages.
Downside: cost, most likely. Unavailability of embedded versions of these
operating systems.
Let the debate begin!
-Matt
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | glass cockpit requirements |
Hum, this time I guess I'll use "***" for my comments.
-----Original Message-----
Subject: RE: Avionics-List: glass cockpit requirements
All this "modular and extensible" stuff is all good and well.
BUT...
...making a system that is so extensible that you can plug in any sensor you
want and have it automagically show up on the display is not trivial.
*** First, I never said anything was going to be trivial. Second, I
wasn't thinking in terms of anything that automagic. A new device on the
buss would still require new code to be written to talk to it. I'm just
trying to keep us from painting ourselves into a corner. Been there, done
that, no fun at all.
...defining a 'data buss' standard takes quite a bit of forethought and
would add to the expense, IMO. Each sensor would have to be connected to a
small computer which could translate its information into the buss standard,
and then transmit that information on the buss. On the other hand, it
certainly does have it's good points. (RS485 is starting to sound good!
Its multidrop and cheap!)
*** We needn't start from scratch here. There are good designs out there
that we can steal. Besides, that's the part I'm really good at. See the
message "Re: Avionics-List: Glass cockpit xbow data packets" from Brian
Lloyd and my reply to it
====
+++ How about 1 to n identical displays, each of which can do all of the
above. This is what Sierra has done. Obvious redundancy benefits if done
right.
Yeah, I like this idea. I guess I hadn't articulated it, but that was my
vision as well.
*** Thought so, just making sure.
- replace the following flight instruments: airspeed indicator, artificial
horizon, altimeter, turn and bank indicator, directional gyroscope, vertical
speed indicator, and magnetic compass. (In order to do this, the instrument
will need both a magnetic compass unit and a heading gyro, and we can
'slave' the gyro to the magnetic compass through software.)
+++ This will be the fun part.
Yup!
*** OBTW, I want to try to do an angle of attack display too.
- be software upgradeable in the aircaft. (Probably a PCMCIA slot, but
floppy and CD-ROM are possibilities as well.)
+++ I agree, but this could be a major can of worms. I want to avoid any
form of rotating memory. Also, one of the corollaries of Murphy's law says
"any memory that can be erased, will be erased at the worst possible time".
For example, I have seen EEPROM (Flash) scrambled by power glitches.
Good counterpoint. But there's GOT to be a way to update the software...
*** Of course! There are, however, different sorts of software. When was the
last time you reprogrammed the BIOS chip in your PC? (I've actually had to
do it a few times, but that's another story) My point is that there are some
parts of the code in the system that SHOULD be hard to change. I'm talking
about the flight test stage here. An early prototype on the bench is a
different story. On the other hand, loading new map data from a PCMCIA slot
or some such is an obvious requirement.
+++ All this "have an interface" stuff is, I think, subsumed by my
"flexible, modular architecture" comment, above. That is, we need to have a
generalized way to add all kinds of interfaces that we haven't thought of
yet.
+++ Ok, I'm going to harp on the "flexible, modular architecture" theme
again. If we do it right, someone could build as much or as little of the
system as they can afford.
===
Much of this also ties into the platform we choose. Windows CE, NT, or
95/98 all would make development quite easy. AND, there are embedded
versions (!) of these operating systems that could be put on a PC/104
computer (I think). However, you can't go down to the local Computer Hut
and buy a copy of embedded NT.
*** I can see you've never tried to write a Windows device driver. Trust me,
there are a lot of words that could be used to describe the process. "Easy"
is not one of them.
On the other hand, a robust operating system such as Windows would make for
easier integration and modular functionality. We could design a sensor
along with a program that reads the data and converts it to useful
information, and then ship that with an ActiveX control that does the
display work. If we choose that kind of path, then additional gauges could
be added with comparative ease-- just have a 'screen designer' mode where
the user selects which gauges s/he wants on a display, and their locations
and sizes, and ActiveX does the rest. In theory. Also, ActiveX controls
can be written in a variety of languages.
Downside: cost, most likely. Unavailability of embedded versions of these
operating systems.
*** I can't believe you just said "robust operating system such as Windows".
There is no way in hell that I would fly in anything that depended on
Windows not crashing to stay in the air! Was that emphatic enough?
*** There, I feel better now. Please don't scare me like that again. When I
have more time I can write a long essay on why Windows (yes, even NT) is
totally unsuitable for real time embedded process control applications.
*** Lest you think I'm some anti-Microsoft pro-Linix fanatic, I'm using Win
2000 RC2 and MS Outlook to send this message. I expect to use Win2k as my
development platform and even for testing prototype code. Just don't ask me
to fly it.
Let the debate begin!
*** It would seem to have done so
-Matt
*** Jeff
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | glass cockpit requirements |
Matthew & All,
I think we need to clarify the difference between the numerous simple
analog signals we will be dealing with from the more complex devices. Many
signals like temps & pressures, will be arriving as voltages to, I assume,
an AD board mounted on some form of motherboard. Making these show up in a
GUI would be I think easy, depending on what software your using.
This gets me to Software Development Environments. Just like with the
hardware interfaces, software will make or break a project of this
complexity. Pick the right software architecture and development enviroment
and you go a long way towards your goal. I have quite alot of software
experience with component based programing using object oriented code, but
none with small imbedded computers. What OOP software development systems
are available for this type of work? I would think ADA, Obj Pascal, C++,
FORTRAN 90 all would be appropriate languages for developing the basic
software. I think though that an efficient GUI Builder would be almost a
neccessity as well. Are there any software development packages of this
type which can be used to create robust imbedded software? Before we
proceed very far we need to address the "Software development Environment"
issue. Anyone have any favorites. I like Delphi myself. but I believe that
would limit us to MS Windows/NT and I don't know if that would be stable
enough?
Sensitive analog pressure transducers plugged into an AD board are all
that is needed to replace the airspeed, rate of climb, altimeter & AOA
instruments. Analog temperature and other sensors will work for most of the
other simple instruments. I think a turn and bank sensor would also be
classified as a simple instrument and could be implemented with a simple SS
rate gyro as mentioned in an earlier posting. All of these sensors would be
plugged into a AD Board (most if not all would be simple analog signals )
for processing and display.
Complex interfaces have already been addressed. As pointed out they
usually have there own communication protocals already defined.
A pre-engineered package from a company like Crossbow may be the best
route for the more complex aircraft attitude and directional sensors.
-----Original Message-----
Sent: Thursday, November 11, 1999 3:06 PM
Subject: RE: Avionics-List: glass cockpit requirements
All this "modular and extensible" stuff is all good and well.
BUT...
...making a system that is so extensible that you can plug in any sensor you
want and have it automagically show up on the display is not trivial.
...defining a 'data buss' standard takes quite a bit of forethought and
would add to the expense, IMO. Each sensor would have to be connected to a
small computer which could translate its information into the buss standard,
and then transmit that information on the buss. On the other hand, it
certainly does have it's good points. (RS485 is starting to sound good!
Its multidrop and cheap!)
====
+++ How about 1 to n identical displays, each of which can do all of the
above. This is what Sierra has done. Obvious redundancy benefits if done
right.
Yeah, I like this idea. I guess I hadn't articulated it, but that was my
vision as well.
- replace the following flight instruments: airspeed indicator, artificial
horizon, altimeter, turn and bank indicator, directional gyroscope, vertical
speed indicator, and magnetic compass. (In order to do this, the instrument
will need both a magnetic compass unit and a heading gyro, and we can
'slave' the gyro to the magnetic compass through software.)
+++ This will be the fun part.
Yup!
- replace the following engine instruments: tachometer, oil temperature and
pressure, manifold pressure, CHT and EGT, fuel pressure, fuel flow, fuel
quantity guages (3 of 'em)
+++ I'm also looking at doing electronic engine control (fuel injection and
ignition). Of course I would want it to talk to the engine display. I want
to be able control engine/drive parameters (mixture, timing, turbo boost,
prop pitch, etc.) from the engine display user interface. Also, don't forget
water temp for all us auto engine conversion folks.
+++ Another way to put this is that we want a flexible, modular architecture
that can accept an arbitrary number of analog or digital inputs and display
them in a manner that is unique to each installation. In addition I would
like each display module to implement a generalized two way user interface.
As an example, we could control electric trim servos from the flight
instrument display.
- contain an integral GPS receiver and be capable of moving map display
+++ Someone will need to look into where we get the map data. The topo stuff
we can get from USGS and/or NOAA. I don't know how we get Jeppesen to sell
us the sectional chart stuff, though.
Answer: MONEY!
- be software upgradeable in the aircaft. (Probably a PCMCIA slot, but
floppy and CD-ROM are possibilities as well.)
+++ I agree, but this could be a major can of worms. I want to avoid any
form of rotating memory. Also, one of the corollaries of Murphy's law says
"any memory that can be erased, will be erased at the worst possible time".
For example, I have seen EEPROM (Flash) scrambled by power glitches.
Good counterpoint. But there's GOT to be a way to update the software...
+++ All this "have an interface" stuff is, I think, subsumed by my
"flexible, modular architecture" comment, above. That is, we need to have a
generalized way to add all kinds of interfaces that we haven't thought of
yet.
+++ Ok, I'm going to harp on the "flexible, modular architecture" theme
again. If we do it right, someone could build as much or as little of the
system as they can afford.
===
Much of this also ties into the platform we choose. Windows CE, NT, or
95/98 all would make development quite easy. AND, there are embedded
versions (!) of these operating systems that could be put on a PC/104
computer (I think). However, you can't go down to the local Computer Hut
and buy a copy of embedded NT.
On the other hand, a robust operating system such as Windows would make for
easier integration and modular functionality. We could design a sensor
along with a program that reads the data and converts it to useful
information, and then ship that with an ActiveX control that does the
display work. If we choose that kind of path, then additional gauges could
be added with comparative ease-- just have a 'screen designer' mode where
the user selects which gauges s/he wants on a display, and their locations
and sizes, and ActiveX does the rest. In theory. Also, ActiveX controls
can be written in a variety of languages.
Downside: cost, most likely. Unavailability of embedded versions of these
operating systems.
Let the debate begin!
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | glass cockpit requirements |
*** I can't believe you just said "robust operating system such as Windows".
There is no way in hell that I would fly in anything that depended on
Windows not crashing to stay in the air! Was that emphatic enough?
*** There, I feel better now. Please don't scare me like that again. When I
have more time I can write a long essay on why Windows (yes, even NT) is
totally unsuitable for real time embedded process control applications.
*** Lest you think I'm some anti-Microsoft pro-Linix fanatic, I'm using Win
2000 RC2 and MS Outlook to send this message. I expect to use Win2k as my
development platform and even for testing prototype code. Just don't ask me
to fly it.
I just gotta reply to those barbs...
First, Windows NT is a VERY reliable operating system. The VAST majority
(by an ENORMOUS margin) of problems with NT (blue screens in particular) are
caused by third party device drivers. Win 9x problems are almost always due
to the application, but I'm not about to stick my neck out for Win 9x. I
really think that either of these, or even Windows CE, could be used as the
OS for a cockpit display. (I wouldn't wanna do IFR with it, but that's just
cuz I don't trust myself to develop properly to make guarantees.)
By the way, you're not 'depending on Windows not crashing to stay in the
air.' You're depending on the pilot to keep you in the air!
Second, I don't see this application as a need for real time control. We
don't need fractions-of-a-second response time, as I see things.
I would like to hear your reasons for stating that NT is unsuitable.
Privately, if you'd prefer, or to the group. I happen to disagree. But as
long as we're on this topic, what operating system would you suggest for the
embedded computer?
-Matt
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass cockpit group introductions |
Matt, Steve, et al,
While so far this thing is still in the talking stage, it's starting to
sound like we might actually end up doing it. This brings to my mind
questions like who and where we all are.
As I've already mentioned I'm a more or less retired embedded systems
engineer/programmer. I say more or less because every so often an old
customer calls me up and talks me into a consulting job. Since about 1970
I've done digital (and a little lame analog) circuit design and written
about a zillion lines of C and various flavors of assembly code. The code
I've cranked out has tended to be the close to the hardware sort. (big
surprise, huh) Device drivers, com link drivers, the lower layers of
protocol stacks, multi-task execs, stuff like that. I've dabbled in circuit
board layout, and I solder pretty well. Your basic aging geek.
I live in the LA area. And, oddly enough, I'm thinking seriously about
building a CH-801. Could there be some sort of strange attraction of nerds
to Zenair?
Ok, who's next
Jeff
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit group introductions |
All right, my bio:
I'm a 27 year old support engineer working for Microsoft. Among other
things, I do determination of blue screens, hence my previous assertion that
NT is stable. (Yes, I am biased!)
I have no formal education in either hardware or software, but am
self-taught in digital electronics and have managed to avoid third degree
burns when using a soldering iron.
I'm constantly on the lookout for my next project, and this looks like a
winner. However, at the same time, I'm going to be building an airplane,
too.
I'm living in the Dallas, TX area.
-Matt
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | glass cockpit requirements |
On Thu, 11 Nov 1999, Matthew Mucker wrote:
> ...making a system that is so extensible that you can plug in any sensor you
> want and have it automagically show up on the display is not trivial.
I agree. At least you can eliminate the communications problems from the
matrix.
> ...defining a 'data buss' standard takes quite a bit of forethought and
> would add to the expense, IMO.
There are already standards out there. I like the idea of 10Mbps but
anything will probably do since the real data rates are pretty low.
> Each sensor would have to be connected to a
> small computer which could translate its information into the buss standard,
> and then transmit that information on the buss. On the other hand, it
> certainly does have it's good points. (RS485 is starting to sound good!
> Its multidrop and cheap!)
Right. I was assuming that a sensor would have the necessary
intelligence to speak the apprpriate protocol on the buss and that there
wouldn't be any protocol translation box. From that point of view the
AHRS module plus the control module that speaks the buss protocol would
be considered one module. With the data sources generating the
appropriate messages, any listener can pick out the info it wants to
process and then "do the right thing."
>
> ====
>
> +++ How about 1 to n identical displays, each of which can do all of the
> above. This is what Sierra has done. Obvious redundancy benefits if done
> right.
It makes sense. The idea is that any processor/display can select the
data it wants and then display it. For that matter, the
processor/display modules can cross check each other and then dynamically
display critical info should one of the displays fail. For example, I
have my primary flight info on display one and display one fails. Display
two then detects that display one is gone and modifies its display to
bring up your critical primary flight info (attitude, heading, airspeed,
etc.)
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | glass cockpit requirements |
On Thu, 11 Nov 1999, Matthew Mucker wrote:
>
> *** I can't believe you just said "robust operating system such as Windows".
> There is no way in hell that I would fly in anything that depended on
> Windows not crashing to stay in the air! Was that emphatic enough?
We still see NT's BSOD almost weekly while our Sun Solaris servers have
uptimes measured in years. No, NT is not suitable for life-critical
applications such as flight management systems. Besides, either UNIX or
NT is overkill. A lightweight, real-time, preemptive, event-driven OS is
more suitable. We probably don't need complex memory management or a
file system.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit xbow data packets |
On Thu, 11 Nov 1999, Jeff Barlow wrote:
> I was thinking of using the CAN buss for this but I'll go refresh my memory
> re ARINC. CAN is just a buss spec and so we would still need a message
> protocol anyway. I'll ponder this and report back.
ARINC specifies both the buss electrical specs and the message formats.
They may be ugly but they have the greatest chance of acceptance by mfgrs
and the FAA. You also might be able to just plug in existing hardware
and have it work. All these seem advantages to me.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | glass cockpit requirements |
Hi Brian,
You get NT to stay up for a whole week, huh. I'm impressed. BTW, that was me
you were quoting not Matt. (The odd way I replied to him made it hard to
tell, I'm sure) We don't want to get Matt in trouble with his boss. He works
for Mr. Bill. I don't think he wants to hear this stuff, too disillusioning.
He needs to learn not to take his job so seriously.
But seriously folks...
To your comment: "Besides, either UNIX or NT is overkill. A lightweight,
real-time, preemptive, event-driven OS is more suitable. We probably don't
need complex memory management or a file system." I can only say amen. We
seem to be on the same page here.
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
Lloyd
Sent: Thursday, November 11, 1999 2:58 PM
Subject: RE: Avionics-List: glass cockpit requirements
On Thu, 11 Nov 1999, Matthew Mucker wrote:
>
> *** I can't believe you just said "robust operating system such as
Windows".
> There is no way in hell that I would fly in anything that depended on
> Windows not crashing to stay in the air! Was that emphatic enough?
We still see NT's BSOD almost weekly while our Sun Solaris servers have
uptimes measured in years. No, NT is not suitable for life-critical
applications such as flight management systems. Besides, either UNIX or
NT is overkill. A lightweight, real-time, preemptive, event-driven OS is
more suitable. We probably don't need complex memory management or a
file system.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | glass cockpit requirements |
On Thu, 11 Nov 1999, Jeff Barlow wrote:
>
> You get NT to stay up for a whole week, huh. I'm impressed.
We is eggspurts.
> BTW, that was me
> you were quoting not Matt. (The odd way I replied to him made it hard to
> tell, I'm sure) We don't want to get Matt in trouble with his boss. He works
> for Mr. Bill.
Ohhhh Noooooo!
> To your comment: "Besides, either UNIX or NT is overkill. A lightweight,
> real-time, preemptive, event-driven OS is more suitable. We probably don't
> need complex memory management or a file system." I can only say amen. We
> seem to be on the same page here.
Good, because paging is expensive.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | glass cockpit requirements |
ROTFL
Would you care to reply to my message: "Avionics-List: Glass cockpit group
introductions" perhaps?
-----Original Message-----
On Thu, 11 Nov 1999, Jeff Barlow wrote:
>
> You get NT to stay up for a whole week, huh. I'm impressed.
We is eggspurts.
> BTW, that was me
> you were quoting not Matt. (The odd way I replied to him made it hard to
> tell, I'm sure) We don't want to get Matt in trouble with his boss. He
works
> for Mr. Bill.
Ohhhh Noooooo!
> To your comment: "Besides, either UNIX or NT is overkill. A lightweight,
> real-time, preemptive, event-driven OS is more suitable. We probably
don't
> need complex memory management or a file system." I can only say amen. We
> seem to be on the same page here.
Good, because paging is expensive.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: glass cockpit requirements |
Arrrgghhh... I knew I was gonna take a ribbing for being a Microsoftie!
I'll bet lots of money that your NT blue screens are not caused by Microsoft
software. (Seriously, being 'on the inside' has shown me that NT can really
be very stable if you know what you're doing. Lots of device driver writers
don't. As far as I'm concerned, any antivirus program is a 'blue screen in
a box.')
On a more relevant note, I agree that such an extensive OS is probably
overkill. The upshot is that everyone is familiar with the development
tools.
So-- who's gonna choose the OS? I'm totally ignorant in this arena.
-Matt
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | glass cockpit requirements |
Sorry Matt, I'll stop picking on you now.
I'll pick on your employer instead. At the risk of wandering a bit off topic
I want to explore your statement: "I'll bet lots of money that your NT blue
screens are not caused by Microsoft software". I could almost agree if we
can insert the word "directly" before "caused". I would agree that most BSOD
are caused by errant driver code. I may even have written some of it. Yes, I
have been one of those ignorant device driver writers that you alluded to.
MS doesn't seem to get that it is shooting itself in the foot here. The DDK
comes with the sorriest excuse for documentation I have ever seen. And I've
seen a lot. A lot is left out and a lot is just plain wrong. MS seems to
view information about Windows internals as the big company secret. This
makes knowing what you're doing as device driver writer almost impossible.
And still the company line is "BSOD are caused by bad drivers". If they
really want to solve the problem, rather than just pass the buck, they must
do a much, much better job of documenting the driver/OS interface. End of
off topic rant. Ah, there, I feel much better now.
To get back to the topic at hand: What OS do we use? (It will help if you
picture a bald guy with a vaguely Asian accent here). Have patience my son,
we'll deal with that issue when the time comes. (I'm having way too much fun
here). But seriously folks... There are a whole bunch of little RTOS's out
there. A lot of them are even in the public domain. Many are portable. If
need be I'll dig out one of the ones I've written before and port it to our
chip of choice, whatever it turns out to be. These things aren't a big deal,
they don't have to do all that much. Remember, no disk, no complex memory
management.
First we have to settle on a system architecture and then a CPU chip choice
for each box. Lets let the requirements drive the design, not the other way
around. We're not trying to sell anything here.
-----Original Message-----
Arrrgghhh... I knew I was gonna take a ribbing for being a Microsoftie!
I'll bet lots of money that your NT blue screens are not caused by Microsoft
software. (Seriously, being 'on the inside' has shown me that NT can really
be very stable if you know what you're doing. Lots of device driver writers
don't. As far as I'm concerned, any antivirus program is a 'blue screen in
a box.')
On a more relevant note, I agree that such an extensive OS is probably
overkill. The upshot is that everyone is familiar with the development
tools.
So-- who's gonna choose the OS? I'm totally ignorant in this arena.
-Matt
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | glass cockpit requirements |
Oops, I was having so much fun I neglected to address your development tool
point. As I said about OSs, there are a lot of cross C compilers out there.
For about every chip you can name. Many are cheap ($200-ish) or free
(various GCC ports and others). They all run on a PC. Some want to run on
Linix but most have Windows ports.
If we write our code in a reasonable subset of ANSI C we can compile it
first with VC++ and test big chunks of it on our PCs and then recompile
later for the target hardware. I've done this sort of thing before and had
it work pretty well. Someone would, of course, have to take responsibility
for rounding up and distributing our common development tool set.
Err, did I just volunteer myself for something? Anyway, we aren't there yet.
-----Original Message-----
On a more relevant note, I agree that such an extensive OS is probably
overkill. The upshot is that everyone is familiar with the development
tools.
So-- who's gonna choose the OS? I'm totally ignorant in this arena.
-Matt
________________________________________________________________________________
| From: | "Robert Day" <robday(at)gte.net> |
| Subject: | Re: glass cockpit requirements |
Good opinions. But the best point in the entire message/reply/reply is this:
DO NOT FLY RELYING ON WINDOWS.
I, too, am a Windows user and sometime writer of code. I use many different
systems, most of which use one or another version of Windows. I see how this
OS behaves with various equipment, and would not fly using it. It will work
beautifully to develop software, though.
Just my thoughts,
Rob Day
________________________________________________________________________________
| From: | "Robert Day" <robday(at)gte.net> |
| Subject: | Re: Glass cockpit group introductions |
>
> Matt, Steve, et al,
>
> While so far this thing is still in the talking stage, it's starting to
> sound like we might actually end up doing it. This brings to my mind
> questions like who and where we all are.
>
> As I've already mentioned I'm a more or less retired embedded systems
> engineer/programmer. I say more or less because every so often an old
> customer calls me up and talks me into a consulting job. Since about 1970
> I've done digital (and a little lame analog) circuit design and written
> about a zillion lines of C and various flavors of assembly code. The code
> I've cranked out has tended to be the close to the hardware sort. (big
> surprise, huh) Device drivers, com link drivers, the lower layers of
> protocol stacks, multi-task execs, stuff like that. I've dabbled in
circuit
> board layout, and I solder pretty well. Your basic aging geek.
>
> I live in the LA area. And, oddly enough, I'm thinking seriously about
> building a CH-801. Could there be some sort of strange attraction of nerds
> to Zenair?
>
> Ok, who's next
>
> Jeff
>
>
Jeff-
LA like Louisiana, or like Los Angeles?
I'm up in Oxnard, getting ready to make a committment to actually starting a
CH601...
Rob Day
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit group introductions |
>While so far this thing is still in the talking stage, it's starting
>to sound like we might actually end up doing it. This brings to
>my mind questions like who and where we all are.
Consultant, primarily in the Client/server arena currently...
Based in Boston, MA area (Tewksbury, MA actually)
Windows based clients, typically NT or UNIX servers...
Experience with a variety of development tools and environments...
DOS, UNIX (Linux, Solaris), Windows (3.x, 9x, NT, etc al)...
Visual Basic, PowerBuilder, C/C++ on DOS, Windows, UNIX...
some assembly...
Steve
Steven J. Devine, President, Consultant
TZOGON Enterprises Incorporated
steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
OK, here's my spin on the debate... (trying to keep this short and
failing)
I am in full agreement with all of the folks who have said that NT, UNIX,
whatever is overkill. What we need is a simple OS which provides some of
the more basic services to our application, but allows us full control
over the system resources.
I am leaning towards either an embedded DOS system or one of the RTOS's...
we can program a standard VGA display in C with relatively little
difficulty. No need for some of these more fancy GUI tools.
The additional benefit is that we can get away with far less processing
power, memory requirements, bootup time, etc., if we eliminate the
operating system overhead. Again, most of the larger OS's mentioned
(Windows, Linux, etc) provide far greater services and utility than this
application requires, and that utility comes for a price...
As for having the system completely extensible, with one of the
standardized buses mentioned, that's a great idea, but as someone has
pointed out, we would need a translator for each sensor to interface to
this standard bus. That's essentially a dedicated microcontroller for
each device, and the necessary programming of each device...
That's all well and good for multi million dollar planes, but for the size
and complexity of our project, we may need to be satisfied with something
somewhat less extensible (and therefor simpler and less costly to
implement).
Steve
http://www.tzogon.com/~steve/stolch801
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit OS debate, bus standards, etc |
On Fri, 12 Nov 1999, Steven J. Devine wrote:
> I am in full agreement with all of the folks who have said that NT, UNIX,
> whatever is overkill. What we need is a simple OS which provides some of
> the more basic services to our application, but allows us full control
> over the system resources.
One OS that is worthy of consideration is Mach. It is a nice microkernel
with a Berkeley UNIX API wrapped around it. You can use it heavyweight
for development and then strip it down to the microkernel for the
run-time environment. The Gnu "herd" is based on Mach.
> I am leaning towards either an embedded DOS system or one of the RTOS's...
> we can program a standard VGA display in C with relatively little
> difficulty. No need for some of these more fancy GUI tools.
You will want widgets to implement the various displays. Also
point-and-click doesn't work in the cockpit.
> As for having the system completely extensible, with one of the
> standardized buses mentioned, that's a great idea, but as someone has
> pointed out, we would need a translator for each sensor to interface to
> this standard bus. That's essentially a dedicated microcontroller for
> each device, and the necessary programming of each device...
You are going to do that anyway so bite the bullet and accept it. This
is an area where you can cut corners now but it will bite you in the butt
later. Being a ble to define the messages that an engine monitor will
generate is nice because then anyone can build an engine monitor module
or a display module. The reason the Internet caught on is because we had
stardardized protocols and messages. Don't lose sight of that.
> That's all well and good for multi million dollar planes, but for the size
> and complexity of our project, we may need to be satisfied with something
> somewhat less extensible (and therefor simpler and less costly to
> implement).
You are talking penny wise and pound foolish. Intelligence is a PIC and
costs a few bucks. Now you have complete control over the message
formats on the busses.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass cockpit group introductions |
Hi, Rob
Oops, I forgot about LA being Louisiana too. I'm in beautiful downtown
Lawndale, LA county, CA, within spitting distance of the dreaded 405
freeway.
You, on the other hand, are up there where the air is clean and Camarillo
airport is nearby. Must be nice.
So, are you also a fellow computer geek?
Jeff
-----Original Message-----
Jeff-
LA like Louisiana, or like Los Angeles?
I'm up in Oxnard, getting ready to make a committment to actually starting a
CH601...
Rob Day
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass Cockpit Group Introductions |
All,
Aerospace design engineer working for the USAF at Wright Patterson AFB (30
yrs). Do software development (not imbedded) of design and analysis tools.
Alot of my work has delt with 2D and 3D graphics software development. Work
with FORTRAN, C/C++, Pascal, ADA, Modula... In the past 8 years have worked
primarily with windows/NT and Delphi. Can handle a solder gun and have
built numerous analog instruments using pressure, temperature and current,
sensors. Building a Tailwind W10.
John Livingston
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit OS & bus standards debate |
>One OS that is worthy of consideration is Mach. It is a nice
>microkernel with a Berkeley UNIX API wrapped around it. You
>can use it heavyweight for development and then strip it down
>to the microkernel for the run-time environment. The Gnu "herd"
>is based on Mach.
Is this available on and/or can this be burned onto a ROM/EPROM? (the
runtime kernel) can the development be done using something like gcc on
linux and then ported over? (or the DOS flavor of gcc?)
>> I am leaning towards either an embedded DOS system or one
>> of the RTOS's... we can program a standard VGA display in C
>> with relatively little difficulty. No need for some of these more
>> fancy GUI tools.
>
>You will want widgets to implement the various displays. Also
>point-and-click doesn't work in the cockpit.
Well, there are plenty of usable graphics libraries (object libraries,
function libraries, whatever suits the development environment) for just
about any platform, or a lean and mean custom library could be built with
just the required functionality...
That also brings in the next topic of dicussion, which is user interface
(to be covered in more detail later, in a separate e-mail)...
Food for thought... (NOT in order of preference)
* Point and click with a mouse or other pointing device may not work, but
touch screens might...
* A menu based system with a row of buttons along the sides of the
display may be in order.
* simple numeric keypad? most people can use these without looking...
and it could be context sensitive, so depending on display mode, it may be
arrows/page up/down etc., in one mode, and numeric in another...
>You are talking penny wise and pound foolish. Intelligence is a PIC
>and costs a few bucks. Now you have complete control over the
>message formats on the busses.
I am not familiar with the bus types that have been discussed... if an
inexpensive PIC can be interfaced to control/report on the sensors and/or
ADC's, and can also interface to one of these standard busses, then this
changes things a bit, and it makes sense to go that route.
However, if it turns out that these bus specs and/or the sensor interface
require more intelligence than a PIC can provide, then it will be a quite
expensive project, and I would sacrifice this expandability in favor of
having the results I want.
from a prior message...
>ARINC specifies both the buss electrical specs and the message
>formats. They may be ugly but they have the greatest chance of
>acceptance by mfgrs and the FAA. You also might be able to
>just plug in existing hardware and have it work. All these seem
>advantages to me.
We all have different priorities... "acceptance by mfgrs and the FAA" may
not be one of them for everybody, particularly if there is a large expense
or effort involved. We're talking about building a custom panel for our
experimentals, not a new cockpit system to sell to Boeing.
As for interfacing to these "standard" instruments Im sure they cost a
fortune (I wouldn't be surprised if some cost more than my entire plane),
so that may not be a real advantage.
Your mileage may vary.
Steve
http://www.tzogon.com/~steve/glass_cockpit (always updating this as more
information becomes available... I think I'm fighting a losing battle...
maybe catch up over the weekend? Grrr...)
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
All,
My comments and questions are prefaced by ///
-----Original Message-----
Sent: Friday, November 12, 1999 10:18 AM
Subject: Re: Avionics-List: Glass cockpit OS debate, bus standards, etc
...we can program a standard VGA display in C with relatively little
> difficulty. No need for some of these more fancy GUI tools....
You will want widgets to implement the various displays. Also
point-and-click doesn't work in the cockpit.
/// What would you all propose to use for doing the 2D and 3D graphics? Does
anyone have any graphics libraries in mind? I agree point and click doesn't
work in the cockpit, that should simplify things.
...
> As for having the system completely extensible, with one of the
> standardized buses mentioned, that's a great idea, but as someone has
> pointed out, we would need a translator for each sensor to interface to
> this standard bus. That's essentially a dedicated microcontroller for
> each device, and the necessary programming of each device...
You are going to do that anyway so bite the bullet and accept it. This
is an area where you can cut corners now but it will bite you in the butt
later. Being able to define the messages that an engine monitor will
generate is nice because then anyone can build an engine monitor module
or a display module. The reason the Internet caught on is because we had
stardardized protocols and messages. Don't lose sight of that....
/// I don't understand (I'm not saying you are wrong) the need for a cpu for
each and every signal. I will have 10-14 temperatures and pressures coming
off of my engine alone. Probably more than 20-30 overall for the entire
airplane. These are all simple amplified analog signals. What is wrong
with routing these numerous signals to one or more AD converters coupled to
a corresponding processor? Why do we need one processor per signal?
Wouldn't each of these "simple signal processors" be able to handle at least
8 to 16 signals? What am I missing? Again, this is not my field of
expertise and so need to be educated.
John
________________________________________________________________________________
| Subject: | Glass cockpit OS debate, bus standards, etc |
/// What would you all propose to use for doing the 2D and 3D graphics? Does
anyone have any graphics libraries in mind? I agree point and click doesn't
work in the cockpit, that should simplify things.
FYI. Collins is putting a mouse and control sticks in cockpits to add point and
click to ease operations.
As for Windows, Lunix and all others: have you ever seen DO-178? It is the software
spec the FAA requires to be met for critical information if you want TSO.
Requires a lot of documentation and testing.
Alan Kritzman
RV-8 builder and systems integration engineer for Collins. No, I don't get a discount.
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
Hi Brian,
I'd forgotten about Mach. Something like that might be a good fit for the
display boxes. Somewhat overkill for sensor boxes, though. (I trust it's
obvious to all that each type of box in the system may have a different CPU
and OS). You have any up to date URLs for me?
About as close as we could get to point and click would be a touch screen,
and I don't much care for even that. I think Sierra got that part just
right: Push buttons with soft labels and a couple of rotary encoders with
knobs on them, all on a big bezel that you can steady your hand on. Very
nice ergonomics.
You and I seem to be in complete agreement on the issue of system
architecture. I have a $29.95 toaster with a processor in it. We're not
talking big money here, if that's what's causing concern for some. I'd think
we're looking at maybe $20 worth of chips on a 2" square circuit board for
the little sensor boxes.
Your comment: "The reason the Internet caught on is because we had
standardized protocols and messages" hits the nail on the head. If we are
really going to develop this as a group project, with team members spread
all over the country, we will have to have a way to design and test each
part very carefully prior to any attempt at system integration. If we try to
do that with a dozen different ad hoc interfaces, we will just drive
ourselves nuts. I'm not up for that kind of pain.
BTW, are you (Brian) a hardware type at all? I'm hoping I'm not the only one
here.
Jeff
-----Original Message-----
One OS that is worthy of consideration is Mach. It is a nice microkernel
with a Berkeley UNIX API wrapped around it. You can use it heavyweight
for development and then strip it down to the microkernel for the
run-time environment. The Gnu "herd" is based on Mach.
You will want widgets to implement the various displays. Also
point-and-click doesn't work in the cockpit.
> As for having the system completely extensible, with one of the
> standardized buses mentioned, that's a great idea, but as someone has
> pointed out, we would need a translator for each sensor to interface to
> this standard bus. That's essentially a dedicated microcontroller for
> each device, and the necessary programming of each device...
You are going to do that anyway so bite the bullet and accept it. This
is an area where you can cut corners now but it will bite you in the butt
later. Being a ble to define the messages that an engine monitor will
generate is nice because then anyone can build an engine monitor module
or a display module. The reason the Internet caught on is because we had
stardardized protocols and messages. Don't lose sight of that.
> That's all well and good for multi million dollar planes, but for the size
> and complexity of our project, we may need to be satisfied with something
> somewhat less extensible (and therefor simpler and less costly to
> implement).
You are talking penny wise and pound foolish. Intelligence is a PIC and
costs a few bucks. Now you have complete control over the message
formats on the busses.
Brian Lloyd
brian(at)lloyd.com
+1.530.676.6513
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit OS & bus standards debate |
* Point and click with a mouse or other pointing device may not work, but
touch screens might...
It might... I'm concerned about fingerprints and glare. (Finger oil glare,
that is.) However, my experience with touch screens is that they are
reliable, and if the interface is designed for them (large hotspots, no
double-clicking, etc.) it could work well. Touchscreens are pricey,
however. (At least CRTs are. I have no experience with LCD touchscreens.)
* A menu based system with a row of buttons along the sides of the
display may be in order.
I agree here as well.
* simple numeric keypad? most people can use these without looking...
and it could be context sensitive, so depending on display mode, it may be
arrows/page up/down etc., in one mode, and numeric in another...
I agree here, too. While a full alphanumeric keyboard would find uses, it
would probably take too much room, and a small one would have keys too small
to use in turbulent flight.
In addition to the numeric keypad, a knob or wheelie-mouse type interface
for "up/down" information will probably be way useful as well.
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass Cockpit Group Introductions |
Brian Lloyd.
I work for Lucent Technologies as a result of multiple mergers and
acquisitions. My field of expertise is in designing routers, routing
protocols, link protocols, and internets in general. I used to hack code
but haven't for some time. I used to speak many programming languages but
the only ones of any use now are C and Java.
I have a friend, Dave Bridgham, who is joining us here as soon as his
subscription to the list "takes." He developed an AHRS display in Java as
the beginning of our glass cockpit project. He might be coercied into
making the code available. It would be a start for someone who wanted to
actually have an AHRS display. It includes displays for attitude, HSI,
altitude, and airspeed. We seriously considered using Java so that we
could run the code on different processors. There are some native code
generators for Java now.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | "Robert Day" <robday(at)gte.net> |
| Subject: | Re: Glass cockpit group introductions |
> Jeff-
> LA like Louisiana, or like Los Angeles?
> I'm up in Oxnard, getting ready to make a committment to actually starting
a
> CH601...
> Rob Day
>
>
> Hi, Rob
>
> Oops, I forgot about LA being Louisiana too. I'm in beautiful downtown
> Lawndale, LA county, CA, within spitting distance of the dreaded 405
> freeway.
>
> You, on the other hand, are up there where the air is clean and Camarillo
> airport is nearby. Must be nice.
>
> So, are you also a fellow computer geek?
>
> Jeff
>
>
Yeah, pretty much. Mostly through my own trial and error...I've got a small
network at home. At work we use various PC's for equipment control and lots
of systems set up for non-linear editing (Avid, Fire, Frost, Hal, etc.). I
work for the Fox Television Network in Century City, also spitting distance
from that stinking 405. However, I never drive the freeway unless PCH is
covered by mud!
I'm a broadcast engineer supporting two stages and several cable/network
sports shows. I'm sure you've seen our stuff. NFL on Fox, NHL (this was the
last season of hockey at Fox), Major League Baseball, all of the cable shows
like Fox Sports News, The Last Word, Goin' Deep, etc. I get to rub elbows
with some of the world's most famous sports celebrities, but unfortunately
I'm no longer a sports fan. After looking at nothing but sports for a few
years, not even Monday Night Football looks good anymore. So, another factor
to help with the "computer geek" label...
I've been doing almost all of my flying out of Camarillo, but when I finally
have a plane I'll fly from Oxnard Airport, where I actually live in the
traffic pattern (just inside the spot where most planes turn base).
Eventually I'll be able to fly into Santa Monica Airport, which is about 3
miles from the Fox lot. Should be about a 20 minute flight. Right now it
takes me about 75 minutes to get there.
We're getting more and more builders in SoCal. I'm glad to (almost) be one
of them!
Rob Day
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass cockpit OS & bus standards debate |
Hi Steve,
I'm assuming all the code in the system will be in EPROM or maybe EEPROM.
The small RTOS's I spoke of are all designed for that. IIRC Mach is that
sort of creature also.
The PIC's are by no means the only game in town in that price range. There
are the Atmel AVR chips, the Motorola 68HC11/16 series, and a huge number of
8051 and 80251 clones from Atmel, Philips, Dallas, Seimens, etc. These all
come with various combinations of RAM, EPROM, EEPROM, timers, UARTS, AtoD
converters, and CAN bus interfaces on chip. I'll round up a batch of URLs
for this stuff and post it here.
Jeff
-----Original Message-----
>One OS that is worthy of consideration is Mach. It is a nice
>microkernel with a Berkeley UNIX API wrapped around it. You
>can use it heavyweight for development and then strip it down
>to the microkernel for the run-time environment. The Gnu "herd"
>is based on Mach.
Is this available on and/or can this be burned onto a ROM/EPROM? (the
runtime kernel) can the development be done using something like gcc on
linux and then ported over? (or the DOS flavor of gcc?)
>> I am leaning towards either an embedded DOS system or one
>> of the RTOS's... we can program a standard VGA display in C
>> with relatively little difficulty. No need for some of these more
>> fancy GUI tools.
>
>You will want widgets to implement the various displays. Also
>point-and-click doesn't work in the cockpit.
Well, there are plenty of usable graphics libraries (object libraries,
function libraries, whatever suits the development environment) for just
about any platform, or a lean and mean custom library could be built with
just the required functionality...
That also brings in the next topic of dicussion, which is user interface
(to be covered in more detail later, in a separate e-mail)...
Food for thought... (NOT in order of preference)
* Point and click with a mouse or other pointing device may not work, but
touch screens might...
* A menu based system with a row of buttons along the sides of the
display may be in order.
* simple numeric keypad? most people can use these without looking...
and it could be context sensitive, so depending on display mode, it may be
arrows/page up/down etc., in one mode, and numeric in another...
>You are talking penny wise and pound foolish. Intelligence is a PIC
>and costs a few bucks. Now you have complete control over the
>message formats on the busses.
I am not familiar with the bus types that have been discussed... if an
inexpensive PIC can be interfaced to control/report on the sensors and/or
ADC's, and can also interface to one of these standard busses, then this
changes things a bit, and it makes sense to go that route.
However, if it turns out that these bus specs and/or the sensor interface
require more intelligence than a PIC can provide, then it will be a quite
expensive project, and I would sacrifice this expandability in favor of
having the results I want.
from a prior message...
>ARINC specifies both the buss electrical specs and the message
>formats. They may be ugly but they have the greatest chance of
>acceptance by mfgrs and the FAA. You also might be able to
>just plug in existing hardware and have it work. All these seem
>advantages to me.
We all have different priorities... "acceptance by mfgrs and the FAA" may
not be one of them for everybody, particularly if there is a large expense
or effort involved. We're talking about building a custom panel for our
experimentals, not a new cockpit system to sell to Boeing.
As for interfacing to these "standard" instruments Im sure they cost a
fortune (I wouldn't be surprised if some cost more than my entire plane),
so that may not be a real advantage.
Your mileage may vary.
Steve
http://www.tzogon.com/~steve/glass_cockpit (always updating this as more
information becomes available... I think I'm fighting a losing battle...
maybe catch up over the weekend? Grrr...)
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
Jeff,
you wrote to Brian:
.... You and I seem to be in complete agreement on the issue of system
architecture. I have a $29.95 toaster with a processor in it. We're not
talking big money here, if that's what's causing concern for some. I'd think
we're looking at maybe $20 worth of chips on a 2" square circuit board for
the little sensor boxes.
earlier today I wrote:
..../// I don't understand (I'm not saying you are wrong) the need for a cpu
for
each and every signal. I will have 10-14 temperatures and pressures coming
off of my engine alone. Probably more than 20-30 overall for the entire
airplane. These are all simple amplified analog signals. What is wrong
with routing these numerous signals to one or more AD converters coupled to
a corresponding processor? Why do we need one processor per signal?
Wouldn't each of these "simple signal processors" be able to handle at least
8 to 16 signals? What am I missing? Again, this is not my field of
expertise and so need to be educated.
How many analog sensors would such a "little sensor box" handle and what
kind of processor/IO chipset are you thinking of?
John
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass Cockpit Requirements |
Well, it looks like there's interest in this project! Being the antagonist
that I am, here's more fuel for the fire! (Gosh, I'm having so much fun!)
So, let's work on the requirements. We've outlined our dream requirements
(see Steve's website at http://www.tzogon.com/~steve/glass_cockpit or read
the archives), now let's get detailed.
Since flight instruments are probably the core of the system, it makes sense
to start there. Anyone is free to disagree and offer other suggestions.
So, what are our requirements for the flight instruments? The flight
instruments are:
-artificial horizon
What ranges of pitch and roll are we going to accept? Full 360 in both
axes? Or limit to a narrower range? What level of error is acceptable?
Under what circumstances? How should the information be displayed? Once we
answer these questions, we can begin to look for sensors that will meet
these requirements.
-altimeter
Again, what range are we looking for? What range of error is acceptable?
Are we going to correct for temperature or other factors that affect
altimeter readings? How are we going to display the altitude?
Although not part of the requirements, what recommendations do we have for
sensors? For instance, we can get altitude from both static pressure and
GPS. Are we going to cross-check the two? What happens if the two don't
agree? (Comments here should probably start another thread.)
-airspeed indicator
Again, what range and what error is acceptable? How will it be displayed?
-vertical speed indicator
Same questions.
-heading indicator
Same questions. Do we use magnetic north or true north? What else? What
do we do in extreme pitch angles where heading is meaningless?
-turn coordinator / turn and bank indicator
Same questions.
-any other flight instruments
-general requirements
How will the system behave on a global level?
As far as general requirements, my ideas are:
All instruments must behave in a manner consistent with traditional TSO'd
flight instruments. The ranges and errors of measurement must be consistent
with traditional instruments and should be spec'd for each instrument
individually. Each indicator must be able to sense when the data it is
receiving is either suspect, known to be unreliable (and, if possible, the
degree of reliability), or failed, and indicate this to the pilot. When an
instrument's reading can be derived from more than one sensor, cross-checks
should be implemented to verify that the multiple sensors agree within a
specified range, and when they don't agree, the 'suspect data' condition
should exist.
As Alan suggested, we should probably all read DO-178 as well. And if there
are other FAA documents out there that give requirements for flight
instruments, we need to make sure we meet those requirements. The hard part
here is probably just finding the information. I'm clueless here.
It's tempting to discuss requirements and sensors at the same time, and to a
point its inevitable to do so (as a practical matter) and I have done so
above. However, discussion here needs to be on requirements. Requirements,
to me, means how we display data to the pilot and ensuring that the data
presented falls within parameters we define.
Steve, can you assemble all of the ideas on to your web page? We can then
use that web page as our requirements document. Also, wanna set up a page
for the bio's of the participants?
Gee, then we can get on to the system architecture debate that's currently
being waged!
-Matt
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass Cockpit Requirements |
>So, let's work on the requirements. We've outlined our dream
requirements
>(see Steve's website at http://www.tzogon.com/~steve/glass_cockpit or
read
>the archives), now let's get detailed.
>
>
>Steve, can you assemble all of the ideas on to your web page? We can
then
>use that web page as our requirements document. Also, wanna set up a
page
>for the bio's of the participants?
Sure thing... I have been updating this on an ongoing basis, as well as
making a personal archive of the relevant messages for future reference
(so that when we get into more detailed analysis of the system
components). I will get everything up to date (as best I can) over the
weekend.
Steve
Steven J. Devine, President, Consultant
TZOGON Enterprises Incorporated
steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit OS & bus standards debate |
>
>>One OS that is worthy of consideration is Mach. It is a nice
>>microkernel with a Berkeley UNIX API wrapped around it. You
>>can use it heavyweight for development and then strip it down
>>to the microkernel for the run-time environment. The Gnu "herd"
>>is based on Mach.
>
>Is this available on and/or can this be burned onto a ROM/EPROM?
I am sure it could be but I haven't tried it. The code is freely
available, having been developed at CMU about 10 years ago.
>(the
>runtime kernel) can the development be done using something like gcc on
>linux and then ported over? (or the DOS flavor of gcc?)
I suspect so but if you run Mach as your main system, you can compile and
execute on the same platform so cross-compiling becomes a much simpler task.
With the price of memory and CPU power coming down, maybe using things like
PICs is underkill. OTOH, a PIC with built-in A/D becomes a one-chip engine
monitor (almost -- analog signal conditioning is nontrivial).
>>> I am leaning towards either an embedded DOS system or one
>>> of the RTOS's... we can program a standard VGA display in C
>>> with relatively little difficulty. No need for some of these more
>>> fancy GUI tools.
>>
>>You will want widgets to implement the various displays. Also
>>point-and-click doesn't work in the cockpit.
>
>Well, there are plenty of usable graphics libraries (object libraries,
>function libraries, whatever suits the development environment) for just
>about any platform, or a lean and mean custom library could be built with
>just the required functionality...
And the simpler the code is, the less effort it will be to verify its
correctness. Given that I may be betting my butt on the code, I want to be
sure it can't die.
>That also brings in the next topic of dicussion, which is user interface
>(to be covered in more detail later, in a separate e-mail)...
>
>Food for thought... (NOT in order of preference)
>
> * Point and click with a mouse or other pointing device may not work, but
>touch screens might...
We had surmised that we would have buttons on the sides of the display and
two knobs on the lower left and right. They would be gray code encoders so
the software could use them for whatever it wanted.
> * A menu based system with a row of buttons along the sides of the
>display may be in order.
The display/processing module was universal so it could be used for primary
flight instrumentation, general horizontal nav display (moving map), and
engine status display (EICAS).
> * simple numeric keypad? most people can use these without looking...
>and it could be context sensitive, so depending on display mode, it may be
>arrows/page up/down etc., in one mode, and numeric in another...
We were going to wait on this until later. We did plan to have the same
system control the multisensor nav system too.
>>You are talking penny wise and pound foolish. Intelligence is a PIC
>>and costs a few bucks. Now you have complete control over the
>>message formats on the busses.
>
>I am not familiar with the bus types that have been discussed... if an
>inexpensive PIC can be interfaced to control/report on the sensors and/or
>ADC's, and can also interface to one of these standard busses, then this
>changes things a bit, and it makes sense to go that route.
Heck, you could even do TCP/IP on a PIC so the kinds of protocols that are
used in aircraft are relatively simple. I believe that ARINC has already
defined the types of messages for the types of equipment that already
exists out there too. The buss that is probably most appropriate for this
project is ARINC-429. There is also MIL-1553b but that is coax-based and
not used in commercial stuff. Boeing came up with a really nice buss for
the 777 but the transceivers are a bit expensive and power hungry.
For more info on ARINC, see http://www.arinc.com/
>However, if it turns out that these bus specs and/or the sensor interface
>require more intelligence than a PIC can provide, then it will be a quite
>expensive project, and I would sacrifice this expandability in favor of
>having the results I want.
No, you can do the ARINC-429 protocol with a PIC. I just don't remember
what the electrical spec is.
Check out this URL for more info:
http://www.arinc.com/Ind_Govt_Srv/AEEC/drafts/98-012.pdf
Looking at this doc, electrically it appears that they support RS-232,
RS-422, and RS-485 electrically. It also appears to support analog signals
too.
>We all have different priorities... "acceptance by mfgrs and the FAA" may
>not be one of them for everybody, particularly if there is a large expense
>or effort involved. We're talking about building a custom panel for our
>experimentals, not a new cockpit system to sell to Boeing.
But the point is being able to plug in something someone else has
constructed, even if it comes from a commercial mfgr. If everything you do
is custom, then you have to build everything you want to add. Prices are
coming down for things. And as I said before, the Internet happened
because everything could plug into everything else. Don't knock that
capability.
>As for interfacing to these "standard" instruments Im sure they cost a
>fortune (I wouldn't be surprised if some cost more than my entire plane),
>so that may not be a real advantage.
Who knows what will be available in the future. Locking yourself out
because you think it might be expensive is foolish. You have to come up
with some way for the boxes to talk to each other so if it is possible to
do it with a standard and that will also make you compatible with other
equipment out there ...
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
Hi John,
I agree, we clearly do not need "a CPU for each and every signal". I don't
think anyone meant to suggest that. Let me use the engine instrumentation as
an example: The pulses from the RPM pickup, the DC levels from EGT
thermocouples, MAP sensors, water temp senders, etc. would connect to a box
on the firewall. In that box would live a CPU, ADC, pulse counter, and a bus
interface to talk to the other parts of the system. As I pointed out
elsewhere: "I'd think we're looking at maybe $20 worth of chips on a 2"
square circuit board" for this sort of function.
The display on the panel need not get involved with the details like how
many pulses per second corresponds to what RPM on your engine. It just
receives an RPM update message from the box on the firewall and displays
that value. I've oversimplified a bit, but I trust you get the idea.
Another box, mounted elsewhere, would contain pressure sensors, plumbed to
static and pitot ports, and would send messages about altitude, airspeed,
etc. I don't think I want that stuff in the same box with the engine stuff
even though it would use similar hardware.
I hope I've clarified this a bit, and not made it muddier.
Jeff
-----Original Message-----
All,
My comments and questions are prefaced by ///
...
> As for having the system completely extensible, with one of the
> standardized buses mentioned, that's a great idea, but as someone has
> pointed out, we would need a translator for each sensor to interface to
> this standard bus. That's essentially a dedicated microcontroller for
> each device, and the necessary programming of each device...
You are going to do that anyway so bite the bullet and accept it. This
is an area where you can cut corners now but it will bite you in the butt
later. Being able to define the messages that an engine monitor will
generate is nice because then anyone can build an engine monitor module
or a display module. The reason the Internet caught on is because we had
stardardized protocols and messages. Don't lose sight of that....
/// I don't understand (I'm not saying you are wrong) the need for a cpu for
each and every signal. I will have 10-14 temperatures and pressures coming
off of my engine alone. Probably more than 20-30 overall for the entire
airplane. These are all simple amplified analog signals. What is wrong
with routing these numerous signals to one or more AD converters coupled to
a corresponding processor? Why do we need one processor per signal?
Wouldn't each of these "simple signal processors" be able to handle at least
8 to 16 signals? What am I missing? Again, this is not my field of
expertise and so need to be educated.
John
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
Jeff
Perfectly clear. Thanks alot. Went out and looked at PIC w ADC
documents. The one I saw supported 4 analog inputs, I think 8 inputs(or 4
diff.) would be more appropriate, but it sounds like there are plenty of
small signal processors to chose from.
John
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit OS & bus standards debate |
>Heck, you could even do TCP/IP on a PIC so the kinds of protocols that are
>used in aircraft are relatively simple. I believe that ARINC has already
>defined the types of messages for the types of equipment that already
>exists out there too. The buss that is probably most appropriate for this
>project is ARINC-429. There is also MIL-1553b but that is coax-based and
>not used in commercial stuff. Boeing came up with a really nice buss for
>the 777 but the transceivers are a bit expensive and power hungry.
>For more info on ARINC, see http://www.arinc.com/
Yes-- a one-year subscription to the docs CD costs $2000.
Individual documents can be purchased at a lower price, but I have no idea
which documents we're interested in.
I have no problem following a standard. But dammit, I'm too cheap to pay to
get the specs!
-Matt
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Glass cockpit OS & bus standards debate |
On Fri, 12 Nov 1999, Matthew Mucker wrote:
> Date: Fri, 12 Nov 1999 15:06:55 -0600
> From: Matthew Mucker <mmucker(at)airmail.net>
> Reply-To: avionics-list(at)matronics.com
> To: avionics-list(at)matronics.com
> Subject: RE: Avionics-List: Glass cockpit OS & bus standards debate
>
>
> >For more info on ARINC, see http://www.arinc.com/
>
> Yes-- a one-year subscription to the docs CD costs $2000.
>
> Individual documents can be purchased at a lower price, but I have no idea
> which documents we're interested in.
>
> I have no problem following a standard. But dammit, I'm too cheap to pay to
> get the specs!
I was thinking the same thing...
(in case you guys hadn't noticed a theme going on here :) )
The ARINC-429 spec (if this is all we need) is more like 170... a little
more palatable...
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Glass cockpit - architecture draft |
Some of the details on the system architecture have been put online
(follow more details link). In invite any comments.
I will move the wish list off to a separate page at some point soon, and
start filling in the details from our requirements discussion...
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit - architecture draft |
Kewl!
So is everyone else on the list ignoring their jobs to do this?
Steve, I like the web page! My only comment would be that I envision the
input/controller module to be shared among the CPU's somehow. I don't know
how, tho...
My nomination for the sensor bus would be RS-485, since many single board
computers have RS-485 interfaces built in. But it's been a while since I've
looked at RS-485, so I don't know if it'd work for us.
-Matt
________________________________________________________________________________
| From: | Mark Wood <mawood(at)zoo.uvm.edu> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
Can someone please take me off the list until this project is done or they
learn to write E-Mail and address it only the people who need it
Mark
>
>Hi John,
>
>
>Jeff
>
>
>-----Original Message-----
>
>
>
>All,
>
>
>John
>
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit OS & bus standards debate |
No, you can do the ARINC-429 protocol with a PIC. I just don't remember
what the electrical spec is.
Check out this URL for more info:
http://www.arinc.com/Ind_Govt_Srv/AEEC/drafts/98-012.pdf
This doc is dated Jan. 1998. I wonder if there's a more recent version.
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
Mark,
This is a thread on the Matronics avionics-list. You can unsubscribe on
Matronics' web site. (That's where you subscribed to the list.)
I'm sorry that we've bombarded this list with emails that not everyone is
interested in, but it is an appropriate forum for this discussion (IMHO).
We certainly didn't mean to be a nuisance.
-Matt
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
Sent: Friday, November 12, 1999 4:37 PM
Subject: RE: Avionics-List: Glass cockpit OS debate, bus standards, etc
Can someone please take me off the list until this project is done or they
learn to write E-Mail and address it only the people who need it
Mark
>
>Hi John,
>
>
>Jeff
>
>
>-----Original Message-----
>
>
>
>All,
>
>
>John
>
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit OS & bus standards debate |
>It might... I'm concerned about fingerprints and glare. (Finger oil glare,
>that is.) However, my experience with touch screens is that they are
>reliable, and if the interface is designed for them (large hotspots, no
>double-clicking, etc.) it could work well. Touchscreens are pricey,
>however. (At least CRTs are. I have no experience with LCD touchscreens.)
The nice thing about buttons with soft labels is that they work pretty well
in turbulance. We will need some kind of stabilizing place for your
fingers and/or hand and that is difficult to do with a touch screen.
One comment on LCDs: sunlight-readable monochrome LCDs are readily
available and cheap compared to color LCDs. One way to bring the price
down is to use a monochrome display.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
>
>Hi Brian,
>
>I'd forgotten about Mach. Something like that might be a good fit for the
>display boxes. Somewhat overkill for sensor boxes, though. (I trust it's
>obvious to all that each type of box in the system may have a different CPU
>and OS). You have any up to date URLs for me?
http://www.cs.cmu.edu:80/afs/cs.cmu.edu/project/mach/public/www/mach.html
Here is the URL for the Gnu HURD OS, Gnu's full-on MACH-based UNIX.
http://www.fsf.org/software/hurd/hurd.html
>About as close as we could get to point and click would be a touch screen,
>and I don't much care for even that. I think Sierra got that part just
>right: Push buttons with soft labels and a couple of rotary encoders with
>knobs on them, all on a big bezel that you can steady your hand on. Very
>nice ergonomics.
Yeah. We backed off on the project when we saw Sierra's MFD. It was just
about identical to what we had planned to build.
>You and I seem to be in complete agreement on the issue of system
>architecture. I have a $29.95 toaster with a processor in it. We're not
>talking big money here, if that's what's causing concern for some. I'd think
>we're looking at maybe $20 worth of chips on a 2" square circuit board for
>the little sensor boxes.
Right. Memory and processing power are cheap so do in software things that
you might otherwise do in hardware.
>Your comment: "The reason the Internet caught on is because we had
>standardized protocols and messages" hits the nail on the head.
Thanks.
>BTW, are you (Brian) a hardware type at all? I'm hoping I'm not the only one
>here.
Yes, I am a hardware hacker with both analog and digital design background
(albeit rather old).
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit OS & bus standards debate |
>>For more info on ARINC, see http://www.arinc.com/
>
>
>Yes-- a one-year subscription to the docs CD costs $2000.
I know, it sucks, doesn't it.
>Individual documents can be purchased at a lower price, but I have no idea
>which documents we're interested in.
The index is available and the cross references are pretty good. I think
we can figure that out.
>I have no problem following a standard. But dammit, I'm too cheap to pay to
>get the specs!
It is painful, isn't it.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit OS debate, bus standards, etc |
> .... You and I seem to be in complete agreement on the issue of system
>architecture.
>
>earlier today I wrote:
>..../// I don't understand (I'm not saying you are wrong) the need for a cpu
>for
>each and every signal.
>
>
>How many analog sensors would such a "little sensor box" handle and what
>kind of processor/IO chipset are you thinking of?
Normally you put an analog multiplexer in front of the A:D converter so
that you can look at lots of different signals with only one A:D. Some of
the single-chip microcomputers have the analog mux built-in making things
even simpler but these tend to be limited to somthing like eight inputs.
I would probably roll a little box that accepts a bunch of thermocouple
inputs. I would also roll a little box that accepts a bunch of voltage
inputs, a MAP sensor, oxygen sensor, etc., and has current sources to turn
a voltage input into a resistance input, e.g. oil pressure, fuel pressure,
oil temperature, etc.
The goal would be to keep the cost of the little box down and then deal
with complexity issues by using one or more of the little boxes. If you
have a really complex airplane and want to measure a bunch of parameters,
you put in more little sensor boxes. If you only want to measure a couple
of inputs, you just need one. If done right they can be built for $20 or
so. These become little building blocks for our system.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass Cockpit Requirements |
>
>Since flight instruments are probably the core of the system, it makes sense
>to start there. Anyone is free to disagree and offer other suggestions.
Engine monitoring is easier to do and might get something done more
quickly. Air data is also easier to do.
>So, what are our requirements for the flight instruments? The flight
>instruments are:
>
>-artificial horizon
>
>What ranges of pitch and roll are we going to accept? Full 360 in both
>axes?
Yes. And since your sensors will be rate sensors, make sure that the roll
sensor's max rate is greater than the roll rate of your aircraft.
>Or limit to a narrower range?
No.
>What level of error is acceptable?
>Under what circumstances? How should the information be displayed? Once we
>answer these questions, we can begin to look for sensors that will meet
>these requirements.
If you have a full-on AHRS with accelerometers you can vector sum the
accelerations along all three axes. If the magnitude remains at 1G for
some period of time, you now have deduced inclination and can use that to
erect your attitude gyro and keep it erect.
>-altimeter
>
>Again, what range are we looking for?
at least -1,000 to +20,000 feet.
>What range of error is acceptable?
What is acceptable in your altimeter?
>Are we going to correct for temperature or other factors that affect
>altimeter readings?
You offer the option. You still want indicated altitude since that is what
others are using.
>How are we going to display the altitude?
A tape.
>Although not part of the requirements, what recommendations do we have for
>sensors? For instance, we can get altitude from both static pressure and
>GPS.
GPS isn't accurate enough. I regularly see errors of 500' on my GPS
altitude. No, it has to be pressure.
>Are we going to cross-check the two? What happens if the two don't
>agree? (Comments here should probably start another thread.)
You can cross check if you want but remember that selective availability on
GPS causes the altitude to wander all over the place.
>-airspeed indicator
>
>Again, what range and what error is acceptable?
The same air data sensor may be used for all kinds of speed ranges. Just
scale to what makes sense. The display is a tape again.
>-vertical speed indicator
I was thinking about a trend arrow on both the ASI and the VSI. For the
VSI it would show you where you will be in something like 1 minute (feet
per minute). The ASI trend arrow would show you where your airspeed would
be in 10 seconds.
>-heading indicator
>
>Same questions. Do we use magnetic north or true north?
It is an option but since everything else we do is magnetic ...
What else? What
>do we do in extreme pitch angles where heading is meaningless?
But it is not meaningless. You look at that portion of your velocity
vector that is projected on the plane that is tangent to the earth's
surface. This will be meaningful for any pitch angle other than +/- 90
degrees. At that point you cheat and use the roll angle for correction.
>-turn coordinator / turn and bank indicator
All your gyro instruments, ATI, DG, and TC, are derived from your inertial
reference platform (three rate gyros and three accelerometers). You won't
have a separate sensor so it just becomes a display issue.
>-any other flight instruments
>
>-general requirements
>
>How will the system behave on a global level?
It had better behave very well or it will get a spanking.
>As far as general requirements, my ideas are:
>
>All instruments must behave in a manner consistent with traditional TSO'd
>flight instruments.
Why? Go check out a glass cockpit in one of the heavies and see what they
look like and then ask again.
>The ranges and errors of measurement must be consistent
>with traditional instruments and should be spec'd for each instrument
>individually.
But you don't have separate instruments, you have separate sensors and then
you get to play games with the display(s). The concept of separate
instruments becomes meaningless.
>Each indicator must be able to sense when the data it is
>receiving is either suspect, known to be unreliable (and, if possible, the
>degree of reliability), or failed, and indicate this to the pilot.
This speaks rather highly for multiple redundant sensors.
>When an
>instrument's reading can be derived from more than one sensor, cross-checks
>should be implemented to verify that the multiple sensors agree within a
>specified range, and when they don't agree, the 'suspect data' condition
>should exist.
Right.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit - architecture draft |
>
>Kewl!
>
>So is everyone else on the list ignoring their jobs to do this?
Yeah.
>Steve, I like the web page! My only comment would be that I envision the
>input/controller module to be shared among the CPU's somehow. I don't know
>how, tho...
Messages my boy, messages. You can either listen to or ignore any message
on the buss so you can have many talkers and many listeners. The talkers
broadcast and the listeners listen to what they want to listen to. So if
your AHRS is broadcasting and your engine data collection box is
broadcasting, you can have two identical processor/display modules, each
programmed to listen to and display the appropriate information. A little
soft switch and your engine display can be pressed into service doing your
primary flight display should the box doing primary flight display fail.
>My nomination for the sensor bus would be RS-485, since many single board
>computers have RS-485 interfaces built in. But it's been a while since I've
>looked at RS-485, so I don't know if it'd work for us.
The ARINC-429 protocol mentions that you may use several different
electrical specs including RS-485. Multidrop RS-485 is nice for a buss.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | "Chuck" <cps(at)tisd.net> |
| Subject: | Re: Glass cockpit OS debate, bus standards, etc |
I enjoy this discussion a great deal about glass cp.
Keep up the good dialog.
Chuck
-----Original Message-----
From: Mark Wood <mawood(at)zoo.uvm.edu>
Date: Friday, November 12, 1999 2:34 PM
Subject: RE: Avionics-List: Glass cockpit OS debate, bus standards, etc
>
>Can someone please take me off the list until this project is done or they
>learn to write E-Mail and address it only the people who need it
>Mark
>
>
>>
>>Hi John,
>>
>
>>
>>Jeff
>>
>>
>>-----Original Message-----
>>
>>
>>
>>All,
>>
>>
>>John
>>
>
>
>
>
>
>
>
>
>
>
________________________________________________________________________________
| From: | dralle(at)matronics.com (Matt Dralle) |
| Subject: | JPI vs. Matronics Settlement Reached... |
Dear Listers,
After seven months of negotiations, JP Instruments, Inc. and Matronics
have reached a mutually agreeable settlement. As most of you are aware,
in February of this year, JP Instruments, Inc. alleged that Matronics'
use of the trademark "FuelScan" with its aircraft fuel management system
infringed upon JP Instruments, Inc's trademark "Scanner" for engine
temperature indicators. JP Instruments, Inc. requested that Matronics
discontinue the use of the "FuelScan" mark. After considerable
negotiations, we have come to an agreement whereby JP Instruments, Inc.
will purchase the FuelScan trademark and, if necessary, assist in paying
the cost of Matronics' adoption of a new trademark. Matronics will
continue to sell and market its aircraft fuel management system under
the FuelScan trademark until a phase-out period of up to one year is
completed. This will allow Matronics time to sell out its current stock
of units marked with the FuelScan trademark and to develop a new
trademark.
While negotiations have been a bit trying at times, I would like to say
that I am satisfied with the outcome, and feel that JP Instruments, Inc.
has treated Matronics and me fairly in this matter. Furthermore, I
would encourage you to consider JP Instruments for your aircraft
avionics in the future as they manufacture an excellent product line.
Finally, I would like to thank everyone from around the world for their
support and consideration in this matter. I was quite moved by the
support - both financial and in the form of letters and comments - that
builders and pilots provided me and my company during this time. I
never felt alone during this period, and so very much appreciated the
encouragement from thousands of my friends! Thank you so very much!
Best regards,
Matt Dralle
President, Matronics
--
Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551
925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email
http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft
________________________________________________________________________________
| From: | "J Livingston" <jliving(at)erinet.com> |
| Subject: | Re: Glass Cockpit Requirements |
Lets bracket the extremes of what people could do with this system.
Since we are talking about an open extensible system I propose we define a
minimum system as well as an all up system. Then we can start talking
about the desired -ilities (reliability, maintainability, affordability....)
assocated with various parts of the system.
Failure Modes analysis must be addressed soon. We want this thing to fail
gracefully.
As I currently see it, a minimum system would consist of something like the
following:
--------------------------
- engine sensors
- oil temperature
- oil pressure
- 2-8 CHT &EHT thermocouples
- rpm counter
- carb temp
- electrical system sensors
- amps
- volts
- Air Data Sensors
- 2 or more static pressures 0-20,000 ft, 50ft
accuracy, 1:400 accuracy
- 2 or more pitot pressures same
- Upper and lower wing pressure (for AOA) same
- OATemperature
- Misc Sensors
- position sensors (trim, flaps, cowls, etc)
- limit switches (landing gear, doors, etc)
- Flight sensors
- Turn and bank sensor (one rate gyro?)
- Compass
- GPS (I hesitate to put this in. It is not a simple sensor, but I
assume it is more or less std)
These need to be distributed to some number of "sensor processors" and from
there to one or more display/interface processors mounted on the dash.
Critical data should be distributed to more than one to insure graceful
failures.
Question: Does anyone think that we need physical redundancy in our comm
lines between our various processors?
There is no reason why a few critical sensors (turn & bank, AOA, oil temp,
oil pressure) could not have a backup analog display as well as providing
its signal to a "sensor processor"
It seems to me that this minimum system would consist of something like the
following:
-------------------------
- 3 sensor processors (assuming about 8 inputs per) w sensors suitably
distributed to ensure graceful failure
- one main display processor with LCD & appropriate input keys etc
- either one small secondary display processor for critical info back up
or have critical sensors have there own analog displays (turn & bank,
AOA, oil temp, oil pressure)
IMO cost of this minimum system should be $1000 in parts or less. I think
this would make it competitive with existing instrumentation. Is this too
high or low? This is just a strawman, comments, critiques?
As far as Artificial Horizons and the like, these are major projects in
there own right and I would try and buy this as an integrated package from a
company like Crossbow etc. These require a fair amount of accurate
numerical integration and other hardware related corrections and gymnastics.
I'm not saying we can't tackle it but we have alot to do already.
John
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit Group Introductions |
On 12 Nov, Brian Lloyd wrote:
> I have a friend, Dave Bridgham, who is joining us here as soon as
> his subscription to the list "takes." He developed an AHRS display
> in Java as the beginning of our glass cockpit project. He might be
> coercied into making the code available. It would be a start for
> someone who wanted to actually have an AHRS display. It includes
> displays for attitude, HSI, altitude, and airspeed. We seriously
> considered using Java so that we could run the code on different
> processors. There are some native code generators for Java now.
I'm receiving messages so it looks like I made it. Anyway, yes, I'm
willing to give out the code I wrote. It's a fairly basic primary
flight display with attitude, airspeed, altitude, and direction. It's
also got a start at navigation display (okay, it's just a CDI needle
in the HSI). Currently it's driven off an _really_ simple flight
simulator. So simple you'll all laugh at it but I just wanted to be
able to generate different attitudes to see the display move around.
As Brian said, it's written in Java. It's a Java application not an
applet. I wrote it a while back with an older version of Java but I
recently ran it with Kaffe and assorted libraries that came with
RedHat 6.0 and it worked as well as it always did.
As I recall, there's some code doing NEWs in the middle of loops so it
exercises the garbage collector more than it should. This is fine on
my desktop machine but should be cleaned up for something embedded.
Pick up http://www.froghouse.org/~dab/inst.tar.gz if you want the
code.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass Cockpit Requirements |
I largely agree with Brian on his responses to the requirements
question, which isn't surprising given how much we've talked about
this over the past few years, but I've got a few differences.
>
>>
>>Since flight instruments are probably the core of the system, it makes sense
>>to start there. Anyone is free to disagree and offer other suggestions.
>
> Engine monitoring is easier to do and might get something done more
> quickly. Air data is also easier to do.
Sure, but flight instruments are the interesting one.
>>-altimeter
>>
>>Again, what range are we looking for?
>
> at least -1,000 to +20,000 feet.
I'm hoping to fly a little higher than that in a year or two. How
about up to 25,000 feet?
>>What range of error is acceptable?
>
> What is acceptable in your altimeter?
I believe it's 75 feet. That's a little disturbing given how tight
some instrument approaches are.
>>How are we going to display the altitude?
>
> A tape.
A round dial. This isn't because I'm a curmudgeon (though I've been
called that) but because round dials are easier to just glance at and
know if you're on or off where you want to be.
>>-airspeed indicator
>>
>>Again, what range and what error is acceptable?
>
> The same air data sensor may be used for all kinds of speed ranges. Just
> scale to what makes sense. The display is a tape again.
Again, I think round dial.
Go take a look at the
Rockwell Collins ProLine 21 system for what I'm talking about.
They used to have better pictures and descriptions but there's still
some there.
>>-vertical speed indicator
>
> I was thinking about a trend arrow on both the ASI and the VSI. For the
> VSI it would show you where you will be in something like 1 minute (feet
> per minute). The ASI trend arrow would show you where your airspeed would
> be in 10 seconds.
The question on the vertical speed indicator (or altitude trend
arrow), is how much lag to build into it. My first guess would be to
approximate an IVSI but I've never actually flown behind one.
>> What else? What do we do in extreme pitch angles where heading is
>>meaningless?
>
> But it is not meaningless. You look at that portion of your
> velocity vector that is projected on the plane that is tangent to
> the earth's surface. This will be meaningful for any pitch angle
> other than +/- 90 degrees. At that point you cheat and use the roll
> angle for correction.
I tried dealing with this in my attitude indicator and wasn't so
pleased with the results. Maybe someone here can take the idea and
fix it up or come up with something better.
Picture a wire frame globe. It's got longitude lines running
vertically from pole to pole and latitude lines circling. You're at
the center of the globe looking out. A level attitude has you looking
out at the equator of this wire globe. The equator is the horizon.
If you're going straight up or straight down, you're looking at the
north or south pole; it looks like a bullseye with radial lines. The
horizon/equator line could also be annotated with compass headings so
your attitude indicator was also a directional display.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass Cockpit Requirements |
On 13 Nov, J Livingston wrote:
> Question: Does anyone think that we need physical redundancy in our
> comm lines between our various processors?
Yes. At least we should allow for it; that is, all devices which
connect to the data bus should have dual parallel bus connections.
One of the neat possibilities of an expandable system is that it can
expand. If you had 90% of the capabilites of your panel traveling
over a single data bus, than a single failure could lose you 90% of
your panel.
One possibility for a lower cost sensor processor which is connected
to less critical sensors, is that it only has one bus connection. If
you want redundancy, you have to install two sensor processors on
different busses, connected to the same sensor or not as the situation
warrants. But all display units would want to be able to monitor both
busses; those are likely to be more expensive boxes anyway.
-Dave
________________________________________________________________________________
| From: | "Terry Watson" <tcwatson(at)seanet.com> |
| Subject: | Notebook Computer Instrument Panel |
Hi guys,
Here is an ad from the Kitplane's New Products, page 10 of the December
issue that I received yesterday:
Notebook Computer Instrument Panel
The notebook computer instrument panel system from LaFave Engineering
consists of an analog module that interfaces with system sensors and outputs
data over a serial bus for graphical display on a PC notebook computer
running Windows 95/98/NT. Display functions include volts, amps, oil
pressure, fuel pressure, carb temperature, up to 8 CHTs and EGTs, automotive
oxygen sensor for mixture adjustment, takeoff and landing roll, manifold
pressure, altimeter, airspeed, density altitude, relative humidity, dew
point, OAT, rpm, fuel flow, fuel quantity, ignition advance, a
user-definable checklist, weight-and balance calculator and warning
messages. The price is $875, excluding notebook computer and sensors.
For more information, contact LaFave Engineering, 710 E. 20th St. #b,
Cheyenne, WY 82001; call 307/772-0942; e-mail Davidlafave(at)hotmail.com;
www.fly.simplenet.com ..
The ad includes a picture of a very full laptop screen displaying much of
the above. I couldn't get the website address to work.
Terry
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass Cockpit Requirements |
Hi Dave,
Welcome aboard, seems like this group is starting to get up to critical
mass. When I started out a few days ago, responding to Matt's post, I felt
we were all talk, myself included. Now this thing seems to be picking up
momentum fast. I've been harping on the point that this is a BIG job. Given
the rate at which we seem to be picking up more folks who sound like they
know what they're talking about (such as yourself) I'm starting to have hope
for this becoming a real project.
I'll now switch to "old hardware curmudgeon" mode, and address the bus
redundancy issue. A lot depends on the low level physical bus
implementation. For example, with your typical async serial over RS-485
setup, a firmware bug in one node can bring the whole network down with
great ease. Just duplicating the bus will not help this much. I don't think
it's the bus transceivers and the wire that we need to worry about, so much
as how we partition system functionality.
I've been looking into the CAN bus, and I'm intrigued by it's error handling
scheme, but I'm not ready recommend it yet.
Later
-----Original Message-----
On 13 Nov, J Livingston wrote:
> Question: Does anyone think that we need physical redundancy in our
> comm lines between our various processors?
Yes. At least we should allow for it; that is, all devices which
connect to the data bus should have dual parallel bus connections.
One of the neat possibilities of an expandable system is that it can
expand. If you had 90% of the capabilites of your panel traveling
over a single data bus, than a single failure could lose you 90% of
your panel.
One possibility for a lower cost sensor processor which is connected
to less critical sensors, is that it only has one bus connection. If
you want redundancy, you have to install two sensor processors on
different busses, connected to the same sensor or not as the situation
warrants. But all display units would want to be able to monitor both
busses; those are likely to be more expensive boxes anyway.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit Requirements |
On 13 Nov, Jeff Barlow wrote:
> I'll now switch to "old hardware curmudgeon" mode, and address the bus
> redundancy issue. A lot depends on the low level physical bus
> implementation. For example, with your typical async serial over RS-485
> setup, a firmware bug in one node can bring the whole network down with
> great ease. Just duplicating the bus will not help this much.
This one has bothered me for a while since I don't have a good answer
to it. Even when we were talking about ethernet, and had bandwidth to
spare, just the interrupt load of someone going berzerk would be a
problem.
Fortunately, it's not a problem that's likely to be very common, a
reasonable testing procedure out to get it, but I've seen it happen
with network protocols so I know it can. I once fielded a poor
implementation of a routing protocol that would completely saturate a
10Mb/s ring net for a half hour at a time. Be wary if any packet
coming in can trigger one going out.
> I don't think it's the bus transceivers and the wire that we need to
> worry about, so much as how we partition system functionality.
I spent some time just now drawing pictures and trying to separate
send and receive directions to help partition things. I'm not sure if
this is what you were thinking of but you can see the picture I came
up with at http://www.froghouse.org/~dab/flight-instruments.gif
-Dave
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Glass Cockpit Requirements |
All,
I think its wonderful that everyone is so enthusiastic about what is
possible with this project. But folks, lets take a step back here.
We're designing a glass cockpit system for homebuilt aircraft. Not for a 747
or an F-18.
The ARINC standard might let me put just about any jetliner box in my
aircraft, but c'mon... I'm not gonna put a 747 part in my Zodiac. That
standard was written to address a completely different set of requirements
than ours.
Bus redundancy is a great idea too. But... modern electronics are EXTREMELY
reliable. My personal thoughts are that a power-on self test should be
sufficient to determine any bus problems. The electronics are far more
likely to fail at power up, when you're on the ground, then they are in
midflight. The additional overhead of a second bus, in terms of development
and hardware costs, could well exceed its value if we're not careful.
I DO want to build a robust system. But I don't want to let this project
spiral out of control. My personal vote is against redundant buses. On a
multidrop RS-485 system, the danger of one sensor bringing down the entire
bus could be mitigated by individual circuit breakers/switches for each
sensor.
Now, if someone finds a single board computer that has TWO onboard RS-485
ports, it may just be enough to change my mind!
On the other hand, if we have two redundant buses, and we stick a sesor on
there... is the sensor gonna have TWO PIC chips, one connected to each bus?
Or one chip driving both buses? (Using a PIC as an example only.)
-Matt
-----Original Message-----
From: dab(at)froghouse.org <dab(at)froghouse.org>
Date: Saturday, November 13, 1999 3:32 PM
Subject: RE: Avionics-List: Glass Cockpit Requirements
>
>On 13 Nov, Jeff Barlow wrote:
>
>> I'll now switch to "old hardware curmudgeon" mode, and address the bus
>> redundancy issue. A lot depends on the low level physical bus
>> implementation. For example, with your typical async serial over RS-485
>> setup, a firmware bug in one node can bring the whole network down with
>> great ease. Just duplicating the bus will not help this much.
>
>This one has bothered me for a while since I don't have a good answer
>to it. Even when we were talking about ethernet, and had bandwidth to
>spare, just the interrupt load of someone going berzerk would be a
>problem.
>
>Fortunately, it's not a problem that's likely to be very common, a
>reasonable testing procedure out to get it, but I've seen it happen
>with network protocols so I know it can. I once fielded a poor
>implementation of a routing protocol that would completely saturate a
>10Mb/s ring net for a half hour at a time. Be wary if any packet
>coming in can trigger one going out.
>
>> I don't think it's the bus transceivers and the wire that we need to
>> worry about, so much as how we partition system functionality.
>
>I spent some time just now drawing pictures and trying to separate
>send and receive directions to help partition things. I'm not sure if
>this is what you were thinking of but you can see the picture I came
>up with at http://www.froghouse.org/~dab/flight-instruments.gif
>
> -Dave
>
>
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass Cockpit Requirements |
Hi Guys,
I keep thinking I should post something that's not just a reaction to
someone else's post. I continue to ponder all this and will eventually have
an original thought or two to express, but here I go again.
Matt said: "But... modern electronics are EXTREMELY reliable. My personal
thoughts are that a power-on self test should be sufficient to determine any
bus problems."
I sorry Matt, and I don't mean to sound condescending, but the first word
that came to mind when I read that was "naive". I don't think hardware
reliability per say is really the issue. The primary issue, IMHO, is fault
containment. Things break, it's a fact of life. You can't just reboot an
airplane in flight. This sort of system MUST be designed so that no single
point failure can take out the whole system. If we can't meet that one
requirement, I don't care how cool the rest of it is, I'm not getting in the
plane with it.
Perhaps I should clarify my point of view here. I've lived in So. Calif. all
my life. I've been doing this stuff for, let's see now, 30 years? From those
facts it follows that I've put in my time at Hughes, TRW, etc. Military
projects tend to have an effect on one's mindset. Now when I sound fanatical
about this, maybe you will at least understand where I'm coming from. (Ouch,
there's a stuck in the '60 phrase.)
Let me paint the following picture: You're cruising along happily when, do
to some low probability sequence of events, the return stack in a PIC
overflows, (they're only eight deep) and the code runs off into the weeds.
It starts trying to execute the data in a lookup table as program code. One
of these bytes looks just like the instruction that jams a one into the
output bit that controls the RS-485 driver. The whole bus locks up tight,
and your panel displays never update again. Sure popping the breaker for the
offending box will clear this type of fault, but which one is it?
I can think up hundreds of these scenarios, hell I may have seen that many
happen. This is a group project. Many of us may end up writing parts of the
code. I'm sure you're all nice guys and all that, but I'm not betting my
life that we all write perfect code. This is not a simple problem. We will
not solve it in a few days or weeks. Hum, I'm ranting again, aren't I? I'll
stop now.
One more point of view issue: I keep reading "single board computer" in a
context that suggests buying same. I tend to naturally think more in terms
of buying chips and designing our own boards. Am I the only one?
I'm a verbose old fart, aren't I?
Later
-----Original Message-----
I think its wonderful that everyone is so enthusiastic about what is
possible with this project. But folks, lets take a step back here.
We're designing a glass cockpit system for homebuilt aircraft. Not for a 747
or an F-18.
The ARINC standard might let me put just about any jetliner box in my
aircraft, but c'mon... I'm not gonna put a 747 part in my Zodiac. That
standard was written to address a completely different set of requirements
than ours.
Bus redundancy is a great idea too. But... modern electronics are EXTREMELY
reliable. My personal thoughts are that a power-on self test should be
sufficient to determine any bus problems. The electronics are far more
likely to fail at power up, when you're on the ground, then they are in
midflight. The additional overhead of a second bus, in terms of development
and hardware costs, could well exceed its value if we're not careful.
I DO want to build a robust system. But I don't want to let this project
spiral out of control. My personal vote is against redundant buses. On a
multidrop RS-485 system, the danger of one sensor bringing down the entire
bus could be mitigated by individual circuit breakers/switches for each
sensor.
Now, if someone finds a single board computer that has TWO onboard RS-485
ports, it may just be enough to change my mind!
On the other hand, if we have two redundant buses, and we stick a sesor on
there... is the sensor gonna have TWO PIC chips, one connected to each bus?
Or one chip driving both buses? (Using a PIC as an example only.)
-Matt
________________________________________________________________________________
| From: | "Chris Atkinson" <chris-atkinson(at)home.com> |
| Subject: | Glass Cockpit Requirements |
Hi guys, I've been away few a few days. Looks like the discussion has
gotten quite lively! Sorry some of you did not seem to like the route I'm
going. For your all's edification, I started off with a wish list nearly
identical to the one at http://www.tzogon.com/~steve/glass_cockpit plus a
TCAS!. I also went down the "robust architecture" path for quite a while.
After thrashing around, I got a bit disillusioned about how much time &
dough it would take to build...so I threw away my nerd beanie for a sec* and
started thinking about the vision of the project. There are lots of
pictures to pick from, but mine turned out to be summed up as basically to
make VFR flight more enjoyable and somewhat safer without making the project
into a "moonshot" sized affair. Our CH601 is 60% done, so it's too late to
make it fit for exoatomospheric excursions or extreme meteorological
phenomena study anyways.*
I'd love to start a sub-thread to share ideas if there's anyone interested
in the same general theme that I'm going...please respond if you're
inclined.
Chris
Ps. Matt asked about activex's in another post. Here's a pretty good starter
set...available store-bought for cheap with no re-inventing required!
http://www.globalmajic.com/x_air.htm. My own lib is not quite ready for
prime time yet but I'll keep you posted.
*sarcasm intended for comic relief. please ignore if you're offended ;-)
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: fault tolerance and custom fabrication |
>The primary issue, IMHO, is fault containment. Things break,
>it's a fact of life. You can't just reboot an airplane in flight. This
>sort of system MUST be designed so that no single point
>failure can take out the whole system.
Agreed... and this will be added to the specs when I get a chance. I
believe that it's (more or less) a common theme here.
>One more point of view issue: I keep reading "single board
>computer" in a context that suggests buying same. I tend to
>naturally think more in terms of buying chips and designing
>our own boards. Am I the only one?
Probably... :-)
To keep this system as simple as possible, I am of the thinking that we will
be fabricating circuits where necessary (such as the sensor-bus interfaces),
but using off-the-shelf components where available and appropriate.
At least for the display side of things, a standard single board computer of
one sort or another can be used. The display can be a pre-made VGA
compatible controller driving any type of display (LCD or CRT, big or
small). This provides quite a bit of flexibility for individual
installations with one piece of software driving it.
But, then again, that's the beauty of making it a modular system on a common
bus (yes, I am a convert)... if you want to, *YOU* can build your own
custom display from chips, transistors, vacuum tubes, whatever strikes your
fancy. You can make it a slick "glass cockpit" style, or have an individual
indicator for each. That's the best part... it's up to you.
But I'm thinking that I won't be doing that for mine. I can work a
soldering iron just fine, but prefer to plug things together and turn them
on whenever it is appropriate.
Steve
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass Cockpit Requirements |
On 13 Nov, Matthew Mucker wrote:
> We're designing a glass cockpit system for homebuilt aircraft. Not
> for a 747 or an F-18.
Good point. If we don't have an idea of what sort of environment
we're going for, we're just going to be at cross purposes a lot of the
time.
My homebuilt (if it's ever done) will fly over 200knots, have built in
oxygen, be able to cruise in the low flight levels, and I expect it to
fly it IFR regularly. Unfortunately, the TKS system is looking less
likely. Bummer.
For me, the goal to shoot for is something that's good enough that I
_could_ just put five MFDs across the panel and that's the entire
panel. Not saying I would do that, but that's the level of
reliability and capability I'd like. However, I also want it
affordable even for installations that aren't trying for that level of
reliability. I don't think this is an impossible goal.
> Bus redundancy is a great idea too. But... modern electronics are
> EXTREMELY reliable. My personal thoughts are that a power-on self
> test should be sufficient to determine any bus problems. The
> electronics are far more likely to fail at power up, when you're on
> the ground, then they are in midflight.
An RS-485 bus is two wires, run daisy chain from one device to the
next. There is probably a connector at each device. Modern
electronics is so reliable because most connections are inside an IC
and the ICs themselves are surface mount devices that were roboticly
assembled. As far as reliability goes, connectors suck. The
contacts in the connector get worn and corroded, the wires can break
or rub against parts of the airframe and short out.
> The additional overhead of a second bus, in terms of development and
> hardware costs, could well exceed its value if we're not careful.
True. The cost of the bus itself, just some wire, is pretty low. The
cost of a second bus on each device could add up.
> On the other hand, if we have two redundant buses, and we stick a
> sesor on there... is the sensor gonna have TWO PIC chips, one
> connected to each bus? Or one chip driving both buses? (Using a PIC
> as an example only.)
As a result of Jeff's comments, I'd say yes, but it's an option. I
was trying to show this in my picture but I think I didn't put in
enough detail.
My original idea was that every device would listen and transmit on
the two redundant busses. Jeff reminded me about the failure mode
there that makes it not nearly as good as I want. So a rethink on the
redundant bus issue.
The basic design criteria I came up with was that while there are
multiple busses in the plane (I have three in my picture), any given
processor unit is only wired to transmit on one of them. Simple
sensor modules (say built around a PIC) probably wouldn't even have a
receive connection but if they did they'd only have one. This is only
a single RS-485 line, it's just that I connected the transmit and
receive connections to different busses.
MFD's (and perhaps some other devices) would have to listen to
multiple busses though they still only transmit on one. I've drawn
two in the picture but they might want to be able to listen to a
second control bus too, I'm not sure. I'm expecting the MFD to be a
bit more expensive anyway, so the hardware for a second or third -485
line doesn't seem that excessive.
Now a simple system, where you're just monitoring engine parameters or
air data where it's a backup to the regular mechanical airspeed and
altimeter, would be just a single PIC sensor module with A/D inputs
connected to appropriate sensors and an MFD. The MFD would have an
extra serial line that's unused.
If you wanted more reliability, you could put in a second PIC sensor
module paralleling the first and connected to the same sensors but
talking on the second sensor bus. If you wanted to go even further
and if it made sense, you could put in a second set of sensors. For
instance, I'd really like a second complete AHRS. I probably won't
because the prices are too high but I'd like a backup. Actually, I'd
like a third one, say a different technology like the Seagull
Technologies GPS based AHRS, so I could automatically figure out which
one had failed. Notice that none of this adds to the cost of the
basic system, except the MFD has to have a second RS-485 port.
And Jeff said he was verbose. Sheesh.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit Requirements |
On 13 Nov, Jeff Barlow wrote:
> One more point of view issue: I keep reading "single board computer"
> in a context that suggests buying same. I tend to naturally think
> more in terms of buying chips and designing our own boards. Am I the
> only one?
Custom hardware would be wonderful but it's not a skill I have so I
don't talk about it. Maybe a PIC sensor module level project but not
the MFD. Do you?
> I'm a verbose old fart, aren't I?
Not so bad.
-Dave
________________________________________________________________________________
| From: | "Jeff Barlow" <barlow(at)thegrid.net> |
| Subject: | Glass Cockpit Requirements |
Yeah, been doing it most of my life. Built radio transmitters out of old TV
set parts (tubes) when I was in high school. Lately I've even gotten to
where I can even solder those little tiny flat pack IC's without shorting
the pins. However, if I'm the only one, I better be careful about what
I'm signing myself up for. For example, doing a six layer circuit board
layout is not my idea of a good time. I keep hoping another EE type will
show up here.
-----Original Message-----
Custom hardware would be wonderful but it's not a skill I have so I
don't talk about it. Maybe a PIC sensor module level project but not
the MFD. Do you?
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass Cockpit Requirements |
>
>As I currently see it, a minimum system would consist of something like the
>following:
> --------------------------
>- engine sensors
> - oil temperature
> - oil pressure
> - 2-8 CHT &EHT thermocouples
> - rpm counter
> - carb temp
>
>- electrical system sensors
> - amps
> - volts
>
>- Air Data Sensors
> - 2 or more static pressures 0-20,000 ft, 50ft
>accuracy, 1:400 accuracy
> - 2 or more pitot pressures same
> - Upper and lower wing pressure (for AOA) same
> - OATemperature
I probably would have characterized the types of sensors I wanted to use
and go from there. For instance:
1. J-type and K-type thermocouples (EGT, CHT, TIT, ITT, etc.);
2. resistive temperature transducers (Oil-T, OAT, carb air temp, inlet air
temp, etc.);
3. pressure transducers (we should find out what is available for
absolute, guage, and differential pressure transducers in various pressure
ranges for different environments);
4. pulse inputs (fuel flow, engine RPM, prop RPM, etc.);
5. voltage inputs (voltage, current, fuel level, etc.; resistive inputs
are probably a special case of voltage inputs);
6. binary state inputs (gear up/down, flaps up/down, speedbrakes deployed,
etc.)
>- Misc Sensors
> - position sensors (trim, flaps, cowls, etc)
> - limit switches (landing gear, doors, etc)
>
>- Flight sensors
> - Turn and bank sensor (one rate gyro?)
> - Compass
I think we are probably coming to the same conclusion from a different
direction.
> - GPS (I hesitate to put this in. It is not a simple sensor, but I
>assume it is more or less std)
I view this as a very interesting sensor since it can give us inertial
information (AHRS) using multiple antennas. We ought to seriously consider
that as the possible primary source for our attitude info and use the gyros
as secondary or backup attitude info.
>These need to be distributed to some number of "sensor processors" and from
>there to one or more display/interface processors mounted on the dash.
Well, I see the raw information being broadcast or multicast on the
avionics buss and then any device that decides it wants that info would
snarf it off the buss and digest it. You get interesting redundancy that way.
>Critical data should be distributed to more than one to insure graceful
>failures.
Dump it on the buss and it is distributed to all, not just one.
>Question: Does anyone think that we need physical redundancy in our comm
>lines between our various processors?
When Dave and I started out, we were going to use a dual ethernet. Each
"talker" would transmit identical data on both busses. Each "listener"
would listen to both busses. This allows you to detect partial or complete
buss failure and still ride through multiple partial buss failures with no
loss of function, i.e. talker 1 loses buss 1 and talker 2 loses buss 2 but
listener 1 still hears talker 1 on buss 2 and still hears talker 2 on buss
one so you haven't lost any functionallity. Listener 1 can probably deduce
that the failures are on the talkers local interface to the busses.
Likewise, you can make some of the boxes routers so that you can ride
through partitioning of a buss. This may be overkill but it pretty well
eliminates the worry that you won't get your data.
>There is no reason why a few critical sensors (turn & bank, AOA, oil temp,
>oil pressure) could not have a backup analog display as well as providing
>its signal to a "sensor processor"
You put multiple displays on the buss system and you have your redundancy.
In fact, if you have two display processors and prioritize the displays,
you can immediately move critical display info from one display to another.
This is a software thing that doesn't require any special hardware to do.
>It seems to me that this minimum system would consist of something like the
>following:
> -------------------------
>- 3 sensor processors (assuming about 8 inputs per) w sensors suitably
>distributed to ensure graceful failure
>- one main display processor with LCD & appropriate input keys etc
>- either one small secondary display processor for critical info back up
> or have critical sensors have there own analog displays (turn & bank,
>AOA, oil temp, oil pressure)
I imagine two identical display processors with the displays spread across
them. Failure of one means the other has to do all the work but does so by
not displaying things you don't need to look at right now.
The "dark cockpit" concept says you don't need to look at anything that is
normal so you can probably shed all your engine display and most of
everything else. You want to bring up the engine performance displays when
you are making engine power changes but they go away again after you quit
moving the knobs. Eventually you will just key in the power setting you
want, "Jeves, set 70% power on the engine," and it will adjust prop,
throttle, and mixture for the optimum efficiency that delivers 70% power at
your altitude.
>IMO cost of this minimum system should be $1000 in parts or less. I think
>this would make it competitive with existing instrumentation. Is this too
>high or low? This is just a strawman, comments, critiques?
Sounds reasonable to me but it MUST be scalable. YOu might want to start
with just an engine monitor now and add things later. Since our AHRS seems
to be the real killer (solid state gyros are expensive), we can still build
the low-end engine monitor and then just plug in the AHRS later as the
prices come down. The display processor(s) will be updatable to provide
flight instrumentation as that becomes realistic. That way the person on a
tight budget doesn't have to do a "forklift upgrade," i.e. total discard
and add new equipment, when he/she is ready to upgrade.
>As far as Artificial Horizons and the like, these are major projects in
>there own right and I would try and buy this as an integrated package from a
>company like Crossbow etc. These require a fair amount of accurate
>numerical integration and other hardware related corrections and gymnastics.
>I'm not saying we can't tackle it but we have alot to do already.
Someone needs to go talk to Crossbow. They have a complete AHRS but it
doesn't use their IFOG technology. Go figure. But, as I recall, they do
have an inertial reference module that does use their IFOG technology but
it doesn't predigest the raw data into AHRS data as does their AHRS module.
Seems that is where we ought to concentrate on Crossbow.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Notebook Computer Instrument Panel |
>
>Notebook Computer Instrument Panel
>The notebook computer instrument panel system from LaFave Engineering
>consists of an analog module that interfaces with system sensors and outputs
>data over a serial bus for graphical display on a PC notebook computer
>running Windows 95/98/NT.
Which means it is totally unsuitable for anything serious.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass Cockpit Requirements |
>I'll now switch to "old hardware curmudgeon" mode, and address the bus
>redundancy issue. A lot depends on the low level physical bus
>implementation. For example, with your typical async serial over RS-485
>setup, a firmware bug in one node can bring the whole network down with
>great ease. Just duplicating the bus will not help this much. I don't think
>it's the bus transceivers and the wire that we need to worry about, so much
>as how we partition system functionality.
That is why Dave and I were talking about using Ethernet. We were going to
use dual 10baseT ethernets each wired as a star topology using standard
chips. The ethernet hub chips already have the ability to automatically
"turn off" a port that is "jabbering," i.e. talking too much and not
relinquishing the buss. Two busses would handle the situation where one
buss hub chip packs it in.
Boeing approached the problem in the 777 by using a coax buss that had
inductive coupling. That way if a transceiver went hard-on or hard-off, it
wouldn't affect anyone else on the buss.
>I've been looking into the CAN bus, and I'm intrigued by it's error handling
>scheme, but I'm not ready recommend it yet.
The CAN buss looks interesting but it isn't an FAA-approved buss. These
are the compromises we have to deal with.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass Cockpit Requirements |
>
>We're designing a glass cockpit system for homebuilt aircraft. Not for a 747
>or an F-18.
It doesn't matter anymore. My $200 palm pilot has almost as much
processing and display power as the avionics suite powering a 1980's
version of the avionics in a 747 or an F-18. It just doesn't cost much
anymore.
>The ARINC standard might let me put just about any jetliner box in my
>aircraft, but c'mon... I'm not gonna put a 747 part in my Zodiac. That
>standard was written to address a completely different set of requirements
>than ours.
No, it wasn't. It was written to allow devices from one company to be
plugged into and talk to devices from another company in a standard
fashion. That is what we are trying to do here too, only the "companies"
are different people here working on different parts of the problem. The
chips needed to build these busses cost under $10 per box and they give us
lots of expansion capability.
>Bus redundancy is a great idea too. But... modern electronics are EXTREMELY
>reliable. My personal thoughts are that a power-on self test should be
>sufficient to determine any bus problems. The electronics are far more
>likely to fail at power up, when you're on the ground, then they are in
>midflight. The additional overhead of a second bus, in terms of development
>and hardware costs, could well exceed its value if we're not careful.
The parts cost is minimal and I don't want the failure of a single chip to
cause all my gyro displays to go away. I expect the vibration and
temperature excursion of flight to be more of a factor than the traditional
"it failed on power up." That failure mode is no where near as common as
environmental failure modes these days and we are talking a pretty hostile
environment (my avionics has operated from -20C to +50C already that I know
of).
>I DO want to build a robust system. But I don't want to let this project
>spiral out of control. My personal vote is against redundant buses. On a
>multidrop RS-485 system, the danger of one sensor bringing down the entire
>bus could be mitigated by individual circuit breakers/switches for each
>sensor.
Let's look at the cost in terms of development time and gold before punting
the redundant buss. It may turn out to be almost a no-brainer in which
case it would be silly not to support it.
>Now, if someone finds a single board computer that has TWO onboard RS-485
>ports, it may just be enough to change my mind!
The difference is just adding the appropriate drivers to a standard serial
port. This is not rocket science.
>On the other hand, if we have two redundant buses, and we stick a sesor on
>there... is the sensor gonna have TWO PIC chips, one connected to each bus?
>Or one chip driving both buses? (Using a PIC as an example only.)
I assumed one chip driving two busses. It just needs two serial ports.
Here is an idea: how about a slow buss (RS-485) and a fast buss (ethernet)?
Finding boxes with one ethernet and one serial port is a no-brainer these
days. The two busses have different characteristics and failure modes.
Just an idea.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass Cockpit Requirements |
>
>One more point of view issue: I keep reading "single board computer" in a
>context that suggests buying same. I tend to naturally think more in terms
>of buying chips and designing our own boards. Am I the only one?
No. But I do think that prepackaged SBCs are a good place to start on this
stuff. They let you pick a processor family and try it out before you
commit to the hardware design. You may want to switch processor families
after you find out one that you thought would be the right thing turned out
to be a real pain-in-the-butt to get it to do what you wanted it to do.
>I'm a verbose old fart, aren't I?
Uh, more than me or Dave? I am at least as much a VOF as you are.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | glass cockpit threads |
You know, we need to start doing separate threads for the various
components so that we can compartmentalize the discussion a bit. Suggested
threads:
glass cockpit -- buss hardware architecture
glass cockpit -- buss message structure
glass cockpit -- processor architecture
glass cockpit -- engine sensor
glass cockpit -- air data sensor
etc.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass Cockpit Requirements |
>
>Yeah, been doing it most of my life. Built radio transmitters out of old TV
>set parts (tubes) when I was in high school.
We must be about the same age then.
>Lately I've even gotten to
>where I can even solder those little tiny flat pack IC's without shorting
>the pins. However, if I'm the only one, I better be careful about what
>I'm signing myself up for. For example, doing a six layer circuit board
>layout is not my idea of a good time. I keep hoping another EE type will
>show up here.
I am still back in the double-sided-through-hole board days. That is as
far as I go. 6-layer stuff has to be farmed out.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| Subject: | Re: Glass Cockpit Requirements |
In a message dated 11/13/99 7:14:41 PM Central Standard Time,
barlow(at)thegrid.net writes:
<< The primary issue, IMHO, is fault
containment. Things break, it's a fact of life. You can't just reboot an
airplane in flight. This sort of system MUST be designed so that no single
point failure can take out the whole system. >>
Not only fault containment but the system has to let the operator know that
something is going on and not to trust the readings. In Biz jets there is
two of everything and the values are compared if they are not close enough a
message is posted to the pilot. Then the pilot has to figure out which
numbers to use. In a small single engine airplane this might be overkill but
fault detection must be present at some level.
Alan Kritzman
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Glass Cockpit Requirements |
>> - GPS (I hesitate to put this in. It is not a simple sensor, but I
>>assume it is more or less std)
>
>I view this as a very interesting sensor since it can give us inertial
>information (AHRS) using multiple antennas. We ought to seriously consider
>that as the possible primary source for our attitude info and use the gyros
>as secondary or backup attitude info.
This is actually an idea that I think has lots of merit. I don't know
enough about GPS to know how accurate a differential between two antennas
would be. Does anyone have any hard information? I found GPS receiver
boards that we can get in onesies for $135 each. Three of these for
attitude reference sure beats a $6K gyro based instrument! However, I'm
concerned that the resolution and response time from GPS won't be good
enough for the purpose.
Again, if anyone has hard data, I'd be most interested.
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Glass Cockpit Requirements |
>>As far as Artificial Horizons and the like, these are major projects in
>>there own right and I would try and buy this as an integrated package from
a
>>company like Crossbow etc. These require a fair amount of accurate
>>numerical integration and other hardware related corrections and
gymnastics.
>>I'm not saying we can't tackle it but we have alot to do already.
>
>Someone needs to go talk to Crossbow. They have a complete AHRS but it
>doesn't use their IFOG technology. Go figure. But, as I recall, they do
>have an inertial reference module that does use their IFOG technology but
>it doesn't predigest the raw data into AHRS data as does their AHRS module.
> Seems that is where we ought to concentrate on Crossbow.
I did talk to Crossbow. Their AHRS unit is about $6K. I have the exact
number I was quoted at the office.
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Notebook Computer Instrument Panel |
>>The notebook computer instrument panel system from LaFave Engineering
>>consists of an analog module that interfaces with system sensors and
outputs
>>data over a serial bus for graphical display on a PC notebook computer
>>running Windows 95/98/NT.
>
>Which means it is totally unsuitable for anything serious.
>
I completely disagree. Windows is in use around the world for "serious"
applications. I don't see anything wrong with Windows other than cost
(versus freeware OSes.)
But I think Brian and I will just have to agree to disagree on this point!
-Matt
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass cockpit: bus hardware |
All,
My goodness, I think I've created a monster!
I think that we all agree, in concept at least, on the overall picture of
our proposed system. Before any development can be done, we do need to work
out the details of these issues we've been batting around. The hardware
communications bus has taken a lot of our bandwidth lately.
My hardware and software experience is limited: I can do PIC programming,
but really haven't advanced above hobbyist level at all. So my opinion is
probably worth less than others.
We've had several proposals for bus design. RS-485 is one candidate.
Ethernet and CANbus are two others. One that no one has proposed that might
warrant consideration is USB. (Just throwing the idea out there.) I had
mentally dismissed Ethernet because I assumed that it would be expensive. I
haven't looked at what's on the market, though, and it might be easy to put
Ethernet on a PIC-based sensor board. RS-485 is certainly cheap, and
debugging could be done with a standard terminal program. No one has
mentioned I2C bus either, which is built in to many PIC chips. Or the SPI
Microwire bus in other micros. Or AppleTalk, etc.
Brian seems to have a wealth of experience and knowledge in this area.
Brian, if you have the time, perhaps you'd be willing to work up a summary
of the pros and cons of each proposed communications bus? I'm prejudiced
because I KNOW that I can quickly and easily get RS-485 to work from a PIC.
I don't have the same confidence in my own ability with Ethernet. Another
attractive feature of RS-485 and Ethernet is that they're built in to many
SBCs. Brian, do you have any references to Ethernet products that we could
interface to a microcontroller?
Processing power on the display side is not a concern to me. Processing
power is cheap and there's plenty of suppliers. It's the sensor side, where
we're going to have limited processing power and will want to reduce cost,
that I'm afraid could get out of hand. Dual RS-485 busses are cheap and easy
to program. Ethernet just scares me because I've never done it before.
RS-232 isn't multidrop, so it's out.
I guess this is a long email just to say that I'm lost on this issue.
Sooner or later, we're going to have to make a decision!
-Matt
========================
"I don't care what anybody says, there ARE user serviceable parts inside. "
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass Cockpit Requirements |
On 14 Nov, Matthew Mucker wrote:
> This is actually an idea that I think has lots of merit. I don't know
> enough about GPS to know how accurate a differential between two antennas
> would be. Does anyone have any hard information? I found GPS receiver
> boards that we can get in onesies for $135 each. Three of these for
> attitude reference sure beats a $6K gyro based instrument! However, I'm
> concerned that the resolution and response time from GPS won't be good
> enough for the purpose.
>
> Again, if anyone has hard data, I'd be most interested.
It doesn't quite work that way. What it does is compare the phase of
the received signal on multiple antennas. Basically this is
interferometry, the same thing the VLA in New Mexico does to get very
high resolution for radio astronomy. So it's not multiple, normal GPS
receivers, it's a special receiver with multiple antennas.
The idea was developed at Stanford a few years ago and, last I heard,
was being commercialized by Seagull Technology (www.seagull.com). I
have no idea what their prices are or if devices are available yet.
This is very cool stuff and the nice thing about a modular design is
that it should be relatively easy to integrate into the system.
-Dave
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass Cockpit Requirements |
Chris,
Don't give up on this yet. I too am very concerned about cost as well as
safety safety. I don't think things like dual busses and multiple
processors have to be expensive. Let's ride it through and see what comes
out of all this.
I'm hoping it will be a well thought out, affordable, extensible, system
spec that we can work from. We do need subthreads though.
John
-----Original Message-----
Sent: Saturday, November 13, 1999 9:20 PM
...
making the project
into a "moonshot" sized affair.
...
I'd love to start a sub-thread to share ideas if there's anyone interested
in the same general theme that I'm going...please respond if you're
inclined.
Chris
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass Cockpit Requirements |
>
>I did talk to Crossbow. Their AHRS unit is about $6K. I have the exact
>number I was quoted at the office.
But we don't really want their existing AHRS module because it doesn't use
their fiber-optic gyro (IFOG) technology. We want their
six-degree-of-freedom (3 axes of IFOG rate gyros and X/Y/Z axis
accelerometers) with their AHRS software built in.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass Cockpit Requirements |
>
>>> - GPS ...
>>
>>... can give us inertial information (AHRS) using multiple antennas.
>
>... I don't know
>enough about GPS to know how accurate a differential between two antennas
>would be. Does anyone have any hard information? I found GPS receiver
>boards that we can get in onesies for $135 each. Three of these for
>attitude reference sure beats a $6K gyro based instrument! However, I'm
>concerned that the resolution and response time from GPS won't be good
>enough for the purpose.
I saw a Long EZ being used by Lockheed for test-bed and surveilance work at
Palo Alto airport a couple years back. They were using GPS for attitude
control of the aircraft (it was a sensor platform). I asked the question
and got the answer that it was accurate on the order of 0.1 degrees in
pitch, and roll. Beats the pants off iron gyros.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | "Chris Atkinson" <chris-atkinson(at)home.com> |
| Subject: | Hobbyists' glass cockpit |
Good to hear from you, John. I've taken the liberty of starting a new
thread so as not to muddle the existing one.
IMHO, a constructive discussion on a project like this should start off with
some talk about what the goals and constraints are. Here's what I came up
with alone:
1) Purpose: To make flight more enjoyable and safer by reducing navigation
workload, by providing automated engine & flight monitoring and by storing
and displaying certain electronic databases and imagery. The key motivation
for the project is to use computer technology to enhance the cockpit and
help the pilot, not to just imitate analog instruments.
2) Reliability requirement: The whole system can crash at any time, but not
so often as to be annoying; Backup instruments must be included to so you
can fly safely for expected conditions. (Mine are VMC). There must be
sufficient engine and flight instrumentation so that the pilot is able, and
expected to, monitor critical aircraft state manually so as to detect any
erroneous information from the glass system before safety is compromised.
3) Total budget requirement: Hardware & purchased software not to exceed
$5k USD. Total time for R&D and initial software development not to exceed
250 hours. No limit on upgrades after its flying!
...constructive comments from anyone are greatly appreciated...would
especially like to hear from anyone with similar interests.
Chris
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
John W Civ ASC/ENFD
Sent: Monday, November 15, 1999 12:45 PM
Subject: RE: Avionics-List: Glass Cockpit Requirements
Chris,
Don't give up on this yet. I too am very concerned about cost as well as
safety safety. I don't think things like dual busses and multiple
processors have to be expensive. Let's ride it through and see what comes
out of all this.
I'm hoping it will be a well thought out, affordable, extensible, system
spec that we can work from. We do need subthreads though.
John
-----Original Message-----
Sent: Saturday, November 13, 1999 9:20 PM
...
making the project
into a "moonshot" sized affair.
...
I'd love to start a sub-thread to share ideas if there's anyone interested
in the same general theme that I'm going...please respond if you're
inclined.
Chris
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Glass Cockpit Requirements |
>I did talk to Crossbow. Their AHRS unit is about $6K. I have the exact
>number I was quoted at the office.
But we don't really want their existing AHRS module because it doesn't use
their fiber-optic gyro (IFOG) technology. We want their
six-degree-of-freedom (3 axes of IFOG rate gyros and X/Y/Z axis
accelerometers) with their AHRS software built in.
Do we want/need the IFOG sensors? If so, why? The Crossbow AHRS unit is
$6500. Their FOG unit is $8000. That's considerable additional expense.
The AHRS unit also has a heading sensor that the FOG unit does not.
The specifications on Crossbow's web site (http://www.xbow.com) don't
include enough information, from what I've seen, to determine the
applicability of their products to certain applications. Also, I don't think
we've defined the requirements for the attitude sensors to the point that we
can evaluate any products to determine if they meet our needs.
From inference between Sierra's web site (http://www.sieraflightsystems.com)
and Watson's web site (http://www.primenet.com/~watgyro/products/ahrs.html),
it appears that the Sierra Flight Systems EFIS products use Watson's AHRS
sensor. Watson's web site does not indicate what kind of technology is in
that box, but it does not mention FOG technology. (Then again, it doesn't
mention any other technology, either.)
-Matt
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Notebook Computer Instrument Panel |
>
>>>The notebook computer instrument panel system from LaFave Engineering
>>>consists of an analog module that interfaces with system sensors and
>outputs
>>>data over a serial bus for graphical display on a PC notebook computer
>>>running Windows 95/98/NT.
>>
>>Which means it is totally unsuitable for anything serious.
>>
>
>I completely disagree. Windows is in use around the world for "serious"
>applications. I don't see anything wrong with Windows other than cost
>(versus freeware OSes.)
Sure it is in use for "serious" applications (depending on your definition
of serious) but not for life-critical applications. It just isn't used
where a BSOD might threaten a life. A BSOD while I am in the soup is life
threatening.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit: bus hardware |
>
>Brian seems to have a wealth of experience and knowledge in [the buss] area.
>Brian, if you have the time, perhaps you'd be willing to work up a summary
>of the pros and cons of each proposed communications bus?
Maybe. Dave is good in this area (probably better'n me). I will take a
stab at it tho'.
>I'm prejudiced
>because I KNOW that I can quickly and easily get RS-485 to work from a PIC.
And that is really valuable. Fixing the RS-485 problems might just involve
creating an RS-485 hub and now you have equalled or surpassed the
complexity of ethernet. OTOH, gluing two ethernets to a PIC is more
expensive than the PIC itself.
>I don't have the same confidence in my own ability with Ethernet. Another
>attractive feature of RS-485 and Ethernet is that they're built in to many
>SBCs. Brian, do you have any references to Ethernet products that we could
>interface to a microcontroller?
I am familiar with a number of ethernet chips and chipsets.
You know, we might just talk about multiple buss types using a common
messaging. Why not do the AOE (avionics over ethernet), AO485 (over
RS-485), AOC (CAN buss), AOU (USB), etc.? The messages would be the same
just the media would be different.
For instance, I would not be uncomfortable with the engine monitor on a
single RS-485 connection. I would probably be more sensitive about my air
data computer but two RS-485 connections would make me happy. I am going
to get downright picky about how I transport my NAV and AHRS data.
>Processing power on the display side is not a concern to me. Processing
>power is cheap and there's plenty of suppliers. It's the sensor side, where
>we're going to have limited processing power and will want to reduce cost,
>that I'm afraid could get out of hand. Dual RS-485 busses are cheap and easy
>to program. Ethernet just scares me because I've never done it before.
>RS-232 isn't multidrop, so it's out.
If you have ever tried to write drivers for something like PPP or SLIP vs.
Ethernet, you will find that, for packetized data, an ethernet driver is a
lot simpler.
As for multidrop RS-232, it is possible but it is a hack. It requires a
couple of resistors and a couple of diodes. But if you create the
equivalent of a hub/bridge for RS-232/423 you can get rid of some of the
problems. You can also get rid of the problem of someone who grabs the
buss and doesn't let go.
>I guess this is a long email just to say that I'm lost on this issue.
>
>Sooner or later, we're going to have to make a decision!
We can actually punt the actual buss itself if we first settle on message
and packet formats. We can do initial testing with RS-232 or existing
ethernet while we settle on the final physical buss.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Hobbyists' glass cockpit & Doc Draft |
Chris,
I am working on a draft Glass Cockpit document (Draft 1) based on the
discussions of this group. In it I am trying to capture all of the various
inputs from everyone and condense and organize it into a readable form.
It's aim will be to provide the information needed to develop a Class
Cockpit with supporting objectives, tradeoffs and rational, etc. I will put
it in the Matronics ftp site shortly and continue to update it. The problem
is everyone talks faster than I can sort it out. I am putting your goals
and constraints in; they appear completely compatible with mine and most of
the groups, as best I can tell. I think that $1,000 for a VFR system with a
simple turn & bank(no AI) should be achievable. I will continue to try and
capture everyone's objectives and concerns.
John
-----Original Message-----
Sent: Monday, November 15, 1999 2:40 PM
Good to hear from you, John. I've taken the liberty of starting a new
thread so as not to muddle the existing one.
IMHO, a constructive discussion on a project like this should start off with
some talk about what the goals and constraints are. Here's what I came up
with alone:
1) Purpose: To make flight more enjoyable and safer by reducing navigation
workload, by providing automated engine & flight monitoring and by storing
and displaying certain electronic databases and imagery. The key motivation
for the project is to use computer technology to enhance the cockpit and
help the pilot, not to just imitate analog instruments.
2) Reliability requirement: The whole system can crash at any time, but not
so often as to be annoying; Backup instruments must be included to so you
can fly safely for expected conditions. (Mine are VMC). There must be
sufficient engine and flight instrumentation so that the pilot is able, and
expected to, monitor critical aircraft state manually so as to detect any
erroneous information from the glass system before safety is compromised.
3) Total budget requirement: Hardware & purchased software not to exceed
$5k USD. Total time for R&D and initial software development not to exceed
250 hours. No limit on upgrades after its flying!
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Hobbyists' glass cockpit |
>
>2) The whole system can crash at any time, but not
>so often as to be annoying;
Somehow, the word "crash" takes on a whole new meaning when describing
flight instrumentation.
Even so, the only reason there should ever be for a "crash" is hardware
failure.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass Cockpit Requirements |
>
>Do we want/need the IFOG sensors? If so, why?
Collins has proven to me that the Systron Donner gyros are good enough but
I am not convinced that the gyros in the Crossbow AHRS are. I am probably
being overly conservative.
I was actually thinking about a limited INS to provide uninterrupted
guidance to ride through NAV info glitches. I have this dream that it
would be good enough to complete an ILS to CAT-I minimums if all my nav
info failed inside the FAF.
>The Crossbow AHRS unit is
>$6500. Their FOG unit is $8000. That's considerable additional expense.
>The AHRS unit also has a heading sensor that the FOG unit does not.
I know. I want IFOGs but the AHRS is probably good enough for now.
>The specifications on Crossbow's web site (http://www.xbow.com) don't
>include enough information, from what I've seen, to determine the
>applicability of their products to certain applications.
We discovered that awhile back too.
>Also, I don't think
>we've defined the requirements for the attitude sensors to the point that we
>can evaluate any products to determine if they meet our needs.
You are probably right.
>From inference between Sierra's web site (http://www.sieraflightsystems.com)
>and Watson's web site (http://www.primenet.com/~watgyro/products/ahrs.html),
>it appears that the Sierra Flight Systems EFIS products use Watson's AHRS
>sensor. Watson's web site does not indicate what kind of technology is in
>that box, but it does not mention FOG technology. (Then again, it doesn't
>mention any other technology, either.)
I have been tyring to find out what Archangel is using for an AHRS and
can't find out about that either.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit Requirements |
On 15 Nov, Matthew Mucker wrote:
> Do we want/need the IFOG sensors? If so, why? The Crossbow AHRS
> unit is $6500. Their FOG unit is $8000. That's considerable
> additional expense. The AHRS unit also has a heading sensor that
> the FOG unit does not.
[...]
>>From inference between Sierra's web site
> (http://www.sieraflightsystems.com) and Watson's web site
> (http://www.primenet.com/~watgyro/products/ahrs.html), it appears
> that the Sierra Flight Systems EFIS products use Watson's AHRS
> sensor.
I talked to Sierra Flight System's two summer's ago at Oshkosh and
they were using Crossbow's stuff. This summer they were using
something else, the price of their unit had doubled, and I became more
interested again in building my own. They said they thought they were
going to be able to compensate for the cheaper gyros in software but,
in the end, gave up on it.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit Requirements |
On 15 Nov, Brian Lloyd wrote:
> I have been tyring to find out what Archangel is using for an AHRS
> and can't find out about that either.
I asked the guy in the Archangel booth this summer at Oshkosh and he
didn't want to answer. Probably because of people like us. He said
it was something they built themselves but I couldn't find out any
more than that.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass cockpit: bus hardware |
On 14 Nov, Matthew Mucker wrote:
> My goodness, I think I've created a monster!
Take it as an indication that a lot of people are really interested in
this idea.
> Brian, if you have the time, perhaps you'd be willing to work up a
> summary of the pros and cons of each proposed communications bus?
I'll take a quite stab at this for a few busses. I know the most
about RS-485 and ethernet so others will get somewhat short changed.
RS-485
Pro: seems simple
could be acceptable to the FAA (I know some people don't care
about this)
no hub needed
good noise immunity
Con: slow
potentially heavy interrupt load on processor
limited number of devices on bus (though I think there are newer
driver chips that allow up to 128 instead of only 32 devices)
many multi-drop -485 busses assume a central control for access
control (or am I confusing -485 and -422?)
Ethernet
Pro: fast
usually much easier to program
already designed to be a distributed, no central control (this
is probably the biggest advantage I see)
good noise immunity
Con: perceived as expensive
FAA certification appears extremely unlikely
hub (I'm assuming 10baseT, the hub is also a pro in that it's a
place to provide protection against jabbering nodes but it's
also an added box you have to worry about, pay for, install,
etc)
not feasible for PICs, maybe not even for 68HC11 or 8052
class processors
Note: Regarding the cost. People are selling ISA ethenet cards for
$19.95 so ethernet in and of itself doesn't have to be all that
expensive. That is if we're talking about rolling our own
hardware and we're talking about processors with enough
horsepower to handle an ethernet. If not, I haven't yet found
_any_ SBCs with two ethernets. You could put two PC/104
ethernet cards in a PC/104 based design but those things are
sure expensive for some reason.
RS-232
Pro: it's on just about everything
Con: poor noise immunity
the hardware is basically identical to RS-485 (different driver
chip) so why bother
SPI
If this is what I think it is, it's a polled system from a
central unit which also supplies the clocking. I think you
daisy chain out-lying devices together so if you lose one in the
middle, you lose everything beyond that.
Appletalk
Isn't this RS-485? Might be a really good idea.
I2C, CANbus, and USB
I don't know anything about these.
> Sooner or later, we're going to have to make a decision!
Very true. My opinion is that we ought to assume multiple RS-485
busses and proceed with the rest of the design. Simple sensor
processors only transmit on one bus. More complex units may listen on
one and transmit on another. Display units listen on two. This may
not be the right way to break things up but the hardware is simple
enough I think and figuring out if it's right is a good next step in
the design process.
-Dave
________________________________________________________________________________
| From: | Warren Gretz <gretz_aero(at)h2net.net> |
list-aviation ,
list-avionics ,
list-beech ,
list-cessna ,
list-ez ,
list-glasair ,
list-homebuilt ,
list-kolb ,
list-lancair ,
list-piper ,
list-rocket ,
list-rvcanada ,
list-seaplane ,
list-tailwind ,
list-warbird ,
list-yak ,
list-zenith
| Subject: | Heated Pitot Tubes |
Greetings to the List,
I just received a new supply of heated pitot tubes. They are the
PH502-12CR (this used to be called the AN5812), and the AN5814-1. Both
styles of these pitot tubes are 12 volt and only come in a chrome
finish. The PH502-12CR has only the dynamic source for the air speed
indicator, but the AN5814 has a heated static source as well and it
looks good. I sell the PH502-12CR for $135 and the AN5814 is $199.
I also sell the mounting bracket kits to hold the pitot to your
aircraft. These are also available in the same chrome finish as the
pitot tubes to make a beautiful installation. These mouning bracket kits
come with all the parts needed for the installation and come with some
detailed instructions and photos of the process. This kit will work on
either a metal airplane or composite. The price of the mounting bracket
kits is $105.
All of my prices INCLUDE shipping in the US.
I have other products that may be of interest to you. If you would like
a set of flyers on my products, provide me with you US Postal Mail
address and I will send you a set.
Warren Gretz
Gretz Aero
3664 East Lake Drive
Littleton, CO 80121
303-770-3811
gretz_aero(at)h2net.net
________________________________________________________________________________
| From: | "Dan Morris" <morristec(at)icdc.com> |
| Subject: | Re: Glass Cockpit Requirements |
Hello to the avionics list,
I've been monitoring this thread for a while and find this somewhat
interseting as I have been involved in the development and certification of
similar systems. Typically I get involved with the system integration to
the flight environment, human factors, FMECA, and system safety analysis.
When you guys get to a point where these thinge need to be considered I
would be happy to contribute.
Dan Morris
----- Original Message -----
From: <N13eer(at)aol.com>
Sent: Sunday, November 14, 1999 8:37 PM
Subject: Re: Avionics-List: Glass Cockpit Requirements
>
> In a message dated 11/13/99 7:14:41 PM Central Standard Time,
> barlow(at)thegrid.net writes:
>
> << The primary issue, IMHO, is fault
> containment. Things break, it's a fact of life. You can't just reboot an
> airplane in flight. This sort of system MUST be designed so that no
single
> point failure can take out the whole system. >>
>
> Not only fault containment but the system has to let the operator know
that
> something is going on and not to trust the readings. In Biz jets there is
> two of everything and the values are compared if they are not close enough
a
> message is posted to the pilot. Then the pilot has to figure out which
> numbers to use. In a small single engine airplane this might be overkill
but
> fault detection must be present at some level.
>
> Alan Kritzman
>
>
________________________________________________________________________________
| From: | "Matthew Mucker" <mmucker(at)airmail.net> |
| Subject: | Re: Glass cockpit: bus hardware |
>> Sooner or later, we're going to have to make a decision!
>
>Very true. My opinion is that we ought to assume multiple RS-485
>busses and proceed with the rest of the design. Simple sensor
>processors only transmit on one bus. More complex units may listen on
>one and transmit on another. Display units listen on two. This may
>not be the right way to break things up but the hardware is simple
>enough I think and figuring out if it's right is a good next step in
>the design process.
>
> -Dave
>
Damn, I love it when someone makes a decision! Since I have yet to hear a
good argument against it, hows about we plan on RS-485?
Next topic seems to be message format.
-Matt
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Hobbyists' glass cockpit |
John,
Speaking of verbose old farts... I am even more verbose... I apologise in
advance for the length of this message, but please read on to see where I
am coming from...
>I am working on a draft Glass Cockpit document (Draft 1) based
>on the discussions of this group. In it I am trying to capture all of
>the various inputs from everyone and condense and organize it into
>a readable form. It's aim will be to provide the information needed
>to develop a Glass Cockpit with supporting objectives, tradeoffs
>and rational, etc. I will put it in the Matronics ftp site shortly and
>continue to update it. The problem is everyone talks faster than I
>can sort it out. I am putting your goals and constraints in; they
>appear completely compatible with mine and most of the groups,
>as best I can tell. I think that $1,000 for a VFR system with a
>simple turn & bank(no AI) should be achievable. I will continue to
>try and capture everyone's objectives and concerns.
The hopes of all of us working on the "more complex and expensive" system
is to design an architecture that supports both the advanced glass cockpit
designs that some people want, with gyro based instruments and full
situational awareness (one person mentioned TCAS and such), as well as a
simpler systems which may only do engine instrument analysis and a moving
map display (which, even given our current design philosophy, should fall
within your guidelines).
The idea is that we all develop our pieces around one common standard. I
anticipate that the hardware for the basic system (avionics bus) will be
reasonably inexpensive (almost a trivial expense). It is the advanced
instruments (the AHRS gyro) and complex displays which would be more
costly. You can buy as much or as little as you want, and it all works
together...
Please stay with the rest of us... if we can produce a spec for this low
cost bus, then it is in everyone's best interest to work from the same
specs... it would allow interoperability and an upgrade path from the
simpler, less expensive systems to a more advanced system down the road.
My 801 does not need much of the instrumentation that some of these guys
are talking about, I could do with a less sensitive altimeter than the guy
with the pressurized cabin, but I want the interoperability. I like the
fact that we can work together on one piece of software for the display
that will work to either altimeter (because they use a common hardware
interface).
Wouldn't it be nice to be able to add some of the flight instruments, such
as an altimeter, or perhaps an interface to your conventional NAV radios,
at a later date? Can't afford a pretty color moving map right now? Use a
simple monochrome display for now and add it later... one could even
build an interface to a palm pilot or some such, if their current needs
were small... but be able to add a new interface later.
>The problem is everyone talks faster than I can sort it out.
I agree... it's been difficult to keep up (and I still have 60 messages in
my inbox to be assimilated into the draft) please see the document I've
been maintaining...
http://www.tzogon.com/~steve/glass_cockpit
Steve Devine
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Hobbyists' glass cockpit |
Steve,
My responces start with >>>...
You wrote:
The hopes of all of us working on the "more complex and expensive" system
is to design an architecture that supports both the advanced glass cockpit
designs that some people want, with gyro based instruments and full
situational awareness (one person mentioned TCAS and such), as well as a
simpler systems which may only do engine instrument analysis and a moving
map display (which, even given our current design philosophy, should fall
within your guidelines).
>>> I understand and agree. I see this as the biggest benefit of this
effort.
The idea is that we all develop our pieces around one common standard. I
anticipate that the hardware for the basic system (avionics bus) will be
reasonably inexpensive (almost a trivial expense). It is the advanced
instruments (the AHRS gyro) and complex displays which would be more
costly. You can buy as much or as little as you want, and it all works
together...
>>> I'm with you! Sometimes all the high tech talk leads people to believe
its high bucks as well. It needs to be kept clear that low cost and good
design are not exclusive. In the draft document I am trying to work in
everyones concerns and inputs as well as I can. So far Cost and Safety are
both highlighted as well as the technical issues.
Please stay with the rest of us... if we can produce a spec for this low
cost bus, then it is in everyone's best interest to work from the same
specs... it would allow interoperability and an upgrade path from the
simpler, less expensive systems to a more advanced system down the road.
>>> I'm not going anywhere. Just trying to keep others with us. I think
that a document describing the objectives, goals, requirements, ilities,
tech details, etc. will help. In fact I believe you have just supplied a
good bit of the objectives section.
My 801 does not need much of the instrumentation that some of these guys
are talking about, I could do with a less sensitive altimeter than the guy
with the pressurized cabin, but I want the interoperability. I like the
fact that we can work together on one piece of software for the display
that will work to either altimeter (because they use a common hardware
interface).
>>> Understand. By the way, I've done some research into the latest crop of
electronic pressure transducers. This as well as other sensor specs will be
included. Also, what the aircraft systems require in the way of accuracy
and update rates.
Wouldn't it be nice to be able to add some of the flight instruments, such
as an altimeter, or perhaps an interface to your conventional NAV radios,
at a later date? Can't afford a pretty color moving map right now? Use a
simple monochrome display for now and add it later... one could even
build an interface to a palm pilot or some such, if their current needs
were small... but be able to add a new interface later.
>>> Again, My view exactly. My background is Aircraft "Systems" Design and
my interest and vocation is in capturing, clarifying and quantifying the
effort from the initially vague desires and needs down to the hoary details,
options and tradeoffs of design and back up to the requirements and final
products. I hope I can help a little. In that reguard.
>The problem is everyone talks faster than I can sort it out.
I agree... it's been difficult to keep up (and I still have 60 messages in
my inbox to be assimilated into the draft) please see the document I've
been maintaining...
>>> I've been reading your document and hope we can cooperate and converge
on a single one. I hope you steal what ever you want from mine, I know I
will be from yours:-)
http://www.tzogon.com/~steve/glass_cockpit
Steve Devine
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit: hardware |
On 14 Nov, Jeff Barlow wrote:
> Lately I've even gotten to where I can even solder those little tiny
> flat pack IC's without shorting the pins.
I'm impressed. I just built a K2 kit (all band HF ham transceiver)
and one of its selling points was that it had no surface mount stuff.
> However, if I'm the only one, I better be careful about what I'm
> signing myself up for. For example, doing a six layer circuit board
> layout is not my idea of a good time. I keep hoping another EE type
> will show up here.
I assume if we design anything that hairy, we'll want to farm out the
production but that seems like a big step to one like me who's never
done anything like that.
So I've been thinking a little about what hardware we'd need to get
started with this and decided that three devices would go a long ways.
The first is a generic sensor procesesor. This has some number (to be
determined) of analog inputs and it just digitizes those analog
signals, tags them, and puts the information out on the sensor bus.
The analog inputs should be configurable to handle resistance or
voltage sensors of the types we're likely to use. It seems this
should be doable with a PIC, an RS-485 driver, and a handful of other
parts. A pretty reasonable hobbyist project.
The second is even simpler, a processor that interfaces between an
RS-232 data source and the sensor bus. Its first use would be to hook
a GPS receiver into the system but the Crossbow AHRS has a -232 output
as well as devices like Rocky Mountain Instruments air data sensor and
engine monitor and others. Again, a PIC ought to be sufficient.
Those little buggers seem to be showing up in everything these days.
The third of course is the MFD and it's not so simple or cheap.
Here's one example of something we could just buy instead of build.
http://www.advantech.com/products/panel_pc/ppc-60.htm
http://adirect.advantech.com/pdf/PPC-60.pdf
It's problems are the screen is not nearly bright enough, it runs off
24vdc, it's only got one -485 interface, and it exceeds the VFR for
under $1k budget. But it is color and has a touch screen. I could
see wanting to add a shaft encoder or two and maybe some buttons if
the touch screen didn't work out so well. Another PIC maybe? It
could also handle listening to the second -485 bus and then talk to
the 386 over the -232 line or even the parallel port.
Note, if we went with this add-on PIC to the main MFD computer, it
could also be attached to any old laptop for development or
experimenting thus keeping the initial investment down.
Beyond those there are all sort of fun possibilites like head mounted
displays, an IR interface so I can download flight plans from my Palm
Pilot and upload engine trend data, and a really neat blind,
multi-channel nav receiver with on-board DSP and a direct connect to
the sensor bus. But just those three devices would suffice to build a
very capable system I think.
-Dave
________________________________________________________________________________
| From: | Jeff Hays <jshays(at)interaccess.com> |
| Subject: | Encoder Output Question |
Can anybody tell me if I can parrallel the output from my AK-350 encoder
to both my GPS, and Transponder? The signal lines in are both the same
for the GPS (gnc-250xl) and the transponder (gtx-320). I currently have
the encoder tied only to the transponder.
Thanks, Jeff Hays.
________________________________________________________________________________
| From: | Gordon Koo <koogordn(at)pgbgroup.com> |
| Subject: | Re: Glass Cockpit Requirements |
Brian,
Doing the layout is actually relatively easy with the PCB software available
these days. The real art is being able to make it all fit in two layers as
opposed to four layers or four layers as opposed to six or eight layers. In the
low volume market, layer quantity is less stressed as quantity savings is
limited. So I would be happy to volunteer layout services if a design is
provided for layout. I can't guarantee how quickly I can perform the layout
since I am a contract consultant but I would be happy to give you all a hand if
and when the time comes in my spare available time.
I would be happy to provide system design support from the standpoint of system
integration and computer design support especially in the area of system design
specification again as my time permits.
Gordon Koo
P & G Business Group
Starting build of Zenith CH801
Brian Lloyd wrote:
>
> >
> >Yeah, been doing it most of my life. Built radio transmitters out of old TV
> >set parts (tubes) when I was in high school.
>
> We must be about the same age then.
>
> >Lately I've even gotten to
> >where I can even solder those little tiny flat pack IC's without shorting
> >the pins. However, if I'm the only one, I better be careful about what
> >I'm signing myself up for. For example, doing a six layer circuit board
> >layout is not my idea of a good time. I keep hoping another EE type will
> >show up here.
>
> I am still back in the double-sided-through-hole board days. That is as
> far as I go. 6-layer stuff has to be farmed out.
>
> Brian Lloyd Lucent Technologies
> brian(at)lloyd.com 3461 Robin Lane, Suite 1
> http://www.livingston.com Cameron Park, CA 95682
> +1.530.676.6513 - voice +1.530.676.3442 - fax
>
>
--
Gordon Koo
P & G Business Group, Inc.
1174 Lincoln Ave. Suite 11
San Jose, CA. 95125
Phone : 408-292-8898
Fax : 408-292-8834
Email : koogordn(at)pgbgroup.com
WWW : http://www.pgbgroup.com
________________________________________________________________________________
| From: | Gordon Koo <koogordn(at)pgbgroup.com> |
| Subject: | Re: Glass Cockpit Requirements |
Brian,
One additional aspect which should be considered is peripheral communication
capability, (i.e.-the ability of the controlling processor to communicate with
its devices in a timely and fault-tolerant method). Especially given that the
system needs to communicate with multiple devices (gauges of different types
etc.) It would be a very good thing to create a very low cost interface of some
kind that can be used with a multiple of different sensor type devices that can
communicate to the main control processor through a common interface protocol
or bus. This would isolate analog to digital requirements to a specific type of
design and allow the system to be easily divided down to multiple design
efforts of particular talents. Any thoughts????
Brian Lloyd wrote:
>
> >
> >One more point of view issue: I keep reading "single board computer" in a
> >context that suggests buying same. I tend to naturally think more in terms
> >of buying chips and designing our own boards. Am I the only one?
>
> No. But I do think that prepackaged SBCs are a good place to start on this
> stuff. They let you pick a processor family and try it out before you
> commit to the hardware design. You may want to switch processor families
> after you find out one that you thought would be the right thing turned out
> to be a real pain-in-the-butt to get it to do what you wanted it to do.
>
> >I'm a verbose old fart, aren't I?
>
> Uh, more than me or Dave? I am at least as much a VOF as you are.
>
> Brian Lloyd Lucent Technologies
> brian(at)lloyd.com 3461 Robin Lane, Suite 1
> http://www.livingston.com Cameron Park, CA 95682
> +1.530.676.6513 - voice +1.530.676.3442 - fax
>
>
--
Gordon Koo
P & G Business Group, Inc.
1174 Lincoln Ave. Suite 11
San Jose, CA. 95125
Phone : 408-292-8898
Fax : 408-292-8834
Email : koogordn(at)pgbgroup.com
WWW : http://www.pgbgroup.com
________________________________________________________________________________
| From: | "Chris Atkinson" <chris-atkinson(at)home.com> |
| Subject: | Glass Cockpit: hardware |
Hi guys, I think I'm becoming a convert. Is this the general drift of what
we're talking about so far?:
-Analog sensors are connected to hub-like black box.
-Box does a/d conversion and formats d into to-be-determined protocol and
broadcasts onto -485 bus
-Computer(s) of any sort with any o/s listen to bus and do whatever they
need to do. E.g. interpret data & display it.
-Each analog sensor wire could be split into n forks and connected to n
black boxes if use warrants need for redundancy.
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass Cockpit: hardware |
>Hi guys, I think I'm becoming a convert. Is this the general drift of
>what we're talking about so far?:
>
>-Analog sensors are connected to hub-like black box.
>-Box does a/d conversion and formats d into to-be-determined
>protocol and broadcasts onto -485 bus
>-Computer(s) of any sort with any o/s listen to bus and do whatever
>they need to do. E.g. interpret data & display it.
>-Each analog sensor wire could be split into n forks and connected
>to n black boxes if use warrants need for redundancy.
Exactly what we're talking about. Welcome to the party.
Build as little or as much as you'd like/need, with whatever technology
(architecture/OS) you perfer and/or is in your personal budget...
I like your summary so much I'm adding it to the specs!
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass Cockpit: hardware |
Chris,
You basically got it. You even added a twist I hadn't thought of. Let me
try and clarify a couple of thoughts. I ought to leave this for the
experts, but I can't help myself.
-4 to 16 (to-be-determined) Analog sensors of various types are connected to
various sorts of $20ish SensorBoxes.
-SensorBoxes do a/d conversion and formating of data into (to-be-determined)
protocol and broadcasts onto a -485 bus.
-Computer(s) of any sort with any o/s listen to bus and do whatever they
need to do. E.g. interpret data & display it.
-Each analog sensor wire could be split into n forks and connected to n
black boxes if use warrants need for redundancy. This is a very cheap way to
get redundancy of signals. Way to go Chris.
-Others include: redundant sensors, redundant busses, and various
conbinations of all three. Failure mode analysis will help us sort out what
is the most cost effective conbination of methods for different kinds of
GlassCockpits. (simple to complex).
I just saw that Steve has answered you as well. Hey Steve, I'll download
my draft today. Its still rough but at least I think I have a pretty good
document outline structure and have all the discussion group comments placed
more or less in the right sections. Its a start. Please steal anythin you
like.
John
________________________________________________________________________________
| From: | "Chris Atkinson" <chris-atkinson(at)home.com> |
| Subject: | Glass Cockpit: hardware |
Hi again guys....found this product at http://www.eeci.com/adc-16p.htm. It
might be a $99 solution to the box...I think you just need a case & power
supply to finish....but anything more electrically complicated than Xmas
lights is out of my area so I don't know for sure. Elsewhere in their site
the say there is an optional -485 interface.
Comments? ...I guess there're lots of brands of these around, right?
Chris
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
[mailto:owner-avionics-list-server(at)matronics.com] On Behalf Of Steven J.
Devine
Sent: Wednesday, November 17, 1999 12:27 PM
Subject: Re: Avionics-List: Glass Cockpit: hardware
>Hi guys, I think I'm becoming a convert. Is this the general drift of
>what we're talking about so far?:
>
>-Analog sensors are connected to hub-like black box.
>-Box does a/d conversion and formats d into to-be-determined
>protocol and broadcasts onto -485 bus
>-Computer(s) of any sort with any o/s listen to bus and do whatever
>they need to do. E.g. interpret data & display it.
>-Each analog sensor wire could be split into n forks and connected
>to n black boxes if use warrants need for redundancy.
Exactly what we're talking about. Welcome to the party.
Build as little or as much as you'd like/need, with whatever technology
(architecture/OS) you perfer and/or is in your personal budget...
I like your summary so much I'm adding it to the specs!
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass Cockpit: RS-232 project |
Dave, All,
What are the pros and cons of simply plugging the GPS RS_232 signal in to
the MFD Module's RS-232(serial port). The MFD will be on the buss already,
so couldn't it just send it out if someone else wanted the data? If this
little interface is under 30 dollars, I'll withdraw the suggestion.
John
-----Original Message-----
From: dab(at)froghouse.org [mailto:dab(at)froghouse.org]
The second is even simpler, a processor that interfaces between an
RS-232 data source and the sensor bus. Its first use would be to hook
a GPS receiver into the system but the Crossbow AHRS has a -232 output
as well as devices like Rocky Mountain Instruments air data sensor and
engine monitor and others. Again, a PIC ought to be sufficient.
Those little buggers seem to be showing up in everything these days.
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass Cockpit: RS-232 project |
On 17 Nov, Livingston John W Civ ASC/ENFD wrote:
> What are the pros and cons of simply plugging the GPS RS_232
> signal in to the MFD Module's RS-232(serial port). The MFD will be
> on the buss already, so couldn't it just send it out if someone else
> wanted the data? If this little interface is under 30 dollars, I'll
> withdraw the suggestion.
I suspect (hope?) the -232 to -485 converter could be done for under
$30 but I don't think this is a bad idea anyway.
Two disadvantages come to mind. First you lose a little reliability.
If you have a second display and the one your GPS is plugged into goes
TU, the second one can't get GPS information. Second, it's
architecturally impure. That is, it works once but not a second time
because you've now used up your one RS-232 port. Where are you going
to plug in the RMI uEncoder? That's why RS-232 is the wrong answer in
general.
The advantage is obviously that you don't need another little box to
convert the RS-232 protocol to the RS-485 protocol (hardware protocol
and data format conversion). If you've only got one RS-232 thing to
plug in and only have one MFD, why the heck not use that port? I
certainly see no reason to forbid it. The software ought to support
this.
To allow this, the little processor that I suggested as a piggyback on
the MFD (to give it a second (and third?) -485 bus and to talk to the
buttons and shaft encoders) would be better off talking to the main
processor over the parallel port than the serial port.
Oh, one other disadvantage. I'd proposed a design rule where the
MFD's didn't transmit on the sensor bus, only on the control bus. The
idea was that any given device only was wired to transmit on one bus.
In this way, no single device could jam all the busses by getting
stuck in a transmit loop. And then I came up with a control bus so
the sensor processors who needed contol, only needed to listen to one
bus for their commands. Since they only transmit on one bus, they
should only need one bus interface.
To have your MFD transmit the GPS information, it'd have to be rewired
to allow it to transmit on the sensor bus. This may be doable just by
allowing the bus connector to be wired differently if you want that
configuration. Sure, just wire both connectors to the same bus.
Maybe the control bus idea isn't necessary anyway.
On the other hand, so long as the other MFDs were listening on the
control bus, you could just transmit over that. I figured they'd all
run the same protocol.
-Dave
________________________________________________________________________________
| From: | "Dick Sipp" <rsipp(at)ismi.net> |
| Subject: | Re: Glass Cockpit: hardware |
As an incurable fan of advanced avionics, I've been facinated watching this
project develop. It's a beautiful thing; the talent available in the group
is impressive.
I wish I was qualified to add something technically, but I am not. From an
operational viewpoint and lots of hours in different "glass" cockpit
configurations, I would offer the observation that for displays presenting
multiple functions, moving tapes are a good choice especially when they
include trend indicators. Tapes are intuitive for most pilots and if
carefully designed, i.e. they all move the same way, they are easy to learn
and interpret. Similarly, I believe display control systems that use line
select keys mounted on the display are preferable to remoted systems. The
Sandel HSI display is a good example of this idea. See
http://www.avweb.com/sponsors/sandel/review/ for a complete review.
In another vain, how much concern should be given to the impact on
certification of the aircraft? IFR certification is probably out of the
question for a reasonable priced system, so an aircraft equipped with this
system would likely be VFR only. There might be a question from some FSDO'S
about even the VFR certification if all instrumentation was integrated in a
single system.
Dick Sipp
RV-4 250DS for fun (180 Hours)
GV/Falcon 900EX for a living
________________________________________________________________________________
| From: | James Baldwin <jamesbaldwin(at)attglobal.net> |
| Subject: | Project organization |
Hello to everyone interested in Glass cockpits for light airplanes:
In a former life I was an engineering manager at National
Semiconductor in the Packaging Group. My degree is in Mechanical and
Aeronautical Engineering. I now fly widebody airliners internationally
(747-200,400) and use both glass and conventional panels. I have
engineered embedded projects involving data acquisition and display as a
hobby more recently. I get magazines like "Sensor." I am aware of the
tremendous potential of using microprocessors in the aviation
environment. For instance: halfway across the Pacific in a 747-400 at
37,000 feet, I know someone is smoking in the lav at door 3 left before
the flight attendant calls me. A smoke detector tied into the buss puts
a yellow message up on our CRTs in the middle of the panel. I love
data.
I am very pleased to see the interest and conversation this subject
has started. There are a wide variety of experiences, specialties and
requirements being exposed here and it will all become disjointed and
fractured if someone is not appointed or elected to organize the
tremendous opportunity we all have here. This, I think, could be an
opportunity along the lines of LINUX. An organized standard is set, a
"guard at the gate" is elected/appointed, and the system is flexible
enough to allow almost everyone to contribute and or use the portions of
the system their particular application requires. There is no real
commercial interest with the majority of participants but if someone
were to use it in such an application, it would gradually become a
standard like the ubiquitous MS products. Great! We would all be the
founders of the "standard" and would be confidant that it was done in a
manner which had been well thought out in an engineering sense.
The contributors so far have expressed a lot of ideas but the time is
now here where organization is required if we are to get this project
headed in a direction where there is something for everyone and of a
quality level that is representative of the technology available today.
I have seen contributions so far from (and if I left someone out,
sorry): Matthew Mucker, Jeff Barlow, Steve Devine, Terry Watson, John
Livingston, Brian Lloyd and Dave (DAB) who allowed his code to be
viewed/uploaded. I think Steve even has a Website with some form of
organizational beginning ( I have to go back and review it but what a
great start).
Here is my suggestion:
1. All those mentioned and all the lurkers should ID themselves with a
simple list of skills. (This has been done by many of those mentioned).
2. Interest by an individual in leading this group should be expressed.
3. There should be "campaigning", if at all required, in the form of
posts to this forum.
4. We should arrive at a consensus through this discussion and elect or
appoint a leader who would then channel each discussion component until
he decides which direction we should go. I am specifically avoiding
using a "committee approach" as I have seen things designed by committee
and am not impressed. That's where "CEO" came from -- industry in
general doesn't go for that approach either.
5. Busses, OS, processor type and a BIOS would be decided on and
written and we would get started with the basic elements.
6. Outside vendors would get PCB design layouts from someone with our
"moniker" and it would be available to all. We could pick and choose
the components each individual wanted and constant improvements would be
available to all. (Sounds kinda Socialistic doesn't it?!)
That's a very basic outline start to this exciting subject and rather
than fragmenting our talents, let's put them together in a constructive
and fun manner which complements the great hobby of home-building we all
enjoy so much. Data acquisition is the key to understanding a lot more
of what is going on inside our engines and airframes and the immediate
response seen here is an indication of how easy this can be if we work
together. If the majority of you continue along the lines of discussion
with no organization, I think something will also come out of it. Go
ahead and post what you think -- my feelings will not be hurt because I
think we will eventually get something that works -- I would just like
to optimize our efforts. Thank you for this long post. JBB
________________________________________________________________________________
| From: | Marlin Mixon <myshkin(at)worldnet.att.net> |
| Subject: | Re: Glass Cockpit Requirements |
Gordon Koo wrote:
>
> One additional aspect which should be considered is peripheral communication
> capability, (i.e.-the ability of the controlling processor to communicate with
> its devices in a timely and fault-tolerant method). Especially given that the
> system needs to communicate with multiple devices (gauges of different types
> etc.) It would be a very good thing to create a very low cost interface of some
> kind that can be used with a multiple of different sensor type devices that can
> communicate to the main control processor through a common interface protocol
> or bus. This would isolate analog to digital requirements to a specific type
of
> design and allow the system to be easily divided down to multiple design
> efforts of particular talents. Any thoughts????
>
Hi, I'm new to the list. Before I comment on the above post, I need to
provide a Quickie Intro on what I'm working on because it provides
background for my response:
I've been working independently on an engine monitor for a few months
now. I soldered up a microcontroller (MCU) PCB (Motorola HC11) to be
used as the hub to attach all the engine sensors. My current design
relies on a Palm Pilot for on-panel display. The interface between the
palm pilot and the MCU and the Palm is a fancy cable that performs a TTL
-> RS-232 conversion.
The above posting by Gordon Koo is exactly what I was pondering a couple
of days ago because I'm finding that my design is deficient in that an
HC11 only has eight Analog to Digital Conversion (ADC) pins, and I
really want to monitor 11 or 12 analog inputs (Hey, what if I was
building a P-51 with a V-12 and I wanted to monitor individual cylinder
head temps?). Now I know that there are probably many solutions to this
problem, but Gordon points out that there really should be the ability
for various communicating units to all be transmitting at once. The
problem is, when you've got many units attempting to communicate
simultaneously on a single wire, you get collisions. Now, believe me,
I'm a strong adherent to simplicity, but the only solution I came up
with is some kind of TCP/IP-like idea (Perhaps UDP because UDP is
simpler than TCP/IP).
I won't say anything more on what I was considering because I don't know
how complex this would have to be.
I will say that a great solution would have the following
characteristics:
1. Needs to be simple so it can run on an MCU.
2. Based on some kind of standard (not an aviation standard especially,
but
some kind of industry standard.)
3. Able to handle collisions (this doesn't mean that every piece of
information that is emitted arrives at its destination, it just means
that two pieces of information that happen collide with each other
won't hurt equipment or disrupt communications for very long.
.....or not What do you think all?
Marlin Mixon
________________________________________________________________________________
| From: | Marlin Mixon <myshkin(at)worldnet.att.net> |
| Subject: | Re: Glass Cockpit: hardware |
Dick Sipp wrote:
>
> In another vain, how much concern should be given to the impact on
> certification of the aircraft? IFR certification is probably out of the
> question for a reasonable priced system, so an aircraft equipped with this
> system would likely be VFR only. There might be a question from some FSDO'S
> about even the VFR certification if all instrumentation was integrated in a
> single system.
I may be delusional BUT...
I would think the FSDO would give their blessing to a system like this
especially if your system is clean, demonstrates good
planning and redundancy considerations. Especially because it
shows individual initiative in improving General Aviation in terms of
cost,
safety and technology. Plus I would assume that the political climate
with NASA pushing hard higher technology in all fronts of aviation, it
just seems like the "right thing to do(TM)," so "Just do it(TM)" :)
Marlin Mixon
________________________________________________________________________________
| From: | Marlin Mixon <myshkin(at)worldnet.att.net> |
| Subject: | Re: Project organization |
James Baldwin wrote:
> ... This, I think, could be an
> opportunity along the lines of LINUX. An organized standard is set, a
> "guard at the gate" is elected/appointed, and the system is flexible
> enough to allow almost everyone to contribute...
Random thoughts on the Open Source approach:
I agree that there needs to be someone who leads and decides. And of
course a leader like this could be elected or appointed...but...
Now, Linux started with Linus Torvalds killing time on summer break,
then sparking the interest other folks on the net to where they joined
in. Linus has always been in charge from start to Finnish. :)
Another open source project I'm familiar with is PHP. Rasmus Lehrdorf
developed PHP and now one million sites use PHP as their web server
engine. Rasmus wrote the first line of code and as always been the main
driving force behind PHP. Rasmus is incredible. I've emailed him
several times and, he's answered my email the same day and not just with
a trivial responses either. Rasmus is dedicated, and there's no
question that was and is successful, but I doubt that he has a life!
I think that open source projects are modern miracles. Does anyone
know of any successful open source efforts that have been planned as
such from the beginning, not just lucked into?
The Netscape Development known as Mozilla is a planned open source
effort, but I don't know how successful Mozilla is. You don't hear too
much about it though.
Now that I've re-read what I've written, I think two things can be said,
1. As a group, realize that Open Source approach doesn't guarantee
success.
2. A good leader, one who can almost guarantee successs, is driven
passionately by the goal. He or she can describe or communicate their
vision with others so that they get excited too. They know what to say
to particular individuals that inspire them to to share the passion and
therefore join in the crusade. But isn't that true in any public or
private endevour as well?
Marlin Mixon
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Project organization |
>...I love data.
Yeah, you know it!
>I think Steve even has a Website with some form of organizational
>beginning ( I have to go back and review it but what a great start).
http://www.tzogon.com/~steve/glass_cockpit
I keep it up to date within a day or two... I yank out the more noteworthy
posts and incorporate them immediately. It is pretty much current right
now.
>Here is my suggestion:
>1. All those mentioned and all the lurkers should ID themselves
> with a simple list of skills. (This has been done by many of those
> mentioned).
Here here... I will add all into's to the list on the web site.
>2. Interest by an individual in leading this group should be expressed.
>4. We should arrive at a consensus through this discussion and elect
>or appoint a leader who would then channel each discussion component
>until he decides which direction we should go. I am specifically
>avoiding using a "committee approach" as I have seen things designed
>by committee and am not impressed. That's where "CEO" came from --
>industry in general doesn't go for that approach either.
I don't know if I am qualified to be a leader, but I'm certainly willing
to be the court stenographer...
>6. Outside vendors would get PCB design layouts from someone with our
>"moniker" and it would be available to all. We could pick and choose
>the components each individual wanted and constant improvements would be
>available to all. (Sounds kinda Socialistic doesn't it?!)
I believe that we are all in agreement on this point.
>Data acquisition is the key to understanding a lot more of what is going
>on inside our engines and airframes and the immediate response seen
>here is an indication of how easy this can be if we work together.
I agree wholeheartedly! This is a very viable project. Particularly if
it is partitioned into separate components/subsystems that are easier to
work on independently. That's why the initial decision of standards is
important. If we come up with a hardware/message standard for the bus,
one person/group could be working on a display while another is setting up
the sensors for their engine, another is working on the AHRS gyro, and
another on the pitot/static sensors... etc.
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Glass cockpit - Avweb (MIT) survey |
I snatched this tidbit form AvWeb this morning...
BIG IRON DRIVERS, LISTEN UP: If you pilot an airliner or
bizjet with a "glass cockpit," the International Center for Air
Transportation (ICAT) at MIT wants to hear from you. MIT
is conducting an Internet-based survey on the complexity
of autoflight systems in modern aircraft. The survey needs
the input of experienced pilots to identify the aspects of
current designs that can be improved upon in future aircraft.
The survey should take approximately 20 to 30 minutes to
complete. Help them (and yourself) out at <http://snipe.mit.edu>.
I wonder if we could get any info on the results of the survey? Perhaps
it might also help us out in our own endeavor when we get to the user
interface/ergonomic side of things?
Steve
Steven J. Devine, President, Consultant
TZOGON Enterprises Incorporated
steve@tzogon.com HAM Tech lic: N1YZJ http://www.tzogon.com
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass Cockpit: hardware |
On 17 Nov, Dick Sipp wrote:
> I wish I was qualified to add something technically, but I am not.
> From an operational viewpoint and lots of hours in different "glass"
> cockpit configurations, I would offer the observation that for
> displays presenting multiple functions,
This sure sounds like a technical contribution to me. Please
continue. I've only eve seen pictures and dreamed of having this kind
of capability.
> moving tapes are a good choice especially when they include trend
> indicators. Tapes are intuitive for most pilots and if carefully
> designed, i.e. they all move the same way, they are easy to learn
> and interpret.
I'm curious which way is the right way for a tape to move. My
instinct would be that the altitude tape moves down to indicate
increasing altitude and the airspeed tape moves down to indicate
increasing airspeed.
I can see that a tape might be easier to show a trend indicator on.
> Similarly, I believe display control systems that use line select
> keys mounted on the display are preferable to remoted systems. The
> Sandel HSI display is a good example of this
> idea. See http://www.avweb.com/sponsors/sandel/review/ for a
> complete review.
I read the Sandel review and see some UI stuff that looks really good.
I like the giant red X over the CDI and glideslope indicator if you
lose signal and the compass rose color change to indicate loss of gyro
sync. But I don't quite understnad what you mean by "line select
keys". Those must be the nine buttons around the instrument but I'm
not sure what you're saying is good about them or what the less good
thing is that you're comparing them too.
> In another vain, how much concern should be given to the impact on
> certification of the aircraft? IFR certification is probably out of
> the question for a reasonable priced system, so an aircraft equipped
> with this system would likely be VFR only. There might be a question
> from some FSDO'S about even the VFR certification if all
> instrumentation was integrated in a single system.
There's quite a problem with educating the FAA in how a properly
designed system can be more reliable than separate devices and can
have much more graceful degradation in the face of component failure.
I'm not the one to do this since I think the FAA stands squarely in
the way of improved safety of GA so I'd just get mad and yell at them.
-Dave
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Glass cockpit survey |
Well, guys, looks like we may be able to get some information and/or
recommendations from Sanjay's survey...
>>
>>
>>If it is at all possible, I would be very interested to read some of
>>your analysis of existing systems, and perhaps some of the
>>feedback that you receive... I would like to share it with the rest
>>of the group, and perhaps incorporate any recommended changes
>>into our design.
>>
>>Thank you for your time. I look forward to hearing any responses
>>you may have.
>
>I'd be happy to share my results. I'll send out a summary email after
>some analysis has been completed.
>
>sanjay
OK, perhaps I use the word "perhaps" too much. Perhaps it was due to the
fact that I reorganized things during the draft. Perhaps.
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass Cockpit: hardware (UI and TSO) |
>> moving tapes are a good choice especially when they include
>> trend indicators. Tapes are intuitive for most pilots and if carefully
>> designed, i.e. they all move the same way, they are easy to learn
>> and interpret.
>
>I'm curious which way is the right way for a tape to move. My
>instinct would be that the altitude tape moves down to indicate
>increasing altitude and the airspeed tape moves down to indicate
>increasing airspeed.
This sounds logical to me... and seems to be correct given my vast
experience in playing PC fighter games with HUD's :-)
But also, we don't have to have (and indeed don't want to have) one set
display... this puppy needs to be configurable such that it fits different
builders' requirements. So that might be a run-time configuration
setting...
For flight instruments, I personally would set it up much like the "HUD"
on fighter games, with the attitude indicator in the center, and tapes
along the sides (altitlude & VSI on one side, airspeed on the other, and
the DG heading along the top)...
Others have indicated a desire for more a conventional representation,
such as dial type indicators...
>> Similarly, I believe display control systems that use line select
>> keys mounted on the display are preferable to remoted systems. The
>> Sandel HSI display is a good example of this
>> idea. See http://www.avweb.com/sponsors/sandel/review/ for a
>> complete review.
>
>But I don't quite understnad what you mean by "line select keys".
>Those must be the nine buttons around the instrument but I'm not
>sure what you're saying is good about them or what the less good
>thing is that you're comparing them too.
Yes, he is referring the keys along the edge of the display... I think
he's trying to say that having the input control immediately next to the
display is far better than the standard PC style, with a keyboard here...
monitor over there... mouse over here...
The buttons would work like the four or so buttons on an ATM (cash
machine)... their meaning will vary depending on context (what you are
doing/what is on the display), and would typically be set by the software
and displayed right on the screen (where the line points?).
The major benefit is marrying the data being displayed, your input
choices, and the controls into one unit. You don't have to look/reach all
around the panel to accomplish a task... K.I.S.S.
>> In another vain, how much concern should be given to the impact on
>> certification of the aircraft? IFR certification is probably out of
>> the question for a reasonable priced system, so an aircraft equipped
>> with this system would likely be VFR only. There might be a question
>> from some FSDO'S about even the VFR certification if all
>> instrumentation was integrated in a single system.
>
>There's quite a problem with educating the FAA in how a properly
>designed system can be more reliable than separate devices and can
>have much more graceful degradation in the face of component failure.
>I'm not the one to do this since I think the FAA stands squarely in
>the way of improved safety of GA so I'd just get mad and yell at them.
Way over my head... anyone out there able to provide some more insight as
to IFR/TSO certification? I would imagine that everything would have to
be certified as separate components...
* the architecture itself (bus hardware and protocols must
meet certain requirements)
* each individual sensor (array) and display unit must get
approval
But that's just a guess. FWIW, I might be interested in certification of
at least the components required for IFR... depending on cost and other
issues...
Steve
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | GlassCockpit Word Doc |
Steve, All,
Here is where I'm at on my attempt to try an organize and document our
efforts. I have outlined it using MS Word's heading system so you might
want to view it in outline mode first to see how it is organized. I have
stolen from everyone, twisted your words, added my own. I have tried to
include most of the concerns voiced during our discussions. I don't have to
many diagrams or pictures yet, but I hope to add more as we work. I've added
a little sensor data that I had gathered and places to put lots of things we
are going to need in the near future. If you can add or correct any of the
sections please do so. A document like this and Steve's website are never
completely right or done. Please tear it to shreds, that's what its for.
ftp://ftp.matronics.com/pub/Public/John.Livingston(at)wpafb.af.mil/GlassCockpit
Nov17.doc
________________________________________________________________________________
| From: | dralle(at)matronics.com (Matt Dralle) |
"RE: Avionics-List: GlassCockpit Word Doc" (Nov 18, 11:55am)
| Subject: | GlassCockpit Word Doc |
>--------------
>
>Steve, All,
>
> Here is where I'm at on my attempt to try an organize and document our
>efforts. I have outlined it using MS Word's heading system so you might
>want to view it in outline mode first to see how it is organized. I have
>stolen from everyone, twisted your words, added my own. I have tried to
>include most of the concerns voiced during our discussions. I don't have to
>many diagrams or pictures yet, but I hope to add more as we work. I've added
>a little sensor data that I had gathered and places to put lots of things we
>are going to need in the near future. If you can add or correct any of the
>sections please do so. A document like this and Steve's website are never
>completely right or done. Please tear it to shreds, that's what its for.
>
>ftp://ftp.matronics.com/pub/Public/John.Livingston(at)wpafb.af.mil/GlassCockpit
>Nov17.doc
>--------------
Here's the clickable link:
ftp://ftp.matronics.com/pub/Public/John.Livingston(at)wpafb.af.mil/GlassCockpitNov17.doc
Matt
--
Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551
925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email
http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass Cockpit: Glass Cockpit Doc |
ftp://ftp.matronics.com/pub/Public/John.Livingston(at)wpafb.af.mil/GlassCockpit
Nov17.doc
________________________________________________________________________________
| From: | Marlin Mixon <myshkin(at)worldnet.att.net> |
I've programmed for 20 years, applications and now internet
programming. I've done a lot of work with Linux (Admin, programming,
networking) and also NT. In addition to know several archaic and arcane
computer languages, I've programmed in C, Visual Basic, PowerBuilder,
awk, and Perl, I'm learning Java programming right now. I'm also aware
of the power of Tk, which is an open-source, platform-independent
graphics library that's design to interface with scripting languages
such as Perl (though originally interfaced with tcl) that might possibly
find use in this avionics project. (I haven't used it much though).
I'm also doing work with Electronic Data Interchange (programs that
output data that is destined for other programs to read). I'm
interested in learning more about XML for data interchange and
information storage.
I'm interested in the Open Source paradigm and have had some minor
involvement in open source development projects.
I've recently rediscovered soldering. I constructed a little robot MCU
board from a kit (It's a BotBoard Plus from the Seattle Robotics
Society) that I was hoping to use as a basis for an engine monitor. The
BotBoard Plus uses a Motorola HC11. I'm also learning a little about
electronics--finally discovered what a transistor does and how an Op-Amp
does it better. On really good days I sort of understand Ohm's Law!
A couple of weeks ago, in working on my engine monitor, I bought an
automotive thermosensor and went to town measuring it's variable
resistivity under different water temperatures--I delight in
discovery!--Then I figured out what value of resistor I'd need in order
to set up a little Op-Amp circuit that would tie the thermosensor to my
BotBoard.
Marlin Mixon
________________________________________________________________________________
| From: | "Terry Watson" <tcwatson(at)seanet.com> |
| Subject: | Powersport's glass cockpit |
Here's another glass cockpit product under development:
http://www.powersportaviation.com/Home/Engines/glass.htm
Terry
________________________________________________________________________________
| From: | "Joe Hovel" <joe.hovel(at)med.monash.edu.au> |
Hi,
by recent messages I've been compelled to introduce myself and why I have
been lurking for a while....
I have nothing whatever to do with the aviation industry but am a keen PPL
and U/L pilot - I own a single seat high performance U/L the Winton
Sapphire, which has very little panel space, very little cockpit space
overall but is extremely comfortable for the pilot and a very capable
cross-country aircraft (there are people her in Australia who have flown
Sapphires for several thousand mile trips!).
Because of the small cockpit space, it is very difficult to manoeuvre
multiple maps in flight.
My professional activities include teaching health informatics and that
resulted from keen (user-level) involvement in computer and software design.
I have a little programming experience, but am more the "ideas man" and
write software specs and supervise programmers.
I have followed the developments of GPS and moving map options for quite a
while and recently bought a Toshiba Libretto palmtop (real computer, Pentium
with hard disk etc) and interfaced it with my non-aviation Garmin II+ with
some moving map software, only to be blown away by the convenience. This
thing has many drawbacks, especially the poor daylight display, but it
showed the way.
I've created a "private sports pilots" aviation database for non-aviation
GPS receivers which has been enthusiastically adopted by many U/L pilots
here (www.med.monash.edu.au/crh/personnel/joeh/waypoints.htm) I also
experimented with some software which uses the in-built sound card's two
channel AD converter and interfaced it to a couple of automotive sensors
just to try it.
That also demonstrated some potential....
So my interests are in particular: small size, low weight (and reasonably
low cost), but not necessarily certification - our authorities here allow
quite a bit of innovation in homebuilt U/L and GA experimental categories -
good test platforms for aviation advancement!
I'll continue lurking and make the odd comment if something strikes chord.
Ok?
While I have no electronic engineering background, I have a hand for
electronic projects, circuit board design and prototyping (never yet in
avionics - only audio and PC interfaces).
I look forward o the day when some circuit designs come out of this exciting
group's discussions!
Joe Hovel
Senior Lecturer
Centre for Rural Health & Centre of Medical Informatics
Monash University
===========================================
www.med.monash.edu.au/crh
www.monash.edu.au/informatics
________________________________________________________________________________
| From: | "Larry Bowen" <Larry(at)BowenAero.com> |
| Subject: | Capacitance Fuel gauges |
I'm starting my RV-8 tanks soon and am planning on capacitance senders.
What sort of gizmo is needed to convert the farad info to ohm info so I
might use the cheaper, more widely available resistance gauges? Is this
something I might be able to build myself?
Electronically challenged,
Larry Bowen
Larry(at)BowenAero.com
http://BowenAero.com
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass cockpit: message format |
On 15 Nov, Matthew Mucker wrote:
> Next topic seems to be message format.
Okay, here are some thoughts on the protocol. I was going to try and
write this up more formally, but since whenever I try I spend more
time worrying about the exact wording than writing up my ideas, I'll
just send my ideas in a less polished form here. The folks who've
stepped forward as scribes should feel free to crib and fix as needed.
I'm just writing basic ideas here, details can follow later when we
get some agreement on the overall structure.
Each device that has some piece of data which might be interesting to
over devices, beacons that data periodically on the data bus. The
general structure of the data is common enough so you can ignore data
you're not interested in but the details of the format are specified
separately for each data item. Also the frequency of beaconing is
specified for each data item.
Each device that wants to learn data, listens to the data bus (busses)
and picks out those data items it's interested in and understands.
Any cross-checking of values between multiple, redundant sensors is
done by the receivers.
The basic packet format is an identification of the sender unit
followed by a series of tag, length, value triples which are the data
items. The tag identifies the data item being sent, the length lets a
receiver skip a data item it doesn't understand, and the value is
encoded as defined by the tag documentation.
The receiver caches each the data values it's interested in, does any
cross checking related to redundant sensors, and looks for loss of
signal. If a receiver doesn't see an update for a data item in three
retransmission intervals, it should assume it's lost that sensor. It
would then revert to other data sources or indicate a failure to the
pilot.
Transitters should do what they can to ensure they're not sending bad
data. For instance, they should figure out that the CHT probe wire
broke and stop sending rather than send -14 degrees.
Questions I have
----------------
I've assumed the retransmission frequency is specified in the tag
documentation. It could instead be added to the transmitted
information. What do you do then if two senders are sending redundant
information at a different rate? Does it matter?
What about labeling things like VOR1 and VOR2? The label could be a
separate tag, it could be derived from the device identification of
the sender (yuck), it could be encoded in the value part of the
triple, it could be encoded in the tag (I'm leaning towards this).
Should redundant information be flagged so we can have a generic
redundant information comparator which just looks for mismatches?
Should transmitters of redundant information listen for others and
report somehow if there's a mismatch?
It's too bad that devices have to identify themselves. This basically
means an address which means the installer has to set the address.
Then we have to detect collisions when they set it wrong and so on.
Ugh. Can we get rid of this? I noticed the CAN bus doesn't have
device addresses. They just have different tags for different,
possibly similar, information. That might be a better way to go.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Project organization |
On 17 Nov, James Baldwin wrote:
> and Dave (DAB) who allowed his code to be viewed/uploaded.
I see people have picked up copies but I haven't had any feedback.
Maybe it just didn't work fo anyone but I'm curious anyway.
> Here is my suggestion:
> 1. All those mentioned and all the lurkers should ID themselves with a
> simple list of skills. (This has been done by many of those mentioned).
My professional computer career, since 1982, has been involved with
implementing Internet protocols, mostly in semi-embedded environments
like routers or writing portable source code for others to put in
their embedded systems. That's probably why I look at cockpit
avionics as badly needing a standard bus and communications protocol.
> 2. Interest by an individual in leading this group should be expressed.
> 3. There should be "campaigning", if at all required, in the form of
> posts to this forum.
I notice no one has yet expressed such an interest. I haven't proven
to be an effective leader in the past (mostly I let people go their
own way) and I'm just joining a new startup company so I think I'd be
a poor choice. But I will happily contribute with throwing ideas
around and with building what pieces I can.
> 5. Busses, OS, processor type and a BIOS would be decided on and
> written and we would get started with the basic elements.
Once the bus and protocol is laid down, people would be quite free to
fragment and work on different pieces of the system. The MFD is going
to be a large one though and might benefit from people working in
concert.
-Dave
________________________________________________________________________________
| From: | James Baldwin <jamesbaldwin(at)attglobal.net> |
| Subject: | Glass cockpit project |
To all of the Glass Cockpit People:
We have here, IMHO, a real opportunity to create not only a useful
set of hardware and software, but also a standard that may enable
further optimization and lower costs as time goes on. As we can all
see, there have only been a couple of responses to my post regarding
organization of the powerful set of skills expressed. As promised, my
feelings are not hurt but MAN !!! it does hurt to see opportunity pass
us by if we don't pool our skills guys. Perhaps I'm all wet (it has
happened before) but a typical group of engineers needs leadership
IMHO. I know, I've been there and DAB's comment is typical of us
engineers because "we know how to do things" and EGOs make it more
difficult because we have to work with "those other guys who aren't as
clever as I am." After a pretty remarkable beginning, posts have tapered
off and no one in particular has stepped up to volunteer to lead. I
certainly would were I qualified but after reading some of the advanced,
albeit undoubtedly current technological thought, it is past me to
suggest the path for the group. I'll tell you what: I'll make one more
suggestion and then shut-up.
If we used Steve's beginnings and his Web site, and allowed him to be
our scribe we could post skills relative to names and time available.
It could make a first step. Then we could post all the possibilities
for each component (OS, processor, BIOS, bus, etc)and reach consensus.
(oh boy)
Perhaps an overall system architect would emerge -- someone who was
technologically able to read the desires of the group and find
compromise, as we all know that is the real definition of any form of
engineering. Following this, pcbs would be designed, Gerber files
generated for anyone to use, or a pcb manufacturer selected, and we
would
all benefit. Sorry guys, you might have to buy your own components and
solder them yourself. It sure could be a lot of fun -- similar to a
specific aircraft building group. By the way, I am type rated in all the
747s including the 400 (glass and more glass), currently fly the 200 and
have a lot of ideas, albeit simple, of how I want to use this technology
in my Harmon Rocket II under slow construction. My time spent here
trying to get us all pointed in the same direction is obviously selfish,
:-) but if we are unable to reach a path and organization for the group,
perhaps a few of you would like to continue along the lines of data
aquisition for at least the engine. Anything further than that is
beyond my immediate potential and I would need help. Otherwise, I have
found a TERN processor board with A to D inputs, 8051 family processor,
C language compiler and plan to do my own system. Let me know guys and
either way, unless prodded I will keep these organizationally oriented
posts in the future to a minimum. Thank you. JBB
________________________________________________________________________________
| From: | Frank and Dorothy <frankvdh(at)ihug.co.nz> |
| Subject: | Re: Glass cockpit project |
James Baldwin wrote:
>
>
> To all of the Glass Cockpit People:
> We have here, IMHO, a real opportunity to create not only a useful
> set of hardware and software, but also a standard that may enable
> further optimization and lower costs as time goes on. As we can all
> see, there have only been a couple of responses to my post regarding
> organization of the powerful set of skills expressed. As promised, my
> feelings are not hurt but MAN !!! it does hurt to see opportunity pass
> us by if we don't pool our skills guys.
James et al,
I've just subscribed to Matt's Avionics list... the above was the first
that I read!
For those who don't know me, I've been a member of the RV-list for some
years. I'm
about halfway (1500 hours) into building an RV-6... fuselage largely
complete, finishing kit arrived on Friday. I maintain a web site aimed
at assisting RV builders at http://members.xoom.com/frankv/bunny.htm
Years ago I participated in the rec.aviation.homebuilt aimed at what I
guess James is aiming at. That project collapsed, in part due to the
negativism of Paul Lamar, and in part because everyone wanted to do
things their own way (Unix vs embedded systems vs Win wars raged).
I'm an embedded software engineer by trade, and spent the last year (and
8 years
earlier) teaching software engineering at the Central Institute of
Technology in
Wellington (New Zealand).
My skill set includes software design and construction (embedded
systems, Unix, DOS, Windows) and I know enough electronics to read a
schematic (although hazy on the analog side of things). At CIT last year
we had students working on projects, including a 2D accelerometer
(intended for measuring wave height in a robot boat, but adaptible to
aircraft use), a strobe system, and a wig-wag flasher. These last two
were based on Kitplanes articles, but weren't successful (I got stuck
with some less than well-motivated students :-( ).
I'm very keen to include glass cockpit type technology in my RV-6. I'm
also keen to share the development of the avionics with others.
Frank.
________________________________________________________________________________
| From: | "J Livingston" <jliving(at)erinet.com> |
| Subject: | Re: Glass cockpit project, Organization |
James, Steve, All,
I agree we need some organization. Sorry I didn't respond but was off
chasing URLs. And I found some good ones. Have you had a chance to
download my doc? I've got no critiques to date. I to hope Steve's web
site can be the focal point for this effort. Why don't you keep us on the
straight and narrow. I'm trying to get up to speed and document the
architecture, bus, and software issues and options. We do need to start
making some Software and Hardware decisions so that we can start defining
various subtasks that need to be done.
John
________________________________________________________________________________
| From: | "J Livingston" <jliving(at)erinet.com> |
| Subject: | The CAN Bus Architiecture, Sardware and Software |
All,
The more I look at CAN bus the more impressed with it I get. It is well
supported in hardware and software. It is used in numerous very demanding
environments; automobile, marine, field networks, factory networks, etc. It
was initially developed for automotive use by, I believe, Phillipse. If you
want to get an Eye full, just go to Google.com and search for: CAN bus. I
do believe this is where we should head. Here are a list of very
interesting URLs to CAN and related issues.
http://mot-sps.com/csic/
http://www.altera.com/html/programs/amppmf/can.html
http://sun-valley.stanford.edu/home.html
http://www.aps.anl.gov/asd/people/anj/
http://www.omegas.co.uk/CAN/implment.htm
http://www.omegas.co.uk/CAN/osimodel.htm
http://www.can-cia.de/start.htm
http://www.hitex-automation.com/ehican.htm
http://www.goofee.com/can.htm
http://www.aps.anl.gov/asd/controls/epics/EpicsDocumentation/WWWPages/EpicsF
rames.html
http://www.goofee.com/
http://www.hmcomp.demon.co.uk/index.htm
http://java.sun.com/beans/infobus/
http://www.mot-sps.com/products/index.html
http://www.triangledigital.com/t2.htm
http://www.advantech.com/
John
________________________________________________________________________________
| From: | "J Livingston" <jliving(at)erinet.com> |
| Subject: | Re: Glass cockpit project, CAN bus |
All,
The Control Area Network (CAN) was developed by Robert Bosch GmbH as a
serial communications protocol for use in automotive applications.
John
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass cockpit project |
On 21 Nov, Frank and Dorothy wrote:
> Years ago I participated in the rec.aviation.homebuilt aimed at what I
> guess James is aiming at. That project collapsed, in part due to the
> negativism of Paul Lamar, and in part because everyone wanted to do
> things their own way (Unix vs embedded systems vs Win wars raged).
My take on this issue is everyone's always going to want to do things
their own way. It's not something that I can change, nor would I want
to if I could. Instead, I want to try and use the power that comes
from diversity to make the whole idea more likely, and more capable.
To that end, if we can define a single bus design and protocol that
people can agree on, after that people can scatter in all different
directions so long as they come back to the bus so we can all
communicate. I'll call this the Internet model of development.
Given that, I have ideas of what I'd like to build. Lots of ideas.
Since I don't have all the skills necessary in some cases, I'd like to
see a forum where people whose ideas match can get together and carry
out their projects to the benefit of us all.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: The CAN Bus Architiecture, Sardware and Software |
On 21 Nov, J Livingston wrote:
> The more I look at CAN bus the more impressed with it I get.
You prompted me to go look more closely at CAN, thanks for the URLs,
and I agree that it looks pretty interesting. I have some questions
though, some of you and some about the bus that you might know the
answers to. But first I'll summarize pros and cons (as I see them at
the moment) like I did with other busses.
Pro:
- good speed (1Mb/s)
- good noise immunity
Actually, the physical layer is a little up in the air since it
seems you can use either RS-485 drivers or a special CAN
transceiver.
- architecture well matched to our purposes (short, tagged messages)
In fact, the protocol sure resembles the one I came up with and
sent to the list the other day. Maybe I'm not completely off in
the weeds after all.
- good bus access method
I thought this was really clever. Besides being fairly
deterministic (ought to keep the FAA happier) it's got a priority
scheme. It means one more thing we'd have to think about in
picking the right priorities, but we're up to the task.
- industry standard
Con:
- requires a CAN chip
I don't see why you couldn't, in principle, just connect a
transceiver to an I/O pin and run the serial protocol like people
tend to do to build an RS-232 interface on a PIC but there's enough
complexity there that you probably don't want to. Unlike ethernet
though, CAN chips can work with very small microcontrollers.
- not so many SBC's have CAN (as compared have to -232 or -485)
- higher layer protocols that I'm not sure we want
- industry standard
May mean there's more bureaucracy there than we want to deal with.
Questions:
What should we use for a physical layer? RS-485 is tempting since I
know driver chips are readily available. Does RS-485 really work for
this? [For those who haven't read the CAN stuff, the bus access
method depends on getting a specified result when two stations
transmit different values at the same time.] Are the CAN transceivers
better? Are they available enough?
Should we go with the basic or extended frame format? Basically
that's a choice of 11-bit tags or 29-bit tags.
Do we have to apply to CiA (that's "CAN in Automation" not "Culinary
Institute of America", "Christians in Action", or whatever else you
might be thinking) or someone else to get tag numbers or do we just
make up our own?
Do we have to use one of those specified higher layer protocols or can
we just roll our own? Are we allowed to call it CAN if we do?
> I do believe this is where we should head.
Does anyone know of a little microcontroller card with a CAN
interface? Or, failing that, are we ready to design and build our
own? There are some microcontrollers with built-in CAN interfaces
which ought to help though I don't know anything about their price or
availability. Dallas Semiconductor has even announced a version of
their 8051 clone with dual CAN interfaces.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass cockpit: tags |
On 21 Nov, J Livingston wrote:
> Have you had a chance to download my doc? I've got no critiques to
> date. I to hope Steve's web site can be the focal point for this
> effort.
I've read it but haven't figured out comments yet. I've got an
addition though, to your document and Steve's web pages.
> We do need to start making some Software and Hardware decisions so
> that we can start defining various subtasks that need to be done.
Here's a sub-task that's perfectly suited to a mailing list. Assuming
we go with a protocol like I lined out, or like the CAN protocol, we
need to define a list of tags, what they mean, how often they're sent,
and (for CAN) their priority.
At the bottom of this message I include a starter list. Everyone,
make additions and comments. I'm sure there'll be lots of additions.
This is just brainstorming and making sure the basic idea is sound for
whatever wild idea we come up with five years from now. It's not
necessarily a list of things you intend to put in your plane.
For instance, I just realized that I left out and sort of stormscope
or weather datalink stuff. Or collision avoidance. Now it may well
be that some of those aren't suitable for this sort of protocol. What
do we do in that case? Chuck the whole thing or layer another
protocol on top?
Another thing I've missed, the flight plan. You should be able to
enter a flight plan on one MFD and have it spread around to the whole
system somehow so if that MFD goes offline, you keep flying as if
nothing happened. Basically, we need a reliable multicast protocol.
Okay, I've got some ideas on that but that's beyond the scope of what
I wanted to talk about in this message.
So here's my start. I haven't worried about prioritizing things yet.
I figure that discussion can come once we've got a more complete list.
-Dave
Tag Count Frequency Notes Description
--- ----- --------- ----- -----------
Engine
------
CHT 16 1
EGT 16 1
TIT 2 1
oil pressure 2 1
oil temp 2 1
cooland temp 2 1
fuel flow 2 1 [1]
fuel pressure 2 1
fuel level 6 1
manifold pressure 2 1
tachometer 2 1
carb temp 2 1
buss voltage 4 1 [2]
buss current 4 1 [2]
Nav
---
VOR/LOC 3 4 [3] radial/angle, frequency, signal
GS 3 4 [3] angle, frequency, signal
DME 3 4 distance, frequency, signal
ADF 3 4 relative angle and frequency
GPS position 3 1 [4] [5]
GPS velocity 3 1 [4]
GPS waypoints 3 1 [6]
Air Data
--------
pitot pressure 2 4 [3]
static pressure 2 4 [3]
OAT 2 1 [6]
angle of attack 2 4 [3]
asymmetric thrust 1 4 [3] I'm not sure what this is
but it was suggested to me
Flight Attitude
---------------
mag compass 3 4 [3]
rate of turn 2 4 [3]
attitude 3 4 [3] heading, pitch, yaw
inclinometer 3 4 [3] all three axes
accelerometer 3 4 [3] all three axes
g-meter 1 4 [3] accelerometer in one axis
Control Sensors
---------------
aileron 2 4 [3]
elevator 2 4 [3]
rudder 2 4 [3]
aileron-trim 2 1
elevator-trim 2 1
rudder-trim 2 1
flaps 2 1
throttle 2 1
mixture 2 1
prop 2 1
speed brakes 1 1
landing gear 3 1 [6]
Control [7]
-------
heading bug 6 1
altitude bug 6 1
VOR/LOC/GS freq 3 1
DME freq 3 1
ADF freq 3 1
transponder squawk 1 1
transponder ident 1 1
autopilot mode 6 1 on/off, heading, source
select, altitude hold, etc
Notes:
======
1 - Some quantites need to be integrated. We can't just send the
current value because this will miss short term variations. And
given an unreliable protocol we can't send the integral since the
previous transmission because the previous transmission may have
been missed. Send the integral since system start maybe?
2 - Not sure about the count.
3 - Not sure about the frequency. Somewhere between 4 and 10 per
second I'd say.
4 - Most GPS's seem to provide their position information once a
second. What if in the future the information is available at a
faster rate? Could just assign a new tag which is the same format
but at a different rate.
5 - Tags for Glonass or LORAN as well?
6 - probably slower
7 - Don't know if we should regularly beacon the controls or just when
they change. It's an unreliable protocol so we should keep
sending. But imagine a multi-MFD system and you set the heading
bug on one. The others should track that change. If the
autopilot is tracking heading, it shouldn't be jumping back and
forth because one of the MFDs hasn't caught up to the change yet.
We've got to figure out how to do that.
________________________________________________________________________________
| From: | "Marlin Mixon" <marlin_mixon(at)hotmail.com> |
| Subject: | Re: Glass cockpit project, CAN bus |
>From: "J Livingston" <jliving(at)erinet.com>
>
> The Control Area Network (CAN) was developed by Robert Bosch GmbH as a
>serial communications protocol for use in automotive applications.
The CAN system sounds interesting. I won't have a chance to study it until
I'm back from vacation. Is CAN an open standard?
Marlin Mixon
________________________________________________________________________________
| From: | "Marlin Mixon" <marlin_mixon(at)hotmail.com> |
| Subject: | Re: Glass cockpit project |
>From: Frank and Dorothy <frankvdh(at)ihug.co.nz>
>
>James et al,
>
>I've just subscribed to Matt's Avionics list... the above was the first
>that I read!
>
>For those who don't know me, I've been a member of the RV-list for some
>years. I'm
>about halfway (1500 hours) into building an RV-6... fuselage largely
>complete, finishing kit arrived on Friday. I maintain a web site aimed
>at assisting RV builders at http://members.xoom.com/frankv/bunny.htm
>
>Years ago I participated in the rec.aviation.homebuilt aimed at what I
>guess James is aiming at. That project collapsed, in part due to the
>negativism of Paul Lamar, and in part because everyone wanted to do
>things their own way (Unix vs embedded systems vs Win wars raged).
>
>I'm an embedded software engineer by trade, and spent the last year (and
>8 years
>earlier) teaching software engineering at the Central Institute of
>Technology in
>Wellington (New Zealand).
>
>My skill set includes software design and construction (embedded
>systems, Unix, DOS, Windows) and I know enough electronics to read a
>schematic (although hazy on the analog side of things). At CIT last year
>we had students working on projects, including a 2D accelerometer
>(intended for measuring wave height in a robot boat, but adaptible to
>aircraft use), a strobe system, and a wig-wag flasher. These last two
>were based on Kitplanes articles, but weren't successful (I got stuck
>with some less than well-motivated students :-( ).
>
>I'm very keen to include glass cockpit type technology in my RV-6. I'm
>also keen to share the development of the avionics with others.
Welcome, Frank! It sounds like you have a very useful set of skills that
are relevant to this endevor.
Marlin Mixon
________________________________________________________________________________
| From: | "Archie" <archie97(at)earthlink.net> |
| Subject: | Contribution / Donation |
Items for sale w/ proceeds to help maintain Matronics websites.
Offers should be directed to:
http://www.matronics.com/contribution
Upon receipt of donation amount, items will be shipped.
No reasonable offer refused!
Unreasonable ones considered!
This will be a one-time posting.
NEW:
Heated Pitot Tube, 24v. "L" shaped.
Aero Instruments #5814-2
Flap Motor w/ adjustable stops. 24v.
Comm.Aircraft Prods. #D145-00-35-7
USED:
Narco Transponder AT5-A
Astronautics amplifier servo 53-005-214 mod#P1SA
Narco altitude reporter. to 25k' Model# AR500
King KS-505 power supply modulator
RCA AVQ55 Weather radar antenna MI 591000
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | The CAN Bus Architiecture, Software and Softwa |
re
Dave,
I am not an expert on this. I'll try and answer with ///
.... the physical layer is a little up in the air since it
seems you can use either RS-485 drivers or a special CAN
transceiver.
/// for a good fault tolerant bus you should use a CAN transceiver.
They claim that it will continue to work (with reduced capacity) under a
number of different failures.
- not so many SBC's have CAN (as compared have to -232 or -485)
/// CAN cards are available, CAN controller and tranciever chips are
available.
- higher layer protocols that I'm not sure we want...Do we have to use one
of those specified higher layer protocols or can
we just roll our own?
///I'm sure we'll find them very useful. I don't want to reinvent this
stuff. We don't have to use it all, but we should understand it.
The CAN Kingdon is the basis for a DoD spec for development of Unmanned
Vehicles(UV)'s. These are way more complicated than an GA aircraft and need
to be just as reliable. I don't claim to know the pro's and con's of these
higher layer protocols (software interfaces?), but I think we should find
out. These are represent a wealth of lessons learned about how to and how
not to dot this network thing for real time control.
My current thinking is that most of this high level software is
encapsulated into something like embedded java or C objects. This in turn
uses lower level CAN bus and microcontroller objects. Some of us can work
at a higher level of abstraction designing user interfaces and systems
management software, and others of us code up low level interfaces for the
microcontrollers and the CAN bus. I would hope we would tap into the
growing CAN community for much support.
- industry standard
May mean there's more bureaucracy there than we want to deal with.
///Yes, but we don't have to deal with the bureaucracy unless we want to go
into the deepwater. We don't have to pass the tests to prove compliancy of
our software and hardware until and unless we want to. We can use it for
guidance.
What should we use for a physical layer? RS-485 is tempting since I
know driver chips are readily available. Does RS-485 really work for
this? [For those who haven't read the CAN stuff, the bus access
method depends on getting a specified result when two stations
transmit different values at the same time.] Are the CAN transceivers
better? Are they available enough?
///To the best of my knowledge CAN chipsets for interfacing to
micro-controllers and pc's area available. I don't know what the
availability or cost is in small lots. I'll see if I can find out.
Anyone know????
Should we go with the basic or extended frame format? Basically
that's a choice of 11-bit tags or 29-bit tags.
/// Don't know yet. Need to find some experts to guide us a little, and
then do our home work.
Do we have to apply to CiA (that's "CAN in Automation" not "Culinary
Institute of America", "Christians in Action", or whatever else you
might be thinking) or someone else to get tag numbers or do we just
make up our own?
/// I think we can get the specs for free, I hope. Many tags are already
defined. There are 2 to the 29th available so I'm guessing many are not. We
need to get the spec.
Does anyone know of a little microcontroller card with a CAN
interface? Or, failing that, are we ready to design and build our
own? There are some microcontrollers with built-in CAN interfaces
which ought to help though I don't know anything about their price or
availability. Dallas Semiconductor has even announced a version of
their 8051 clone with dual CAN interfaces.
/// I believe Phillipse and Motorola, and I think others, have a
microcontroller and a CAN controller on a single chip. They also carry CAN
trancievers. I don't know about the pricing. I think they offer starter
kits of sorts as well. We really need to look into this more.
In another vain, I found a Web sight that has JAVA on a microcontroller
chip. Others are doing this as well. C, Java, Pascal, Forth all seem to be
out there and being used for RT programing.
john
________________________________________________________________________________
| From: | "Marlin Mixon" <marlin_mixon(at)hotmail.com> |
| Subject: | The CAN Bus Architiecture, Software and Softwa re |
>From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
///To the best of my knowledge CAN chipsets for interfacing to
micro-controllers and pc's area available. I don't know what the
availability or cost is in small lots. I'll see if I can find out.
Anyone know????
Yeah, check out this web page (I included an excerpt from it as
well):
----------------- http://www.goofee.com/can.htm --------------------
CAN chips
There are lots of chips with microcontroller CPU and CAN on the same chip,
but there are also stand-alone CAN controller chips that can be interfaced
to a microcontroller. Of the stand-alone variety, Intel has the 82527, which
is capable of interfacing to a wide range of 8- and 16-bit micros. Also
there is the Philips PCA82C200, which is soon to be replaced by the
almost-pin-compatible SJA1000. The Philips chip attracts me, as it is
available in a 28-pin DIP, which is useful for prototyping. On the other
hand, the 82527, 44 pin PLCC, has a couple of extra I/O ports.
What do they cost? In small quantities, it can be anything from US$7 to
US$30, depending on the vendor. If you buy 1,000, the price drops to around
US$5.
Marlin Mixon
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit: bus hardware |
>
>Appletalk
>
> Isn't this RS-485? Might be a really good idea.
I presume you are talking about Apple's "Localtalk". It is RS-422
electrically. They use synchronous datacomm at 307 Kbps using CSMA-CA.
The chip is the fairly common Z80-SCC with an internal clock recovery
circuit. You transmit and receive on the same pair, half-duplex. Think of
it as a poor-man's ethernet.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | RS-485 and RS-232 |
You should be able to adapt a standard RS-232 serial port to do RS-485 by
changing the line drivers and receivers.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Encoder Output Question |
>
>
>Can anybody tell me if I can parrallel the output from my AK-350 encoder
>to both my GPS, and Transponder? The signal lines in are both the same
>for the GPS (gnc-250xl) and the transponder (gtx-320). I currently have
>the encoder tied only to the transponder.
Yes, but you should diode isolate the lines. I believe that Garmin
provides the info on how to do this in their installation guide. Most
other GPS vendors require a serial input for altitude and are not directly
compatible with the output from altitude encoders.
I have heard (but not verified) that there are some encoders that have the
requsite serial output for the rest of the GPS's.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
>
>Hi again guys....found this product at http://www.eeci.com/adc-16p.htm. It
>might be a $99 solution to the box...I think you just need a case & power
>supply to finish....but anything more electrically complicated than Xmas
>lights is out of my area so I don't know for sure. Elsewhere in their site
>the say there is an optional -485 interface.
>
>Comments? ...I guess there're lots of brands of these around, right?
Analog is not quite as easy as you think. Remember that you are poking
probes into some really (electrically) hostile places. Analog input signal
conditioning is really important. You want to filter out crud that could
damage the A/D converter and/or the rest of your system.
Also some signal sources have very specific connection and loading
requirements, e.g. thermocouples. The signal from a thermocouple is very
small (we are talking microvolts here) and very sensitive to *ANY*
dissimilar metals in the path. This part requires more effort than you
might think.
Pulse inputs from things like magnetos are really nasty. We are talking
300V pulses, not exactly everyday fare for 5V microprocessor components.
We need to do some isolation here.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Re: Glass cockpit: message format |
>
>Should redundant information be flagged so we can have a generic
>redundant information comparator which just looks for mismatches?
>Should transmitters of redundant information listen for others and
>report somehow if there's a mismatch?
If it is redundant information. Consider a twin with two identical modules
collecting information from the different engines. We need some way to
tell the data sinks which tags are which.
>It's too bad that devices have to identify themselves. This basically
>means an address which means the installer has to set the address.
>Then we have to detect collisions when they set it wrong and so on.
I don't think that you need settable IDs, only that every box has a unique
ID. Ethernet solved this problem by every device having a unique MAC
address. That way when I saw a particular parameter the MAC address would
uniquely identify what it is.
>Ugh. Can we get rid of this? I noticed the CAN bus doesn't have
>device addresses. They just have different tags for different,
>possibly similar, information. That might be a better way to go.
Well, you end up with a totally flat attribute/tag space which I don't like
at all. When I see a tag that purports to be pitch angle, I want it to be
pitch angle. If I have two AHRS's, I want each to use the same tag for
pitch angle and have some other data element that allows me to identify
which AHRS is sourcing that particular data element. This problem comes up
with every device where you expect to have multiple sources for the same
type of data such as:
multiengine sensors
multiple AHRS's
multiple nav receivers
You know, the simple AVP (attribute/value pair) type tag seems
old-fashioned and annoying to me. Seems that we might want a more complex
data element so that things are not ambiguous. For instance, my VOR
receiver sensor needs to send several pieces of information in a frame:
frequency
ID
signal valid
radial
Consider the possibility of putting all this info in a single message
frame. Sure you could send it as four separate AVPs but things might
change between the transmission of one AVP and the next leading a device to
make an erronious assumption about the data.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit: message format |
>>Ugh. Can we get rid of this? I noticed the CAN bus doesn't
>>have device addresses. They just have different tags for
>>different, possibly similar, information. That might be a better
>>way to go.
>
>Well, you end up with a totally flat attribute/tag space which I
>don't like at all. When I see a tag that purports to be pitch angle,
>I want it to be pitch angle. If I have two AHRS's, I want each to
>use the same tag for pitch angle and have some other data
>element that allows me to identify which AHRS is sourcing
>that particular data element.
Why not come up with our own bit-mapping scheme for the tags? Set the 3
or 4 LSB's to be a device ID, maybe the 3 or 4 MSB's to be the subsystem
(nav, engine, flight inst, etc.) and everything in between identify the
specific type of signal (EGT, pitch angle, GPS data).
I know, kinda weak, just a thought...
>This problem comes up with every device where you expect to have
>multiple sources for the same type of data such as:
>
> multiengine sensors
> multiple AHRS's
> multiple nav receivers
also things like multiple CHT/EGT probes... we would want to know which
cylinder is being measured...
>You know, the simple AVP (attribute/value pair) type tag seems
>old-fashioned and annoying to me. Seems that we might want a more
complex
>data element so that things are not ambiguous. For instance, my VOR
>receiver sensor needs to send several pieces of information in a frame:
>
> frequency
> ID
> signal valid
> radial
>
>Consider the possibility of putting all this info in a single message
>frame. Sure you could send it as four separate AVPs but things might
>change between the transmission of one AVP and the next leading a device
to
>make an erronious assumption about the data.
I agree... perhaps a tag would identify an entire data block of a
pre-defined format, and our black boxes would be partitioned according to
these parameters. For instance, a single box (well, perhaps two redundant
boxes) could report engine data... ALL of it.
Design a message block (first byte(s) packet type, next byte(s) verion
number to allow for later revisions) which contains everything anyone
would want to know about a single gas engine... just round numbers, but
perhaps... 8 CHT, 8 EGT, 2 carb temp, water temp, water pressure (?), oil
temp, oil pressure, manifold pressure, (whatever else is desired for
turbo/superchargers?)... have another data block defined for turbines...
etc. in addition to the AVP's that may be needed for individual isolated
sensors.
Perhaps we bitmap the attribute field as described above for boxes that
transmit individual signals, but define the 0 or FFFFFF... attribute as
containing a data packet.
Steve
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit project, Organization |
>I agree we need some organization. Sorry I didn't respond but was off
>chasing URLs. And I found some good ones.
>
>Have you had a chance to download my doc? I've got no critiques to
>date. I to hope Steve's web site can be the focal point for this
effort.
>Why don't you keep us on the straight and narrow.
>
>We do need to start making some Software and Hardware decisions so
>that we can start defining various subtasks that need to be done.
I have downloaded the document, but I have not as of yet had a chance to
review and plagiarize it :-) Hopefully some time today, or over the
weekend.
Since nobody has stepped up to the plate, I am willing and able to take
over the responsibility of being the project manager. I have had a bit of
project management experience over the last several years in software
engineering.
Like any good manager, I want to be rather hands-off... I don't want or
need to micromanage this thing. We seem to have a nice group of
self-motivated individuals, many with much more hardware experience than I
have, so naturally I would look to others to make some of these decisions.
Y'all decide if I'm what you want, then we can move on and get some work
done!
In the meantime, I will continue to maintain the web site for this
project, and add details as we go along...
Steve, with 75 messages perpetually in my inbox, waiting to be
incorporated into the specs or reviewed...
http://www.tzogon.com/~steve/glass_cockpit
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Glass cockpit project - bus focus |
>My take on this issue is everyone's always going to want to do
>things their own way. It's not something that I can change, nor
>would I want to if I could. Instead, I want to try and use the
>power that comes from diversity to make the whole idea more
>likely, and more capable.
>
>To that end, if we can define a single bus design and protocol
>that people can agree on, after that people can scatter in all
>different directions so long as they come back to the bus so
>we can all communicate. I'll call this the Internet model of
>development.
>
>Given that, I have ideas of what I'd like to build. Lots of ideas.
>Since I don't have all the skills necessary in some cases, I'd
>like to see a forum where people whose ideas match can get
>together and carry out their projects to the benefit of us all.
Yes, I agree... taht's why I'm glad that everyone is pretty well focused
on the bus specifications for the time being. Once we decide and agree on
an architecture, there are certain things that we will all have in common:
* common bus architecture (thus interoperability)
* the need for an array of "semi-intelligent" devices (sensors and
interfaces) which would not cause such religious debates
as the user interface/operating system stuff
People who want to develop different custom interfaces can split off and
do their own thing, but we will still all share a common goal and work
together as a team, instead of against one another. There may be separate
sub-teams doing their own thing, but we're still working together.
You want to do a Linux front end? Fine, knock yourself out. Need help
with the specs/interface? We're all here for you. Need to build a
pitot/static sensor box? (insert name here) developed one for this bus...
etc. You want to do a Windows front end? Same thing. It does not
matter.
Steve
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and NME |
A 2000
All,
It appears that almost all of the software and hardware work has been
accomplished already in developing the bus system we need, including the
High Level Protocol (HPL). It all seems to focus on CAN, CAN Kingdom,
CDA101(DOD) and NMEA 2000. CAN Kingdom http://www.kvaser.se/main.htm is a
HLP for designing real-time, flexible, control systems. I have downloaded
the spec and am reading it now. Seems real straight forward. It appears to
be the basis for CDA101 and NMEA 2000. CDA101 is a Unmanned Vehicle
(UV)Spec being developed by DOD for marine and air UVs. NMEA 2000 is an
emerging standard for Naval Maritime Electronics Assoc. (NMEA). I haven't
got a look at this one yet. CDA101 appears to be an ongoing effort out of a
DOD UV office. There are some wonderful (free) documents covering this
work. Its been demo'd on a UV boat and some target drones.
http://www.kvaser.se/canking/cda101/index.htm One of them defines, in
detail, most parameters we will need for aircraft and helicopter work. C
software for this effort is apparently available as well.
This appears to be ready made for us to steal, lock, stock and barrel.
This work is all available free. It uses affordable off the shelf devices.
Real complex system's have been built using it. The results were positive
on all counts. We might do well aligning our efforts with these folks. I
am going to try and contact some of them.
Again I would like to stress the importance of not reinventing anything
that you can steal. Lets find the best, make it our own and build on that.
If we do, we will find that we may just be able to accomplish something
useful for general and sport aviation.
I envision this group providing "starter kits" including hardware,
software and appropriate interfaces to PC's. Serious hobbyists and would be
entrepreneurs could educate themselves and quickly start turning out sensor
packages, instrument displays, etc for aircraft.
It really seems odd that I have not run across any general aviation or NASA
efforts in this field. Does anyone know of any?
John
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and NME |
A 2000
I think I may have found the NASA/AGATE work on an aviation data bus
http://agate.larc.nasa.gov/meetings/DatabusWP/Databusmeet.htm
John
________________________________________________________________________________
| From: | James Baldwin <jamesbaldwin(at)attglobal.net> |
| Subject: | Re: Glass cockpit project, Organization |
Steve--
Thank you for stepping up to the plate. My vote is for you to assemble some
sort of protocol for us to adhere to in terms of Identification of
Intellectual Assets. Obviously your Website is the location. This thing can
move pretty fast if something is proposed and all those in the know discuss
the pros and cons to arrive at an agreeable solution. Your thoughts and
guidance please. JBB
"Steven J. Devine" wrote:
>
> >I agree we need some organization. Sorry I didn't respond but was off
> >chasing URLs. And I found some good ones.
> >
> >Have you had a chance to download my doc? I've got no critiques to
> >date. I to hope Steve's web site can be the focal point for this
> effort.
> >Why don't you keep us on the straight and narrow.
> >
> >We do need to start making some Software and Hardware decisions so
> >that we can start defining various subtasks that need to be done.
>
> I have downloaded the document, but I have not as of yet had a chance to
> review and plagiarize it :-) Hopefully some time today, or over the
> weekend.
>
> Since nobody has stepped up to the plate, I am willing and able to take
> over the responsibility of being the project manager. I have had a bit of
> project management experience over the last several years in software
> engineering.
>
> Like any good manager, I want to be rather hands-off... I don't want or
> need to micromanage this thing. We seem to have a nice group of
> self-motivated individuals, many with much more hardware experience than I
> have, so naturally I would look to others to make some of these decisions.
>
> Y'all decide if I'm what you want, then we can move on and get some work
> done!
>
> In the meantime, I will continue to maintain the web site for this
> project, and add details as we go along...
>
> Steve, with 75 messages perpetually in my inbox, waiting to be
> incorporated into the specs or reviewed...
> http://www.tzogon.com/~steve/glass_cockpit
>
>
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit NASA, AGATE Avionics Databus |
It appears NASA & AGATE have done little in this area. Do these people ever
publish anything? I have attempted to email them to see if I can find out
anymore than what is on their website (which is damn little) but their
server appears to be down. I'll keep trying. EAA has a seat on the AGATE
commitee so I would assume members could get AGATE documents? We need to
keep in touch with a kindred spirit in this group, if we can find one.
John
http://agate.larc.nasa.gov/meetings/DatabusWP/Databusmeet.htm
________________________________________________________________________________
| From: | "Marlin Mixon" <marlin_mixon(at)hotmail.com> |
CAN is great, I think, because of its low cost. The fact that NASA is
proposing CAN for the AGATE Databus speaks well in it's favor, if only for
the fact that NASA is pushing for FAA approval of such a system.
The AGATE Databus DOES modify the CAN system a little, but if we shoot for
CAN, I would think we'd be able to modify it later without too much hassle
to conform to the AGATE Databus.
For more on AGATE Databus (technical abstract):
http://www.sbir.nasa.gov/95abstracts/06.01/951268.html
Marlin Mixon
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and |
NME A 2000
>
> It really seems odd that I have not run across any general aviation or NASA
>efforts in this field. Does anyone know of any?
Everything I have seen seems to focus on the ARINC standards. The ARINC
stuff is bloated and topheavy but there are already people using it to do
databusses in aircraft.
Can we really do what we want with NMEA2000?
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit NASA, AGATE Avionics Databus |
>
>It appears NASA & AGATE have done little in this area.
It figures. Dave and I wandered around to various participating vendors at
OSH '98 and discovered that noone seems to know much about communications
busses.
>Do these people ever publish anything?
This is a problem with traditional standards groups. For some reason they
want to sell their work rather than publish openly.
>I have attempted to email them to see if I can find out
>anymore than what is on their website (which is damn little) but their
>server appears to be down. I'll keep trying. EAA has a seat on the AGATE
>commitee so I would assume members could get AGATE documents? We need to
>keep in touch with a kindred spirit in this group, if we can find one.
Maybe we should be pursuing this through either EAA or AOPA. Clearly there
is a lot of technical horsepower on this list with more experience in data
communications than what they are used to having around.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and |
NME A 2000
>
>I think I may have found the NASA/AGATE work on an aviation data bus
>http://agate.larc.nasa.gov/meetings/DatabusWP/Databusmeet.htm
It is in Virginia and claims to be an open meeting. Someone from this
group probably ought to go. I know that Dave (dab) is not too far away but
I don't know about anyone else. I may be back there but I don't know for
sure.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
Marlin,
What do you know about the AGATE Databus? The only thing I found was a
meeting announcement for Dec 9 1999. Any websites? The AGATE site is almost
worthless. Is NASA proposing CAN? Who would I contact at NASA or AGATE to
get more info? DOD CDA101 folks might be are best bet for hardware and
software guidance. So far they seem to be the most open about their work.
John
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and NME |
A 2000
Brian,
I have not got my hands on a NMEA 2000 draft yet. I think it will be
formally released
end of this year. Any spec is just a set of aggreed upon rules which have
been carefully worked out to yield the desired results. They come in lots
of flavors, loose to rigid.
Reading the CDA101 exec summary (pdf) and others (the ST2000 UV boat is
really good) gives you a real feel how it is evolving. Most specs are not
as cast in concrete as most people think. The important thing is that the
good ones are surrounded by a community of practitioners, and in our case
hardware and software that we can draw from. Knowing companies I'd guess
they gave themselves lots of wiggle room for in this spec. I don't think it
even pins down the physical bus connectors(the least of our worries).
John
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
>
>For more on AGATE Databus (technical abstract):
>http://www.sbir.nasa.gov/95abstracts/06.01/951268.html
I looked this up and it appears to be a proposal for funding by a vendor,
not the output of the group.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | Glass cockpit: Numerous Bus Docs. |
Steve D.,
I have accumulated quite a few pdf documents I'd like to email you so that
you can post them on your website, it that's ok. They include CAN, CAN
Kingdom, CDA101 etc. Taken together they give a very complete picture of
the current state of affairs related to databuses of this ilk.
John
________________________________________________________________________________
| From: | "Chris Atkinson" <chris-atkinson(at)home.com> |
| Subject: | Glass cockpit project, Organization |
Hey Steven, you got my vote....you seem to be a pretty level headed
moderator-kind-o-guy. I'll likely keep kinda quiet and watch while talk is
centered on the hardware stuff, but then re-surface when we get to the user
interface side. For your skills inventory document, you could mark me down
under "maps & GPS".
....let's keep the ball rolling guys, it's getting really good. ...just
wish I could help more at this stage.
Chris
-----Original Message-----
From: owner-avionics-list-server(at)matronics.com
[mailto:owner-avionics-list-server(at)matronics.com] On Behalf Of Steven J.
Devine
Sent: Tuesday, November 23, 1999 8:16 AM
Subject: Re: Avionics-List: Glass cockpit project, Organization
Since nobody has stepped up to the plate, I am willing and able to take
over the responsibility of being the project manager.
________________________________________________________________________________
| From: | Brian Lloyd <brian(at)lloyd.com> |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and |
NME A 2000
>
>Brian,
>
> I have not got my hands on a NMEA 2000 draft yet. I think it will be
>formally released
>end of this year. Any spec is just a set of aggreed upon rules which have
>been carefully worked out to yield the desired results. They come in lots
>of flavors, loose to rigid.
Many are not worked out and many do not yield the desired results. There
are too many protocols out there that were "engineered" in a vacuum and
hence do not do what they purport to do. You have to implement them and
then gain experience with them before you can pronounce them as "standard."
>Reading the CDA101 exec summary (pdf) and others (the ST2000 UV boat is
>really good) gives you a real feel how it is evolving. Most specs are not
>as cast in concrete as most people think.
I have a history of developing protocols and specs in the IETF. Your PC
running PPP is the result of work by me and others. Been there, done that.
>The important thing is that the
>good ones are surrounded by a community of practitioners,
That is absolutely essential.
>and in our case
>hardware and software that we can draw from. Knowing companies I'd guess
>they gave themselves lots of wiggle room for in this spec. I don't think it
>even pins down the physical bus connectors(the least of our worries).
That should be kept separate from the electrical and message specs. If you
think about it from the point of view of layering you really need four specs:
1. the physical (connectors, etc.)
2. the electrical (voltages, acceptable bitrates, etc.)
3. the link (framing, link establishment, link teardown, arbitration, etc.)
4. the messages
I tend to want to work from #4 toward #1. Sometimes you can have multiple
lower layer specs and still keep the same messaging. For instance, you
might want to send the messages over CAN, RS-485, and Ethernet. That means
that #4 stays the same while numbers 1-3 change.
Brian Lloyd Lucent Technologies
brian(at)lloyd.com 3461 Robin Lane, Suite 1
http://www.livingston.com Cameron Park, CA 95682
+1.530.676.6513 - voice +1.530.676.3442 - fax
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Glass cockpit CAN, CAN Kingdom, CDA101 and NME |
A 2000
On 23 Nov, Brian Lloyd wrote:
> It is in Virginia and claims to be an open meeting. Someone from
> this group probably ought to go. I know that Dave (dab) is not too
> far away but I don't know about anyone else. I may be back there
> but I don't know for sure.
I'm going to be in California for organizational meetings for my new
job from Dec 4 to 12 so I can't make this one. Okay, part of that
time I'll be visiting friends and hopefully getting to try out his
Cessna 310.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Capacitance Fuel gauges |
On 19 Nov, Larry Bowen wrote:
> I'm starting my RV-8 tanks soon and am planning on capacitance senders.
> What sort of gizmo is needed to convert the farad info to ohm info so I
> might use the cheaper, more widely available resistance gauges? Is this
> something I might be able to build myself?
>
> Electronically challenged,
I don't have a definitive answer for you, but since no one else has
piped up I figured I'd say something. First, it's probably easier to
change farads to volts rather than ohms. You could attach the sender
to an oscillator circuit in such a way that the frequency changes
depending on the capacitance. Then you need either a frequency
counter or a frequency to voltage chip (which I think you can get).
Or, you could switch a voltage on and off into the capacitive sender
through a resistor and see how long the rise and fall times are. Do
this regularly (square wave oscillator) and feed the voltage across
the capacitor sender through a buffer (op-amp) and a low pass filter
(a large capacitor and resistor) and you should be able to get a
voltage out proportional to the capacitance.
I'm just talking off the top of my head here, I haven't tried to build
any of this, but if I was in the mood to experiment and come up with
my own circuit, that's where I'd start.
I think there was a circuit to do this published in Kitplanes magazine
sometime recently. Well, sometime in the past five years anyway. A
letter to them and money for a back issue might set you up.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass cockpit: message format |
On 23 Nov, Steven J. Devine wrote:
> Why not come up with our own bit-mapping scheme for the tags? Set the 3
> or 4 LSB's to be a device ID, maybe the 3 or 4 MSB's to be the subsystem
> (nav, engine, flight inst, etc.) and everything in between identify the
> specific type of signal (EGT, pitch angle, GPS data).
>
> I know, kinda weak, just a thought...
That's sort of what I was thinking. It seems pretty obvious that 11
bits MIGHT be workable but it's tighter than I'd like. So far all of
the microcontrollers I've looked at with built-in CAN interfaces
support 29-bit tags anyway.
> I agree... perhaps a tag would identify an entire data block of a
> pre-defined format, and our black boxes would be partitioned according to
> these parameters. For instance, a single box (well, perhaps two redundant
> boxes) could report engine data... ALL of it.
Unfortunately, the CAN spec limits the packets to 8 bytes of payload.
I suspect they did that to bound the latency of high priority data
items. 8 bytes is enough to package a few things together though.
All 8 cylinders of CHT or EGT for instance. Or the Nav radio packet
can include frequency, radial, and signal valid. Station ID
(automatic decode of the morse identifier) might need a separate
packet but that's probably a very low frequency event anyway.
I think it's workable.
-Dave
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: Capacitance Fuel gauges |
>> I'm starting my RV-8 tanks soon and am planning on
>> capacitance senders. What sort of gizmo is needed to
>> convert the farad info to ohm info so I might use the
>> cheaper, more widely available resistance gauges? Is
>> this something I might be able to build myself?
>
>
>I think there was a circuit to do this published in Kitplanes
>magazine sometime recently. Well, sometime in the past
>five years anyway. A letter to them and money for a back
>issue might set you up.
Yes, I have it. I believe I got it off the web from aeroelectric.com at
one point, but their articles area is down, so I ant check or refer you
back there...
In any case, I have the article in digital form... it is a September 89
article by Jim Weir. I put it on the web at the following address:
http://web.tzogon.com/~steve/stolch801/fuel_gauge/
Good luck!
Steve
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | "Marlin Mixon" <marlin_mixon(at)hotmail.com> |
>From: Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil>
>
>Marlin,
>
> What do you know about the AGATE Databus? The only thing I found was a
>meeting announcement for Dec 9 1999. Any websites? The AGATE site is
>almost
>worthless. Is NASA proposing CAN? Who would I contact at NASA or AGATE to
>get more info? DOD CDA101 folks might be are best bet for hardware and
>software guidance. So far they seem to be the most open about their work.
Well, I'm finding out that I know darn little about CAN and darn little
about the scope of what Y'all have been discussing on this list, so I'll
stand by the sidelines for now... I'd like to learn though: what was Brian
talking about re "ARINC standards" and then "NMEA2000"? Also, to help
newbies (like me) I'd be interested in helping set up a glossary of terms
(in HTML) and if Steve would be so kind to install them on his site, we can
have a nice reference of acronyms and other "proprietary" terms that we can
banty about to our hearts' content without confusing anybody.
Marlin Mixon
________________________________________________________________________________
| From: | dralle(at)matronics.com (Matt Dralle) |
| Subject: | [Please Read] List Fund Raiser Continues; LOC #1 December |
1st!
Greetings Listers!
Don't forget the 1999 List Fund Raiser is still in progress and there is
still plenty of time to make a Contribution and assure yourself a place
on on the first List Of Contributors (LOC)! I will post the first LOC
on December 1st and it will detail everyone that has generously made a
Contribution so far this year!!
It costs a great deal to maintain the Email and Web server systems and
high-speed Internet connection that provide the Email List services
found here. I won't even mention the many, many hours I spend each week
running the Lists, doing backups, handling subscription requests, and
creating new email and web features and services such as the Archive
Search Engine, and Archive Browser... Whoops; I think I just did! :-)
This year's Fund Raiser started out pretty slow and I was starting to
think that no one appreciated me anymore... ;-) But, in the last week
or so things have really started to pick up! So if you haven't made a
Contribution yet this year, why not join your email List friends and
make a contribution today to support the continued operation of these
Lists!
There are two easy methods for making your Contribution:
* Make a SSL Secure Web Contribution using your Visa or MasterCard,
surf over to:
http://www.matronics.com/contribution.html
* Make a Contribution by check, send US Mail to:
Matronics
c/o Matt Dralle
PO Box 347
Livermore, CA 94551
I would like to sincerely thank everyone who has already made a
Contribution so far this year! I greatly appreciate your generosity and
support and want you to know that these Lists have been made possible
directly by *YOU*!
Thank you!
Matt Dralle
Your Email List Administrator
--
Matt G. Dralle | Matronics | P.O. Box 347 | Livermore | CA | 94551
925-606-1001 Voice | 925-606-6281 FAX | dralle(at)matronics.com Email
http://www.matronics.com/ W.W.W. | Featuring Products For Aircraft
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
>Well, I'm finding out that I know darn little about CAN and darn
>little about the scope of what Y'all have been discussing on this
>list, so I'll stand by the sidelines for now... I'd like to learn
>though: what was Brian talking about re "ARINC standards"
>and then "NMEA2000"? Also, to help newbies (like me) I'd be
>interested in helping set up a glossary of terms (in HTML) and
>if Steve would be so kind to install them on his site, we can
>have a nice reference of acronyms and other "proprietary" terms
>that we can banty about to our hearts' content without confusing
>anybody.
OK... I'll get on it as soon as I can... *BUT*, I'm much in the same boat,
which is why I've been so quiet.
I still have all of the messages (I just haven't assimilated them yet),
and I know quite a bit of these have been explained, but if there is
anything which has *NOT* been explained, or at least defined, could we all
do so?
Thanks,
Steve
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | "Steven J. Devine" <steve(at)tzogon.com> |
| Subject: | Re: I like CAN (terms on web site) |
>I'd like to learn though: what was Brian talking about re
>"ARINC standards" and then "NMEA2000"? Also, to help
>newbies (like me) I'd be interested in helping set up a
>glossary of terms (in HTML) and if Steve would be so kind to
>install them on his site, we can have a nice reference of
>acronyms and other "proprietary" terms that we can
>banty about to our hearts' content without confusing anybody.
I have begun to add the terms to the web sit. This will obviously be an
ongoing activity...
I decided that, instead of adding a whole new glossary page (and having
lots o' links to it), I will add the terms to the bottom of the relevant
page.
In the case of the bus terms and such (electrical specs, message formats),
I will add these to the architecture details page.
Steve
http://www.tzogon.com/~steve/glass_cockpit
http://www.tzogon.com/~steve/stolch801
________________________________________________________________________________
| From: | Livingston John W Civ ASC/ENFD <John.Livingston(at)wpafb.af.mil> |
| Subject: | AGATE/ NASA Avionics Bus |
All,
I called talked to Jack sheehan(executive director, AGATE Alliance
Association) and Lanny Jimes(USAF AGATE rep) to try and get some input on
the current status of there Avionics Bus. They were very nice, but could
not tell me much do to AGATE proprietary rules.
Jack wrote me the following:
(We are starting)...a new work package(group) to complete FAA certification
and establish an open standard. There has been a down select process (to a
bus std. selection?) and there were many issues including issues of product
liability. The new work package(group) will make the decisions on technical
issues, funding and any issues such as implementation that may remain
proprietary. The intent is for an open standard, open architecture solution.
The meeting on Dec 9, 1999 is to provide enough information to allow
companies not currently involved to (help?) make the decision. (what
decision?)
It appears that the way AGATE works is by allowing participating groups
(those footing the bills) to be in on the front end standard setting
process, and then allows them to have additional AGATE proprietary
information rights for a period of time before this information is released
to the public (if ever). In some ways this appears fair; in other ways it
appears to go against the grain of open standard setting and technology
transfer. It also appears not to provide any help to serious hobbyists and
small entrepenures until well after the technology is well established.
So far I do not know what their bus standard is based on. I'm still
trying to contact a good techi in their group who can shed some light on it,
without violating any of their rules. I'll keep you posted.
John
-----Original Message-----
From: Marlin Mixon [mailto:marlin_mixon(at)hotmail.com]
Sent: Tuesday, November 23, 1999 12:19 PM
Subject: Avionics-List: I like CAN
CAN is great, I think, because of its low cost. The fact that NASA is
proposing CAN for the AGATE Databus speaks well in it's favor, if only for
the fact that NASA is pushing for FAA approval of such a system.
The AGATE Databus DOES modify the CAN system a little, but if we shoot for
CAN, I would think we'd be able to modify it later without too much hassle
to conform to the AGATE Databus.
For more on AGATE Databus (technical abstract):
http://www.sbir.nasa.gov/95abstracts/06.01/951268.html
Marlin Mixon
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Java flight display code |
A while back I put up some Java code for people to look at if they
were interested. A few people have downloaded it but I've heard
nothing back about it. Probably because it didn't work.
I'd been developing under a rather old version of the Javasoft JDK and
apparently that did things rather differently from other Java systems.
If you tried the code and got a null pointer exception trying to get
the graphics context, I've fixed that (I think). I've also fixed the
Makefile to be a little more explicit about building things in the
right order if you're trying to recompile.
I've found that toy simulator I built has an annoying bug when run
under Kaffe. While you hold down the mouse button to move the
"joysitck" around, the windows all freeze. When you let up on the
mouse button you find that it's been running behind the scenes and the
displays all jump ahead.
Probably the right thing, at some point, is for someone to pick up a
real flight simulator (there's an open source one for Linux out there
somewhere) and put in hooks to have it simulate AHRS and nav sensors
and send that data out somehow. The information could come out a
serial line, the ethernet, or even an RS-485 or CAN interface. That's
for a bit further down the road, but for people who may not want to
play with soldering irons or embedded sytems but don't mind a little
software work, this would be helpful.
http://www.froghouse.org/~dab/inst.tar.gz
http://www.froghouse.org/~dab/inst.zip
To run say "java Simulator".
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | Re: Glass cockpit project, Organization |
On 23 Nov, Steven J. Devine wrote:
> Y'all decide if I'm what you want, then we can move on and get some work
> done!
Works for me.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | The CAN Bus Architiecture, Software and Softwa |
re
On 22 Nov, Livingston John W Civ ASC/ENFD wrote:
> - not so many SBC's have CAN (as compared have to -232 or -485)
>
> /// CAN cards are available, CAN controller and tranciever chips are
> available.
I know there are chips available, looks like some pretty nice stuff
actually; I was just wondering if there were SBC's around that used
those chips or if we'd have to make our own hardware right from the
start.
> ///To the best of my knowledge CAN chipsets for interfacing to
> micro-controllers and pc's area available. I don't know what the
> availability or cost is in small lots. I'll see if I can find out.
> Anyone know????
One of the sites you sent a URL for sells CAN cards for the ISA bus.
Not what we want to put in a plane but possibly useful for R&D. They
had 1, 2, and 4 port cards starting at $355. Ouch.
> In another vain, I found a Web sight that has JAVA on a
> microcontroller chip.
With a CAN interface? Either way could you send me the URL? Thanks.
-Dave
________________________________________________________________________________
| From: | dab(at)froghouse.org |
| Subject: | The CAN Bus Architiecture, Software and Softwa |
re
September 12, 1999 - November 24, 1999
Avionics-Archive.digest.vol-aa