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.
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.
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).
Likewise, the Zone Collision Detection module should only send Zones that the Trackable is actively colliding (inside) with. If a Zone is not sent, it is assumed the collision is not happening and the Trackable is outside of the Zone.
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:
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 respectively:
| 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 | Header Version | UInt16 | 2 | Value = 0x0002, will increase if header changes |
| 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 | |
| ... | ... |
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.
For application specific use cases and systems which have implemented RTTrP, please visit the Systems and Applications page.
If you have written to RTTrP and would like to have a description of your implementation included under the Systems and Applications section of this website, please submit the RTTrP Implementation Form.
If you have any questions about the protocol or any information on this site, please send an e-mail using the contact form.