Menu Sign In Contact FAQ
Banner
Welcome to our forums

Garmin G5 (merged thread)

Peter wrote:

do the latter which is why a bunged-up pitot on an EFD1000 equipped aircraft wipes out the box pretty well, AF447-style. Actually more than AF447 because they still had INS-derived attitude on the PFD (but didn’t know how their plane worked)

This is simply not correct. When the pitot gets blocked it will show “Check pitot heat” AHRS will still be functional. If you continue to fly with blocked pitot it will loose AHRS after a while.

Both Garmin and Aspen systems will degrade from incorrect speed information.

In the past Aspen did had an issue with the pitot heat monitor being over sensitive, and showing this message to early, which, when it was ignored let to the red crosses. This is solved now.

JP-Avionics
EHMZ

This is simply not correct

Except you then go on to paraphrase more or less what I said, Jesse

I have a few of these photos from one owner

Administrator
Shoreham EGKA, United Kingdom

This image is not representative for the issue discussed, so it is not fair to use this photo in this context. In this photo clearly more / other issues are vissible which do not related to a frozen pitot tube. Such as the GPS bearing indicator is invisible, even though valid and selected, and the OAT is dashed out. So there are three different issues visible.

Possibly the unit has just been restarted before taking the picture.

JP-Avionics
EHMZ

A couple of points:

1) The Garmin G5 has no commonality with other Garmin EFIS products in terms of code base or sensor hardware. This was an explicit design decision by Garmin, to reduce common failure modes with their other products, since the G5 is designed as a backup instrument. This approach has clear benefits but does leave the possibility of flaws which were ironed out a long time ago in the G3X, G1000, etc.

2) I haven’t seen any evidence yet on this thread that the G5 has a software fault. It could be an installation issue, or faulty hardware, so let’s not jump to conclusions.

Lucius wrote:

I am trying to figure out why the G5 is unable to detect a flight attitude that is physically impossible, despite having GPS and pitot static data available

I just looked at the photo again. It appears as a coordinated right turn so I can’t see why you think it is an impossible attitude that the software should be able to detect?

Also, the G5 shows TRK not heading, is it not set up with magnetic heading input?

Peter wrote:

a bunged-up pitot on an EFD1000 equipped aircraft wipes out the box pretty well, AF447-style.

What do you mean by “AF447-style”? The airspeed indication on AF447 was temporarily lost which of course also affected the TAS, Mach number and SAT indications since they depend directly on the dynamic pressure. On the particular aircraft model it also meant that a speed-dependent correction of static pressure position error was affected which caused the altitude indication to be a few hundred feet low. Apart from that the instruments on AF447 were indicating correctly during the whole event. After the pitot cleared, of course, every indication was correct.

ESKC (Uppsala/Sundbro), Sweden

“Wipes out the box” sounds more dramatic and casts doubt over the manufacturer’s intellectual stamina.

ortac wrote:

I haven’t seen any evidence yet on this thread that the G5 has a software fault. It could be an installation issue, or faulty hardware, so let’s not jump to conclusions.

There must have been something “odd” in the software:

The fixes from 2.20 to 2.40 include Improved attitude sensor processing
The fixes from 2.40 to 2.50 include Improved attitude data calculation

We don’t know exactly what this improvements are, but both the sensor processing has been improved as well as the calculation. Improved sensor processing must have something to do with filter settings, while data calculation could be anything. These improvements could also be exclusively connected to installation and calibration of the unit.

The elephant is the circulation
ENVA ENOP ENMO, Norway

Airborne_Again wrote:

It is an accepted fact in Software Engineering that you can not achieve high reliability of complex software by testing alone. You must have a software development process which addresses this from the very beginning.

I think there is another aspect of this. That is detailed and deep knowledge and understanding about the process, or nature of the problem you want to solve. I am no software engineer, yet, two years ago I made a predictive control system for a 960 MW power pant. We were two people working on this for 4 years, a bit on and off. The other person made a monitoring system, to monitor the plant and the predictive controller. It was a first of it’s kind anywhere, a prototype in the correct sense of the word. It has been running for two years now without a single incident of any kind. And it has been running continuously, 24/7. It is actually what enables Denmark (and Germany) to run an additional couple of GWs of wind turbine power. The controller was a prerequisite for a 700 MW DC cable from Norway to Denmark that was commissioned at the same time, to be able to do rapid changes of power, and do it securely and safely without human intervention.

As to these EFIS’es and attitude indicators and similar, they should IMO be perfect as one man projects. I cannot understand what improvements would be achieved by making these into large multiprogrammer projects. 1 or 2 persons with the right background and experience would handle this just fine, and there is no need for them to be software engineers. 99% of the difficult stuff is electronics and control systems theory, as well as knowledge of aviation. Making operating systems and large software packages like MS Office, web browsers and so on would of course require software engineers, and lots of them, because the nature of the “problem” is software.

The elephant is the circulation
ENVA ENOP ENMO, Norway

LeSving wrote:

I cannot understand what improvements would be achieved by making these into large multiprogrammer projects

There’s quite a lot to do even on a G5. I don’t believe the G5 has a COTS (crap off the shelf) general purpose operating system running on its SOC, it boots far too quickly for that. So someone at Garmin has probably written a low level OS for their small devices. That person probably has a different skill set to the people who do the higher level stuff on the device. Even a minimal tiny OS for a SOC can be quite a bit of work, about 18 months ago I did a big portion of one for a small ARM SOC on a contract because the guy who was making the system simply didn’t have enough time to do both parts of the system he was building. We didn’t even have a way of displaying on the screen at the time, I had to write all of the stuff to just make characters appear on the screen (while it’s not rocket science, it takes time to do properly, and we were pretty constrained on CPU cycles). The “datasheet” for the SoC was over 1600 pages long, and it was only a small device!

Last Edited by alioth at 30 Dec 15:49
Andreas IOM
Sign in to add your message

Back to Top