Inter-Display link protocol documented

GRT_Jeff
Posts: 802
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Post by GRT_Jeff »

MolsonB wrote:The addition of 'Air/Ground Transition speed', is that flag being passed on inter-display? I'm basically trying to find out when we are flying vs on the ground. Right now I'm using the GPS ground speed (better then nothing).
No. Every display checks that using its own setting and the current airspeed and ground speed.
MolsonB
Posts: 84
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Post by MolsonB »

ok Gotcha, I'll stick with ground speed from GPS.
I'm finishing up sending GPS data (0x09 0x00) to the Megasquirt ECU, is there anything in the GPS packets 0x09 0x03 and 0x09 0x04 worth while? GPS altitude?
GRT_Jeff
Posts: 802
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Post by GRT_Jeff »

09 00 -- time, date, position, speed, mag var, from current GPS source, like data in GPRMC
09 01 -- navigation data to active waypoint, like data in GPRMB
09 02 -- waypoints in active flight plan from current GPS source
09 03 -- time and date from GPS1 and/or GPS2 independent of current GPS source
09 04 -- GPS altitude and geoidal difference, fix quality, number of satellites used, from current GPS source, like data in GPGGA
MolsonB
Posts: 84
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Post by MolsonB »

Thanks Jeff for the late night reply, got what I needed.
MolsonB
Posts: 84
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Post by MolsonB »

So I'm using a Teensy 3.6 to capture the interlink data. I was having troubles if I started the HXr before the teensy, the teensy wouldn't process the serial data. The serial data was there at the pin, just nothing was happening. If I unplugged the serial cable a few times, it would catch and start reading the packets. OR if the teensy was started before the HXr.

Turns out, @ 19200 baud it was just to overloaded with VPX, GPS, COM1, COM2, Traffic and AOA data, etc being transferred. Up'd it to 38400 and all is well. I think it was the VPX data that put it over the top. The VPX is only sending it's data @ 1Hz, so not sure why the interlink is sending it so many times within the 1Hz cycle.
MolsonB
Posts: 84
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Post by MolsonB »

Can confirm it's the VPX data that is overloading the interlink display.

Simple sketch

Code: Select all

#include <Metro.h>          
Metro Serial1_TMR = Metro(1000); 

long counter;

void setup() {
  Serial.begin(115200);
  Serial1.begin(38400); 
}

void loop() {
  if (Serial1_TMR.check()) {
    Serial.println(counter);
    counter = 0;
  }
 
  if (Serial1.available()) {
    Serial1.read();
    counter++;
  }
}


@19200 baud
With COM1, COM2, GPS, Traffic and AOA turned on, the average bytes per second is ~370.
Turn on VPX, and it maxes out at 1920.

@38400 baud
Turn on VPX, and it maxes out at ~2072.
GRT_Jeff
Posts: 802
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Post by GRT_Jeff »

According to my notes, the flaps and trim status messages are output at 10Hz from the VPX. When the EFIS receives any update from the VPX (flaps/trim or one of the other status updates), it immediately schedules a DULink VPX message that contains everything. With a 137-byte DULink VPX message plus other frame data and other VPX optional features that could take up 1400+ bytes per second just for the VPX (if there is enough bandwidth to send all of the updates).
MolsonB
Posts: 84
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Post by MolsonB »

GRT_Jeff wrote:According to my notes, the flaps and trim status messages are output at 10Hz from the VPX. When the EFIS receives any update from the VPX (flaps/trim or one of the other status updates), it immediately schedules a DULink VPX message that contains everything. With a 137-byte DULink VPX message plus other frame data and other VPX optional features that could take up 1400+ bytes per second just for the VPX (if there is enough bandwidth to send all of the updates).
Correct. General device data is 1HZ and flaps/trim is 10Hz. Too bad they weren't split into 2 different packet types to save sending the device data so much. I'm guessing your hardware has better UART then Arduino and can pick up between packets when the baud rate is maxed out. Again, upping the baud rate to 38400 worked with VPX data turned on. I think I'm going to go the Ethernet route anyways in my final version instead of the serial bus, trying something new.
MolsonB
Posts: 84
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Post by MolsonB »

I got the Ethernet working with Teensy & W5500 board. The UDP packet, I don't need to send any hello's back on there, just send the hello's on TCP? I'm guessing the UDP hello packet is just to tell you what TCP ip address to connect to.
GRT_Jeff
Posts: 802
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Post by GRT_Jeff »

Correct. The UDP hello is a broadcast for units to find each other and establish a TCP connection between each unit. When the UDP broadcasts are exchanged, the unit with the lower IP address of the pair initiates the TCP connection. The EFIS will accept a connection in any order, though. You can skip sending UDP broadcasts and initiate a TCP connection as soon as you see a UDP hello if you don't want to manage accepting TCP connections and sending UDP broadcasts.
Post Reply