Login    Register
  • Author
    Message

Re: Inter-Display link protocol documented

Postby GRT_Jeff » Tue Oct 03, 2017 12:50 am

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.
GRT_Jeff
 
Posts: 579
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Postby MolsonB » Thu Oct 05, 2017 2:38 pm

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?
MolsonB
 
Posts: 74
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Postby GRT_Jeff » Sat Oct 07, 2017 5:11 am

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
GRT_Jeff
 
Posts: 579
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Postby MolsonB » Sat Oct 07, 2017 11:25 pm

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

Re: Inter-Display link protocol documented

Postby MolsonB » Wed Oct 18, 2017 7:08 pm

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: 74
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Postby MolsonB » Thu Oct 19, 2017 1:35 pm

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.
MolsonB
 
Posts: 74
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Postby GRT_Jeff » Fri Oct 20, 2017 4:23 am

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).
GRT_Jeff
 
Posts: 579
Joined: Tue Dec 11, 2012 12:11 am

Re: Inter-Display link protocol documented

Postby MolsonB » Mon Oct 23, 2017 9:34 pm

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: 74
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Postby MolsonB » Sun Jan 28, 2018 2:49 am

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.
MolsonB
 
Posts: 74
Joined: Fri Apr 10, 2015 1:53 am

Re: Inter-Display link protocol documented

Postby GRT_Jeff » Tue Jan 30, 2018 3:43 am

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.
GRT_Jeff
 
Posts: 579
Joined: Tue Dec 11, 2012 12:11 am

PreviousNext

Return to Product Feature Requests

Who is online

Users browsing this forum: No registered users and 1 guest