EFIS flight data interchange protocols

Flight Information eXchange (FIX) Protocol

Vx Aviation has been in discussion with some EFIS vendors about the publishing of interoperability specifications for air data, engine data and other information streams that are generated by modern EFIS systems and their related devices.

The original objective was to ensure that our products could interoperate with as many EFIS products as possible, but it has now grown into a more wide-ranging objective: To support, as much as possible, the commonality of flight data protocols.

To that end, I have had discussions with two major vendors in this space, Dynon and Garmin as well as a brief discussion with MGL. My apologies to other EFIS vendors, I invite them to contact me directly to discuss. This is also extended to Vertical Power, because of their interesting application in power managment.

As a result of these discussions, I have obtained permission to publish Dynon's new SkyView serial protocols on this page.

I am working with Garmin for early access to their new G3X protocols as well, and I will publish them (with their permission) on this page as well. I am also coaxing as many EFIS vendors as possible to adopt existing protocols as appropriate. The objective here is interoperability of basic data exchange protocols. While it's a maybe a bit too ambitious to have an EFIS from one vendor feed an EFIS from another, I think the goal is noble.

Here's what the population of VAF can do to help:

1) Support the objective of common, well documented flight data protocols
2) Coax your favourite EFIS vendors to publish their specifications and support ones that already as they migrate their products.
3) Provide public feedback and commentary on the proposed specifications so that vendors can improve their products.

At Vx aviation, we only have a little bit of skin in the game here (with our remote AoA indicator). The purpose of this initiative is to lay the groundwork for better, more integrated glass cockpit systems in the future.

Again, I invite the EFIS vendors to contact me directly with comments and concerns, or post to this thread.

FMI : www.vx-aviation.com/FIX

Noble effort Vern...and it does make sense. An open standard for streaming data could enable tons of third party/user built products. Never have understood why the EFIS makers did not get together and come up with a standard for this. It would only make their lives easier and provide more value to the end user.

Kudo's to Dynon since they have always made their serial protocol's available and well documented. I am sure that will continue with the Skyview products as they start to stream data from them as well.

PS: The protocol data sheet you have listed for the Dynon Legendary products is not the latest version. It is missing a few characters....

Brantel said:

Noble effort Vern...and it does make sense. An open standard for streaming data could enable tons of third party/user built products. Never have understood why the EFIS makers did not get together and come up with a standard for this. It would only make their lives easier and provide more value to the end user.

Kudo's to Dynon since they have always made their serial protocol's available and well documented. I am sure that will continue with the Skyview products as they start to stream data from them as well.

PS: The protocol data sheet you have listed for the Dynon legacy products is not the latest version. It is missing a few characters....

Click to expand...

Got it, thanks Brian. Problem was that a page was cut off. It's been corrected. I appreciate your involvement in this. Since you've been through the exercise of developing code to interpret air data protocols, your commentary is invited and appreciated. I've invited the EFIS vendors to participate here as well.

V

Garmin GPS Data now on FIX site

Update, Garmin GPS Text output is now on the FIX site, with codepoint '@'.

Vern

Might I also suggest we add the Vertical Power folks to the list...

VP-X Pro & VP-X Sport Development Kit

Looks like Dynon has done a great job with this look at what they are planning for the Skyview. They are adding a bunch more data to their format than what is possible with the legacy system. They also appear to be getting rid of the weird way they swapped data sources for a few of the characters. This coupled with the fact that they are gonna allow the end user to modify the streaming baud rate really makes their format cool!

As part of my day job, I brought this up with GAMA a few years ago with a suggestion to amend the GAMA 429 GA Subset to encourage standardization. They thought it was a great idea, but everyone is so busy with other projects it never got much traction. I hope your efforts are successful.

HowardGMac said:

Might I also suggest we add the Vertical Power folks to the list...

VP-X Pro & VP-X Sport Development Kit

Click to expand...

Yes, VP is on the radar screen, however, theirs is a tightly coupled protocol as opposed to the simple data/status transmit only protocol that FIX will address initially. Also, VP has the market to itself, so they have a defacto standard already.

Expansion of FIX to Next-FIX is a possibility. I've also had requests to work on a simple CAN interface (CAN-FIX). That will have to come much later, unless someone wants to pay for a full-time standards representative.

Keep it coming, it looks like there is good interest here.

V

Dynon SkyView protocol update

See the FIX'd link for a new version of the SkyView protocol. EMS data has been fixed (puns intended).

I don't have a clue about this stuff, but maybe it should be a 'sticky' at the top of the Glass Cockpit forum. Easier to find for those concerned.
...just a thought.

SourceForge Site

I created a SourceForge Project yesterday. It's probably a little bit pre-mature at this point but it's free and easy.

https://sourceforge.net/projects/fix-project/

I'm not sure how we might use it right now. Perhaps if this thing really gets into development it will make a better collaboration tool. Right now we probably need more of a discussion tool and this forum is perfect for that.

I took the liberty of coming up with a list of data points that might be communicated by a protocol like we are discussing and I tried to put them in some kind of priority order. It is far from complete and probably wrong in some respects but we need a place to start.

Some deficiencies that I know exist are large blocks of data such as Nexrad data, airport information data, images and the like. Also missing is configuration data like Vx, Vy, Low Oil pressure set points, etc.

I developed this list with a CAN bus protocol in mind but it could be used with RS-232, RS-485, Ethernet, etc. if that is the direction we go.

The files are here...

https://sourceforge.net/projects/fix-project/files/

I don't have Micro$oft Expel so the spreasheets are in CSV and ODS formats but Expel can open the CSV, and LibreOffice is libre (free).

TX7A said:

I don't have a clue about this stuff, but maybe it should be a 'sticky' at the top of the Glass Cockpit forum. Easier to find for those concerned.
...just a thought.

Click to expand...

I agree. A request was sent to DR for moderator priveledges. No response yet... Once he replys, I can manage the thread better.

V

Birkelbach said:

I created a SourceForge Project yesterday. It's probably a little bit pre-mature at this point but it's free and easy.

https://sourceforge.net/projects/fix-project/

I'm not sure how we might use it right now. Perhaps if this thing really gets into development it will make a better collaboration tool. Right now we probably need more of a discussion tool and this forum is perfect for that.

I took the liberty of coming up with a list of data points that might be communicated by a protocol like we are discussing and I tried to put them in some kind of priority order. It is far from complete and probably wrong in some respects but we need a place to start.

Some deficiencies that I know exist are large blocks of data such as Nexrad data, airport information data, images and the like. Also missing is configuration data like Vx, Vy, Low Oil pressure set points, etc.

I developed this list with a CAN bus protocol in mind but it could be used with RS-232, RS-485, Ethernet, etc. if that is the direction we go.

The files are here...

https://sourceforge.net/projects/fix-project/files/

I don't have Micro$oft Expel so the spreasheets are in CSV and ODS formats but Expel can open the CSV, and LibreOffice is libre (free).

Click to expand...

For the uninitiated, what Phil is discussing here primarily is the next-gen effort once we've locked down the first phase of FIX, which is the agreement on serial data output protocols.

Phil has suggested that we take the next step by defining a simple, open protocol for multi-vendor EFIS communications based on the CAN (Control Area Network) bus. Standards do exist in this area for aeronautics but are exceedingly complex and not appropriate for our application segment.

Both Garmin and Dynon run buses that are similar in concept to CAN, if not identical in some aspects. Nevertheless, their protocols are proprietary.

Looking forward (way ahead), it would be nice if we had an interworking standard between EFIS systems and peripherals that would allow plug and play connections between vendors' products.

Dubbed "CAN-FIX" by me, once we lock down the work we are doing right now as represented on the FIX site we'll turn out efforts on it.

As an update, the FIX documents are coming together, however, there has been no participation by GRT, MGL, AFS or TruTrak. With Sun N Fun, I expect that they have been overloaded.

They have a unique opportunity to contribute if they so wish. We have managed to resolve several issues related to the Dynon and Garmin protocols and hope to have as many vendors as possible cooperating.

Thanks,
Vern

vlittle said:

Yes, VP is on the radar screen, however, theirs is a tightly coupled protocol as opposed to the simple data/status transmit only protocol that FIX will address initially. Also, VP has the market to itself, so they have a defacto standard already.

Expansion of FIX to Next-FIX is a possibility. I've also had requests to work on a simple CAN interface (CAN-FIX). That will have to come much later, unless someone wants to pay for a full-time standards representative.

Keep it coming, it looks like there is good interest here.

V

Click to expand...

You may want to look at CANaerospace. I have been developing hardware on this bus for a few years and it has grown into AIRINC825. The AIRINC version is complex but the original CANaero standard is still supported by Stock Fight Systems and quite simple

Do you think that we can take the CANaerospace protocol and manipulate it to our needs? There are some things that I love about CANaero and some things that I don't like.

CANaerospace may be too flexible. Flexibility is the enemy of simplicity. For example CA allows multiple data types for each different type of information. That may make it more difficult for small systems to handle. For example, if I build a small 8-bit microcontroller based trim controller I might only want airspeed data. If the air data computer is transmitting that data in a 32-bit float it's going to be difficult enough, but if my little uC has to deal with all the other data types on top of that for a single airspeed then it gets rather complicated. If I don't deal with all of the allowable data types then I run the risk of my little widget working okay with one device and not with another one and the end user won't know why. If we define the data type, range and units for each type of data then we eliminate a lot of complexity. It's not as flexible but it is much simpler.

Don't get me wrong, I am very impressed with CANaero but I think the goal of this endeavor is to build something that hobbyist tinkerers and amateur airplane builders can play with. Vern is correct, in that, we need to start with something very simple, probably RS-232 based that can be easily implemented. The list that I put up earlier was based on my ideas of a CAN based protocol similar to CANaero (In fact I stole most the list of points from the CA spec), but I just wanted to use it as a starting point. I think we need to define what information we want to transmit, what form it will take and how to identify it on the network. In that case it doesn't matter what the lower level communication medium is.

If we keep CAN bus (and/or other types) in mind as we develop the protocol for RS-232 then converting between PRE-FIX and CAN-FIX will be much easier in the future.

Opinions please. I'm sure I'm not right and I know others have some good ideas. Let's discuss it.

Just a thought: how about using key/value pairs? The key wouldn't actually be text as that increases the data transmission overhead dramatically but rather a unique ID number. For example, airspeed might have a key number of 14. Thus, the data would come down the pipe as 14:165. The trick would be administering the list of key/value pairs. The values could either be unique to the key (bool, int, float, etc.) which would add to the administration overhead.

I think, however, a fixed length data field might be better for simplicty. Let's say, for example and ease of conversation, that we make all values 8-bit. Values that will never exceed 0-255 could be one simple key/value pair. Let's assume oil temperature has a key number of 23. So it arrives as 23:125.

If you needed more than an 8-bit width you could use multiple pairs to increase precision. We could have an Airspeed1 key number of 5 and an Airspeed2 key number of 6. To send airspeed, we would send 5:1 and 6:84. Combine the value pairs at the controller of 1 (binary 00000001) and 84 (binary 01010100) for 16-bit resolution so that in this example your airspeed would be 340 (binary 0000000101010100).

Honestly, I think 16-bit might be a better width as most values for GA could be handled with that level of precision. The major benefit of this is that you don't have to define every possible parameter under the sun; it's readily expandable. Also, your 8-bit controller can only look for values you need. Finally, this is fairly transmission neutral as all you're doing is sending bytes. I think CanBus has an 8 byte payload, so if you used 16-bit for the key and the value you would have 2 values per frame. Further down the road if we wanted to do a TCP/UDP transmission we could with relative ease. In the distant future we could use whatever new fangled fiberoptic medium that transmits at 1 petabyte per second. In fact, you could have several communication links on the same controller looking at several types of networks. Bytes are bytes!

Thoughts?

Birkelbach said:

if I build a small 8-bit microcontroller based trim controller I might only want airspeed data. .

Click to expand...

Hey...thats my idea...just kidding. That is a perfect example of what kind of things people could do with this stuff even with today's existing data streams.

Binary or ASCII

ksauce said:

Just a thought: how about using key/value pairs? <<SNIP>>

Click to expand...

I like the key / value idea.

This brings up the fundamental question. Do we want this to be an ASCII based protocol or a binary one? ASCII is easy but not very efficient, binary is much more efficient but is more difficult.

16 bits should be more than enough resolution for just about any piece of data that we need to send, except maybe lat and longs. Do we used fixed point notation (i.e. to send 150.00 we send 15000 and assume two decimal places) or do we scale the number into the 16 bits and know the scaling range beforehand (i.e. we send 150 as 32767 with the assumption that the range is 0-300)? The former is easier to read the latter gives better resolution of data.

How many digits / letters for the ID?

Do we send a checksum for validation of the message?

What baudrate? Specified or configurable?

What about configuration data. For example, an AOA indicator would need the Angle but also the critical angle, and at what angle do we want to "warn" the pilot. This is not information that needs to be sent continually but should be sent occasionally. Airspeed will also have this problem. The actual airspeed is simple enough but where is the yellow arc, the white arc, red line?

I'm pretty sure that, at the moment, we are talking about a broadcast only type protocol that is point-to-point with one device producing information and the other device receiving it. Is this a correct assumption?

trim and power modules already exist

I already have a trim PCB and power controllers based on CANaero you can see them on my old jadsystems.com website.
CAN is much better than RS-232/422 simply because of low power controllers. The CAN chip filters all the messages with no processor overhead.
In addition CAN is robust in many way that would require software overhead for most other protocols.
I invite you to read my white paper on the website and see what you think
As for type values, you can send the same information using several types without causing any issues. You just key the receivers to only process those of interest.
I have completed the hardware for a GIO/Serial bridge. The idea being to bridge EFIS data streams into the CANaero bus. That is also in the white paper.

It is amazing...open up a thread like this and all of a sudden there are experts in the field falling out of the woodwork!!!!

The RV universe is big!!!!

I say binary, but that's just my preference as I like being able to look at hex numbers and it has little overhead. Also, since we're just sending numbers, it makes no sense to add the overhead.

I think fixed point notation is the best; it will just be up to the administers to agree what the decimal shift is for each key. And for high precision numbers, again, we could have Latitude1 key/value and Latitude2 key/value that represent the most significant and least significant words of a 32-bit precision floating point value. Or, alternatively we could have LatitudeDegrees, LatitudeMinutes, and LatitudeSeconds.

I don't think letters should be used for the key. Numbers are pretty easy to deal with and low power controllers will have a much easier time checking to see if they want to use key 13 as opposed to dealing with string "Altitude." This will just mean that there needs to be a freely available table somewhere that defines what each key number is and the value decimal shifts.

Because the overhead is lower with a number, and if we assume a 16-bit number we have a total of 65535 keys. This means we can define a ton of parameters. Both angle of attack and critical angle can have a unique keys. The same is true for the airspeeds you mentioned and everything else we can possibly think of in the future.

I don't think a checksum is necessary. This isn't going to be a safety rated protocol. I think perhaps each controller could send a heartbeat ID (maybe key 0?) every second or so just so the other controllers know it's still alive. Considering that this does indeed sound like a broadcast protocol checksums would be very difficult to implement. Again, for simplicity, I don't think it's necessary.

Baud rate is I think too much of a implementation question right now. Essentially, it will be whatever the manufacturers decide is affordable right now. That might be (and sounds like it will be) canbus. I don't know too much about canbus so I can't make much of a comment about available baud rates but I don't think it matters at this stage.

For most of us, this would be 1 efis broadcasting this data; however, that doesn't mean it has to be that way. Vertical power could listen as well as transmit. The trim controller could listen for airspeed and transmit trim position. Everything is broadcasting; we just need to rely on the mechanisms already present in the lower level protocols (TCP, CanBus, etc.) to avoid collisions and handle integrity. Why reinvent the wheel?

Again, this isn't a safety protocol and will not be real-time. It would be up to the developer to decide what to do with their own data as well as the data received. If I was writing a flap controller, I might decide I can retain the value of Vfe until I receive an updated value. I can decide that airspeed data is only valid for 100ms. I might also decide to fail "elegantly" (no idea what that is) if I stopped receiving airspeed data every 100ms and I haven't seen the heartbeat in 500ms. Sending is a bit more tricky as certain values would need a minimum update time to be usable. That will take some input from lots of sources.

Birkelbach said:

I like the key / value idea.

This brings up the fundamental question. Do we want this to be an ASCII based protocol or a binary one? ASCII is easy but not very efficient, binary is much more efficient but is more difficult.

16 bits should be more than enough resolution for just about any piece of data that we need to send, except maybe lat and longs. Do we used fixed point notation (i.e. to send 150.00 we send 15000 and assume two decimal places) or do we scale the number into the 16 bits and know the scaling range beforehand (i.e. we send 150 as 32767 with the assumption that the range is 0-300)? The former is easier to read the latter gives better resolution of data.

How many digits / letters for the ID?

Do we send a checksum for validation of the message?

What baudrate? Specified or configurable?

What about configuration data. For example, an AOA indicator would need the Angle but also the critical angle, and at what angle do we want to "warn" the pilot. This is not information that needs to be sent continually but should be sent occasionally. Airspeed will also have this problem. The actual airspeed is simple enough but where is the yellow arc, the white arc, red line?

I'm pretty sure that, at the moment, we are talking about a broadcast only type protocol that is point-to-point with one device producing information and the other device receiving it. Is this a correct assumption?

Click to expand...

It's nice to be able to contribute for once. I'm glad my days of staring at Profibus telegrams and TCP/UDP packets at work is finally paying off!

Brantel said:

It is amazing...open up a thread like this and all of a sudden there are experts in the field falling out of the woodwork!!!!

The RV universe is big!!!!

Click to expand...

It may help the others participating in this thread if we would all give a brief rundown of what our experience is related to this project.

I am an Electrical Automation Engineer of about 20 years focusing mainly on the Rockwell Automation product line but most other major brands as well.

I have much experience in dealing with Ethernet, EthernetIP, ControlNet, DeviceNet, Modbus, Profibus, DH+, DH485. Tons of experience parsing RS232/RS485 ASCII/Binary data into usable infomation and also packaging data for sending.

Experienced with VB, VB.NET, C, C+, C#

Love to work on projects for uControllers and have the most experience with the Arduino compatible units.

Self taught in regards to avionics and aircraft electrical systems by soaking up bits and pieces from many different areas on the web. Built my own airplane including all the systems. Have built two projects for integration with my airplane. A remote AOA indicator that is Plug and Play compatible with the Dynon legacy system complete with uController control and automatic dimming and a remote indicator for my P-mag ignition system. Both use RS232 ASCII data streams from the device to display remote data.

Thats enough about me....NEXT

I love this thread. It makes me feel all wrapped up in a nice warm wubbie . I'm just going to kick back an reminisce with myself of a bygone day before I got sucked into management. I don't need to display my credentials, you guys have it covered.

I'm an automation engineer in the entertainment industry. I haven't been at it as long as Brian (only 8 years). Most of my experience is with Siemens equipment using profibus/profinet and the profisafe extensions.

I focus mostly on drives/motion control but I also help develop a code library we run on the motion controllers. We do all of our user interface via TCP/UDP. I spend most of my time writing stuff for work in Structured Text (the IEC flavor of pascal) but I have dabbled in C, Objective-C, and Python. I have some experience with RS485 based protocols (the major control network in the entertainment industry, DMX, is based off of 485).

I'm also playing around with the arduino. Right now I'm working on a arduino powered, GPS enabled reverse geocache puzzle/wedding present for my brother-in-law.

Beware Of the New Garmin

At Sun-N-Fun I was talking to several of the ADSB vendors about integration of their equipment with the Garmin G430W and they said they were waiting on Garmin to support them due to Gamins proprietary protocols , and then I talked with the Garmin folks who said NEVER, they would only interface with their own ADSB units, and their own Weather equipment. The arrogance clearly displayed left no doubt this was a new chapter in Garmin company policy. So I believe we will see less Garmin avionics equipment that will connect to Non-Garmin equipment and less published interface support from Garmin in coming years, not more. I now believe Garmin wants to become the Apple of the Avionics world and they will do this by making equipment that has as little Non-Garmin interfaces protocols or capability as they can get away with to force us to Buy only GARMIN equipment.
To stop this assault the experimental aviation community has 2 options, beg the FAA to require that manufactures of products the FAA approves publish interface protocols and use common interfaces to support avionics interoperability (most unlikely) or the EAA community stop buying from manufactures who do not support interoperability with other modern avionics and who don't publish complete interface protocols. So those of you buying into Garmin in the future will likely be doing so for the long term whether you want to or not, and it will be at a premium price. This is fine as long as you fully understand what you are buying into (all pilots have lots of $$-Right!!).
If this is not for you then let your feet vote (and send a message) by looking and buying from the great Experimental avionics manufactures we are blessed with who believe in interoperability and who publish and support workable interfaces that allow us to interface the great equipment options available. And maybe King or some other commercial avionics manufacture can step-up and fill the Void Garmin will be leaving behind.
To start off I think we should rate each piece of avionics that is being sold with some type of Interface and protocol rating available to all, so the EAA community can clearly understand what the truth is for interfacing the equipment with other avionics. We could call it ?WikiAvionics?. There are probably a lot of victims who have invested thousands of dollars buying interoperability where none existed, and then either paid for its creation or gave up.
But Garmin can always change, lets see?

background

20 years mixed signal design both hardware and software for the broadcast and entertainment industry. Everything from 8-bit MIDI controllers to 32-bit network enabled controllers.
Currently half way through Airframe class (which is what has slowed the plane and CANaero development)

Another hacker here.
Worked with a lot of embedded programming. And all sorts of protocols.
Now doing mobile development on iphones and androids. And had a start of a open source efis project in the works, but life keeps getting in the way. Got as far as the ADHRS programming.

I'll help how I can.

Chris.

hpmicrowave said:

At Sun-N-Fun I was talking to several of the ADSB vendors about integration of their equipment with the Garmin G430W and they said they were waiting on Garmin to support them due to Gamins proprietary protocols , and then I talked with the Garmin folks who said NEVER, they would only interface with their own ADSB units, and their own Weather equipment. The arrogance clearly displayed left no doubt this was a new chapter in Garmin company policy. So I believe we will see less Garmin avionics equipment that will connect to Non-Garmin equipment and less published interface support from Garmin in coming years, not more. I now believe Garmin wants to become the Apple of the Avionics world and they will do this by making equipment that has as little Non-Garmin interfaces protocols or capability as they can get away with to force us to Buy only GARMIN equipment.
To stop this assault the experimental aviation community has 2 options, beg the FAA to require that manufactures of products the FAA approves publish interface protocols and use common interfaces to support avionics interoperability (most unlikely) or the EAA community stop buying from manufactures who do not support interoperability with other modern avionics and who don't publish complete interface protocols. So those of you buying into Garmin in the future will likely be doing so for the long term whether you want to or not, and it will be at a premium price. This is fine as long as you fully understand what you are buying into (all pilots have lots of $$-Right!!).
If this is not for you then let your feet vote (and send a message) by looking and buying from the great Experimental avionics manufactures we are blessed with who believe in interoperability and who publish and support workable interfaces that allow us to interface the great equipment options available. And maybe King or some other commercial avionics manufacture can step-up and fill the Void Garmin will be leaving behind.
To start off I think we should rate each piece of avionics that is being sold with some type of Interface and protocol rating available to all, so the EAA community can clearly understand what the truth is for interfacing the equipment with other avionics. We could call it ?WikiAvionics?. There are probably a lot of victims who have invested thousands of dollars buying interoperability where none existed, and then either paid for its creation or gave up.
But Garmin can always change, lets see?

Click to expand...

I think that this in an uncalled for criticism of Garmin. Garmin has been very supportive of the FIX intiative and is bending over backwards to work with me on the homologation of protocols. I'm filtering and brokering information flow from the vendors who have chosen to participate.

Don't confuse the certified world with our world. They are serious about cooperation and interoperability with out stuff because if they don't, somebody else will.

I have been a bit disappointed with some of the other EFIS vendors who have been invited to participate but have chose not too. Maybe it was the conflict of SNF and the backlog of work following.

V

Brantel said:

It may help the others participating in this thread if we would all give a brief rundown of what our experience is related to this project.

Click to expand...

I've been in industrial controls for almost 20 years. Most of that time in Offshore Oil and Gas Production. I'm familiar with most PLC's but most of my experience is with Allen Bradley products. I've used DH+, Modbus, RIO, Foundation Fieldbus, ControlNet, DeviceNet and probably half a dozen other protocols that I can't think of.

I can program in C, C++, Ruby, Python, Lua, Fortran (but don't tell anybody), VB, VBA, Assembly, etc. I've built a few micro controller circuits along the way and programed them is C and Assembly.

I'm a fan of open source software and I've been using Linux for 14 years. I'm looking forward to helping to develop some open communications standards for aviation. Let's git 'er done!

Birkelbach said:

I've been in industrial controls for almost 20 years. Most of that time in Offshore Oil and Gas Production. I'm familiar with most PLC's but most of my experience is with Allen Bradley products. I've used DH+, Modbus, RIO, Foundation Fieldbus, ControlNet, DeviceNet and probably half a dozen other protocols that I can't think of.

I can program in C, C++, Ruby, Python, Lua, Fortran (but don't tell anybody), VB, VBA, Assembly, etc. I've built a few micro controller circuits along the way and programed them is C and Assembly.

I'm a fan of open source software and I've been using Linux for 14 years. I'm looking forward to helping to develop some open communications standards for aviation. Let's git 'er done!

Click to expand...

As the defactor moderator of this thread, my background is more hardware than software, although I can write assembly language in my sleep (this is not an exaggeration).

My background is telecom, datacom, marketing, mergers&acquistions R&D and industry standards (author and contributor). 25+ years in telecom/datacom, primarily with PMC-Sierra. Several related patents including some fundamental to ATM networks and Ethernet.

My role here is as a facilitator as opposed to a technical expert, although I can do that when necessary. I invite as much productive participation as possible, and when we are done with the initial hit of the FIX protocols, I really like the idea of the simple CAN protocol. I'm not sure the existing vendors will participate right away, though. They are not about to re-engineer their systems. Perhaps for the 3rd generation, though.

Vern

vlittle said:

I'm not sure the existing vendors will participate right away, though. They are not about to re-engineer their systems. Perhaps for the 3rd generation, though.

Click to expand...

True. I doubt that they would change hardware right away to utilize a CAN based protocol, but an RS-232 based protocol would be a firmware update. If we are smart about how we design the RS-232 version of FIX (can we call it PRE-FIX? please, please please) then a translator to a CAN based version should be quite easy.

I updated the list of data points on SourceForge. I added my idea of an ASCII identifier and played around with some formats and data types. The document is not well described but I hope its a good starting point. There is no pride of authorship. Please go get it and make comments. It's here...

https://sourceforge.net/projects/fix-project/files/

ksauce argued for a binary protocol. Let me argue the other way just for the sake of discussion. There are several advantages to an ASCII protocol, the most obvious is that it can be easily read by a human. The main disadvantage (as has been discussed) is efficiency. I wonder how much we'll miss the efficiency. The baud rates that we are talking about (28k, 56k, 115k) are pretty fast in the grand scheme of things. Also, since RS-232 is inherently point-to-point there will not be that much data since it will be produced from a single source.

Another advantage is how easily ASCII protocols can be logged with a simple terminal emulator and spreadsheet. If each data point is separated by commas and terminated with a carriage return then moderately computer savvy users will be able to log the data, open it in a spreadsheet and graph it, without having to know the intimate details of the protocol.

Also byte ordering and data typing issues don't have to be dealt with.

CAN will all but require a binary protocol. There are only 8 bytes available for data.

We need to start seriously discussing the particulars of this thing if we are going to get it done. Would it be helpful to schedule an IRC session? A serial, producer / consumer, point-to-point protocol is not terribly difficult to implement once it is described but getting agreement on the description is not easy. Should we have a benevolent dictator? Vern?

As a heads up, I am actively working at resolving the issues in a common set of protocols right now that meet the short term goals.

The vendors who are working with me are quite cooperative and we are fixing some know bugs in the definition and trying to get some changes made that everyone will support.

They are not participating in this forum because they prefer the focus of a narrow definition and deterministic time line to product release, whereas the forum has taken on a longer-term initiative at this point.

Nevertheless, once there is some agreement from the vendors, the information will be posted on the FIX site.

In the mean time, if anyone has refinements on the protocols that are currently posted on the site, now is the time for input. I can broker the information to the vendors and see if agreements can be made.

Thanks, Vern

i myself am in favor of ASCII protocols, as they are much easier to interpret, log and process using simple tools like excel or vb.net or even just a notepad. pure efficiency should rarely be the limiting factor in our cases, especially when using higher baud rates.
also, it's very easy to immediately grasp whether one receives data that makes sense or not, whether it's the right type/format in a realtime stream etc...

as to our project:
we've developed an auxiliary flight control unit (similar to the one in an airliner) to make up for the lack of discrete rotary buttons on the advanced flight systems efis. through a serial protocol (which is still under development / about to be implemented) the unit controls/receives information regarding heading bug, selected altitude, which type of navigation mode and so on...

technically, the unit could work with any other higher-end efis that has functionality for flight mode selection/guidance both lateral and vertical. no decision yet on who would make it, and if this is ever going to become a product, it was mainly an HMI improvement we really wanted, so we built two prototypes. hardware is atmel AVR based. one unit is with afs for development and either they're going to keep it or alternatively it's already promised to another rv builder.

my background is computer geek from 5th grade onwards, doing anything from flightsimming to programming to some 3d modelling. still do some programming projects for fun, but nothing serious these days other than for the airplane. the most serious work in the domain has been asp/web/database connection stuff in the past. not much of use in reference to the airplane for that however. and not much to do with serial protocols either ;-) the flight control unit, although it is my brainchild was mostly built (and to perfection) by my brother (micro/mechanical engineer) and another great buddy (electrical engineer). only involved in the firmware programming and testing again (C).

a picture can be found here:
http://www.flyvans.com/wordpress/wp-content/gallery/2010_09_11_noisetest/p1040660.jpg
the unit is the wide one in the top center of the panel.


also, another protocol that might be nice to take into the fix collection is the FLARM traffic avoidance protocol:
http://www.flarm.com/support/manual/FLARM_DataportManual_v5.00E.pdf
flarm is a broadly used collision avoidance tool (stemming from the glider scene) in europe, that outputs gps data interweaved with traffic info if present.


rgds, bernie

It seems that most are in favor of ASCII and I do agree with the idea that efficiency might not be much of a concern at higher bandwidths. As has previously been pointed out, CAN limits us to an 8-byte payload. That was my major reason for supporting binary.

Seeing as it seems that what we've been discussing here could wind up being a next generation (or after that) protocol, perhaps we should bypass CAN protocols entirely and go straight for a TCP/UDP based protocol. Ethernet is certainly more prevalent than CAN in the consumer realm and as such would allow far more tinkerers to play around with the data. For those of us interested in playing with Arduino, SparkFun lists the Ethernet shield for $1 more than the CanBus shield so cost is a wash. Ethereal would make sucking up and exporting the data trivial. TCP/UDP also greatly increases the payload and bandwidth. Then there's the possibility of wifi (oh my!)

Phil has done some great work starting the framework. I might suggest that instead of breaking the groupings into 100s we increase to groups of 1000 (or more) just in case.

I think ultimately we will have Ethernet for some things. I can see a mixture of RS-232/ASCII, CAN/Binary and TCP/Whatever. TCP is so easy that any protocol that we come up with for RS-232 or CAN would be very simple to implement on TCP.

I wasn't advocating using ASCII and CAN. I don't think you have much of a choice with CAN, but to go with binary. There is no question that this would be much more complex than a simple RS-232/ASCII approach, but once we build a box and some software (I intend to open source anything that I dream up in this area) it'll just get easier and easier to add features. More than anything I just wanted to use this as an excuse to learn CAN.

The reason that I separated them out by 100's is because the base type of a CAN frame only has an 11 bit identifier so that gives us 0 - 2047. If we go with the extended frame then we get 29 bits which is in the 500 million range. Due to the way CAN works, a base frame has a higher priority than an extended frame. Perhaps we put high priority data (pilot controls and critical flight data) in base frames and lower priority data in extended frames. What do you think? I plan on spending some time on the list this weekend. I've already thought of some changes in priorities and thought of some other parameters that might be needed.

A CAN controller and transceiver can be added to a microcontroller for less than 5 dollars.

I would love to see Ethernet in our airplanes at some point. Imagine weather data boxes with NEXRAD radar that can produce that data for many different types of display units. How 'bout Wifi so your plane can talk to the hangar? You could monitor the battery charger, download logbook data or upload flight plans over the internet. Ethernet will definitely have a place in that.

Skyview and AFS already have Ethernet ports correct? Do any of the others?

Brantel said:

Skyview and AFS already have Ethernet ports correct? Do any of the others?

Click to expand...

Yes, the AFS units have 1 Ethernet port to allow dual screens to communicate with each other. A hub can be used to connect more than 2 if needed.

GRT HX's have an ethernet port as well.

Dynon Skyview, CHECK
AFS, CHECK
GRT HX, CHECK

Sounds like we are well on our way with most EFIS's supporting Ethernet.

How about MGL, TT and Garmin?

I am also a huge fan of Ethernet for a long term solution. Very small industrial switches are readily available, tons of off the shelf hardware available, tons of possibilities with the uController world, most of the hard work is already done at the hardware level for error checking and fault tolerance, high bandwidth available, multiple masters, etc. etc. etc.

It seems most of the manufacturers at least have the physical port. Who knows what the next generation will have?

In any case, I think it more important for our protocol to be good for at least a decade. I think basing the protocol on ethernet would give us that possibility.

Most of us (on this thread anyway) seem to love the idea of ethernet in our avionics because of the amazing possibilities. I think most of us agree it would be a killer feature; however, the same might not be the case for the vast majority of experimental aviators. If the demand from the masses is there, the manufacturers will likely show an interest in it. If not, we've all been part of a fascinating academic exercise.

So before we fall into the classic trap of building a solution to a problem no one has, maybe we should see what the interest is among the potential end users. I'll start a poll and see what kind of interest it generates. This will be completely unscientific, but it might give us an idea of how many people want their equipment to talk.

A Question of Units

I am working on the list of parameters and priorities for CAN-FIX. I am rearranging some of the priorities and adding some groups and adding some more parameters. If anybody has anything that I have forgotten or comments on what I have done thus far, please let me know.

I also have a question about units. Should everything be in metric? (meters, meters/sec, deg C, etc) or do our friends overseas tend to use the same units that we do over here in the U.S.? I don't mind specifying the protocol to communicate altitude in meters and then converting at the display, but it'd be a shame if most of the world uses feet for altitude anyway? I'm just not sure what the most common units are. Any help here would be appreciated.

Some that I'm stuck on...

Altitude (feet or meters)
Distance (meters, nm)
Speed (meters/sec, km/hr, knots)
Pressure Altitudes (bar, kPa, inHg, ...)
Pressures (kPa, psi, ...)
Temperature (probably deg C on this one)
Flow and quantities (liters or gallons?)
Weight / Force (lbs, N, kg)
...

It is admitted that the metric system is far superior to the Imperial system from a mathematics and engineering standpoint, but in this case I think it'd be better to simply reduce the number of conversions in the system. If it seems a wash I'll probably go with metric units but if everybody uses the same (i.e. I'm pretty sure knots is fairly universal) then perhaps it makes sense to stick with that.

FIX 1.0

The FIX 1.0 specification is currently in final review by the respective EFIS manufacturers who are participating in this effort.

It is a transmit-only RS-232 based protocol for sending air data and engine data, as appropriate for data loggers and listen-only avionics devices. Information will be made available shortly for adding GPS and system status information.

The FIX website has not yet been updated. Once the final reviews have been completed, I'll publish the specification, with formal version control.

I would expect some revisions to the specification as data field interpretation is clarified. Nevertheless, the effort to have some commonality between EFIS systems is bearing fruit.

Thank you to both Garmin and Dynon for allocating resources to this project and their willingness to share proprietary information for the good of the industry. Once the FIX protocol is published, I invite other vendors to consider supporting the formats as well.

Thanks,
Vern

Have you looked at the "Chelton Format"? The Chelton EFIS systems have been getting Engine and Air Data for years over RS-232. The AFS, GRT, EI, Chelton, and Vertical Power all use this format to send or receive engine and air data.

Have you been able to get Garmin to give you the RS-232 serial TIS traffic format from the GTX-330 or the Crossfill data format so that the 430W can receive a flight plan?

The AF-5600 has a CAN-bus interface on the DB-15 connector.

Rob Hickman
Advanced Flight Systems Inc.

Plan for more than TX only

It would be great if the FIX protocol was based on a bi-directional standard. I realize that EFIS manufactures may never open their systems to receive data but many smaller devices might. If this protocol does come into being I would love to create a FIX to CANaerospace bridge so intelligent third party devices like trims, flap controllers, power switches etc would have access to all the EFIS data. Perhaps then simple things like flap and trim position could be accepted back to the EFIS in future releases.

Birkelbach said:

I am working on the list of parameters and priorities for CAN-FIX. I am rearranging some of the priorities and adding some groups and adding some more parameters. If anybody has anything that I have forgotten or comments on what I have done thus far, please let me know.

I also have a question about units. Should everything be in metric? (meters, meters/sec, deg C, etc) or do our friends overseas tend to use the same units that we do over here in the U.S.? I don't mind specifying the protocol to communicate altitude in meters and then converting at the display, but it'd be a shame if most of the world uses feet for altitude anyway? I'm just not sure what the most common units are. Any help here would be appreciated.

Some that I'm stuck on...

Altitude (feet or meters)
Distance (meters, nm)
Speed (meters/sec, km/hr, knots)
Pressure Altitudes (bar, kPa, inHg, ...)
Pressures (kPa, psi, ...)
Temperature (probably deg C on this one)
Flow and quantities (liters or gallons?)
Weight / Force (lbs, N, kg)
...

It is admitted that the metric system is far superior to the Imperial system from a mathematics and engineering standpoint, but in this case I think it'd be better to simply reduce the number of conversions in the system. If it seems a wash I'll probably go with metric units but if everybody uses the same (i.e. I'm pretty sure knots is fairly universal) then perhaps it makes sense to stick with that.

Click to expand...

we use a mixed system in aviation in western europe:
- knots for airspeed
- NM for distances
- ft for altitude
- hPa for pressure altitude
- pressures depending on engine either psi or bar, bar for tires e.g.
- volume mostly in liters, but sometimes gallons (american built planes)
- temperatures mostly in ?C, but some engine temps in ?F (lycoming)
- weight almost always in kg.

gliders use metric only.

bernie

Add MGL to that list as well.
The Chelton format can be selected onto one of our EFIS RS232 ports. It was originally added to support the VPX.

Rainier

N401RH said:

Have you looked at the "Chelton Format"? The Chelton EFIS systems have been getting Engine and Air Data for years over RS-232. The AFS, GRT, EI, Chelton, and Vertical Power all use this format to send or receive engine and air data.

Have you been able to get Garmin to give you the RS-232 serial TIS traffic format from the GTX-330 or the Crossfill data format so that the 430W can receive a flight plan?

The AF-5600 has a CAN-bus interface on the DB-15 connector.

Rob Hickman
Advanced Flight Systems Inc.

Click to expand...

flyvans.com said:

we use a mixed system in aviation in western europe:
[...]
gliders use metric only.

bernie

Click to expand...

Except here in the UK where they use knots for horizontal and vertical speed and feet for altitude.

Oh wait, you said Europe. Never mind.

N401RH said:

Have you looked at the "Chelton Format"? The Chelton EFIS systems have been getting Engine and Air Data for years over RS-232. The AFS, GRT, EI, Chelton, and Vertical Power all use this format to send or receive engine and air data.

Have you been able to get Garmin to give you the RS-232 serial TIS traffic format from the GTX-330 or the Crossfill data format so that the 430W can receive a flight plan?

The AF-5600 has a CAN-bus interface on the DB-15 connector.

Rob Hickman
Advanced Flight Systems Inc.

Click to expand...

I have not reviewed the Chelton format because it is not publically available. The objective of FIX is to provide a common, publically available format for broadcasting air and engine data (among other things). It has the support of Garmin and Dynon right now, but their are a few vendors have explicitly not supported it.

Certainly, if Chelton or vendors who support Chelton wish to partcipate, it's not too late for input. I've included the concept of code-points aka escape sequences for delineating manufacturers and types of data so that multiple data sentences can be placed on the same data link or a particular data sentence can be extracted just by looking for these code-points.

Originally, this was a simple wrapper around existing sentences to allow this delineation and multiplexing, and that in principal will work with any existing format.

Recent achievements, however, is that some vendors have agreed to cooperate on the definition of the internal format so that data fields and interpretations are identical or similar between vendors. While not an absolute requirement, this makes the development of external devices (such as data loggers and hardware boxes) easier.

I've been following the path of least resistance by working with the vendors who are motivated for this to happen. I invite any vendor who wishes to participate to do so. All it requires is a bit of manpower and a willingness to share protocol information.

Thanks, Vern

MGL EFIS data feet protocol

We have been working for some time on a EFIS data feed, mainly intended for a flight data recorder ("Black box").
I have uploaded a beta release of the G2 EFIS that supports messages 1,2 and 3 (Primary flight, GPS, attitude) of the specification available for download at:

www.MGLAvionics.co.za/Docs/MGL EFIS data feed.pdf

The G2 update is available on the G2 Beta page at www.MGLAvionics.co.za

The data feed can be enabled in the "Serial port routing and allocation" menu onto any available port.

While the data feed is intended for a flight data recorder, it is very comprehensive and easily usable for other purposes and herewith placed in the public domain.
A demo application that includes source code will be made available within the next few days. The demo application runs on a Windows system using a RS232 port (via USB is OK) and it shows the data received from the various messages.

Rainier
CEO MGL Avionics