RTTrPM
BlackTrax's real-time tracking protocol for motion data, carrying trackable centroids, orientation and per-point detail over UDP.
What it is
RTTrP is BlackTrax's real-time tracking protocol family, and RTTrPM is the motion variant that carries tracked-object data. It runs over UDP and can be configured for unicast to specific consumers or for multicast, depending on the deployment. A packet consists of a header carrying version and timing information followed by a sequence of modules, so a single packet can describe a trackable in several ways at once: a centroid position, orientation expressed as a quaternion, orientation expressed as Euler angles, and per-point or per-beacon detail where the tracking system produces it. Consumers subscribe to what they can use, which in practice means different departments read different subsets of the same stream.
Why it matters
RTTrPM is frequently the native output of the tracking system, which makes it the upstream source of truth for everything downstream, including any translation into other protocols. Two things follow from that. First, a mistake made here propagates to every consumer at once and is hard to attribute, because each department sees a different symptom. Second, the details that are configured rather than fixed by the protocol are the ones that bite: which modules are transmitted, at what rate, in what units, and with what coordinate convention. Over a long run the risk is that these were set once, correctly, by someone who has moved on, and are not written anywhere a maintaining engineer will find them.
Trackables carry a centroid and, where the system produces it, per-point detail; consumers read different subsets
Confirm the protocol version each consumer expects rather than assuming sender and receiver agree
Unicast to named consumers is common, which makes the sender's destination list part of the show documentation
Quaternion and Euler orientation may both be present; mixing conventions between them is a classic silent error
Is RTTrPM an open standard?
It is a vendor protocol rather than an ANSI or ESTA standard, with documentation available from BlackTrax and wide third-party support across consoles, media servers and spatial audio systems. Treat the vendor specification as the authority on packet structure, versions and unit conventions, and verify against the specific firmware in the room, since third-party implementations may support a subset or an older revision.
What consumes RTTrPM directly?
Lighting consoles with tracking integration, media servers, spatial audio processors and automation or show control systems commonly accept it, but coverage differs by product and version. The important question for a design is not whether a product lists support but which modules it reads, what it ignores, and at what rate it updates internally, because a consumer that decimates the stream sets the effective responsiveness regardless of what the network delivers.
How do we translate RTTrPM into PSN or OTP?
Through a bridge that handles units, coordinate handedness, axis order, origin and rotation representation explicitly, with each of those confirmed by measurement rather than by reading a configuration screen. Rate conversion needs attention too, since resampling adds latency and can introduce artifacts. Every bridge is a component in the signal path, so it needs a spare, a documented configuration and a place in the failover plan.