Some insights into the G1000

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.

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.

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

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.

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.

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

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.

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

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

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