Glass Panel Longevity

"Grumman-581" writes:

Personally, I'm not a big fan of the one system does everything approach in
some of the glass panels... I have no problem with mechanical gauges being
replaced with electronic gauges, but I would prefer for them to be
independent, possibly communicating to some other system through some sort
of standard interface... At Rockwell, many of their new systems were
communicating via TCP/IP packets... I kind of liked this approach... It
seemed rather simple and elegant... A device would have a particular IP
address and port number associated with it... You could send information to
that device or retrieve information from it as appropriate... For a
non-compliant device, you could just design a TCP/IP interface to the device
that translated from the proprietary device information format to the TCP/IP
format...

Minimizing the software improves reliability and safety. TCP/IP
interfaces generally require software, and that's not a good thing.

--
Transpose mxsmanic and gmail to reach me by e-mail.

Mxsmanic wrote:
Guy Elden Jr writes:

It's a lot easier / cheaper to replace one mechanical gauge than an
entire instrument panel.

And it's a lot easier to survive in flight with one failing gauge than
with an entire failing panel.

I guess that's why they have 2 and redundant steam gauges.

Guy Elden Jr wrote:

Do people repair mechanical gauges or simply replace them when they stop
working?

It's a lot easier / cheaper to replace one mechanical gauge than an
entire instrument panel.

I don't know much about the G1000, but I am currently reading Max
Trescott's book on the subject; isn't the whole idea of this system
that it is made up of easily serviceable and replaceable (and
presumably upgradable) modules?

--Sylvain

Originally Posted by Jim Logajan

john smith wrote:
Steam gauges are forever,

They are?

Is the same model artificial horizon designed decades ago still
manufactured today?

Do people repair mechanical gauges or simply replace them when they stop
working?

Jim,

I make a very good living repairing mechanical instruments. My company (The Gyro House) repairs over 500 instruments every month. It often amazes me how old some of those instruments are, many are older than me and I'll be 53 in December. It is true that it is difficult to find parts for some of the older instruments, but it is just as difficult to find chips for electronic instruments that were built in the 1970 -1990 time period. Again I can say this with certainty as my shop works on electronic instruments as well as the mechanical ones.

Concerning replacing instruments: it is sometimes the case that an instrument can become so worn out that it is no longer repairable,however out of the over 500 we do per month I can confidently say that less than 2% are found to be non-repairable.


Rich

Recently, Sylvain posted:

Guy Elden Jr wrote:

Do people repair mechanical gauges or simply replace them when they
stop working?

It's a lot easier / cheaper to replace one mechanical gauge than an
entire instrument panel.

I don't know much about the G1000, but I am currently reading Max
Trescott's book on the subject; isn't the whole idea of this system
that it is made up of easily serviceable and replaceable (and
presumably upgradable) modules?

I don't know, but I would design the system that way. Even at the level of
integrated circuits, there are plug-in replacements for obsolete parts,
and I don't see any advantage to using unique components in this kind of
application.

Neil

Neil Gould wrote:
Recently, Sylvain posted:

Guy Elden Jr wrote:

Do people repair mechanical gauges or simply replace them when they
stop working?

It's a lot easier / cheaper to replace one mechanical gauge than an
entire instrument panel.

When digital watches first came out, they cost a lot more than
the old wind-ups even though they cost far less to produce. As more
manufacturers got into the act, the cost came down to more reasonable
levels.
I had an attitude indicator overhauled the other day. Cost
$675 Canadian. This stuff is only going to get more expensive as labour
goes up, since it can't be totally assembled by some robot. The life of
a gyro is rather short, too, especially in an operation like ours where
starting the airplane in cold weather is hard on gyro bearings. Engine
vibration eats gyros, and dry vacuum pumps last maybe 1200 hours.
If there are enough EFIS systems in use when a manufacturer
quits making them, some aftermarket manufacturer will find profit in
making replacement boards and displays for them under PMA rules. And as
more companies start making them, the up-front costs will come down. It
won't be instrument replacement costs that finally ground us; it will
be lawyers and insurance companies and heavyhanded regulation.

Dan

"Neil Gould" wrote in message
t...
I don't know, but I would design the system that way. Even at the level of
integrated circuits, there are plug-in replacements for obsolete parts,
and I don't see any advantage to using unique components in this kind of
application.

Unfortunately, some of the people making the decisions in these companies
don't necessarily see it that way... I was looking for a way to hook up the
output from my Northstar M1A LORAN to my laptop a few years ago so that I
could use it as input to a situation awareness program that I was writing...
Although NMEA 0183 was used by all the handheld LORANs and GPSs at that
time, it seems that Northstar chose to use a proprietary format for the data
stream coming out of their unit... While talking with them, I learned that
this was not uncommon within the avionics industry... A system like the
Argus moving map had to be able to understand all the possible data formats
of the various units that it supported...

Standards are great if everyone agrees to support them... Supposedly FireFox
is a true W3C compliant browser (unlike MS's IE)... I've encountered various
web sites that do not work correctly with it, but they work with IE... It
seems that developers get sloppy in that IE allows them to get away with
things that are not W3C compliant... Hell, I've even had to go back and
modify some of my own web apps that I created in the pre-FireFox days to
make them work with FireFox... Luckily it's only been needing to add
"document.getElementById" for each field accessed by a JavaScript function
variable... It seems that IE allowed you to be lazy and not require this...

Oh well, I'm digressing... The point is, don't assume that companies will
make decisions that will give you the most flexibility... They have a vested
interest in tying you to their products... Even if they have a common
interface like the TCP/IP interface that Rockwell was using on the systems
that I worked on, it doesn't necessarily help unless there is a standardized
command packet format... Otherwise, you will find yourself with one device
that although physically able to talk to another device, they might not be
able to understand what each other are saying... With some devices, it might
not be that difficult to come up with a common message protocol that the
device could support, with others, this could be quite extensive... For
example, consider the following devices and what they might need:

ADF:
1. Set frequency
2. Get frequency
3. Get bearing to transmitter
4. Enable audio output
5. Disable audio output

Transponder:
1. Set squawk code
2. Get squawk code
3. Set current mode (standby, Mode-A, Mode-C, Mode-S)
4. Get current mode
5. Initiate IDENT
6. Get IDENT status

Of course, every unit would also need a "Get system health / status" message
for retrieval internal diagnostics... It would be *nice* to know when a
particular device could not be relied upon... grin

I would like to see a system where you could put the actual measuring
devices in one location and the panel only needed to contain the devices
that display the information... For example, you could buy a small 2"-4"
generic display that could be set to display the output for various types of
devices... If one of the displays was acting up, you could change another
display so that it would display the output from the particular measuring
device... One advantage of this might be that although you might have
redundant measuring devices, only one display for the pair might need to be
on the panel... A failed health check might cause an indication to the pilot
that the backup device needs to be made active... Maybe it would even be
possible to toggle between the two devices...

Hell, as long as we're at it, let's give it a panel mount plug so that we
can plug our laptop PC into it also... If you had the building blocks in
place with this sort of TCP/IP controlled devices, just think of what sort
of flexibility that you could get without having to buy a $20K+ avionics
package... Of course, my point of view is as a VFR pilot would would like
some of the capabilities of the flight director type systems, but are not
able (either from a monetary or a physical panel space point of view) to put
one in their aircraft...

Grumman-581 wrote:

Unfortunately, some of the people making the decisions in these companies
don't necessarily see it that way...

so in short, the only reasonable long term stragegy would be to make
these things open source; I couldn't agree more, but how do you
go about achieving this? the manufacturer must either be coerced in
doing it (via regulations) or have a good incentive, i.e., a
painfully obvious -- as in, that even the most bone-headed MBA
waiving PHB manager could understand -- evidence that it would
be in their best interest to open up at least the interface
specs. But considering what I have seen so far in the industry
I am not holding my breath...

--Sylvain

Sylvain writes:

so in short, the only reasonable long term stragegy would be to make
these things open source; I couldn't agree more, but how do you
go about achieving this? the manufacturer must either be coerced in
doing it (via regulations) or have a good incentive, i.e., a
painfully obvious -- as in, that even the most bone-headed MBA
waiving PHB manager could understand -- evidence that it would
be in their best interest to open up at least the interface
specs. But considering what I have seen so far in the industry
I am not holding my breath...

How do you certify open source?

--
Transpose mxsmanic and gmail to reach me by e-mail.

Sylvain wrote:
so in short, the only reasonable long term stragegy would be to make
these things open source; I couldn't agree more, but how do you
go about achieving this? the manufacturer must either be coerced in
doing it (via regulations) or have a good incentive, i.e., a
painfully obvious -- as in, that even the most bone-headed MBA
waiving PHB manager could understand -- evidence that it would
be in their best interest to open up at least the interface
specs. But considering what I have seen so far in the industry
I am not holding my breath...

Unfortunately, you're right about this... I am not all that crazy about
the idea of regulatory standards though... Once you get the government
involved in something, often, it gets rapidly screwed up...

When I was wanting to interface a program with the Northstar M1A LORAN,
it took a bit of digging to find out who to contact, but they did not
have a problem sending me a copy of the actual interface document...
Yeah, it was probably a Xerox copy of a copy of a copy, but it was
sufficiently readable and I did not have a problem understanding what
would be necessary to write a program to interface with it... Still, the
problem is that if I wanted to also make the program work with a
different unit, I would have to get the interface document and write
code for the different unit... Hell, even with NMEA 0183 that is output
by nearly every handheld GPS, the output stream from one manufacturer
might vary from what a different manufacturer might choose to send...
Some manufacturers use one particular NMEA 0183 sentence for position
reporting whereas another manufacturer might use a different sentence...
If you look at some of the PC based moving map programs, you'll see that
they might give you an option on the type of GPS that you have... If
they have a pretty good selection of them and your GPS is not one of
them, it's at least possible that your GPS will be similar enough to one
of the ones that they do support for it to work for you... On the other
hand, some of the GPS manufacturers utilize a binary NMEA format instead
of the standard text based one...