Skip to main content

Third Party Integration

This page is intended to describe how third party applications can integrate with the FLYsky Display, to send data to be shown on the radar.

Data Sources​

The FLYsky Display can receive data from different sources, currently the following are supported:

  • Via WIFI Network using GDL90 or NMEA protocols
  • Via Bluetooth Low Energy BLE acting as a server/peripheral, that other devices can connect and send data to a certain service/characteristic.
  • Via Bluetooth Low Energy BLE acting as a client/central, that connects to other devices and subscribes to a certain service/characteristic to receive data.

Messages Timing​

The FLYsky Display expects to receive data with a certain frequency, to be able to show the traffic information on the radar in a timely manner. The expected frequency is at least one message sequence per second, if the messages are received with a lower frequency, the FLYsky Display may not be able to show the traffic information on the radar or may show it with a delay.

If a certain target does not receive an update for more than 10 seconds, the FLYsky Display will consider that target as "lost" and will remove it from the radar. This is to avoid showing stale information on the radar.

If no HearBeat message is received for more than 10 seconds, the FLYsky Display will consider that there is no valid GPS data / source and will show a warning on the radar to indicate that there is no valid GPS data, and it will not show any traffic information on the radar until a valid HearBeat message is received again.

WIFI Network​

The FLYsky Display can connect to a WIFI Network and receive data using GDL90 or NMEA protocols. The configuration of the WIFI Network and supported protocols is done in the Settings page of the Display.

It's not advisable to have both protocols enabled at the same time, as well as having WIFI and BLE usage at the same time.

Device accepts messages that are sent in Broadcast or Unicast mode, but not in Multicast mode. When using Unicast mode, the messages must be sent to the IP address of the FLYsky Display on the local network.

WIFI GDL90​

The GDL90 protocol is a binary protocol that is used by some devices to send traffic information. The FLYsky Display can receive data in this format and show it on the radar.

By default the FLYsky Display is configured to receive GDL90 data on port 4000 using UDP transmission protocol and it expects to receive the following GDL90 messages ID's:

  • 0 - Heartbeat message, to get GPS data validity (Bit 7 of Status Byte 1).
  • 10 - OwnShip GPS position
  • 20 - Traffic Information

These three messages must exist in the data stream for the FLYsky Display to be able to show the traffic information on the radar. The GDL90 protocol has many other messages that can be used to send more information, but these three are the minimum required for the FLYsky Display to work.

A full sequence will consist of these three messages being sent at least once per second, the traffic information may not be sent in case there is no traffic to report.

The device expects to receive these messages once per second, if the messages are received with a lower frequency, the FLYsky Display may not be able to show the traffic information on the radar or may show it with a delay.

Currently when using GDL90 protocol, Mode-S/Bearingless targets are not supported to be shown on the radar since there is no standard way to send this information via GDL90 protocol, but this may change in the future if a standard way to send this information is defined and implemented by the data sources.

WIFI NMEA​

The NMEA protocol is a text-based protocol that is used by some devices to send traffic information. The FLYsky Display can receive data in this format and show it on the radar.

By default the FLYsky Display is configured to receive NMEA data on port 2000 using UDP transmission protocol and it expects to receive the following NMEA sentences:

  • $GxGGA - OwnShip GPS position
  • $GxRMC - OwnShip GPS position and speed
  • $PFLAU - FLARM NMEA HeartBeat status
  • $PFLAA - FLARM NMEA Traffic Information

These four sentences must exist in the data stream for the FLYsky Display to be able to show the traffic information on the radar, the sentences must be valid NMEA sentences (checksum validation) and with standard termination (CRLF). The NMEA protocol has many other sentences that can be used to send more information, but these four are the minimum required for the FLYsky Display to work.

The device expects to receive these messages once per second, if the messages are received with a lower frequency, the FLYsky Display may not be able to show the traffic information on the radar or may show it with a delay.

More details regarding NMEA protocol below.

Bluetooth Low Energy BLE​

The FLYsky Display can also receive data via Bluetooth Low Energy BLE, either acting as a server/peripheral that other devices can connect and send data to a certain service/characteristic, or acting as a client/central that connects to other devices and subscribes to a certain service/characteristic to receive data.

When using BLE the only supported protocol is FLARM NMEA messages, which are text-based messages that contain information about the traffic. FLYsky Display does not currently support receiving GDL90 messages via BLE, only FLARM NMEA messages.

BLE Server/Peripheral​

In this mode, the FLYsky Display acts as a server/peripheral that other devices can connect and send data to a certain service/characteristic. The FLYsky Display will have a custom service with a custom characteristic that other devices can write to send data to be shown on the radar. The data format used is FLARM NMEA messages. This operational mode is intended to be used by devices that have the capability to connect to a BLE device and send data to it like mobile phones/tablets.

The FLYsky Display has the following characteristic/services for this mode:

  • Service UUID: FFE0
    • Characteristic UUID: FFE1
      • Properties: Notify, Read, Write
      • Description: This characteristic is used to send data to be shown on the radar. The data format used is FLARM NMEA messages. At the moment only the Write property is used, but the Notify and Read properties are implemented for future use if needed.
      • Expected Data Format: FLARM NMEA messages. Standard NMEA sentence framing and checksum validation are expected. The FLYsky Display supports BLE MTU negotiation up to 256 bytes; this is optional and mainly useful for efficiency, allowing multiple complete NMEA sentences to be sent in a single BLE write/notification when the peer stack supports it.
  • Service UUID: 180F (Battery Service)
    • Characteristic UUID: 2A19 (Battery Level)
      • Properties: Notify, Read
      • Description: This characteristic is used to send the battery level of the FLYsky Display. The data format used is a single byte that represents the battery level in percentage (0-100).
  • Service UUID: 180A (Device Information Service)
    • Characteristic UUID: 2A24 (Model Number String)
      • Properties: Read
      • Description: This characteristic is used to send the model number of the FLYsky Display. The data format used is a string that represents the model number.
    • Characteristic UUID: 2A26 (Firmware Revision String)
      • Properties: Read
      • Description: This characteristic is used to send the firmware revision of the FLYsky Display. The data format used is a string that represents the firmware revision.
    • Characteristic UUID: 2A27 (Hardware Revision String)
      • Properties: Read
      • Description: This characteristic is used to send the hardware revision of the FLYsky Display. The data format used is a string that represents the hardware revision.
    • Characteristic UUID: 2A29 (Manufacturer Name String)
      • Properties: Read
      • Description: This characteristic is used to send the manufacturer name of the FLYsky Display. The data format used is a string that represents the manufacturer name.

On the advertisement data, the FLYsky Display will include the following information:

  • Local Name: Radar_xxxxxx (where xxxxxx is the last 6 characters of the FLYsky Display's Bluetooth MAC address)
  • Service UUID: FFE0

BLE Client/Central​

In this mode, the FLYsky Display acts as a client/central that connects to other devices and subscribes to a certain service/characteristic to receive data. The FLYsky Display will connect to devices that have a custom service with a custom characteristic that other devices use to send data to be shown on the radar, the FLYsky Display will subscribe to this characteristic with a notify property. The data format used is FLARM NMEA messages. This operational mode is intended to be used by devices that have the capability to act as a server to send data to other devices like Aero-Tracker, Soft-RF Based Dongles.

The FLYsky Display expects the bluetooth devices to have the following characteristic/services for this mode:

  • Service UUID: FFE0
    • Characteristic UUID: FFE1
      • Properties: Notify (mandatory), Read (optional)
      • Description: This characteristic is used to send data to be shown on the radar. The data format used is FLARM NMEA messages.
      • Expected Data Format: The data sent to this characteristic must be in the format of FLARM NMEA messages, which are text-based messages that contain information about the traffic. FLYsky Display will attempt to negotiate a higher BLE MTU value up to 256 bytes to allow multiple complete NMEA sentences to be sent in a single BLE notification when the peer stack supports it. Standard NMEA sentence framing and checksum validation are expected.

The device must advertise the service UUID FFE0 for the FLYsky Display to be able to discover it and connect to it. Once connected, the FLYsky Display will subscribe to the characteristic UUID FFE1 to receive data to be shown on the radar.

In case of Aero-Tracker an additional service/characteristic is subscribed by the FLYsky Display to get battery / LTE status information, but this service/characteristic is not required for the FLYsky Display to work, it's only used to show additional information on the radar in case of Aero-Tracker device.

NMEA Protocol​

The NMEA protocol is a text-based protocol that is used by some devices to send traffic information, can be used either via BLE Connection or WIFI. The FLYsky Display can receive data in this format and show it on the radar. The NMEA protocol has many sentences that can be used to send more information, but the FLYsky Display expects to receive at least the following sentences:

  • $GxGGA - OwnShip GPS position
  • $GxRMC - OwnShip GPS position and speed
  • $PFLAU - FLARM NMEA HeartBeat status
  • $PFLAA - FLARM NMEA Traffic Information

The $Gxxxx messages are standard NMEA 0183 sentences, and $PFxxx are custom sentences that follow the FLARM NMEA specification, but with some modifications to support additional information as described in the next section. Device supports a multitude of NMEA talker Ids as specified in NMEA 0183 spec.

A full sequence will consist of these four sentences being sent at least once per second, the FLARM NMEA Traffic Information sentence may not be sent in case there is no traffic to report. Even if GPS data is invalid, it's expected that the GPS and FLARM NMEA HeartBeat sentences are still sent with the correct information regarding GPS validity, this is to allow the FLYsky Display to show a warning on the radar to indicate that there is no valid GPS data, and it will not show any traffic information on the radar until a valid HearBeat message is received again.

NMEA messages must be valid NMEA sentences (checksum validation) and with standard termination (CRLF).

Mode-S/Bearingless targets information is supported when using FLARM NMEA, data should be transmitted according to the FLARM NMEA specification.

The device expects to receive these messages once per second, if the messages are received with a lower frequency, the FLYsky Display may not be able to show the traffic information on the radar or may show it with a delay.

In case of FLARM Traffic Information, the $PFLAA sentence contains the information about the traffic, and the FLYsky Display will show this information on the radar. The $PFLAU sentence contains the HeartBeat status of the FLARM device, it expects that the GPS field information is correct.

It also expects that the alerts are properly managed by the device sending the data by setting the correct fields in the $PFLAA and $PFLAU sentences according to FLARM NMEA specification, meaning that if the device is sending an alert for a certain target, it should keep sending that alert until the alert is no longer active, and only then it should stop sending that alert. The FLYsky Display relies on this behavior to manage the alerts and show them on the radar. Optionally the device can be configured to ignore this alert information and generate alerts internally based on the received traffic information, but this is not recommended to avoid discrepancies between the data source visualization and the radar display.

Custom NMEA fields implementation​

The display for most part supports the standard FLARM NMEA sentences, there are some modifications on how to handle certain fields derived from the AeroTracker/SafeSky implementation:

  • ID field on the $PFLAA and $PFLAU sentences is expected to be the ICAO ID of the target, this is a 6 hexadecimal digits that uniquely identifies an aircraft. This is used by the FLYsky Display to identify the targets and show the correct symbol on the radar. Currently the display supports that this field can also contain the CallSign of the target:
    • This is implemented by expecting both strings in the same field separated by a : character, for example ID:CallSign, this is to allow sending the aircraft CallSign information via NMEA sentences which is not natively supported in the FLARM NMEA specification.
    • The ID is always mandatory to be sent as a 6 hexadecimal digits, and the CallSign is optional.
    • If the CallSign is not sent, the FLYsky Display will show only the ID on the radar.
  • When the device is connected to SafeSky App and the internal Data Source is configured to SafeSky App, the field POWER on $PFLAU sentence is used to indicate to the FLYsky Display if the phone/tablet has internet connection:
    • If this field is false a popup warning shows up on the FLYsky Display to indicate that no internet connection available.
    • If this field is true the popup warning is removed.
    • This is to help users to understand that if they are not seeing any traffic information on the radar, it may be because the SafeSky App is not receiving traffic information due to no internet connection, and not because of a problem with the FLYsky Display itself.
Last updated on by Artur Vieira