It would be very wonderful if the Inter-Display link serial protocols is documented, so us tech users that create our own interfaces/Android apps can talk to GRT devices (HXr). Even better is having the bluetooth dongle send all the data, which I believe is in the works but on a smaller scale (and only 1 way communication). Won't be able to send any commands to the HXr.
Example 1: My tablet program will talk to VPX to turn on devices (lights, pumps, air vents, etc). HXr is already using that communication port, so if I could just tell the HXR to turn on the VPX device for me, it saves me from tapping into the VPX serial link. To get around this, I will have to add a CMOS Quad bilateral switch, so I stop the HXR to VPX communication, add my own command to VPX, then resume HXR to VPX link.
Example 2: At night I'll dim my tablet, which would send the dim command to the HXR/Mini using inter-display link. At the same time, if I dimmed the screens using the knobs, my tablet would read the inter-display data and adjust accordingly.
Example 3: My engine controller generates the EIS information. Instead of trying up the "I'm running out of serial ports", I could send the EIS data using the inter-display serial link. Basically the one inter-display serial link (or Ethernet link), would satisfy most of the serial port devices.
I'm probably pretty rare in this request, but I'm going to develop an app like you see in cars, where you can control the heat, lights, entertainment, etc, from a tablet. I went with GRT over everyone else because I fully support any company that is open source. Like Android.
Inter-Display link protocol documented
Re: Inter-Display link protocol documented
Bump. Just wondering if there is any bluetooth or Inter-Display documentation ?
I'd like to get my Body Control Module that I'm building to communicate with HXR.
ie. I dim my cabin lights, send the same dimming level through Inter-Display link. Just like you would if you dimmed the mini, it dims the HXR via serial link.
For the future, I'm sure the bluetooth route would be easier to document/implement. I might be a one-off customer looking for this info, but it would be really really cool to interface my android tablet program with HXR.
-Matt
I'd like to get my Body Control Module that I'm building to communicate with HXR.
ie. I dim my cabin lights, send the same dimming level through Inter-Display link. Just like you would if you dimmed the mini, it dims the HXR via serial link.
For the future, I'm sure the bluetooth route would be easier to document/implement. I might be a one-off customer looking for this info, but it would be really really cool to interface my android tablet program with HXR.
-Matt
MolsonB wrote:It would be very wonderful if the Inter-Display link serial protocols is documented, so us tech users that create our own interfaces/Android apps can talk to GRT devices (HXr). Even better is having the bluetooth dongle send all the data, which I believe is in the works but on a smaller scale (and only 1 way communication). Won't be able to send any commands to the HXr.
Example 1: My tablet program will talk to VPX to turn on devices (lights, pumps, air vents, etc). HXr is already using that communication port, so if I could just tell the HXR to turn on the VPX device for me, it saves me from tapping into the VPX serial link. To get around this, I will have to add a CMOS Quad bilateral switch, so I stop the HXR to VPX communication, add my own command to VPX, then resume HXR to VPX link.
Example 2: At night I'll dim my tablet, which would send the dim command to the HXR/Mini using inter-display link. At the same time, if I dimmed the screens using the knobs, my tablet would read the inter-display data and adjust accordingly.
Example 3: My engine controller generates the EIS information. Instead of trying up the "I'm running out of serial ports", I could send the EIS data using the inter-display serial link. Basically the one inter-display serial link (or Ethernet link), would satisfy most of the serial port devices.
I'm probably pretty rare in this request, but I'm going to develop an app like you see in cars, where you can control the heat, lights, entertainment, etc, from a tablet. I went with GRT over everyone else because I fully support any company that is open source. Like Android.
Re: Inter-Display link protocol documented
The Bluetooth link is documented now, but it doesn't contain any of the interfaces you want. It's completely separate from the inter-display link. It only does what's needed to make our app work, like AHRS and GPS data, flight planning, COM frequencies and volume controls. It doesn't have dimmer or VPX controls or an EIS input. To do any part of what you want, you'd still need the inter-display link at this point.
If you want to try the inter-display link, the framing is based on PPP framing, including the 16-bit FCS.
Within the frame data:
8-bit source ID (0=none)
8-bit destination ID (255=broadcast)
8-bit TTL
8-bit packet type
variable packet data
The dimmer is set using packet type 2 (STATE) with data:
18=x\0
This is a string where x is a number from 0 to 255. The \0 is a required NUL character.
This would be enough to send/receive the dimmer, but the display will complain about the link not working unless it gets regular HELLO packets.
Serial and Ethernet use the same format, including the framing.
The serial link is a chain, so it's expected that each node forwards packets that don't match its ID and haven't expired (TTL).
Ethernet uses UDP and TCP port 10001, network 192.168.0.0/16. Use IP 192.168.0.ID.
Every node is expected to send a HELLO packet (type=0) at least once every 10 seconds.
Ethernet sends HELLO as a UDP broadcast as well as to each TCP connection.
On Ethernet, the device with the lower IP address will attempt to make a TCP connection to the UDP HELLO source.
All other data only goes over the TCP connection.
The HELLO packet includes:
8-bit link version = 1
16-bit display serial number (just set to zero)
If you want to try the inter-display link, the framing is based on PPP framing, including the 16-bit FCS.
Within the frame data:
8-bit source ID (0=none)
8-bit destination ID (255=broadcast)
8-bit TTL
8-bit packet type
variable packet data
The dimmer is set using packet type 2 (STATE) with data:
18=x\0
This is a string where x is a number from 0 to 255. The \0 is a required NUL character.
This would be enough to send/receive the dimmer, but the display will complain about the link not working unless it gets regular HELLO packets.
Serial and Ethernet use the same format, including the framing.
The serial link is a chain, so it's expected that each node forwards packets that don't match its ID and haven't expired (TTL).
Ethernet uses UDP and TCP port 10001, network 192.168.0.0/16. Use IP 192.168.0.ID.
Every node is expected to send a HELLO packet (type=0) at least once every 10 seconds.
Ethernet sends HELLO as a UDP broadcast as well as to each TCP connection.
On Ethernet, the device with the lower IP address will attempt to make a TCP connection to the UDP HELLO source.
All other data only goes over the TCP connection.
The HELLO packet includes:
8-bit link version = 1
16-bit display serial number (just set to zero)
Re: Inter-Display link protocol documented
Thank you Jeff for your explanation. This will give me something to play around with this summer. I'm un-familiar with the TTL bit, that adds some type of expiry to the packets? Is your header byte 0xFE? This might be asking for a lot, could you just display one full 'Hello' transmission?
This all comes down to trying to get more serial ports out of 1 HXR & Mini. All mine will be filled up and still need a few more ports. Have you thought about adding a 'black box' that connects via Ethernet and just has a bunch of serial ports? Any device that is compatible with the interlink transmissions (EIS, VPX, Trig, etc) can go there, freeing up ports on HXR. Or think getting a bunch of USB -> serial port cables might be the way to go (if supported in software down the road)?
Happy New Year.
-Matt
This all comes down to trying to get more serial ports out of 1 HXR & Mini. All mine will be filled up and still need a few more ports. Have you thought about adding a 'black box' that connects via Ethernet and just has a bunch of serial ports? Any device that is compatible with the interlink transmissions (EIS, VPX, Trig, etc) can go there, freeing up ports on HXR. Or think getting a bunch of USB -> serial port cables might be the way to go (if supported in software down the road)?
Happy New Year.
-Matt
Re: Inter-Display link protocol documented
We are considering an Ethernet I/O box for future hardware. We only support ADS-B on USB serial right now.
The TTL limits the number of hops the packet can take, therefore the number of displays the packet can go through. The serial link is a loop, so it limits the serial traffic if there is some kind of misconfiguration or data corruption.
The TCP stream has the same framing as the serial connection.
The UDP packets do not have frame flags or byte escaping.
HELLO
7e frame flag
5b vendor protocol code
01 source=1 (Primary ID)
ff destination=255 (broadcast)
0a TTL=10
00 packet type=0 (hello)
01 link version=1
00 serial number=1
01 (LSB of serial number)
94 checksum=0x7f94
7f (MSB of checksum)
7e frame flag
The UDP version of this example wouldn't have the frame flags.
The TTL limits the number of hops the packet can take, therefore the number of displays the packet can go through. The serial link is a loop, so it limits the serial traffic if there is some kind of misconfiguration or data corruption.
The TCP stream has the same framing as the serial connection.
The UDP packets do not have frame flags or byte escaping.
HELLO
7e frame flag
5b vendor protocol code
01 source=1 (Primary ID)
ff destination=255 (broadcast)
0a TTL=10
00 packet type=0 (hello)
01 link version=1
00 serial number=1
01 (LSB of serial number)
94 checksum=0x7f94
7f (MSB of checksum)
7e frame flag
The UDP version of this example wouldn't have the frame flags.
Re: Inter-Display link protocol documented
Edit. Found the correct checksum.
Re: Inter-Display link protocol documented
Hello and screen dim is working great. I don't know where is a good spot for this post on the forum as it will evolve to more questions on packets details. You can move it to where you see fit.
a) Found tiny little bug with screen dim.
ºPrimary ID 1 (Works when you change the ID from 1 to something else)
ºDim level 4
For some reason, it's added 5D after the checksum D587. Someone probably just fat fingered a ] in the code.
1)Sent predefined EIS data the normal serial port way and compared it to what the interlink shares. I can't seem to figure out what method you use to convert the fuel flow, fuel quantity, hour meter from 2 bytes to 4 bytes. Also there are 6 bytes after EGT6 and 1 byte before Tach2 that I don't know what they are. Got everything else covered.
2) The HXr send packet 0x1A every second. Anything good in there? I don't know how I did it, but the odd time I get packet 0x0B which is over 500bytes.
3) What method do you use to prevent the flag character from occurring in the frame? Bit or character stuffing? I know it doesn't like 0x7E,0x7D, but I tried replacing 7E with 7D5E and 7D with 7D5D with no luck. (Standard character stuffing)
a) Found tiny little bug with screen dim.
ºPrimary ID 1 (Works when you change the ID from 1 to something else)
ºDim level 4
Code: Select all
5B01FF0A0231383D3400687D5D
1)Sent predefined EIS data the normal serial port way and compared it to what the interlink shares. I can't seem to figure out what method you use to convert the fuel flow, fuel quantity, hour meter from 2 bytes to 4 bytes. Also there are 6 bytes after EGT6 and 1 byte before Tach2 that I don't know what they are. Got everything else covered.
2) The HXr send packet 0x1A every second. Anything good in there? I don't know how I did it, but the odd time I get packet 0x0B which is over 500bytes.
3) What method do you use to prevent the flag character from occurring in the frame? Bit or character stuffing? I know it doesn't like 0x7E,0x7D, but I tried replacing 7E with 7D5E and 7D with 7D5D with no luck. (Standard character stuffing)
Re: Inter-Display link protocol documented
a) That's not a bug. What you are seeing is the character stuffing on the 7D in the checksum. 68 7D becomes 68 7D 5D.
1. The engine monitor data is sent from the data as it's stored in the display based on early design decisions. Fuel flow, fuel quantity, and hourmeter are sent as standard 32-bit floats. After EGT6 are airspeed (2 byte integer) and altimeter (4 byte integer), which are not displayed by the EFIS. Volts, vertical speed, and baroset are also sent as 32-bit floats. The byte before Tach2 is a bit field. Bit 0 means the tachometer has stopped (steady at zero). Bit 1 means the fuel flow has stopped (steady at zero). Bit 2 means additional data follows for a CAN bus input.
2. Packet 0x1A 0x00 is the "NAV/COM" state packet, although it does more than just NAV/COM now. The HXr regularly shares current NAV/COM frequencies, volume levels, audio panel modes, and transponder modes. This is mostly the data that drives the boxes in the upper right corner of the main screens. Packet 0x0B shares all the limit settings (Engine Limits) for the limit comparison function when the link first starts working.
3. Standard character stuffing, as seen above. Make sure you are computing the checksum before stuffing, and also applying stuffing to the checksum bytes.
1. The engine monitor data is sent from the data as it's stored in the display based on early design decisions. Fuel flow, fuel quantity, and hourmeter are sent as standard 32-bit floats. After EGT6 are airspeed (2 byte integer) and altimeter (4 byte integer), which are not displayed by the EFIS. Volts, vertical speed, and baroset are also sent as 32-bit floats. The byte before Tach2 is a bit field. Bit 0 means the tachometer has stopped (steady at zero). Bit 1 means the fuel flow has stopped (steady at zero). Bit 2 means additional data follows for a CAN bus input.
2. Packet 0x1A 0x00 is the "NAV/COM" state packet, although it does more than just NAV/COM now. The HXr regularly shares current NAV/COM frequencies, volume levels, audio panel modes, and transponder modes. This is mostly the data that drives the boxes in the upper right corner of the main screens. Packet 0x0B shares all the limit settings (Engine Limits) for the limit comparison function when the link first starts working.
3. Standard character stuffing, as seen above. Make sure you are computing the checksum before stuffing, and also applying stuffing to the checksum bytes.
Re: Inter-Display link protocol documented
a) & 3. Doah!! It was right infront of me and didn't catch it. I have character stuffing working properly now.
1. I still have 000000000000 between EGT6 and Airspeed on the interlink packet. I'm wondering are they intentionally zero based on early design? Do the tach & fuel flow stopped bits, just stop the endurance and fuel used calculations? On a sad note, I was hoping to display engine data on my MINI after seeing it at Oshkosh. Just realized it's an extra paid option to get it
If you ever need someone to test any releases, I'm getting fairly comfortable sending interlink EIS data.
2. Ok, thanks. No need to dig into those, the EIS and VPX will keep me busy for now.
One last 2-part question before I have to put down the keyboard and go fly back down to work on building the plane.
4a) I have 4 fuel tanks (wet wings), left/right wing and front/back of wing spar. I'm going to use the HXr analog inputs to handle the fuel level probes. How hard would it be to add another tank to the tables? There's left, center, right tank. If we could add another, it would help us 4 tank people out (Left Front, Left Back, Right Back, Right Front)
4b) Speaking of analog inputs, the HXr can send them via interlink (packet 0x04). It doesn't make sense to me. I can't see a pattern that shows what each 8 analog inputs are. I want to be able to read my fuel probes as well once the HXr processes them.
I played around with VPX interlink packets and have the right data to turn on power sources. I attached a fun screenshot of an Android app, that will bluetooth to my Teenzy3.2, which sends VPX commands to HXr via Interlink. It's how I envision your App that Greg is creating. I love this open source / experimental plane stuff, can be very creative.
1. I still have 000000000000 between EGT6 and Airspeed on the interlink packet. I'm wondering are they intentionally zero based on early design? Do the tach & fuel flow stopped bits, just stop the endurance and fuel used calculations? On a sad note, I was hoping to display engine data on my MINI after seeing it at Oshkosh. Just realized it's an extra paid option to get it
![Sad :(](./images/smilies/icon_e_sad.gif)
2. Ok, thanks. No need to dig into those, the EIS and VPX will keep me busy for now.
One last 2-part question before I have to put down the keyboard and go fly back down to work on building the plane.
4a) I have 4 fuel tanks (wet wings), left/right wing and front/back of wing spar. I'm going to use the HXr analog inputs to handle the fuel level probes. How hard would it be to add another tank to the tables? There's left, center, right tank. If we could add another, it would help us 4 tank people out (Left Front, Left Back, Right Back, Right Front)
4b) Speaking of analog inputs, the HXr can send them via interlink (packet 0x04). It doesn't make sense to me.
Code: Select all
5B01FF09040000FFFAFFE4000000008A2B
I played around with VPX interlink packets and have the right data to turn on power sources. I attached a fun screenshot of an Android app, that will bluetooth to my Teenzy3.2, which sends VPX commands to HXr via Interlink. It's how I envision your App that Greg is creating. I love this open source / experimental plane stuff, can be very creative.
- Attachments
-
- Android screenshot
- Screenshot_2015-03-31-22-35-57.png (153.3 KiB) Viewed 59952 times
Re: Inter-Display link protocol documented
1. Looking again, after EGT6 are EGT7 through EGT9. These are copies of CHT4-6 in 9-cylinder mode. The stopped bits currently only trigger a save-state event in preparation for shutdown. The bits are set when we see 10 zero values in a row.
4a. The fuel tanks are hard coded in several places. It will take some time to add another one.
4b. Fuel level inputs would be configured as "Aux (EIS compatible)" analog inputs. The display doesn't send these unless you configure them on a Remote Channel.
4a. The fuel tanks are hard coded in several places. It will take some time to add another one.
4b. Fuel level inputs would be configured as "Aux (EIS compatible)" analog inputs. The display doesn't send these unless you configure them on a Remote Channel.