The Real Time Tracking Protocol (RTTrP) is a suite of protocols developed to transmit tracked motion information between systems.

RTTrP is comprised of two separate protocols which share a common header:

Note: As of August 19th, 2014, Tracking Protocol is renamed to RTTrPM, On-the-Fly Merging (OTFM) is renamed to RTTrPL and common elements shared between the protocols are now named RTTrP.

Data Structures

RTTrP is simply a packet header, which encapsulates RTTrPL, and RTTrPM packets. An RTTrP Packet contains any number of packet modules, either Output modules (RTTrPL) or Trackable modules (RTTrPM), but not both. Each type contains other packet modules nested within, which contain further information.

For RTTrPL, Output modules contain a number of nested modules which contain information about specific DMX universes and the channels being controlled. Whereas for RTTrPM, Trackable modules contain other modules which provide information about the motion of a specific tracked object.

General Information

Real-Time Tracking Protocol - Motion

RTTrPM is the protocol that is used to stream to third party listeners that are interested in the position and orientation of a tracking point, relative to the origin of the coordinate system (as defined by the user). The RTTrPM protocol should be sent at a fixed rate. However, if there is no motion data available, then RTTrPM should stop sending (unless a form of heartbeat is implemented).

Real-Time Tracking Protocol - Lighting

RTTrPL is used to stream lighting fixture and DMX information to third parties interested in overwriting fixture DMX values sent from a lighting console, for control over said fixtures. RTTrPL output should be triggered by motion data, DMX input, show starting/stopping, and third party requests. As such, it should not send at a fixed rate like the RTTrPM protocol.

The Integer Signature field is always one of two values to define Endianness of the integer type fields in a packet. To distinguish an RTTrPL packet from an RTTrPM packet, the Floating Point Signature Fields should be set to the following:

  • RTTrPM: Big Endian - 0x4434, Little Endian - 0x3444
  • RTTrPL: Big Endian - 0x4334, Little Endian - 0x3443

Lastly, the context field is a user definable field that can be used for any purpose.


The RTTrP Repository has stub code available which contains packet definitions of both RTTrPM and RTTrPL. Please visit the following for Python and C++ code respecitvely:

Modules and Packet Structure

Real-Time Tracking Protocol (RTTrP) Header

Field Name Type Size (bytes) Description
0 Header / Integer Signature UInt16 2 Big Endian: 0x4154, Little Endian: 0x5441
1 Header / Float Signature UInt16 2 Big Endian: 0x4434 (RTTrPL) / 0x4334 (RTTrPM), Little Endian: 0x3444 (RTTrPL) / 0x3443 (RTTrPM)
2 Version UInt16 2 Value = 0x0002
3 Packet ID UInt32 4 Packet sequence number
4 Packet Format UInt8 1 Value = 0x00 (Raw), 0x01 (Protobuf), 0x02 (Thrift)
5 Size UInt16 2 Size of packet in bytes including header
6 Context UInt32 4 User definable
7 Number of Packet Modules UInt8 1
8 Packet Module 0 Packet Module Variable
9 Packet Module 1 Packet Module Variable
... ...

Versions and Backwards Compatibility

A protocol version number is included in the RTTrP packet header. Users of previous versions of the protocol should always check the “type” field of modules, and ignore new or unrecognized module types. There can be multiple levels of modules within modules and the order of module types within a module is not guaranteed.

Systems and Applications

For application specific use cases and systems which have implemented RTTrP, please visit the following:

If you would like to have your system listed on this site, please send an e-mail using the contact form.

Tools and Resources