I’ve read somewhere an assertion that Avidyne’s (IFD440/540) backward compatibility with the GNS interfaces (basically analog + RS232 + ARINC429) is flawed and that the future lies in a special variant of Ethernet which supposedly Garmin use in the GTN boxes (and which somehow avoids the collision based multi-master protocol).
Are there any aircraft systems in GA that actually use Ethernet – other than it being used as a proprietary comms link between e.g. different modules of a G1000 system?
Also haven’t Garmin secured their Ethernet links, to prevent 3rd party compatible expansions? They have secured their crossfill protocol on the GTN boxes already, to block 3rd party add-ons such as voice control…
I also can’t see the need for a higher speed than ARINC429 which is already way fast enough for stuff like roll steering and should be easily fast enough for full LPV autopilot control (currently the glideslope is still analog, AFAIK).
Also haven’t Garmin secured their Ethernet links, to prevent 3rd party compatible expansions?
It sure isn’t an open standard.
I also can’t see the need for a higher speed than ARINC429 which is already way fast enough for stuff like roll steering and should be easily fast enough for full LPV autopilot control
If you want to transport video (eg. from a weather radar), ARINC429 isn’t fast enough…
But IMO the point about ethernet (or HSDB in Garmin speak) isn’t so much about the speed (they run it at 10MBps AFAIK), but ethernet is dirt cheap and robust, it even provides for galvanic isolation unlike all the older aviation interfaces. Nowadays it’s almost impossible to get integrated interface circuits for ARINC429, and if you get them they’re very expensive and likely not very reliable (ceramic package, low volumes).
If you want to transport video (eg. from a weather radar), ARINC429 isn’t fast enough…
Sure, but you can transport video over, ahem, a piece of coax 
Also I don’t think radar images are NTSC video anymore, in modern systems. I think the stuff is sent as icons, placed at x,y coordinates or (I’ve seen that in some radar protocols) at a given radius and bearing.
Nowadays it’s almost impossible to get integrated interface circuits for ARINC429, and if you get them they’re very expensive and likely not very reliable (ceramic package, low volumes).
Yes… though transmitting-only ARINC429 can be done quite cheaply, by bit-banging the data+encoding etc. If you want to transmit/receive say 20 channels concurrently then you would implement it in an FPGA, as e.g. Sandel have clearly done. I don’t get the impression this is a big enough fish to fry to dump the old interfaces, in this market.
And Avidyne have to play a catch-up game with Garmin, as Job #1.
a piece of coax
which is usually more expensive than twisted pair wire, and doesn’t provide any galvanic isolation
Yes… though transmitting-only ARINC429 can be done quite cheaply, by bit-banging the data+encoding etc
But then you’re likely not compliant with the ARINC 429 standard, it has some tight slew rate specs, which need some analog hardware to comply with.
Sandel have clearly done
It’s not so clear to me. They have loads of analog switches and DAC’s close to the connector, and possibly also OpAmps. Maybe they do it using a DAC, maybe they have some OpAmp filters to achieve the slew rate. But the component count is huge (Analog Devices must love Sandel). Now compare this to Ethernet, which is usually built into the microcontroller and the only external component is the transformer (and the connector).
I looked at this recently. ARINC429 is not a problem at all. I would actually do it with discrete components, which are dirt cheap. Sure the SN3500 has a large component count but I don’t see them using ARINC429 chips of any kind. I suppose doing with with an 8-bit DAC driven from an up/down counter in an FPGA would be pretty slick.
But that’s a detail. I just don’t see ethernet taking over in GA avionics unless everybody throws out the existing stuff, which isn’t going to happen. As Garmin gradually take over the world, they will use whatever they want internally but others (e.g. Avidyne) have to be compatible with all the old stuff, not least because Garmin will have secured their own new-style interfaces.
Also I don’t see ethernet a good solution for everything because if the cable breaks, or better still shorts, you lose everything connected to that bus.
tomjnx,
The price of a piece of wire is the least of my worries in aviation, for example our chief pilot recently snagged an aircraft as an annunciator bulb was gone on an autopilot mode selector panel. The bulb is not field serviceable and an exchange panel cost over £1200
Also I don’t see ethernet a good solution for everything because if the cable breaks, or better still shorts, you lose everything connected to that bus.
No one uses thin wire ethernet any more. A wire breaks, you lose that one device.
The thing is ethernet MAC/PHY chips can be bought off the shelf. Ethernet is simple, cheap and robust. You can also trivially implement a 10 meg ethernet PHY in an FPGA rather easily, just add a magjack and termination and you’re done on the hardware side. (100baseTX on the other hand is 3 level so you’d need something that can do that kind of signalling).
Shame on Garmin for encrypting their communication protocol – this just adds more software complexity (and therefore reduces reliability). Keeping their protocol secret should be secondary to reliability.
I agree one normally uses a switch rather than a hub nowadays, but then why is the Garmin implementation called “deterministic” when ethernet used in a point to point manner is hardly non-deterministic?
I am fairly sure they don’t use DHCP in avionics 
Also I have seen loads of “funny ethernet behaviour” which “magically” goes away when the ethernet switch (a standard 16 port gigabit thing from say Netgear) is power cycled… just what you want in an aircraft.
Anyway, the bottom line is that I don’t see any cross-vendor drift towards ethernet. RS232 and ARINC429 still seem to rule the light GA business, regardless of the implementation hassle of the latter one.
Also I have seen loads of “funny ethernet behaviour” which “magically” goes away when the ethernet switch (…) is power cycled
That must be a Windows-only thing. In more than 15 years of Linux www use, I have only had to do that once, and that was when the service provider had their network badly botched up. And I am using very low-end low-cost switches.
That said, I quite agree that I can’t see the need for the complexity of Ethernet in avionics – as long as one only communicates commands and measured data. The transmission of images might be another matter, though.
That said, I quite agree that I can’t see the need for the complexity of Ethernet in avionics
But ethernet isn’t complex, that’s the beauty of it – it’s very straightforward and that’s why it’s turning up everywhere. 10 meg ethernet is simple enough that the PHY will probably fit in a CPLD, and the ethernet protocol is also very simple – don’t forget the ethernet protocol had to work with what was available in the late 1970s so it really doesn’t have much in the way of processing requirements. As far as packet based protocols go, it’s about as simple as you can get.
It sounds like ARINC with its tightly specified slew rates requiring all sorts of analogue stuff on the board is a lot more complex than ethernet.
Ethernet used point to point will be extremely deterministic – there is never the possibility of a collision (in fact 1000baseTX gets rid of collision detection altogether). If it’s physically a bus topology and you’ve done something to get rid of the possibility of collisions, you no longer have Ethernet but something else (IBM for instance had token ring that used the same UTP cabling that ethernet used). I’m presuming if it’s switched ethernet that Garmin uses, the switch is somewhat smarter than a consumer dumb Netgear switch.
