Anyone recommend a good tutorial for modern GA avionics interfaces?

Martin Horton

Filing Flight Plan
Joined
Aug 16, 2018
Messages
6
Display Name

Display name:
martinhorton
I've spent a lifetime in software development so I'm very familiar with programming, etc. And in the "old days" when it was just VORs and ILS it didn't really matter how all the parts fitted together because all the representations were standard. So a NARCO VOR indicator looked the same as a King and either would drive an autopilot.

But today it's not obvious to me what components are responsible for what functions and how they communicate with each other.

The fact that Garmin G3X Touch will only interface with Garmin navigators (according to Garmin) indicates that these interfaces are not standard. I watch a lot of YouTube videos and one of my favorites is Kevin (N771BC) as 310 Pilot. His airplane is equipped with Avidynes interfacing to an STEC 3100 autopilot which relies on 2 G5s. But the 3100 cannot drive the FD bars on the G5 but the GFC500 of GFC600 AP can. Again, this indicates that interfaces are not standard.

What I am looking for is a good book, or PDF or article that explains how all these modern avionics work together, or more precisely, why they don't work together. If anyone can point me in that direction, I'd be very grateful.
 
Would be great to get a hold of a book like that.

It is definitely a world of confusion. It took me a while to understand “Garmin” boxes when I took on the challenge of installing a full Garmin suite in my experimental. What may be useful is to look over the CANBUS layout in the G3x Touch installation manual. And also it’s corresponding RS-232 serial interfaces and how they map between various boxes. I do believe the G3x systems will talk to the Avidyne navigators over RS-232.

As for the FD bars, the intelligence comes from the Garmin servos (GSA28) themselves. So when you are using an STEC head, it is talking to the STEC servos which don’t support a FD command.

I've spent a lifetime in software development so I'm very familiar with programming, etc. And in the "old days" when it was just VORs and ILS it didn't really matter how all the parts fitted together because all the representations were standard. So a NARCO VOR indicator looked the same as a King and either would drive an autopilot.

But today it's not obvious to me what components are responsible for what functions and how they communicate with each other.

The fact that Garmin G3X Touch will only interface with Garmin navigators (according to Garmin) indicates that these interfaces are not standard. I watch a lot of YouTube videos and one of my favorites is Kevin (N771BC) as 310 Pilot. His airplane is equipped with Avidynes interfacing to an STEC 3100 autopilot which relies on 2 G5s. But the 3100 cannot drive the FD bars on the G5 but the GFC500 of GFC600 AP can. Again, this indicates that interfaces are not standard.

What I am looking for is a good book, or PDF or article that explains how all these modern avionics work together, or more precisely, why they don't work together. If anyone can point me in that direction, I'd be very grateful.
 
I've spent a lifetime in software development so I'm very familiar with programming, etc. And in the "old days" when it was just VORs and ILS it didn't really matter how all the parts fitted together because all the representations were standard. So a NARCO VOR indicator looked the same as a King and either would drive an autopilot.

But today it's not obvious to me what components are responsible for what functions and how they communicate with each other.

The fact that Garmin G3X Touch will only interface with Garmin navigators (according to Garmin) indicates that these interfaces are not standard. I watch a lot of YouTube videos and one of my favorites is Kevin (N771BC) as 310 Pilot. His airplane is equipped with Avidynes interfacing to an STEC 3100 autopilot which relies on 2 G5s. But the 3100 cannot drive the FD bars on the G5 but the GFC500 of GFC600 AP can. Again, this indicates that interfaces are not standard.

What I am looking for is a good book, or PDF or article that explains how all these modern avionics work together, or more precisely, why they don't work together. If anyone can point me in that direction, I'd be very grateful.
Most of the old interfaces are still there, and semi-standardised, but there are new interfaces on top of them, and emulators on top of others, and some of those are proprietary.

In my simple Warrior II, my single-axis STEC-20 autopilot takes a heading-deviation signal from my mechanical DG (with heading bug) for when it's operating in HDG mode, and a course-deviation signal from one of two mechanical CDIs for when it's operating in HI or LO nav mode. So far, these are all 1970s-era interfaces.

There are catches, however. I have a switch between two mechanical CDIs for the autopilot, and one of them is driven by my GTN 650, which sends digital (rather than analogue) course-deviation signals to the CDI, but also a mode indication signal (RNAV vs VLOC). This is still pretty standardised, but it's newer (GNC 430-era stuff, about 20 years old). The GTN 650 also sends GPS steering commands (standardised over a digital RS 232 interface) to an STEC GPSS unit that sits between my DG and autopilot. When I switch it from Heading to GPSS mode, it replaces the heading-deviation signal from my DG with a simulated heading-deviation signal based on the roll-steering commands from the GPS.

So, even in my simple plane with rather basic avionics, I have a lot of input paths leading to my bare-bones single-axis autopilot.

1. Roll knob -> A/P (roll mode): hold the bank angle set by the knob

2. DG (heading bug) -> GPSS (heading mode) -> A/P (HDG mode): steer to the heading bug on the DG.

3. GTN 650 (RNAV mode) -> GPSS (GPSS mode) -> A/P (HDG mode): take steering commands from the GPS (can even fly me around a hold, which is sweet)

4. GTN 650 (RNAV mode)->CDI1->A/P source switch (NAV1)->A/P (HI nav mode): track an RNAV course with high sensitivity

5. GTN 650 (VLOC mode)->CDI1->A/P source switch (NAV1)->A/P (HI nav mode): track a VOR or LOC course with high sensitivity

6. KX-155->CDI2->A/P source switch (NAV2)->A/P (HI nav mode): track a VOR or LOC course from my nav2 radio with high sensitivity

7. GTN 650 (RNAV mode)->CDI1->A/P source switch (NAV1)->A/P (LO nav mode): track an RNAV course with low sensitivity

8. GTN 650 (VLOC mode)->CDI1->A/P source switch (NAV1)->A/P (LO nav mode): track a VOR or LOC course with low sensitivity

9. KX-155->CDI2->A/P source switch (NAV2 position)->A/P (LO nav mode): track a VOR or LOC course from my nav2 with low sensitivity

There are lots of switches/indicators to check to make sure my A/P is really taking input from where I want it to. Every plane will be set up a little differently, so there's a learning curve. If I had fancier stuff, like a G5, that's when the proprietary interfaces would kick in (though it still uses a lot of de-facto standard interfaces).

This publication is a bit out of date -- it's from 10+ years ago, and a lot has changed in that time -- but I still wish I'd known about it when I was first trying to learn about all this stuff, when I installed my GTN 650 back in 2017:

https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/advanced_avionics_handbook/
 
Would be great to get a hold of a book like that.

As for the FD bars, the intelligence comes from the Garmin servos (GSA28) themselves. So when you are using an STEC head, it is talking to the STEC servos which don’t support a FD command.

Wow, I just assumed the autopilot drove the FD command bars. The way I assumed it worked was that the autopilot worked out the pitch and roll desired and relayed that to the FD and then monitored the attitude to ensure it was correct, sending messages to the servos to pitch up or down and roll left or right to achieve the desired attitude.

Obviously the people who design and program autopilots have a lot more experience than I do so there must be good reasons for doing it that way but, to my mind at least, that is counter intuitive. But it does explain why the 3100 can't drive the G5 command bars.
 
I have a question: what is it you're hoping to do? Are you trying to design your own interface adapter? Or just learn about the digital protocols for manufacturers' proprietary data busses?

I know Garmin uses a proprietary bi-directional CANBUS, and Dynon uses a "multi-drop, serial network" similar to Ethernet. Both provide interface with RS232 and ARINC 429. There are tutorials for both those standards. But, that stuff is way over my head. I'm pretty much a plug-n-play kinda homebuilder.
 
As others have said, it really depends on what you're trying to learn. There's any variety of ways for interfaces to be "non-standard".

In the past I've worked with hardware that was ARINC 429 "compliant" but did not comply to the actual electrical standard fully - This poses a problem in some cases. Then you have the actual bit/label definitions of what's on the data bus, the definition of what is "standard" breaks down even further at this level. Now multiple that across the 10-20 common interfaces used and you can see why things become complicated in a hurry.
 
I have a question: what is it you're hoping to do? Are you trying to design your own interface adapter? Or just learn about the digital protocols for manufacturers' proprietary data busses?

I'm not really trying to do anything. I'm just trying to understand stuff so that I don't end up buying equipment that would ultimately be incompatible. For example, my airplane has the GPS in it that was designed by Noah for navigation during the flood (a Garmin 155XL) and I'm inclined to replace that with an Avidyne IFD540. But longer term, I would like to put in a G3X Touch and I don't want to find that I have a nice G3X Touch but it won't work with Avidyne. I understand, from a post I read somewhere else, that An Avidyne has been linked to a G3X Touch in an experimental aircraft and that Avidyne have given big hints that the next iteration of their software will make it fully compatible with a G3X. But most of all, I just like knowing how stuff works. If you know HOW something works, when a failure occurs it helps you to diagnose what the likely problem area is.

But the software engineer in me wonders why an Avidyne, that was designed to be plug replaceable for the GNS series, would fail to work with the G3X which supports the GNS series.

I understand that a lot of stuff is old, but I woul dhave thought the simplest solution was for all equipment to have capability to communicate via something like the CANBUS. For backwards compatibility it might be desirable to also support legacy interfaces. In all office buildings all equipment is connected by Ethernet running TCP/IP or UDP. so it would make sense to me if avionics followed a similar path. And so I was hoping that somewhere there was a book describing modern avionics architecture.

I searched on Amazon for such books and came with with gems from the 1980s purporting to describe the latest in avionics technology :)
 
Wow, I just assumed the autopilot drove the FD command bars. The way I assumed it worked was that the autopilot worked out the pitch and roll desired and relayed that to the FD and then monitored the attitude to ensure it was correct, sending messages to the servos to pitch up or down and roll left or right to achieve the desired attitude.

Obviously the people who design and program autopilots have a lot more experience than I do so there must be good reasons for doing it that way but, to my mind at least, that is counter intuitive. But it does explain why the 3100 can't drive the G5 command bars.
My GTN 650 GPS does produce FD-style roll-steering commands in the lateral axis, at least. My simple S-TEC 20 A/P can't use those directly (it just chases the CDI in its nav modes), but I have an S-TEC GPSS unit that converts those commands to pseudo-heading instructions, as if I were manually rotating the heading bug back and forth to chase the steering commands.

I think the G5 has a GPSS converter built in, so I wouldn't need the separate unit if I installed one.
 
But the software engineer in me wonders why an Avidyne, that was designed to be plug replaceable for the GNS series, would fail to work with the G3X which supports the GNS series.

That's a whole different question now. More than just interfaces, now you're talking about certification/paperwork.
 
That's a whole different question now. More than just interfaces, now you're talking about certification/paperwork.

I agree, but it's actually more complicated that that for reasons I don't understand.

For example, the G3X Manual lists precisely all the equipment that it works with. But the LOGICAL statement would be to say, for example, "Any navigator that complies with FAA reg xxx.yyy.zzz will work with the G3X". But it doesn't which leads me to believe that there is no FAA reg xxx.yyy.zzz. That means that Company X is forced to demonstrate to the FAA that their navigator works flawlessly with, in this case the G3X. But also with every other EFIS system out there. If company X only had to demonstrate that their navigator conformed strictly the FAA reg xxx.yyy.zzz massive amounts of time, money and paperwork would be saved. It seems to me that one of the major reasons why an iPad with a fully functioning touch screen, bluetooth and Wifi is about $500 But a GTN 750 navigator, which is essentially a slightly more robust but much smaller iPad costs $17,000. I can't help but think that if there were well defined interfaces to follow and to design to, the cost of avionics and lead design time would both shrink drastically.
 
I agree, but it's actually more complicated that that for reasons I don't understand......

I think that pretty much sums it up. If the Avidyne is a "Slide-in" replacement for the GNS, then it would seem to me to work the same on the G3X as the GNS does. I highly suspect in the certified world, this may boil down to paperwork.

Has anyone in the HBA world said they tried it and it didn't work? As far as S-Tec and G5 not being 100% compatible, that doesn't surprise me one bit.
 
Just looked at the IFD540 install manual. It has the following caveat
The IFD5XX can interface with a host of other avionics equipment. The following list represents the proven interfaces. There may be other devices that can be configured the same as one on the below list but has not been tested by Avidyne and cannot make any compatibility claims.

Yet, if you look at the wiring, its says it has full ARINC429 and RS232 interfaces. I don't think that means the IFD won't be compatible. I haven't looked at Garmin's claims for compatibility. But, I'd suspect if they said the G3X system works with the GNS line, then the IFD oughta work, right?
 
I had an STec ST-901 for GPSS for my STec 20/30/60 before I added the G5 AI and HSI. Yes, the G5 does have GPSS incorporated so my ST-901 went away.
 
Here's an interesting thread on Avidyne's forum: http://forums.avidyne.com/garmin-g3x-and-ifd440-540-compatibility_topic1713.html

Here's the media kit for the press release mentioned in the above thread: https://hf-files-oregon.s3.amazonaw...8bc16ecdf82c/IFD_R10.2.3.1_Overview_REV03.pdf

Here's Garmin's FB response to someone back in May: https://www.facebook.com/garminavia...b-in-system-that-uses-the-g/2290070324407127/
Interesting response from Garmin. They don't seem to be trying to prevent people from using non-Garmin avionics, despite some conspiracy theories to the contrary; basically, they just say they've heard the IFD works with the G3X, but can't be bothered to confirm, so go check with Avidyne.
 
Back
Top