Jump to content

G5 / GFC500 Install Info


Recommended Posts

Thought I would start a new thread for this.

Over on BeechTalk, there has been information presented about recent changes to installation of the G5 (which impacts installing the GFC500 too).  Apparently in the G5 installation manual, revision 16 (and now 17 as well), installing a G5 now requires installation of a resister and diode (no big deal) but also requires use of Carlisle CAN24TST120 wire for all CAN buss connections.  Unfortunately this appears to be made of unobtainium (almost).  There have been reports of it being found in small quantities which by now I'm such have been snatched up.  100' at $10/foot and somebody else found 125 feet and took it.

Anyway, supposedly it is going to be very difficult or impossible to find until July sometime.  So if you are like us, with an upcoming G5 installation date (April 22nd for us), you might want to make sure your installer has the wire in stock before you let them rip into your airplane.  If they ripped into ours in April and then found out they couldn't finish the job until July or August, I'd be pissed.  That's almost the entire good flying season in this part of the country.

Our installer is checking into it but has not called me back yet.

Fore warned is fore armed.

Link to comment
Share on other sites

From what I understand, only the G5 installation manual has been updated, the GFC-500 manual has not yet been updated and it still allows installation with the original wire.  Not sure if that will hold long enough for the GFC-500 to be released and installed in my M20J (I already have an installed G5 which is still legal from the previous install manual).

Link to comment
Share on other sites

From what I understand, only the G5 installation manual has been updated, the GFC-500 manual has not yet been updated and it still allows installation with the original wire.  Not sure if that will hold long enough for the GFC-500 to be released and installed in my M20J (I already have an installed G5 which is still legal from the previous install manual).



The GFC500 manual REV 9 has the Carlisle CAN wiring listed.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

It looks to be an old spec 120 ohm cable.   Old as in out of production not showing up in the catalog.   Garmin may want to redesign their box.  What it looks like is carlisle has replaced the prior product with 100 ohm products.   https://www.datasheets.com/datasheet/CAN24TST120-Carlisle Interconnect Technologies-60513276

 

Edited by Yetti
Link to comment
Share on other sites

We bought 150 feet of the new spec CANBUS cable 2 weeks ago from a major wire products distributor.  It was in stock and arrived promptly. 

Two G5 units and the GFC500 use it for inter-box communication.  Garmin designed CANBUS into their lower-cost boxes as an alternative to ARINC429.  

The specified cable is CAN24TST120,  a shielded twisted pair with controlled impedance. 

 

 

Link to comment
Share on other sites

56 minutes ago, Hyett6420 said:

So why not just use the Standards that are out there already and not reinvent the wheel.  Sorry but as a CIO this stuff infuriates me as ive seen it SO many times in IT.  

yep.   My 2005 BMW motorcycle has canbus running on it.  It's not like canbus is a new thing.   seems like Garmin knows how to network things the same way that Microsoft still has not figured out networking.   Garmin should have gone IP Based.

 

Link to comment
Share on other sites

2 hours ago, Yetti said:

yep.   My 2005 BMW motorcycle has canbus running on it.  It's not like canbus is a new thing.   seems like Garmin knows how to network things the same way that Microsoft still has not figured out networking.   Garmin should have gone IP Based.

 

I don't know that I agree with the IP based strategy.  CANBUS is THE standard for interdevice communication in the auto industry and it is designed specifically for what garmin is using it for, communicating between their different devices. 

In industrial automation, we use IP based systems for I/O, but they are not as easy to work with as you might think.  The standards have to be redesigned for the industrial environmnet so they have their own set of problems. 

Yes, IP based may more "adaptable," but look at what Garmin is using it for.  They are using to talk between their devices, not their device and aspen and avidyne.  Just like you BMW statement, they communicate between other BMW devices, not BMW and yamaha.  It does exactly what they want.  If you want to see IP based systems, you'll have to get the WHOLE avionics industry to sit down and agree and develop one and maybe I'm a pessimist, but that is never going to happen.

  • Like 1
Link to comment
Share on other sites

Garmin chose CANBUS as a lower cost standard compared to the ARINC 429 commercial aviation interfaces.   

Now that their lower cost gear, originally intended for experimental, has been approved for certificated aircraft we gain the benefits of that robust automobile standard.   

Link to comment
Share on other sites

The annoying thing is that they are referring to just one manufacturer. There are at least two more making Aerospace/Milspec CAN bus wires where one is used on Airbuses (means fulfilling Air Transport requirements). There even is a European Standard for Aerospace CAN Bus wires which could have been referenced.

  • Like 1
Link to comment
Share on other sites

1 hour ago, bob865 said:

I don't know that I agree with the IP based strategy.  CANBUS is THE standard for interdevice communication in the auto industry and it is designed specifically for what garmin is using it for, communicating between their different devices. 

In industrial automation, we use IP based systems for I/O, but they are not as easy to work with as you might think.  The standards have to be redesigned for the industrial environmnet so they have their own set of problems. 

Yes, IP based may more "adaptable," but look at what Garmin is using it for.  They are using to talk between their devices, not their device and aspen and avidyne.  Just like you BMW statement, they communicate between other BMW devices, not BMW and yamaha.  It does exactly what they want.  If you want to see IP based systems, you'll have to get the WHOLE avionics industry to sit down and agree and develop one and maybe I'm a pessimist, but that is never going to happen.

Industrial automation or Operational intelligence pays my salary.  whatever protocol on top of the IP stack would be an upgrade from the 1990s technology that the GA vendors are currently doing.   The IP stack was designed by DARPA in the 1960s to protect against nuclear annihilation.  Pretty sure it would work in a little airplane.   If vendors would start using current day technology, it would reduce costs because they could repurpose stuff off the shelf.

Do you need help to get your factory talking?

Link to comment
Share on other sites

12 minutes ago, Emmet said:

What practical benefit would IP bring over CAN?

In the automotive industrie IP is only used for high bandwidth applications and they analyzed it pretty extensively.

millions of off the shelf components that are plug and play.   Want a night vision camera for you plane to see through the haze.  Already IP based.  Just plug it in.   Way more of the workforce that understand how to put it all together.

  • Like 1
Link to comment
Share on other sites

7 minutes ago, Yetti said:

Industrial automation or Operational intelligence pays my salary.  whatever protocol on top of the IP stack would be an upgrade from the 1990s technology that the GA vendors are currently doing.   The IP stack was designed by DARPA in the 1960s to protect against nuclear annihilation.  Pretty sure it would work in a little airplane.   If vendors would start using current day technology, it would reduce costs because they could repurpose stuff off the shelf.

Do you need help to get your factory talking?

Nah.  We are doing ok.  Industrial automation pays my slary too.  We are largest auto exporter by value in the US so our equipment is talking ok.  :)

Below is a comparison article that may explain your question @Emmet

http://canlab.cz/pages/download/artikel_comparison_can_and_ethernet.pdf

What I understood from the article is it is a faster and more secure.

Link to comment
Share on other sites

Garmin uses ethernet and IP on the G1000 and higher systems.. also the  GTN6xx 7xx and others.. see HSDB.  

Since it is not a published standard they only use it between their own devices, GTX345, GDL69A. etc... ARINC 429 for interoperability. 

Link to comment
Share on other sites

The article shows nicely that CAN is the better choice for our application. Using IP you need additional protocol layers for a lot of tasks. This means more complexity, more testing, more computing power and memory. Add this to the higher hardware cost (remember we are talking about embedded software here and not gaming PCs) makes it a clear choice.

What the article is not addressing is EMI immunity. My understanding is that CAN is superior in that area as well.

Speed is only relevant if your system requires this speed otherwise it is wasted money.
Robustness and data integrity is something that at least myself would call a must.

Concerning connecting other devices : having a compatible physical and protocol layer doesn‘t mean that you can use it in any practical way within the network out of the box.

Don‘t get me wrong - I wouldn‘t use CAN for my home network, but for low cost networked avionics it is a ideal choice.
Simply the right tool for the right application...

  • Like 2
Link to comment
Share on other sites

33 minutes ago, bob865 said:

Nah.  We are doing ok.  Industrial automation pays my slary too.  We are largest auto exporter by value in the US so our equipment is talking ok.  :)

Below is a comparison article that may explain your question @Emmet

http://canlab.cz/pages/download/artikel_comparison_can_and_ethernet.pdf

What I understood from the article is it is a faster and more secure.

CAN is generally slower.  That comparison uses 10MBPS Ethernet.  Nobody's used that for ages.  Your home network is most likely all gigabit (mine is, except for a handful of low cost appliance-like devices which only have 100mbps controllers because they don't need any more) and could easily be 10 gigabit if you have a reason to need that much throughput.  Also odd, that paper compares TCP running on top of ethernet.  TCP seems like an inappropriate protocol for this sort of application.  High performance, low latency networking over ethernet generally calls for UDP.

CAN seems appropriate for aviation as it was for automotive.  Small area, relatively low latency, low throughput is the application.  It's a huge improvement over what aviation currently uses.  Consider, you have a transponder, ELT, and a couple AP servos in the tail.  Conventional aviation engineering requires two ports on your GPS with GPS out, one port each on your XPDR and ELT for GPS in, a third port to feed your AP somehow, three runs of wire, one for each device connected to your GPS (so two runs to the avionics bay) and separate runs from the AP to the servos (so a third/fourth run through the avionics bay) and also more runs to the switches for the ELT, etc.  CAN allows one port per device and one run of wire from the panel to the avionics bay.  Installation times and costs for additional remote avionics would be dramatically reduced.  Volume and complexity of wiring would be dramatically reduced.  WEIGHT of wiring would be dramatically reduced.  It's amazing that they haven't done this ages ago.  Inter-company device communications aren't generally a problem either.  I know people think of their car as being made by, say, BMW or Mercedes, but both those manufacturers source lots of electronics from suppliers.  You may have a Garett variable geometry turbo, a Bosch fuel injection system, and a Borg Warner transmission, all in the same Mercedes, all talking to each other.

Link to comment
Share on other sites

1 hour ago, Emmet said:


What the article is not addressing is EMI immunity. My understanding is that CAN is superior in that area as well.

 

Well you know unless you have to specify a really specific cable and add some resistors and diodes and then it is not.

Link to comment
Share on other sites

32 minutes ago, johncuyle said:

CAN is generally slower.  That comparison uses 10MBPS Ethernet.  Nobody's used that for ages.  Your home network is most likely all gigabit (mine is, except for a handful of low cost appliance-like devices which only have 100mbps controllers because they don't need any more) and could easily be 10 gigabit if you have a reason to need that much throughput.  Also odd, that paper compares TCP running on top of ethernet.  TCP seems like an inappropriate protocol for this sort of application.  High performance, low latency networking over ethernet generally calls for UDP.

CAN seems appropriate for aviation as it was for automotive.  Small area, relatively low latency, low throughput is the application.  It's a huge improvement over what aviation currently uses.  Consider, you have a transponder, ELT, and a couple AP servos in the tail.  Conventional aviation engineering requires two ports on your GPS with GPS out, one port each on your XPDR and ELT for GPS in, a third port to feed your AP somehow, three runs of wire, one for each device connected to your GPS (so two runs to the avionics bay) and separate runs from the AP to the servos (so a third/fourth run through the avionics bay) and also more runs to the switches for the ELT, etc.  CAN allows one port per device and one run of wire from the panel to the avionics bay.  Installation times and costs for additional remote avionics would be dramatically reduced.  Volume and complexity of wiring would be dramatically reduced.  WEIGHT of wiring would be dramatically reduced.  It's amazing that they haven't done this ages ago.  Inter-company device communications aren't generally a problem either.  I know people think of their car as being made by, say, BMW or Mercedes, but both those manufacturers source lots of electronics from suppliers.  You may have a Garett variable geometry turbo, a Bosch fuel injection system, and a Borg Warner transmission, all in the same Mercedes, all talking to each other.

I agree with your genreally slower statement, but think about what you actually send across the wire in these applications.  It's short telegrams of very specific data.  For example the basic ADS-B message your plane broadcasts, assuming you're 2020 compliant, is only 112bits.  (https://mode-s.org/decode/adsb/introduction.html in case you're interested) That's not a typo, it's bits not bytes.  That's only 14 bytes or .013kb, or 0.000013MB and that contains your ID, surface position, airborne position with baro alt, airborn velocity, airbone position with gnss height, and a few other pieces of info. You don't need blazing speeds for that kind of transmission.  You're not sending video and pictures in these cases.  You just need it to be robust and reliable. And the slower you go, the less opportunity there is for error in encoding or decoding. 

Fun fact, we may all complain about the range of of our wifi, but did you know they were able to communicate all the way across the continent of Austrailia with 802.11b wifi?  They were able to do this becuase of the speed degrades in wifi allow B wifi to downgrade all the way to 1MB which allows for up to 180 degrees of error to be injected and the signal still successfully decoded.  To go faster, we have to define more data points on the carrier wave which means less room for error.  To go even faster, we have to use mulitple modulation methods, which puts the data points even closer still and even less room for error.

Your point about TCP vs. UDP is where I was going with the industiral automation statement.  We may use IP based systems for automation, but there is no TCP to be found(except for non-I/O related tasks).  There isn't even UDP.  They are all propritary standards.  For example Allen Bradley uses EthernetIP, Siemens uses Profinet, and inside a Kuka cabinet, they use EtherCat.  You can typically get any standard with any manufacturer, but these are the 'native' standards.  All of these define their own special Transport layer specs.  And you have to pay a liscense fee for every device that communicates using that protocol.  Technology aside, I would think this alone could cause problems with certification.  Who would pay to get the FAA to cerfity a protocol?  I certainly wouldn't since it means if I do someone could buy my competitor's product since it would work with my other product.  And I doubt the FAA is going to take the initiative to specify a certified standard either.That seems like it would open a whole new can of worms too.  I assume that is how it would work.  I'm not sure how exactly you go about certifying software.

Just my thoughts.  Geeking out on this a little bit.  :) 

  • Like 1
Link to comment
Share on other sites

9 hours ago, bob865 said:

I agree with your genreally slower statement, but think about what you actually send across the wire in these applications.  It's short telegrams of very specific data.  For example the basic ADS-B message your plane broadcasts, assuming you're 2020 compliant, is only 112bits.  (https://mode-s.org/decode/adsb/introduction.html in case you're interested) That's not a typo, it's bits not bytes.  That's only 14 bytes or .013kb, or 0.000013MB and that contains your ID, surface position, airborne position with baro alt, airborn velocity, airbone position with gnss height, and a few other pieces of info. You don't need blazing speeds for that kind of transmission.  You're not sending video and pictures in these cases.  You just need it to be robust and reliable. And the slower you go, the less opportunity there is for error in encoding or decoding. 

Fun fact, we may all complain about the range of of our wifi, but did you know they were able to communicate all the way across the continent of Austrailia with 802.11b wifi?  They were able to do this becuase of the speed degrades in wifi allow B wifi to downgrade all the way to 1MB which allows for up to 180 degrees of error to be injected and the signal still successfully decoded.  To go faster, we have to define more data points on the carrier wave which means less room for error.  To go even faster, we have to use mulitple modulation methods, which puts the data points even closer still and even less room for error.

Your point about TCP vs. UDP is where I was going with the industiral automation statement.  We may use IP based systems for automation, but there is no TCP to be found(except for non-I/O related tasks).  There isn't even UDP.  They are all propritary standards.  For example Allen Bradley uses EthernetIP, Siemens uses Profinet, and inside a Kuka cabinet, they use EtherCat.  You can typically get any standard with any manufacturer, but these are the 'native' standards.  All of these define their own special Transport layer specs.  And you have to pay a liscense fee for every device that communicates using that protocol.  Technology aside, I would think this alone could cause problems with certification.  Who would pay to get the FAA to cerfity a protocol?  I certainly wouldn't since it means if I do someone could buy my competitor's product since it would work with my other product.  And I doubt the FAA is going to take the initiative to specify a certified standard either.That seems like it would open a whole new can of worms too.  I assume that is how it would work.  I'm not sure how exactly you go about certifying software.

Just my thoughts.  Geeking out on this a little bit.  :) 

Agree, you just don't need the kind of throughput ethernet offers for the places where CAN is used, and I can't even come up with an avionics-related application where high throughput would be useful.  Was more addressing the previous poster's comment that it was faster and more secure.  Faster it is not.  I'm not sure how it's more secure either, although it looks like they might have meant reliable/better data integrity rather than more secure in the IT/network administration/network security sense.  (I mean, they say the word security but there's no mention of encryption anywhere...)  My professional experience is pretty much all video games or web services, so it isn't terribly relevant to avionics.  I have only a passing familiarity with CAN due to being an auto enthusiast and (very) infrequent electronics tinkerer.

  • Like 1
Link to comment
Share on other sites

2 hours ago, Yetti said:

people are getting their transport vs data protocol interchanged.  Time to get out the 7 layer OSI model.

Here ya go :)

https://en.wikipedia.org/wiki/OSI_model

If I made a mistake, let me know where.  This stuff is a random interest of mine so I'd seriously like to know.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.