If I have two AHRS can I get rid of my vacuum system?

[Ragsf15e]

1 hour ago, PT20J said:

There are some interesting differences in the AFMS Limitations sections between the G3X and the GI 275. Note that the GI 275 requires GPS and pitot inputs whereas the G3X requires GPS or pitot. I have no idea why.

GI 275

 

G3X

Also, the fact that the GI 275 apparently powers the GMU 11 magnetometer probably accounts for the reduced battery operating time compared to the G5. 

And here’s one from that diagram… the gmu isn’t required unless you are using it for hsi compensated heading??  So if I just have an GI275 adi with no gmu, and lose gps, I lose attitude?  Doesn’t make sense.

Yet pitot static is required for ahrs aiding (in the notes).  It makes me think that g3x failure tree isn’t the same for the -275.

[RobertGary1]

7 hours ago, 201Mooniac said:

While I'm hopeful that Garmin thought this out well and designed the system to handle all the faults they identified, the concern for me is that by not documenting their fault analysis and remediation, there is no way to know how best to respond to an issue.  I would hope Garmin would publish this data so users will know what to expect and how to respond.

As well as I'm sure they thought it out, my experience in the first post demonstrates that sometimes things happen. I would not want to go into the clouds if I only had my two GI-275's and I intend to retain my inexpensive vacuum attitude indicator. If I was just a VFR guy I'd ditch the vacuum. 

[201Mooniac]

That is why I think it is important for them to tell us their fault analysis so we can make informed decisions about how to use the equipment.  It is important to understand each different system since they aren't all the same.  I have a TXi and a G5, it isn't clear how that compares to the G3x or the GI-275.  The lack of information is what keeps us from making an informed decision as to whether I am comfortable with the risk or not.

[RobertGary1]

In addition to no voltage you have to wonder about low voltage. One of the G1000 planes I fly was throwing red X's on random parts of the panel at random times. The diagnosis was a bad alternator. Although it wasn't bad enough to throw a fault itself. 

[EricJ]

I wouldn't assume that there has been a strong system design overview that took into account how the G5, GI-275, G3X, GTN, GFC, etc., etc., devices would all work together and made all of their requirements and failure modes nicely compatible with robust alerting and reporting.   Given the timeframes when each were developed and the differences in the products, markets, etc., it's possible that there may not have been nearly as much of that as one might think.   Whichever got developed first could not have been fully informed by the requirements, features and functions of later devices, and whichever got developed later may have wanted to depart from "legacy" architecture behavior in favor of some newer, improved strategy.

Or not, who knows.   They're not saying, and that may be because there isn't much useful to say.

 

[PT20J]

20 minutes ago, EricJ said:

I wouldn't assume that there has been a strong system design overview that took into account how the G5, GI-275, G3X, GTN, GFC, etc., etc., devices would all work together and made all of their requirements and failure modes nicely compatible with robust alerting and reporting.   Given the timeframes when each were developed and the differences in the products, markets, etc., it's possible that there may not have been nearly as much of that as one might think.   Whichever got developed first could not have been fully informed by the requirements, features and functions of later devices, and whichever got developed later may have wanted to depart from "legacy" architecture behavior in favor of some newer, improved strategy.

Or not, who knows.   They're not saying, and that may be because there isn't much useful to say.

 

I believe you hit the nail on the head. When I set out to put together a suite of Garmin avionics I assumed it was all designed to work together and be consistent in operation and nomenclature. After diving fairly deeply into this (I am still far from getting to the bottom) I can say that it is not that way at all.  It's a collection of individual products designed at different times by different groups for different markets that sort of work together. I haven't looked into the TXi stuff, but from looking at the G3X and the GI 275, it appears that the GI 275 is pretty well designed for multiple 275 units to work together and the G5 has been optimized to work well with the G3X. But there are still a lot of unknowns about failure modes. 

Some design choices seem questionable for a certificated aircraft. For instance, the GFC 500 uses the same servo for all four applications (pitch, roll, yaw and trim). According to the documentation, the servo contains all the software for all applications and it gets it's "personality" by setting hardware straps during installation. It's been 20 years, and things may have changed, but the one time I looked into designing something to meet RTCA DO-178 which is the standard for certifying software for airborne systems, it was required to show that a device with an embedded processor contained no unexecuted code. That would preclude this sort of strapping option. The reason for the requirement is the assumption that a fault can misdirect the processor's program counter into the unintended code. In other words, some glitch might cause a roll servo to suddenly start behaving as a pitch servo. But coming out of the Experimental world, it was likely never a requirement to comply with DO-178 and so it probably doesn't.

Skip

[RobertGary1]

15 minutes ago, PT20J said:

I believe you hit the nail on the head. When I set out to put together a suite of Garmin avionics I assumed it was all designed to work together and be consistent in operation and nomenclature. After diving fairly deeply into this (I am still far from getting to the bottom) I can say that it is not that way at all.  It's a collection of individual products designed at different times by different groups for different markets that sort of work together. I haven't looked into the TXi stuff, but from looking at the G3X and the GI 275, it appears that the GI 275 is pretty well designed for multiple 275 units to work together and the G5 has been optimized to work well with the G3X. But there are still a lot of unknowns about failure modes. 

Some design choices seem questionable for a certificated aircraft. For instance, the GFC 500 uses the same servo for all four applications (pitch, roll, yaw and trim). According to the documentation, the servo contains all the software for all applications and it gets it's "personality" by setting hardware straps during installation. It's been 20 years, and things may have changed, but the one time I looked into designing something to meet RTCA DO-178 which is the standard for certifying software for airborne systems, it was required to show that a device with an embedded processor contained no unexecuted code. That would preclude this sort of strapping option. The reason for the requirement is the assumption that a fault can misdirect the processor's program counter into the unintended code. In other words, some glitch might cause a roll servo to suddenly start behaving as a pitch servo. But coming out of the Experimental world, it was likely never a requirement to comply with DO-178 and so it probably doesn't.

Skip

Personally I think that is one of the best things about the 500 servos. Hopefully it helps keep costs down. The 500 isn’t cheap but it’s a leap ahead in the functionality/ price ratio for the market 

[Tom 4536]

8 hours ago, PT20J said:

I believe you hit the nail on the head. When I set out to put together a suite of Garmin avionics I assumed it was all designed to work together and be consistent in operation and nomenclature. After diving fairly deeply into this (I am still far from getting to the bottom) I can say that it is not that way at all.  It's a collection of individual products designed at different times by different groups for different markets that sort of work together. I haven't looked into the TXi stuff, but from looking at the G3X and the GI 275, it appears that the GI 275 is pretty well designed for multiple 275 units to work together and the G5 has been optimized to work well with the G3X. But there are still a lot of unknowns about failure modes. 

Some design choices seem questionable for a certificated aircraft. For instance, the GFC 500 uses the same servo for all four applications (pitch, roll, yaw and trim). According to the documentation, the servo contains all the software for all applications and it gets it's "personality" by setting hardware straps during installation. It's been 20 years, and things may have changed, but the one time I looked into designing something to meet RTCA DO-178 which is the standard for certifying software for airborne systems, it was required to show that a device with an embedded processor contained no unexecuted code. That would preclude this sort of strapping option. The reason for the requirement is the assumption that a fault can misdirect the processor's program counter into the unintended code. In other words, some glitch might cause a roll servo to suddenly start behaving as a pitch servo. But coming out of the Experimental world, it was likely never a requirement to comply with DO-178 and so it probably doesn't.

Skip

Last week my avionics installer said that although each servo is identical mechanically, each needs to be programed for it's function..pitch, roll, trim.

[PT20J]

1 hour ago, Tom 4536 said:

Last week my avionics installer said that although each servo is identical mechanically, each needs to be programed for it's function..pitch, roll, trim.

Yes, but the servos contain all the software and they are programmed by strapping at installation which tells the servo which part of its code to run. The software is not at all trivial as the GFC 500 is a distributed system and much of the logic is in the servos.

[Tom 4536]

26 minutes ago, PT20J said:

Yes, but the servos contain all the software and they are programmed by strapping at installation which tells the servo which part of its code to run. The software is not at all trivial as the GFC 500 is a distributed system and much of the logic is in the servos.

First, I always trust and appreciate you advise. Thank you very much for your input.

My (apparently incorrect) interpretation of what my avionics guy said was that he would install the software appropriate to the function of the servo. This came up because he is trying a new servo to see if the servo is causing my CFC500 disconnect problem and doing so he has to put the appropriate software/programing in the new servo.

[PT20J]

13 minutes ago, Tom 4536 said:

First, I always trust and appreciate you advise. Thank you very much for your input.

My (apparently incorrect) interpretation of what my avionics guy said was that he would install the software appropriate to the function of the servo. This came up because he is trying a new servo to see if the servo is causing my CFC500 disconnect problem and doing so he has to put the appropriate software/programing in the new servo.

This stuff is really complicated and I don’t think anyone except some engineers at Garmin fully understand it. I’ve held various engineering positions during my eclectic career and I’ve written manuals and also managed a technical publications group so I know a little something about what constitutes good documentation. I find Garmin’s documentation miserable. For example: Incomplete entries in the Pilot’s Guides often refer to the Installation Manual for more information. But those manuals are often unavailable except to Garmin dealers. Why would the author refer the reader to an unobtainable document? That’s only one example of problems with the documentation that make it difficult to understand.

So, I don’t believe the installers could possibly understand everything, and I know that Garmin first level tech support doesn’t because some of their answers have been incorrect or don’t make sense. One example: I asked if the AHRS in a GTX 345 would work if the GPS input were lost. The tech didn’t know and said he would ask engineering. He called back and said it “should” work. I tried it and the AHRS goes nuts in short order with the GNS 430W it’s connected to turned off.

To be fair, the various pieces of equipment can be assembled in a bewildering number of combinations, so it is difficult to describe every possible combination. But because of this, its really important to explain better how these products actually work and especially what the various options are.

But, personal computers are pretty complicated and no one understands them either. 

Skip

[Ragsf15e]

1 hour ago, PT20J said:

This stuff is really complicated and I don’t think anyone except some engineers at Garmin fully understand it. I’ve held various engineering positions during my eclectic career and I’ve written manuals and also managed a technical publications group so I know a little something about what constitutes good documentation. I find Garmin’s documentation miserable. For example: Incomplete entries in the Pilot’s Guides often refer to the Installation Manual for more information. But those manuals are often unavailable except to Garmin dealers. Why would the author refer the reader to an unobtainable document? That’s only one example of problems with the documentation that make it difficult to understand.

So, I don’t believe the installers could possibly understand everything, and I know that Garmin first level tech support doesn’t because some of their answers have been incorrect or don’t make sense. One example: I asked if the AHRS in a GTX 345 would work if the GPS input were lost. The tech didn’t know and said he would ask engineering. He called back and said it “should” work. I tried it and the AHRS goes nuts in short order with the GNS 430W it’s connected to turned off.

To be fair, the various pieces of equipment can be assembled in a bewildering number of combinations, so it is difficult to describe every possible combination. But because of this, its really important to explain better how these products actually work and especially what the various options are.

But, personal computers are pretty complicated and no one understands them either. 

Skip

Now combine some Garmin products with Aspen and STEC of varying vintage!  Sometimes I’m surprised any of this works!

[PT20J]

12 minutes ago, Ragsf15e said:

Now combine some Garmin products with Aspen and STEC of varying vintage!  Sometimes I’m surprised any of this works!

What we really need, and would have if there were any real competition, is open standards-based systems. It might slow innovation, but the end result is more robust and gives the user options. Something to think about on a dark and stormy night, all alone in a little airplane, bouncing around in the clouds.

Skip

[RobertGary1]

3 hours ago, Tom 4536 said:

First, I always trust and appreciate you advise. Thank you very much for your input.

My (apparently incorrect) interpretation of what my avionics guy said was that he would install the software appropriate to the function of the servo. This came up because he is trying a new servo to see if the servo is causing my CFC500 disconnect problem and doing so he has to put the appropriate software/programing in the new servo.

I doubt an avionics installer would know the difference. They just know they plug it in and do some stuff. Whether they are enabling code on the device or installing code isn’t going to be visible to them 

[PT20J]

I got some more information from Garmin support and also by reading the G3X Experimental Pilot's Guide as well as the STC version.

In a  G3X Touch with G5 Standby installation, the PFD menu has an option to select the AHRS. This is described in the Experimental Pilot's Guide in Section 1.5 because the Experimental version allows the installation of up to three AHRS. However the STC version only allows one GSU 25D AHRS to be installed. It appears that the STC Pilot's Guide was edited from the Experimental Guide and the paragraph describing multiple AHRS was deleted which also deleted the description of how to switch AHRS. But according to Garmin (I haven't verified this -- someone with a G3X might want to check it), the selection is on the PFD menu and allows selection of AUTO, or the GSU 25D, or the G5 as the AHRS source for the G3X

The normal selection is AUTO in which case the G3X will use the GSU 25 unless that fails in which case it will revert to the G5. The G3X software continuously compares the two AHRS. If there is a MISCOMPARE (as opposed to a failure) it will annunciate and the flight director/autopilot cannot be engaged. The documentation doesn't say, but presumably this would cause an autopilot disconnect if the autopilot were engaged. In this case, you are left to determine whether the GSU 25D or the G5 is displaying the correct attitude. If the GSU 25D is bad, you can pull the ADAHRS circuit breaker to force reversion to the G5 ADAHRS. Or, you can go to the PFD menu and manually change the AHRS source to the G5.

At least that's how I think  it works. Someone should try this and let us know.

Also, it would be interesting to know how a similar condition in a dual GI 275 installation is handled: That is, what happens when the two don't agree, but neither AHRS has "failed"?

Skip

[PT20J]

Something to consider with GI 275 installations...

Early on apparently, the experimental guys were having a lot of problems with the G3X ADAHRS. This turned out to be due to vibration. When the  GSU 25D is mounted to the back of the GDU, and the GDU is installed in a shock-mounted panel, the vibration can cause the ADAHRS to act up. Shock mounted panels are standard of course when mechanical gyros are installed. If the GI 275 has an internal ADAHRS, it probably shouldn't be installed in a shock-mounted panel. I don't have the installation manual, but it would be something to check.

Skip

[EricJ]

50 minutes ago, PT20J said:

Also, it would be interesting to know how a similar condition in a dual GI 275 installation is handled: That is, what happens when the two don't agree, but neither AHRS has "failed"?

Skip

Managing failure detection outside of or even in the context of redundant compared AHRS outputs must be a trip.   I'd suspect there would be some landmines in there.

 

 

[PT20J]

6 minutes ago, EricJ said:

Managing failure detection outside of or even in the context of redundant compared AHRS outputs must be a trip.   I'd suspect there would be some landmines in there.

 

 

Here's what I suspect is happening: The ADAHRS contains software to detect gross failures like a pressure transducer with no output or a missing signal from one of the accelerometers or a really out of bounds output -- things like that. The reason for the comparison logic and the MISCOMPARE annunciation is to alert you to more subtle failures and drop the problem in your lap. It's a little problematic with only two sensors since you can't do a majority vote.

Skip

[takair]

Found this link On Beechtalk….lots of new discussion there  on another event:  

https://www.tsb.gc.ca/eng/rapports-reports/aviation/2021/A21P0001/A21P0001.html

 

[PT20J]

1 hour ago, takair said:

Found this link On Beechtalk….lots of new discussion there  on another event:  

https://www.tsb.gc.ca/eng/rapports-reports/aviation/2021/A21P0001/A21P0001.html

 

Wow. Here's my favorite quote: "Although the pilot did have access to these documents during the occurrence flight, he did not refer to them as he was focussed on controlling the aircraft."  Seems a pretty lame pilot that cannot thumb through the  AFMS when single pilot IMC with a total and unexpected instrument failure while in a graveyard spiral. 

Seems to be something going on with the 275s.

Skip

[takair]

14 minutes ago, PT20J said:

Wow. Here's my favorite quote: "Although the pilot did have access to these documents during the occurrence flight, he did not refer to them as he was focussed on controlling the aircraft."  Seems a pretty lame pilot that cannot thumb through the  AFMS when single pilot IMC with a total and unexpected instrument failure while in a graveyard spiral. 

Seems to be something going on with the 275s.

Skip

They discuss lack of proficiency with partial panel, but they don’t mention what may have been left functioning in his panel…

[RobertGary1]

30 minutes ago, takair said:

They discuss lack of proficiency with partial panel, but they don’t mention what may have been left functioning in his panel…

And the entire point advertised so heavily by Garmin is partial panel is gone. Two gi-275’s is legal to replace every primary instrument in front of the pilot. Partial panel is stop looking at gi-275#1 and start looking at gi-275#2. In fact most people installing these are ditching their vacuum attitude and if the autopilot allows ditching their turn coordinator (the gi-275 has a built in turn coordinator at the top)

[carusoam]

Yikes!

Ascent and descent rates went way off-scale… a pair of stalls…

Does the GI275 record G-force measurements?

Amazing the pilot and the plane continued to fly together as one… 

Go Mooney!

Best regards,

-a-

[PT20J]

Interesting that apparently that even Transport Canada can’t get Garmin to tell them how this stuff works.

I don’t know much about the GI 275. From the details given in the report, it sounds like maybe they weren’t configured properly. I thought the HSI was supposed to revert to a ADI (as apparently the pilot also believed).

Skip

[RobertGary1]

38 minutes ago, PT20J said:

Interesting that apparently that even Transport Canada can’t get Garmin to tell them how this stuff works.

I don’t know much about the GI 275. From the details given in the report, it sounds like maybe they weren’t configured properly. I thought the HSI was supposed to revert to a ADI (as apparently the pilot also believed).

Skip

In the normal failure mode they do but I think there are failure modes they didn’t consider as my dual AHRS failure also shows