Are you interested in a standard avionics network?

  • Yes, regardless of cost!

    Votes: 5 6.2%

  • Yes, but only if it has a minimal cost.

    Votes: 51 63.0%

  • No thanks.

    Votes: 14 17.3%

  • Maybe.

    Votes: 11 13.6%
  • Total voters
    81
K

ksauce

Well Known Member
Patron
By talking avionics, I don't mean having your EFIS whisper sweet nothings in your ear while you're tracking a VOR. The question is how many would be interested in having a simple way to have the equipment in our planes talk to one another?

A simple example would be having your EFIS tell your trim controller the airspeed in order to change the rate of your trim motor. Or it could be having your strobe controller indicate a blown lamp on your MFD. There are lots of capabilities that we've thought of and hundreds more we can't imagine at this point. It might just be like how the internet has turned into something that no one could have possibly envisioned 30 years ago when it was invented.

Several of the VAF geeks are having an interesting discussion about developing a method to allow the devices we all know and love to have such meaningful conversations. This would hopefully be as close to plug and play as possible using a standard ethernet cable.

So my question is, would you be interested in such a system?
 
Last edited:
I have thought about this before.

Cars manufactures have been doing this for years. Most use CAN bus to communicate.
It sure would be nice to run one wire for power, one ground wire and then one for smart control of simple devices.

As for the avionics, it would take all the manufactures to agree on a standard protocol for data exchange. Then just use ethernet. Why invent something new.

But how do we get everyone to buy into the exchange of data?

Kent
 
Last edited:
I voted with minimal cost, but that is rather subjective and would be willing to pay more then minimum but not open ended.

I think creating standards such that has been done in IT would benefit greatly and simply this very much. I can imagine, how much it would open it up for new innovation and newer companies to move forward when they have a clear path as how to talk to other instruments.
 
These capabilities are already out there, mostly with Vertical Power.

It will do all the above, including IIRC, gaining down the pitch trim as a/s increases. That may be another product, but I do know the capability is out there.
 
The idea is we're looking at developing a protocol the manufacturers will embrace. The question I would like answered is if there is any demand for such a protocol? If there is, then we open up a plethora of possibilities. If the demand isn't there then there is little point as the manufacturers will have no incentive to support it. While the examples I listed are certainly feasible today (and by no means do I want to down play the capabilities of vertical power or any other manufacturer), they are limited, simple examples. I really think that by connecting these amazing devices we can create something truly greater than the sum of the parts. I think we're aiming to go beyond what the automotive manufacturers have been doing as each auto manufacturer is a closed, proprietary system. We're aiming for something that folks can tap into, tweak, invent, and play with to tailor the way you interact with the equipment in your airplane. I get the impression that I'm not explaining the concept very well. I'll see if I can come up with some more impressive examples and possibilities.
 
Re inventing the wheel (again)

Hi Kevin,

I suspect coming up with a standard for middleware communication between components installed in an experimental aircraft is going to be a tricky one.

This puts another layer of software and complexity between connecting components together. However, if you have enough components then the added complexity is worthwhile with a standard connection and configuration.

So we are talking a central digital communications bus probably based on TCP/IP with added layers on top in order to connect and configure the components.

Open source offerings should not be discounted Advanced Message Queuing Protocol as a quick example could be looked at to provide the backbone of the development.

Getting the manufacturers on board is another obstacle. It only takes someone like Garmin to say "I aint going down that route" and your development is heavily compromised.

Good luck.
 
TCP/IP is nice for computers, but not so nice for embedded (not impossible, just a lot more overhead). I would vote for CAN bus -- lots of things speak CAN both high and low speed including readily available diagnostic equipment for the automotive industry.
 
No, not correct.
Yes, they use CAN. That is exactly the same as Avionics manufacturers do.
They use RS232, RS422, RS485, ARINC429 and some also use CAN.

All these just specify the HARDWARE used to tranfer data. None of these specify HOW data it transfered or WHAT data is transfered or anything like that at all.

This is where you need a "protocol" specification. Yes, some will argue that there is one for CAN (for engine data) called J1939. It's useless as no engine managenement system uses it as specificied or have changed things to suit them.

This is exactly the dilemma avionics manufacturers (like us) face. We have certain ideas and need certain data to flow in certain ways. Due to the infinite amount of different ways you can do things you can well imagine that talking compatibility is out of the question.

The only thing we can do is to provide a subset of data in a published form. This would pertain to things like "altitude", "airspeed" and things like that. If several manufacturers would agree on a way of doing that (completely independent of their own internal data highways which are need based and not suitable for this), then it becomes possible to use such information for third party hardware vendors and everybody wins.

What is happening now is a start.

Rainier


kentb said:
Cars manufactures have been doing this for years. Most use CAN bus to communicate.

Kent
Click to expand...
 
Loboflyer said:
TCP/IP is nice for computers, but not so nice for embedded (not impossible, just a lot more overhead). I would vote for CAN bus -- lots of things speak CAN both high and low speed including readily available diagnostic equipment for the automotive industry.
Click to expand...

Yes, CAN is nice. It is robust and multi-drop which means you can connect several pieces of equipment on a single bus is a fairly safe manner (i.e. if one piece of equipment is powered down it will not cause the bus to fail).
There are some slight issues as it also has "baud rates" and two (luckily compatible) low level protocols. However, you likely cannot connect devices onto a single CAN bus unless they are "made for each other". This is due to addressing schemes which have to be agreed upon. This can make it difficult to integrate something. Yes, there has been a very good attempt called "CAN Aerospace" but it seems it is going nowhere due to complexity and burden it places on the bandwidth. Designers have 8 bytes of payload per message to play with and need to use these bytes for real data or else things just become inefficiant.

TCP/IP works over any kind of link (and could work over CAN or anything else). It is a software protocol stack.
The overhead is fairly large but not impossible for a micro controller as you need only the TCP/IP level and the hardware interface layer. None of the higher level protocols are required (UPD etc).

I think the best solution, considering the actual need is to stick with RS232 and agree on several "standard" messages containing all that is typically needed. This is the easiest and safest from an implementation point and user installation point of view, as long as enough serial ports are available.

Rainier
 
MIL-STD-1553B

I've often wondered why civil avionics never went this way. This standard has been out since 1978, and allows for significant redundancy.

I think the only things that should be on your panel are display and control heads. All the "guts" should be line replaceable units (LRUs) in the form of plug in cards or boxes in an avionics bay. But then again I think taxes should be fair and 100LL should be a fair price. Sigh...

See Wikipedia http://en.wikipedia.org/wiki/MIL-STD-1553 for more info.

Don
 
This is an idea who's time has come, IMHO----or maybe long overdue is probably more like it.

MIDI was my first exposure to using a standard method of connecting various boxes of electrons together and having they play nicely together, I have often wondered why more disciplines dont follow suite.
 
I guess nobody has heard of ARINC? Their (orignal) purpose in life is just what you are asking for.
ARINC-429
ARINC-664 AFDX (Ethernet)

But, what is not standard is what data gets put on the bus and when.

I would caution that putting Ethernet (100MBit) in and airplane is a very tricky proposition EMI wise. The signalling frequency lands right smack dab in the middle of the com/nav frequency band. You can toss any ideas of using RJ connectors right out. DO-160F cat M and H are not trivial to pass.
 
fl-mike said:
I would caution that putting Ethernet (100MBit) in and airplane is a very tricky proposition EMI wise. The signalling frequency lands right smack dab in the middle of the com/nav frequency band. You can toss any ideas of using RJ connectors right out. DO-160F cat M and H are not trivial to pass.
Click to expand...

AFS has been using RJ connectors and Ethernet for years to communicate between screens. Dynon just released the same with the Skyview.
 
fl-mike said:
I guess nobody has heard of ARINC? Their (orignal) purpose in life is just what you are asking for.
ARINC-429
ARINC-664 AFDX (Ethernet)

But, what is not standard is what data gets put on the bus and when.

I would caution that putting Ethernet (100MBit) in and airplane is a very tricky proposition EMI wise. The signalling frequency lands right smack dab in the middle of the com/nav frequency band. You can toss any ideas of using RJ connectors right out. DO-160F cat M and H are not trivial to pass.
Click to expand...

of course there is arinc-429...
but
- you have to pay quite a bit to even get the documentation only
- uses special (rare and therefore expensive) electronics or you have to emulate the function with software and a microprocessor (as AFS and all the others do)

in general overly complicated and way more expensive than rs-232 or even ethernet. of course one could agree to use the arinc-429 data format but over ethernet, though it probably couldn't be called 429 any more *G*

rgds bernie
 
100Base-TX encoding

fl-mike said:
I would caution that putting Ethernet (100MBit) in and airplane is a very tricky proposition EMI wise. The signalling frequency lands right smack dab in the middle of the com/nav frequency band.
Click to expand...

Just a technical point... While it is true that encoding a 100MBit/s data stream with 4B5B runs the apparent bit rate up to 125MBit/s, 100Base-TX then encodes that with the 4-transition code MLT-3, which results in a signal on the wire that has maximum fundamental frequency (125/4) = 31.25 MHz. This signal then can be lowpass filtered with a cutoff not much above that. There doesn't need to be significant energy in the resulting spectrum anywhere in the 108-135MHz range.

Discussion here: http://www.hwkb.com/Uwe/Forum.aspx/network-ethernet/1824/Theory-behind-31-25-MHz-in-100BASE-TX

--Paul
 
You must log in or register to reply here.