showstack

GitHub
Free forever·no account, no tracking, no third-party requests ·open data, free API
showstack / compare / psn-vs-rttrpm

PosiStageNet vs RTTrPM

Which tracking protocol does my media server actually take? Below is every field we hold on both, side by side. Each one is sourced on the individual entry, and anything nobody could source is left blank rather than guessed.

Side by side

PosiStageNetRTTrPM
Categorytracking-positiontracking-position
FlowControl — small, urgent, must arriveControl — small, urgent, must arrive
PortsUDP 56565
Transportudpudp
Multicast236.10.10.10 (IPv4 default group)
Spec availabilityopen-publishedopen-published
StewardVYV Corporation, developed with MA Lighting Technology GmbHCAST Group (BlackTrax)
First published2013—
Statuscurrentcurrent
Our confidenceverifiedreported

Both are control flows. Latency and loss on the messages that fire once. A repeating level survives a dropped packet; a GO does not. That applies equally to either, so it is not a discriminator here.

Speaks both (9)

These are the safe choices if you have not committed to either, or need to bridge the two.

PosiStageNet only (15)

RTTrPM only (3)

What goes wrong with PosiStageNet

There are two packet types. PSN_INFO carries system and tracker names at a slow rate, PSN_DATA carries the positions. A parser that only reads DATA gets numbers with no idea which tracker they belong to.
Default rate is 60 Hz and it can be pushed to 250 Hz. Every increase multiplies packet load on a network that is often shared with lighting multicast, so raise it deliberately, not by default.
Positions are metres in the tracking system's own coordinate frame. PSN carries no origin, axis convention or handedness, so the venue origin and which way is up have to be agreed and written down before anyone patches.
The protocol is public domain and royalty-free, but the name is not. You can implement it freely; you cannot ship something called PosiStageNet without talking to VYV.
Trackers can drop out and reappear. Consumers that hold the last known position will happily keep pointing a light at a spot the performer left thirty seconds ago, so check what your receiver does on timeout.

What goes wrong with RTTrPM

The RTTrP header carries both a big-endian signature (0x4154) and a little-endian one (0x5441). Read the signature first and byte-swap the rest of the packet accordingly, or every position you decode looks like noise.
A packet is a header plus a variable list of modules, each with its own type and size. Do not assume fixed offsets. Walk the module list by declared size or you will break on the next firmware release.
Centroid position and tracked point position are separate module types. A beacon taped to a performer's shoulder is not the centroid of the trackable, and consuming the wrong one puts the light in the wrong place.
RTTrPM (motion) and RTTrPL (lighting) share the same header. Motion is a fixed-rate stream, lighting is event-driven, so a receiver that assumes a steady packet rate will time out on the lighting side.
The wiki documents no default port and no default address. Whatever the BlackTrax output configuration says is the truth, so get it from the tracking operator rather than guessing.

Sources

Disagree with any of this?

Every claim above comes from one of the two entries and carries a source. If one is wrong, correcting it is a single file and it fixes this page automatically. Edit PosiStageNet or edit RTTrPM.