OGN Tracking Protocol (OGNTP)

Introduction

The description of the Open Tracking Protocol follows.

Please note it is by no mean a complete specification (in its current state).
If you have particular doubt, questions or comments feel free to send us a message and we add the appropriate description here.
Same if you spot a mistake.

Modulation

Data is sent on a GFSK (BT=0.5) modulated carrier. Bitrate is 100kbps and Manchester encoding is used thus effective bit rate is 50 kbps.
The modulation is as used by the nRF905 chip, so that the already existing demodulator can be used. However, the existing Open Tracker hardware does not use nRF905 but other RF chips and modules: SPIRIT1, CC1101 and RFM69(H)W

Preamble and SYNC pattern

SYNC pattern is used to mark the start of a packet. It should be a sequence of bits with good autocorrelation properties. It should as well be sufficiently different from other protocols to avoid misreception and/or misinterpretations of other systems.

Preamble is the bit sequence sent by the RF chip before the SYNC pattern to allow for bit-level synchronization. Different chips send possibly different preambles, thus some care needs to be taken for the reception between different RF chips to work correctly.

Radio frame

Header field width [bits] range resolution unit Description Comment
Aircraft ID (address 24 0x000000-0xFFFFFF ICAO or OGN internal
Address type 2 0 .. 3 1=ICAO, 3=OGN
Address parity 1
Emergency flag 1 Manual or automatic emergency signalling Can be based on unusual movement parameters e.q. high sink rate or high spin rate. Internal pressure/acceleration/gyroscope/temperature sensors can be involved too.
Relay count 2 0 .. 3 0 = direct, 1..3 relayed frame Counts the number of time a frame has been relayed
Other data flag 1 Other than position data Can be meteo, thermal estimate, telemetry, … when set position data structure does not apply
Custom/encrypt flag 1 Data encrypted or format known to the (dedicated) listener When this flag is set, the data part has format defined by the owner of this device (or other parties, the owner wishes to inform)
Data field position data - other formats to be defined
Aircraft type 4 0 .. 15 glider, tow plane, helicopter, etc. Look at AircraftType for constants definition. TODO: do we have a C++ header file with these constants to point to ?
Stealth flag 1
Time 6 0 .. 59 1 sec UTC second, 0x3F=out of range
Latitude 24 +/- 90 0.0008/60 deg 1.5 meter accuracy
Longitude 24 +/- 180 0.0016/60 deg 3 meter on the Equator
Altitude 14 0 .. 61432 1 .. 8 meter above Geoid or above sea level Can come from GPS or barometer (if installed)
Climb rate 9 +/- 95.2 0.1 .. 0.8 meter/sec climb/sink rate Can come from GPS or barometer (if installed)
Barometer flag 1 altitude/climb are from the barometer For trackers with a barometer and an algorithm to correlate GPS altitude with pressure
Speed 10 0 .. 766 0.2 .. 1.6 knot ground speed
Heading 10 0 .. 360 0.1 deg ground heading
Turn rate 8 +/- 47.2 0.1 .. 0.8 deg/sec
GPS fix mode 1 0=2D, 1=3D
GPS fix quality 2 0=no fix, 1=GPS, 2=D-GPS, 3=other Tracker can still transmit its (last known) position after GPS lock is lost (for whatever reason)
GPS DOP 6 GPS Dilution of Precision

The header is 4 bytes and the data portion of the radio frame takes 16 bytes.

Note: several fields have variable resolution coding, so that a greater range can be accommodated within a limited bit width while keeping relative resolution relatively constant.

Forward Error Correcting (FEC) code

For best reception range, with limited power, technique known as Forward Error Correction (FEC) can help.
By introducing additional, redundant information, transmission errors can be recovered by the receiver and the reception S/N threshold is effectively lower thus increasing the range.

Code chosen for the Open Tracker is Gallager code or Low Density Parity Check (LDPC) code. It is simple and decoding can be done by successive iterations and it accepts soft bit information from the demodulator.

The redundant information in this case is 48 bits = 6 bytes.

Packet relay

One particular feature of the Open Tracker is the capability to relay packets of other trackers.
The main goal is to relay packets of lower flying aircraft (or those on the ground) by the high flying aircraft, so the positions of those below have a chance to be caught by the ground receivers as the radio range heavily depends on the altitude.

Implementations

The protocol described here was implemented on SPIRIT1 RF chip (see the main OGN Tracker page). Then It was done as well on the CC1101 and RFM69(H)W RF chips/modules. In all cases the signals could be properly received on the DVB-T receiver, reception on SPIRIT1 and RFM69(H)W was tested as well. Some but not all combinations or reception between different RF chips have been positively tested, others are awaiting tests.

For all those implementations the Manchester encoding was done in software, not by the RF chip hardware. This gave more flexibility in programming the chip and on reception allowed for detections of transmission errors which made the error correction logic more efficient.

The fine details

Please for now, refer to the source - see the ogn.h in our GIT repository.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License