ADS-L
ADS-L means Automatic Dependent Surveillance - Light. It is an electronic conspicuity protocol intended for low-cost, low-power devices, especially for aircraft that are not equipped with certified ADS-B Out installations.
ADS-L is not the same as ADS-B. It uses ADS-B-like parameter definitions where possible, but it is designed for lighter, non-certified devices and can be carried over different communication links. The currently relevant radio specification for OGN tracker work is ADS-L over the SRD860 band.
EASA recognises ADS-L as a means of electronic conspicuity for U-space access under SERA.6005(c), but ADS-L does not give IFR surveillance credit and is not a replacement for certified ADS-B, Mode S or other required avionics.
Why ADS-L exists
General aviation, gliders, microlights, paragliders, drones and vintage aircraft often cannot practically install certified ADS-B Out. ADS-L is intended to provide a common, affordable way for such aircraft to transmit their position and basic aircraft data.
The goal is interoperability: many different devices should be able to understand the same basic aircraft position message, even if they come from different manufacturers or communities.
For OGN, ADS-L is important because modern OGN-compatible trackers can transmit ADS-L in addition to OGNTP or other protocols. OGN receivers and trackers can then participate in a broader electronic conspicuity ecosystem.
Frequency bands
ADS-L over SRD860 uses two parts of the 860 MHz short-range-device spectrum:
| Band | Frequencies | Typical role |
|---|---|---|
| M-band | 868.2 MHz and 868.4 MHz | low-power, medium-rate transmissions sharing the same practical radio environment as existing 868 MHz conspicuity systems |
| O-band | 869.525 MHz | higher-power operation, with LDR and HDR variants |
EASA describes the ADS-L SRD860 frequencies as two M-band channels, 868.2 MHz and 868.4 MHz, plus one O-band channel, 869.525 MHz. EASA also gives the SRD860 power limits as 14 dBm / 25 mW ERP in M-band and 27 dBm / 500 mW in O-band.
Actual legal operation depends on the country, aircraft category, installation and applicable radio rules. Device firmware must select the correct regional frequency plan.
Why there are different bands and modulations
The bands have different regulatory and practical constraints:
- M-band has lower allowed power and is close to existing European glider/electronic-conspicuity activity around 868.2/868.4 MHz.
- O-band allows higher power but occupies a different SRD860 channel around 869.525 MHz.
- Different legacy systems already use different modulation parameters in these bands, so ADS-L adapts to more than one physical link instead of forcing a single radio waveform.
This is why ADS-L can appear in several forms. In OGN tracker firmware, the relevant practical forms are M-band MDR, O-band LDR and O-band HDR.
Physical layer summary
The following table describes the practical radio settings used by current OGN tracker firmware. It is a working implementation view, not a replacement for the official ADS-L technical specification.
| Link | Frequency | Modulation | Rate / coding | Deviation | Notes |
|---|---|---|---|---|---|
| M-band MDR | 868.2 or 868.4 MHz | 2-GFSK, BT=0.5 | 100 kchip/s, Manchester encoded, 50 kbit/s effective | +/-50 kHz | medium data rate; similar RF parameters to OGNTP/FLARM-style M-band reception |
| O-band LDR | 869.525 MHz | 2-GFSK, BT=1.0 | 38.4 kbit/s NRZ | +/-12.5 kHz | low data rate mode, compatible with the PilotAware-style O-band framing used by the firmware |
| O-band HDR | 869.525 MHz | 2-GFSK, BT=0.5 | 200 kbit/s radio bit rate in current firmware | +/-50 kHz | high data rate mode; no Manchester decoding in current OGN tracker firmware |
In the current OGN tracker receiver code, M-band MDR is Manchester decoded. LDR and HDR are treated as non-Manchester packet modes.
Channel choice and altitude-based hopping
In Europe, current OGN tracker firmware can choose between:
- channel 0: 868.200 MHz M-band,
- channel 1: 868.400 MHz M-band,
- channel 2: 869.525 MHz O-band LDR,
- channel 3: 869.525 MHz O-band HDR.
The implemented channel choice can depend on UTC second and altitude band. This spreads transmissions across time and channels, reducing collisions between nearby aircraft.
Altitude-based hopping, or ABH, is the idea of making the hopping schedule depend not only on time but also on aircraft altitude. Aircraft at similar altitudes use similar schedules and are therefore more likely to meet on the same frequency/modulation. Aircraft at very different altitudes can use different parts of the available time/frequency space, which improves capacity because not all aircraft need to listen and transmit in the same slots.
This is useful because ADS-L over SRD860 has several practical links: M-band MDR, O-band LDR and O-band HDR. A simple fixed time-based hopping plan is easy to understand, but it can leave large parts of the available channel space unused. ABH tries to recover this capacity while keeping the schedule predictable from GNSS time and altitude.
The altitude shift should be gradual. An aircraft climbing or descending should not suddenly disappear from nearby aircraft; it should remain close in schedule to aircraft at similar altitude. Extra packets or fallback transmissions can be used in special cases, for example during fast vertical movement or when compatibility with simpler receivers is required.
The exact ABH algorithm, hopping sequence and slot-timing rules should be documented separately from the packet format because they are implementation-sensitive and may evolve.
See also:
Packet overview
The current OGN tracker firmware represents an ADS-L packet as:
| Part | Size | Notes |
|---|---|---|
| Sync | 2 bytes | normally 72 4B; HDR uses 2D D4 |
| Length | 1 byte | fixed 0x18 for the 24-byte packet after sync/length |
| Version/header byte | 1 byte | protocol version and signature/key flags |
| Payload | 20 bytes | position, telemetry, info or other payload |
| CRC24 | 3 bytes | CRC over the version/header byte and payload |
For normal MDR and HDR transmission, the radio layer transmits the 24 bytes starting with the version/header byte and ending with the CRC24. Sync and fixed-length framing are handled by the radio configuration.
For O-band LDR, the current firmware adds additional pre-data bytes used by the PilotAware-style LDR framing, then appends an extra CRC8 around the transmitted ADS-L packet.
Message type
The first byte of the 20-byte payload is the ADS-L message type:
| Type | Meaning |
|---|---|
| 0x02 | iConspicuity / basic position |
| 0x42 | telemetry, information or other non-position report |
Bit 7 can indicate unicast use in the firmware structure. This page only describes the normal broadcast-style basic position packet.
Basic position packet
For message type 0x02, the current firmware uses the following 20-byte payload structure:
| Field | Size | Unit / coding | Notes |
|---|---|---|---|
| Type | 8 bits | 0x02 | iConspicuity / basic position |
| Address | 32 bits | packed address table, 24-bit address and relay flag | address is not aligned as a plain 32-bit field in the structure |
| TimeStamp | 6 bits | 0.25 s | time within the second or local ADS-L frame period |
| FlightState | 2 bits | enum | 0=unknown, 1=ground, 2=airborne |
| AcftCat | 5 bits | enum | aircraft category |
| Emergency | 3 bits | enum | current firmware comments mark 1 as OK |
| Lat | 24 bits signed | FANET-style coordinate coding | converted by firmware helper functions |
| Lon | 24 bits signed | FANET-style coordinate coding | converted by firmware helper functions |
| Speed | 8 bits | 0.25 m/s, variable resolution | max value marks invalid |
| Alt | 14 bits | meters, variable resolution, offset by -320 m | max value marks invalid |
| Climb | 9 bits | 0.125 m/s, signed variable resolution | max value marks invalid |
| Track | 9 bits | 9-bit cyclic angle | converted to degrees by track * 45 / 64 |
| SourceIntegrity | 2 bits | enum | roughly SIL-like source integrity coding |
| DesignAssurance | 2 bits | enum | roughly SDA-like design assurance coding |
| NavigIntegrity | 4 bits | enum | roughly NIC/NIC+1-like navigation integrity coding |
| HorizAccuracy | 3 bits | enum | roughly NACp-like horizontal accuracy coding |
| VertAccuracy | 2 bits | enum | vertical accuracy coding |
| VelAccuracy | 2 bits | enum | velocity accuracy coding |
| SpoofDet | 1 bit | flag | GNSS spoofing suspected |
The position payload is compact and not byte-aligned after the address field. Implementers should use the reference structures and helper functions rather than manually assembling bytes unless they are writing a formal encoder/decoder.
Address coding
The firmware stores an address table/type and a 24-bit address in the 4-byte address field.
The helper mapping to OGN address types is:
| ADS-L address table | OGN meaning |
|---|---|
| 0x05 | ICAO |
| 0x06 | FLARM |
| 0x07 | OGN |
| 0x08 | FANET, currently mapped toward FLARM in the OGN helper |
Other address tables should be documented from the official ADS-L specification before being used in a public interoperability claim.
Scrambling and CRC
The 20-byte payload is scrambled by the current firmware using an XXTEA key-zero function:
Scramble()
setCRC24()The CRC24 is calculated over the version/header byte and the 20-byte scrambled payload. A correct received packet has a zero CRC24 syndrome when checked over the 24 transmitted bytes.
For LDR mode, the firmware also appends an extra CRC8 used by the LDR framing.
Relation to OGNTP
OGNTP and ADS-L are different packet formats. A tracker may transmit both, depending on firmware configuration, regional rules and available transmit slots.
On the OGN network side, both can be decoded into aircraft position reports. This is where interoperability becomes useful: the radio packets may be different, but the resulting traffic information can be merged, displayed and forwarded in a common way.
References
- EASA ADS-L FAQ
- EASA publication of ADS-L 4 SRD860 Issue 2
- github.com/pjalocha/ogn-tracker
- github.com/pjalocha/cubecell-ogn-tracker
Open items
This page still needs:
- exact references to the official ADS-L 4 SRD860 Issue 2 clauses,
- exact bit numbering convention compared with the official document,
- full telemetry, info, flight and GNSS-status packet layouts,
- exact M-band and O-band slot timing rules,
- exact signature/key/version handling,
- receiver acceptance and relay rules.