Glass Panel Longevity

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.

Mxsmanic wrote:
How do you certify open source?

why should it be any different than proprietary stuff?

--Sylvain

Sylvain writes:

why should it be any different than proprietary stuff?

A total lack of control is one huge difference. A total lack of
accountability and liability is another. A total lack of
customer-oriented incentive for fixes and improvements is still
another. There are many differences.

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

Mxsmanic wrote:

why should it be any different than proprietary stuff?

A total lack of control is one huge difference. A total lack of
accountability and liability is another. A total lack of
customer-oriented incentive for fixes and improvements is still
another. There are many differences.

you just made it clear that you do not understand how open
source development works. I don't even know where to start...

--Sylvain

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...

On Fri, 20 Oct 2006 16:47:48 -0700, Sylvain wrote:

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

Even if "open source" you have not addressed the hard ware you have in
hand issue. It would make it easier to replace with something more
modern, BUT what ever goes in would need to be certified. But for a
major piece of hard ware having a chip fail that is no longer
available...what do you do? Developing a replacement board, even if
you know the signal config into and out of the board, is going to be
expensive to the point of not being economically viable.

What would be nice would be some sort of standardization for the I/O
protocols instead of every one doing it "their own way". Of course I
think the same thing about the controls.

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
Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com