Some insights into the G1000

[Neil Gould]

Yesterday, I attended a 4-hour seminar on the G1000 presented by Charlie
Masters (Cessna/FITS & Sporty's @ Clermont County). The focus was on
providing an overview of transitioning from steam gauges to glass panels
as implemented in new Cessna single-engine aircraft. Charlie did a great
job, and has good general knowledge of the system. Overall, I am quite
impressed with the thought behind this unit, and think it will be the way
of things to come.

Of course, in addition to the general information, I was curious about the
possible causes for NW_Pilot's experience during the ferrying of a 172,
and asked a couple of questions that might have provided some insights. I
believe that I have some clues, but I'm still at a loss to explain some of
what he went through.

There are many things to understand about the G1000 installation, perhaps
foremost is that this is not a single box that is located in the panel.
There are more than a half dozen modules (not including the sensors), some
located in the tail of the plane, some located behind the panel. These
have specific functions, for example the Attitude/Heading Reference System
(AHRS) provides attitude and directional information to the virtual AI &
HSI separately from the Integrated Avionics (GIA) that provides GPS/NAV &
Comm functions. Other modules include the Engine/Airframe (GEA) unit, Data
Link (GDL), and audio panel. The modules are on separate breakers in the
panel.

The significance of this kind of modularity is that the failure of any of
these modules will not cause an overall system failure. I also asked
Charlie about the connections between these modules and the monitor. There
is a single multi-conductor cable connection to the back of the monitor
panels. The entire system is fed power from a connection to the master
switch (there is also a backup battery that can operate the unit
separately from master power). So, the total failure is unlikely to have
been caused by sensors, monitors or modules, as all of those would have to
not only fail simultaneously, but would have to reinstate themselves to
"come up" after a reboot, which is highly unlikely. Even a problem with
the multi-conductor cable would only affect one of the two monitor panels.

All of this confirms my original suspicion that for the entire system to
periodically spontaneously reboot, the cause is likely to be an
intermittent power connection. In such a case, all of the modules would go
down, and the process would emulate the POH procedure for intentionally
rebooting the system.

Neil

[J. Severyn]

"Neil Gould" > wrote in message
et...
> Yesterday, I attended a 4-hour seminar on the G1000 presented by Charlie
> Masters (Cessna/FITS & Sporty's @ Clermont County). The focus was on
> providing an overview of transitioning from steam gauges to glass panels
> as implemented in new Cessna single-engine aircraft. Charlie did a great
> job, and has good general knowledge of the system. Overall, I am quite
> impressed with the thought behind this unit, and think it will be the way
> of things to come.
>
> Of course, in addition to the general information, I was curious about the
> possible causes for NW_Pilot's experience during the ferrying of a 172,
> and asked a couple of questions that might have provided some insights. I
> believe that I have some clues, but I'm still at a loss to explain some of
> what he went through.
>
> There are many things to understand about the G1000 installation, perhaps
> foremost is that this is not a single box that is located in the panel.
> There are more than a half dozen modules (not including the sensors), some
> located in the tail of the plane, some located behind the panel. These
> have specific functions, for example the Attitude/Heading Reference System
> (AHRS) provides attitude and directional information to the virtual AI &
> HSI separately from the Integrated Avionics (GIA) that provides GPS/NAV &
> Comm functions. Other modules include the Engine/Airframe (GEA) unit, Data
> Link (GDL), and audio panel. The modules are on separate breakers in the
> panel.
>
> The significance of this kind of modularity is that the failure of any of
> these modules will not cause an overall system failure. I also asked
> Charlie about the connections between these modules and the monitor. There
> is a single multi-conductor cable connection to the back of the monitor
> panels. The entire system is fed power from a connection to the master
> switch (there is also a backup battery that can operate the unit
> separately from master power). So, the total failure is unlikely to have
> been caused by sensors, monitors or modules, as all of those would have to
> not only fail simultaneously, but would have to reinstate themselves to
> "come up" after a reboot, which is highly unlikely. Even a problem with
> the multi-conductor cable would only affect one of the two monitor panels.
>
> All of this confirms my original suspicion that for the entire system to
> periodically spontaneously reboot, the cause is likely to be an
> intermittent power connection. In such a case, all of the modules would go
> down, and the process would emulate the POH procedure for intentionally
> rebooting the system.
>
> Neil
>

Neil,
You could be correct. A bad power connection or poorly regulated power
could cause big problems. But the G1000 has an internal battery pack that is
supposed to provide graceful transition with bad power inputs. Accordingly,
I would not rule out a latent software problem. After reading NW_Pilot's
postings, I was thinking that the original fuel quantity display problems
might have caused some sort of over or under-range internal calculation
error. Since my day job involves integrating hardware and software in large
million-line control systems, this is one of the first things that came to
mind. It is exceedingly difficult to test hardware and software in complex
systems at the possible extremes to guarantee proper operation.

I sure hope that Garmin reads these types of newsgroup postings and
investigates. Invalid or over inputs on one or more sensors should not have
radical effects on unrelated operational modes of the G1000. But it
certainly looked like it was happening to NW_Pilot.

Regards,
John Severyn

[Neil Gould]

Recently, J. Severyn > posted:

> "Neil Gould" > wrote in message
> et...
>> Yesterday, I attended a 4-hour seminar on the G1000 presented by
>> Charlie Masters (Cessna/FITS & Sporty's @ Clermont County). The
>> focus was on providing an overview of transitioning from steam
>> gauges to glass panels as implemented in new Cessna single-engine
>> aircraft. Charlie did a great job, and has good general knowledge of
>> the system. Overall, I am quite impressed with the thought behind
>> this unit, and think it will be the way of things to come.
>>
>> Of course, in addition to the general information, I was curious
>> about the possible causes for NW_Pilot's experience during the
>> ferrying of a 172, and asked a couple of questions that might have
>> provided some insights. I believe that I have some clues, but I'm
>> still at a loss to explain some of what he went through.
>>
>> There are many things to understand about the G1000 installation,
>> perhaps foremost is that this is not a single box that is located in
>> the panel. There are more than a half dozen modules (not including
>> the sensors), some located in the tail of the plane, some located
>> behind the panel. These have specific functions, for example the
>> Attitude/Heading Reference System (AHRS) provides attitude and
>> directional information to the virtual AI & HSI separately from the
>> Integrated Avionics (GIA) that provides GPS/NAV & Comm functions.
>> Other modules include the Engine/Airframe (GEA) unit, Data Link
>> (GDL), and audio panel. The modules are on separate breakers in the
>> panel.
>>
>> The significance of this kind of modularity is that the failure of
>> any of these modules will not cause an overall system failure. I
>> also asked Charlie about the connections between these modules and
>> the monitor. There is a single multi-conductor cable connection to
>> the back of the monitor panels. The entire system is fed power from
>> a connection to the master switch (there is also a backup battery
>> that can operate the unit separately from master power). So, the
>> total failure is unlikely to have been caused by sensors, monitors
>> or modules, as all of those would have to not only fail
>> simultaneously, but would have to reinstate themselves to "come up"
>> after a reboot, which is highly unlikely. Even a problem with the
>> multi-conductor cable would only affect one of the two monitor
>> panels.
>>
>> All of this confirms my original suspicion that for the entire
>> system to periodically spontaneously reboot, the cause is likely to
>> be an intermittent power connection. In such a case, all of the
>> modules would go down, and the process would emulate the POH
>> procedure for intentionally rebooting the system.
>>
>> Neil
>>
>
> Neil,
> You could be correct. A bad power connection or poorly regulated
> power could cause big problems. But the G1000 has an internal battery
> pack that is supposed to provide graceful transition with bad power
> inputs. Accordingly, I would not rule out a latent software problem.
> After reading NW_Pilot's postings, I was thinking that the original
> fuel quantity display problems might have caused some sort of over or
> under-range internal calculation error.
>
Originally, I thought that this might be a possible scenario. However, the
fuel information is provided by the GEA, and even if that unit fails
completely, it would only result in red "X" over the fuel readout. There
are a couple of scenarios that can produce failure indications in the fuel
readouts, but from what I understand, nothing that can trigger a complete
system failure.

> Since my day job involves
> integrating hardware and software in large million-line control
> systems, this is one of the first things that came to mind. It is
> exceedingly difficult to test hardware and software in complex
> systems at the possible extremes to guarantee proper operation.
>
I understand, and it appears that this was done. On the one hand, this
system isn't all that complex; rather than feed numerous inputs into a
single interpreter module, which might result in the kind of event you're
anticipating, each module is a physically separate piece of hardware that
feeds its results to the integraged display. There is also redundancy
built into some modules (multiple components doing the same job), and any
ambiguities are either resolved by a "vote of the majority" or failed, but
won't result in a system-wide reboot.

Simply put, out of range data would just fail that particular function.
For example, in the case of his fuel level reading failures, it seems
reasonable that the *increasing* fuel level readings as engine overflow
was fed from the aux tank to the main tanks didn't agree with the fuel
consumption computer, and as a result, the G1000 "X'd" it out, in essence
saying "don't depend on this info"; that is an intended behavior of the
G1000.

> I sure hope that Garmin reads these types of newsgroup postings and
> investigates. Invalid or over inputs on one or more sensors should
> not have radical effects on unrelated operational modes of the G1000.
> But it certainly looked like it was happening to NW_Pilot.
>
What I took away from the seminar is that about the only scenario that
could produce the effects that NW_Pilot reported is a main power failure.
All of the modules would have to fail simultaneously, and even then, the
system wouldn't reboot, but would show a screen full of red Xs. In fact,
the POH method of rebooting the G1000 in-flight is to shut off the main
power switch. The backup battery is only good for 1/2 hour, so it seems
possible that the spontaneous rebooting behavior started after the backup
battery was dry.

Neil

[J. Severyn]

"Neil Gould" > wrote in message
et...
> Recently, J. Severyn > posted:
>
>> "Neil Gould" > wrote in message
>> et...
>>> Yesterday, I attended a 4-hour seminar on the G1000 presented by

snip

> I understand, and it appears that this was done. On the one hand, this
> system isn't all that complex; rather than feed numerous inputs into a
> single interpreter module, which might result in the kind of event you're
> anticipating, each module is a physically separate piece of hardware that
> feeds its results to the integraged display. There is also redundancy
> built into some modules (multiple components doing the same job), and any
> ambiguities are either resolved by a "vote of the majority" or failed, but
> won't result in a system-wide reboot.

I understand. But the integrated display might be the culprit. The
individual LRUs might be acting properly and feeding data to the display
system. If the display system (hardware or software) does not properly
handle the exceptions, then lots of unintended things can happen. Software
patches, compiler errors etc. only make the testing combinations all the
more difficult.

In any case, a pilot has got to be able to keep the dirty side down using
the backup steam guages.

snip
> Neil
>

Regards,
John Severyn

[J. Severyn]

"Neil Gould" > wrote in message
et...

By the way, Garmin is not unique to similar problems. It has happened to
the big iron too.
http://www.ntsb.gov/recs/letters/1998/A98_3_5.pdf notes intended reboots in
the EFIS in an A300 back in 1997.
Regards,
John Severyn

[Mxsmanic]

J. Severyn writes:

> I sure hope that Garmin reads these types of newsgroup postings and
> investigates. Invalid or over inputs on one or more sensors should not have
> radical effects on unrelated operational modes of the G1000. But it
> certainly looked like it was happening to NW_Pilot.

Many companies in this domain for the first time, especially those
with PC backgrounds, never read anything and reinvent the wheel the
hard way, sometimes only after a string of very bad things happen.

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

[Mxsmanic]

J. Severyn writes:

> By the way, Garmin is not unique to similar problems. It has happened to
> the big iron too.
> http://www.ntsb.gov/recs/letters/1998/A98_3_5.pdf notes intended reboots in
> the EFIS in an A300 back in 1997.

Airbus and Garmin have some things in common.

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

[Neil Gould]

Recently, J. Severyn > posted:

> "Neil Gould" > wrote:
>> Recently, J. Severyn > posted:
>>
>>> "Neil Gould" > wrote in message
>>> et...
>>>> Yesterday, I attended a 4-hour seminar on the G1000 presented by
>
> snip
>
>> I understand, and it appears that this was done. On the one hand,
>> this system isn't all that complex; rather than feed numerous inputs
>> into a single interpreter module, which might result in the kind of
>> event you're anticipating, each module is a physically separate
>> piece of hardware that feeds its results to the integraged display.
>> There is also redundancy built into some modules (multiple
>> components doing the same job), and any ambiguities are either
>> resolved by a "vote of the majority" or failed, but won't result in
>> a system-wide reboot.
>
> I understand. But the integrated display might be the culprit.
>
I don't think that's possible. There is no provision for the display
system to reboot the hardware; that just isn't done via software, or even
by physical switches located on the display unit(s). The display unit(s)
can't turn on or off the individual modules either, so a software glitch
of any kind -- or even total failure of the display -- isn't able to be
the cause of a system-wide reboot.

> The
> individual LRUs might be acting properly and feeding data to the
> display system. If the display system (hardware or software) does
> not properly handle the exceptions, then lots of unintended things
> can happen. Software patches, compiler errors etc. only make the
> testing combinations all the more difficult.
>
I understand, and in a type of arrangement where sensor outputs are being
interpreted by centralized CPU, what you describe might be an area of
concern. But, the G1000 is not that kind of system. Each module is its own
complete computing system, the integrated display merely reports the data
provided by the modules. When the data from modules conflicts and can't be
resolved, the centralized display can disable that module's content *on
the screen*, it can't shut the module down.

> In any case, a pilot has got to be able to keep the dirty side down
> using the backup steam guages.
>
The backup steam gauges are completely separate from the G1000, as is the
autopilot and the comm (another reason that I suspect NW_Pilot's problems
are related to the loss of power). In fact, the 2-axis autopilot has its
own turn coordinator mounted behind(!) the panel, and will fly the plane
even if the G1000 is turned off.

Neil

[Mxsmanic]

Neil Gould writes:

> I don't think that's possible. There is no provision for the display
> system to reboot the hardware; that just isn't done via software, or even
> by physical switches located on the display unit(s). The display unit(s)
> can't turn on or off the individual modules either, so a software glitch
> of any kind -- or even total failure of the display -- isn't able to be
> the cause of a system-wide reboot.

Virtually any bug can cause a reboot. Anything that produces a
hardware exception can cause a reboot if it is unexpected,
particularly if the system is doing privileged work at the time. A
reboot is the typical response to any unhandled exception. The
alternative is to let the system run hither and yon uncontrolled
through the code, which is even worse than a reboot in most cases.

Of course, in safety-of-life applications, there must not be any
unexpected exceptions; if there are, it's a flaw in the design.
Unfortunately, people from PC-land tend to take the system down
whenever there's a spot in the code that they don't want to design or
analyze in detail.

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

[Robert M. Gary]

Although many of the components of the G1000 have backups, many do
not. There are a lot of failures you can have that don't effect the
operation, but some do. Part of the transition training (especially
for IFR pilots) is to understand the failure mode of the different
components. Sadly, we're finding that we are only able to sign off
most of our instrument pilots for VFR in the G1000. The biggest
problem is getting behind the plane and not getting the approach set
up in the system soon enough. This is mostly the older guys though. I
dont' think anyone under 40 has had a problem.

-Robert, CFII, FITS trained TAA instructor


On Jan 28, 8:23 am, "Neil Gould" > wrote:
> Yesterday, I attended a 4-hour seminar on the G1000 presented by Charlie
> Masters (Cessna/FITS & Sporty's @ Clermont County). The focus was on
> providing an overview of transitioning from steam gauges to glass panels
> as implemented in new Cessna single-engine aircraft. Charlie did a great
> job, and has good general knowledge of the system. Overall, I am quite
> impressed with the thought behind this unit, and think it will be the way
> of things to come.
>
> Of course, in addition to the general information, I was curious about the
> possible causes for NW_Pilot's experience during the ferrying of a 172,
> and asked a couple of questions that might have provided some insights. I
> believe that I have some clues, but I'm still at a loss to explain some of
> what he went through.
>
> There are many things to understand about the G1000 installation, perhaps
> foremost is that this is not a single box that is located in the panel.
> There are more than a half dozen modules (not including the sensors), some
> located in the tail of the plane, some located behind the panel. These
> have specific functions, for example the Attitude/Heading Reference System
> (AHRS) provides attitude and directional information to the virtual AI &
> HSI separately from the Integrated Avionics (GIA) that provides GPS/NAV &
> Comm functions. Other modules include the Engine/Airframe (GEA) unit, Data
> Link (GDL), and audio panel. The modules are on separate breakers in the
> panel.
>
> The significance of this kind of modularity is that the failure of any of
> these modules will not cause an overall system failure. I also asked
> Charlie about the connections between these modules and the monitor. There
> is a single multi-conductor cable connection to the back of the monitor
> panels. The entire system is fed power from a connection to the master
> switch (there is also a backup battery that can operate the unit
> separately from master power). So, the total failure is unlikely to have
> been caused by sensors, monitors or modules, as all of those would have to
> not only fail simultaneously, but would have to reinstate themselves to
> "come up" after a reboot, which is highly unlikely. Even a problem with
> the multi-conductor cable would only affect one of the two monitor panels.
>
> All of this confirms my original suspicion that for the entire system to
> periodically spontaneously reboot, the cause is likely to be an
> intermittent power connection. In such a case, all of the modules would go
> down, and the process would emulate the POH procedure for intentionally
> rebooting the system.
>
> Neil

[Robert M. Gary]

On Jan 28, 5:14 pm, Mxsmanic > wrote:
> Neil Gould writes:
> > I don't think that's possible. There is no provision for the display
> > system to reboot the hardware; that just isn't done via software, or even
> > by physical switches located on the display unit(s). The display unit(s)
> > can't turn on or off the individual modules either, so a software glitch
> > of any kind -- or even total failure of the display -- isn't able to be
> > the cause of a system-wide reboot.Virtually any bug can cause a reboot. Anything that produces a
> hardware exception can cause a reboot if it is unexpected,
> particularly if the system is doing privileged work at the time. A
> reboot is the typical response to any unhandled exception. The
> alternative is to let the system run hither and yon uncontrolled
> through the code, which is even worse than a reboot in most cases.
>
> Of course, in safety-of-life applications, there must not be any
> unexpected exceptions; if there are, it's a flaw in the design.
> Unfortunately, people from PC-land tend to take the system down
> whenever there's a spot in the code that they don't want to design or
> analyze in detail.

A reboot of an individual display would not surprise me (although I've
never seen it happen). A reboot of both would surprise me. However,
NW_pilot's issue was a software bug associated with the long range
tanks that were installed. I guess the computer failed working out the
fuel calculations. Since both sides run the same software, both sides
probably had the same fault.

-Robert, CFII, FITS TAA instructor.

[Mxsmanic]

Robert M. Gary writes:

> Although many of the components of the G1000 have backups, many do
> not. There are a lot of failures you can have that don't effect the
> operation, but some do. Part of the transition training (especially
> for IFR pilots) is to understand the failure mode of the different
> components. Sadly, we're finding that we are only able to sign off
> most of our instrument pilots for VFR in the G1000. The biggest
> problem is getting behind the plane and not getting the approach set
> up in the system soon enough. This is mostly the older guys though. I
> dont' think anyone under 40 has had a problem.

Why is it sad? You can still sign them off in an aircraft with more
traditional gauges at a much lower cost, and without the risk of a
software bug putting them in mortal danger.

You can't really teach them the failure modes of the system
completely, anyway, since even the manufacturer hasn't bothered to
figure that out (which is one of the risks of these systems).

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

[Neil Gould]

Recently, Robert M. Gary > posted:

>> Neil Gould writes:
>>> I don't think that's possible. There is no provision for the display
>>> system to reboot the hardware; that just isn't done via software,
>>> or even by physical switches located on the display unit(s). The
display
>>> unit(s) can't turn on or off the individual modules either, so a
software
>>> glitch of any kind -- or even total failure of the display -- isn't
able
>>> to be the cause of a system-wide reboot.
>
> A reboot of an individual display would not surprise me (although I've
> never seen it happen). A reboot of both would surprise me.
>
Do you mean a display failure rather than a reboot? Anyway, as I
understand it, there is no facility for the display to reboot the
individual computers

> However,
> NW_pilot's issue was a software bug associated with the long range
> tanks that were installed. I guess the computer failed working out the
> fuel calculations. Since both sides run the same software, both sides
> probably had the same fault.
>
That is my guess as well, based on the information from the seminar. As I
understand it, the G1000 would disable (red "X") the readout of any
component with an unresolvable conflict. Since the aux tank was
"refilling" the main fuel tanks via the overflow return, it wouldn't be
long before the flight computer data would be in conflict with the fuel
level sensor and therefore generate an unresolvable error. It should be
expected that both displays would show the same error condition.

Neil

[Peter Clark]

On 29 Jan 2007 10:23:49 -0800, "Robert M. Gary" >
wrote:

>A reboot of an individual display would not surprise me (although I've
>never seen it happen). A reboot of both would surprise me. However,
>NW_pilot's issue was a software bug associated with the long range
>tanks that were installed. I guess the computer failed working out the
>fuel calculations. Since both sides run the same software, both sides
>probably had the same fault.
>
>-Robert, CFII, FITS TAA instructor.

If it was a software problem with handling the long range tank, don't
you think it would have shown up in some other flight than his? It's
not like he's the first to take ferry tanks and a G1000 equipped
aircraft across the pond.

The fuel indication system in the Cessna 172 G1000 is a plastic float
attached to an arm which controls a rheostat and produces a variable
resistance. The resistance is measured, from a high-ohm to a low-ohm
limit (+-5ohm if I remember correctly) by the GEA and translated into
a pointer on the display. It's not computed, it's not analyzed, it's
not even compared with time-to-empty, fuel-flow, etc etc etc. In
fact, the standard full-tanks is about 1hr flight above where the
float starts generating something other than the signal "full" and the
system doesn't reboot due to it. We've replaced many floats in my
aircraft (they have a tendency to red X when the tanks are full until
a couple of gallons are burned down) and not once was a red X for
extended periods of time responsible for a system rebooting. In fact,
I've never seen or heard of a system rebooting to "initializing
system" outside of the one sample. The three shops I deal with for
avionics, who are Cessna service centers and Garmin dealers, haven't
seen this either.

[Peter Clark]

On Mon, 29 Jan 2007 21:17:47 GMT, "Neil Gould"
> wrote:

>That is my guess as well, based on the information from the seminar. As I
>understand it, the G1000 would disable (red "X") the readout of any
>component with an unresolvable conflict. Since the aux tank was
>"refilling" the main fuel tanks via the overflow return, it wouldn't be
>long before the flight computer data would be in conflict with the fuel
>level sensor and therefore generate an unresolvable error. It should be
>expected that both displays would show the same error condition.

I guess that would be based on the invalid presumption that the fuel
computer, time to empty, fuel flow, etc have any interaction with the
fuel level indicators. They don't. You tell the time-to-empty
computer how much fuel is onboard and it deducts based on current fuel
flow. If you don't refresh it's fuel on board at the beginning of a
flight you can get 0:00 minutes to empty with hours worth of fuel left
in the tanks.

[Neil Gould]

Recently, Peter Clark > posted:

> On Mon, 29 Jan 2007 21:17:47 GMT, "Neil Gould"
> > wrote:
>
>> That is my guess as well, based on the information from the seminar.
>> As I understand it, the G1000 would disable (red "X") the readout of
>> any component with an unresolvable conflict. Since the aux tank was
>> "refilling" the main fuel tanks via the overflow return, it wouldn't
>> be long before the flight computer data would be in conflict with
>> the fuel level sensor and therefore generate an unresolvable error.
>> It should be expected that both displays would show the same error
>> condition.
>
> I guess that would be based on the invalid presumption that the fuel
> computer, time to empty, fuel flow, etc have any interaction with the
> fuel level indicators.
>
Yes, that would be it. ;-)

> They don't.
>
Thanks for the clarification, as it is not the answer that I got to the
question I asked about it. But, as you apparently own one and have
observed this condition, your knowledge resolves the conflict. ;-)

So, what happens if the fuel level indicators report "full" after a few of
hours of flying, which could be the case in NW_Pilot's ferrying scenario?
Might the GEA presume that they weren't working, and "X" it out on the
display?

Neil

[Peter Clark]

On Mon, 29 Jan 2007 17:50:21 -0600, "Neil Gould"
> wrote:

>Thanks for the clarification, as it is not the answer that I got to the
>question I asked about it. But, as you apparently own one and have
>observed this condition, your knowledge resolves the conflict. ;-)

No worries.

>So, what happens if the fuel level indicators report "full" after a few of
>hours of flying, which could be the case in NW_Pilot's ferrying scenario?
>Might the GEA presume that they weren't working, and "X" it out on the
>display?

I can't say with absolute certainty as I don't have access to the code
directly, but in my experience the GEA happily continues on showing
the pointer at F. It doesn't appear to process the data coming in
beyond saying "input ohm x, display level y". The first issue NW
experienced (Xing the level) was likely similar to issues we've had
when the float produces an out-of-range resistance. They seem to do
that routinely when the tanks are topped off to the point of fuel
coming out of the filler cap when opened and will function fine when
the fuel level goes down a bit. I've seen over 2 hours of an X'd fuel
gauge due to tippy-topped tanks, 182, and uneven burn keeping one tank
high. I even asked at the factory last time I picked one up about the
ferry account and they hadn't heard about it.

I still think the most likely culprit in his account was the
third-party non-integrated (XM? CD?) player hacked into the system.
As I mentioned in another post, it's not like these things haven't
been ferried routinely since 2004, and the lack of field issues like
this in all the aircraft makes and models with G1000 equipment IMO
just doesn't support the assertions that this is some kind of inherent
design defect.

[Neil Gould]

Recently, Peter Clark > posted:

> On Mon, 29 Jan 2007 17:50:21 -0600, "Neil Gould"
> > wrote:
>
>> So, what happens if the fuel level indicators report "full" after a
>> few of hours of flying, which could be the case in NW_Pilot's
>> ferrying scenario? Might the GEA presume that they weren't working,
>> and "X" it out on the display?
>
> I can't say with absolute certainty as I don't have access to the code
> directly, but in my experience the GEA happily continues on showing
> the pointer at F. It doesn't appear to process the data coming in
> beyond saying "input ohm x, display level y".
>
I suppose that's what one could expect if there is no interaction between
the readout and any other engine information.

> The first issue NW experienced (Xing the level) was likely similar to
> issues we've had when the float produces an out-of-range resistance.
> They seem to do that routinely when the tanks are topped off to the
point
> of fuel coming out of the filler cap when opened and will function fine
when
> the fuel level goes down a bit. I've seen over 2 hours of an X'd fuel
> gauge due to tippy-topped tanks, 182, and uneven burn keeping one tank
> high. I even asked at the factory last time I picked one up about the
> ferry account and they hadn't heard about it.
>
That anomaly was mentioned in the seminar, and could explain NW's
observations because the tanks would be "over full" if fuel was venting
in-flight.
> I still think the most likely culprit in his account was the
> third-party non-integrated (XM? CD?) player hacked into the system.
>
I agree that the reboot problem was most likely something related to the
third-party panel mods.

> As I mentioned in another post, it's not like these things haven't
> been ferried routinely since 2004, and the lack of field issues like
> this in all the aircraft makes and models with G1000 equipment IMO
> just doesn't support the assertions that this is some kind of inherent
> design defect.
>
Again, I agree. Overall, the system would seem unlikely to reboot in the
way NW experienced.

Neil

[Robert M. Gary]

On Jan 29, 1:53 pm, Peter Clark
> wrote:
> On Mon, 29 Jan 2007 21:17:47 GMT, "Neil Gould"
>
> > wrote:
> >That is my guess as well, based on the information from the seminar. As I
> >understand it, the G1000 would disable (red "X") the readout of any
> >component with an unresolvable conflict. Since the aux tank was
> >"refilling" the main fuel tanks via the overflow return, it wouldn't be
> >long before the flight computer data would be in conflict with the fuel
> >level sensor and therefore generate an unresolvable error. It should be
> >expected that both displays would show the same error condition.
>
> I guess that would be based on the invalid presumption that the fuel
> computer, time to empty, fuel flow, etc have any interaction with the
> fuel level indicators. They don't. You tell the time-to-empty
> computer how much fuel is onboard and it deducts based on current fuel
> flow. If you don't refresh it's fuel on board at the beginning of a
> flight you can get 0:00 minutes to empty with hours worth of fuel left
> in the tanks.

>From the pilot's point of view that's true. However, a fault in the
GEA 71 system could cause the entire thing to get sick. Your argument
is a bit like saying Word could never hang because of a fault in IE.
Ideally, yea, practically, maybe not.

-Robert, CFII G1000 instructor

[Robert M. Gary]

On Jan 29, 11:05 am, Mxsmanic > wrote:
> Robert M. Gary writes:
> > Although many of the components of the G1000 have backups, many do
> > not. There are a lot of failures you can have that don't effect the
> > operation, but some do. Part of the transition training (especially
> > for IFR pilots) is to understand the failure mode of the different
> > components. Sadly, we're finding that we are only able to sign off
> > most of our instrument pilots for VFR in the G1000. The biggest
> > problem is getting behind the plane and not getting the approach set
> > up in the system soon enough. This is mostly the older guys though. I
> > dont' think anyone under 40 has had a problem.
>
> Why is it sad? You can still sign them off in an aircraft with more
> traditional gauges at a much lower cost, and without the risk of a
> software bug putting them in mortal danger.

I feel *WAY* safer in the G1000 system than the steam gauges. Look at
how often an attitude indicator goes out in the steam gauges. I for
one would not welcome having to shoot an actual ILS on the TC.
Everyone has heard the 1 or 2 stores of hard failures in the G1000 but
most of us have personally had hard failures of an attitude indicator,
a TC, an airspeed indicator, etc.
Besides, even if the entire G1000 system went TU, you are left with
you basic 3 steam gauges anyway, no worse than in an old plane.

> You can't really teach them the failure modes of the system
> completely, anyway, since even the manufacturer hasn't bothered to
> figure that out (which is one of the risks of these systems).

While I'm sure you can come up with some strange "this happened to my
brother-in-law" stories, Garmin clearly documents what each LRU is
responsible for and disabling any LRU gives a predictable set of
failures. I've had a few actual failures in the G1000, none were very
interesting, and none as bad as what I've had happen in steam gauges.

-Robert

[Mxsmanic]

Robert M. Gary writes:

> I feel *WAY* safer in the G1000 system than the steam gauges. Look at
> how often an attitude indicator goes out in the steam gauges. I for
> one would not welcome having to shoot an actual ILS on the TC.
> Everyone has heard the 1 or 2 stores of hard failures in the G1000 but
> most of us have personally had hard failures of an attitude indicator,
> a TC, an airspeed indicator, etc.

After decades of dealing with computers professionally, I get
extremely nervous thinking about any system that allows a computer to
deal with safety-of-life issues.

Properly programmed computers are safer than human beings in such
applications. The problem is that they are almost never properly
programmed. Many of the people developing such systems have
absolutely no clue of the important considerations that must be kept
in mind when designing them. To them, everything is just a Windows
PC.

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

[Robert M. Gary]

On Jan 30, 11:52 am, Mxsmanic > wrote:
> Robert M. Gary writes:
> > I feel *WAY* safer in the G1000 system than the steam gauges. Look at
> > how often an attitude indicator goes out in the steam gauges. I for
> > one would not welcome having to shoot an actual ILS on the TC.
> > Everyone has heard the 1 or 2 stores of hard failures in the G1000 but
> > most of us have personally had hard failures of an attitude indicator,
> > a TC, an airspeed indicator, etc.
>
> After decades of dealing with computers professionally, I get
> extremely nervous thinking about any system that allows a computer to
> deal with safety-of-life issues.
>
> Properly programmed computers are safer than human beings in such
> applications. The problem is that they are almost never properly
> programmed. Many of the people developing such systems have
> absolutely no clue of the important considerations that must be kept
> in mind when designing them. To them, everything is just a Windows
> PC.

Do you feel the same about traffic lights, commuter trains, and all
other things that rely of computers to keep us from dieing?

-robert

[John Theune]

Robert M. Gary wrote:
> On Jan 30, 11:52 am, Mxsmanic > wrote:
>> Robert M. Gary writes:
>>> I feel *WAY* safer in the G1000 system than the steam gauges. Look at
>>> how often an attitude indicator goes out in the steam gauges. I for
>>> one would not welcome having to shoot an actual ILS on the TC.
>>> Everyone has heard the 1 or 2 stores of hard failures in the G1000 but
>>> most of us have personally had hard failures of an attitude indicator,
>>> a TC, an airspeed indicator, etc.
>> After decades of dealing with computers professionally, I get
>> extremely nervous thinking about any system that allows a computer to
>> deal with safety-of-life issues.
>>
>> Properly programmed computers are safer than human beings in such
>> applications. The problem is that they are almost never properly
>> programmed. Many of the people developing such systems have
>> absolutely no clue of the important considerations that must be kept
>> in mind when designing them. To them, everything is just a Windows
>> PC.
>
> Do you feel the same about traffic lights, commuter trains, and all
> other things that rely of computers to keep us from dieing?
>
> -robert
>
Perhaps if your 'decades of experience with computers' was with real
mission critical systems instead of MSFS then you would understand that
computers have been running most of the controlled devices around you
for the last 30 years or so and have worked very well. Yes there have
been problems, but not to the level which you so foolishly assign them.
Having worked with mission critical systems for the last 25 years
I can tell you that the developers have much more of a idea of what's
important then you seem to have.

[Mxsmanic]

Robert M. Gary writes:

> Do you feel the same about traffic lights, commuter trains, and all
> other things that rely of computers to keep us from dieing?

To a varying extent, yes. It depends on a number of factors.

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

[Mxsmanic]

John Theune writes:

> Perhaps if your 'decades of experience with computers' was with real
> mission critical systems instead of MSFS then you would understand that
> computers have been running most of the controlled devices around you
> for the last 30 years or so and have worked very well.

Some systems are a lot simpler than others.

> Yes there have been problems, but not to the level which you so
> foolishly assign them.

The number of problems is vast, but not widely publicized.

> Having worked with mission critical systems for the last 25 years
> I can tell you that the developers have much more of a idea of what's
> important then you seem to have.

Not if their systems reboot.

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