Choosing between tracking and control protocols
How to pick a protocol path across a rig, and what actually breaks when data is translated between them.
What it is
In practice the choice is constrained by what the endpoints support, so the real design question is which protocol reaches the most consumers natively and where translation is unavoidable. The comparison worth making is by what each layer carries. sACN and Art-Net carry level data with no notion of space. PSN, RTTrPM and OTP carry object state, differing in addressing model, discovery, unit conventions and how much of the transform they express. OSC carries anything and guarantees nothing. Around that sits the transport question of multicast versus unicast and what that demands from the fabric. The design output is a signal path diagram naming every translation and everything downstream of it.
Why it matters
Translation is where tracking systems fail in ways that survive a technical rehearsal. A unit error, a handedness flip or a wrong axis order does not produce nothing; it produces plausible motion in the wrong place or the wrong direction, which reads as a programming issue and can be worked around until the day it cannot. Origin offsets behave the same way and are worse, because they are correct near the reference point and wrong everywhere else. Rate conversion adds latency at every hop and can introduce artifacts. Over eight shows a week, each bridge is also a component with a power supply and a configuration, so it needs a spare, documentation and a place in the failover plan.
Unit and handedness mismatches produce plausible motion, which is why they survive into previews
Origin errors look correct near the reference point and get worse with distance from it
Rate conversion adds latency and can alias; match the consumer's expected rate rather than the highest available
Every translation hop can add delay, drop a field and lose the timestamp; prefer the fewest that reach all consumers
How many protocols should one system speak?
As few as reach every consumer natively. Each additional protocol is another translation, another configuration, another spare and another thing to verify after a firmware update. Sometimes the answer is unavoidably several, because departments arrive with fixed toolsets. When that happens, put the translation in one documented place rather than letting each department build its own bridge, since parallel bridges drift out of agreement.
Where should the bridge live?
Somewhere powered, monitored, physically accessible and owned by a named person, with a configured spare next to it. The worst placement is a laptop under a desk that also does something else. Consider what happens to every downstream consumer when the bridge stops, because a translation point is a single point of failure for everything behind it unless it was deliberately designed not to be.
How do we prove a translation is correct?
Measure it. Place a tracked object at surveyed positions and compare what each consumer reports. Walk each axis separately and check the sign at both extremes, which is what exposes a handedness flip. Check a far corner as well as the center, since origin and scale errors hide near the reference point. Record the results, because that measurement is the reference when something changes later.