PosiStageNet
An open protocol for streaming tracked-object position data to consoles, media servers and show systems over IP.
What it is
PosiStageNet, usually written PSN, is an open protocol for streaming the position and motion state of tracked objects across a network. It is carried over UDP and is normally distributed by multicast, so one producer can feed many consumers without maintaining a destination list. The stream is split into two kinds of message: fast data packets carrying per-tracker state, and slower informational packets carrying descriptive material such as tracker names and system identification. Trackers are identified numerically, and the name is metadata attached to that identifier rather than the address itself. Data typically includes position, motion derivatives, orientation, a validity or status indication, and a timestamp that lets a consumer reason about age.
Why it matters
PSN is often the layer between a tracking system and everything that consumes tracking, which makes it a shared dependency across departments. When it is right, a lighting console, a media server and an audio spatializer are all working from the same object state and agreeing about where a performer is. When it is subtly wrong, they disagree in ways that read as artistic problems rather than technical ones, and the note comes back as a look that is off rather than a system that is broken. Across a run the durable risks are configuration drift and identity: a tracker renumbered on one end, a consumer keyed to a name that changed, a multicast group that stops being delivered after a switch swap.
The numeric tracker id is the address; names arrive in the slower info stream and make a fragile join key
Timestamps let a consumer judge staleness rather than trusting whatever packet arrived most recently
Multicast delivery means the switch fabric, not the sender, decides who actually receives the stream
Origin, axis order and handedness are conventions agreed between systems, so confirm them rather than assume
What consumes PSN?
Support is broad across lighting consoles, media servers, spatial audio systems and show control platforms, but it varies by product and by firmware version, and what a given consumer does with the data varies more. Some use position only, some use orientation, some expose the full object state to the programmer. Confirm per device what fields are read and at what rate, because that determines what you can actually design with.
Multicast or unicast?
Multicast is the normal case and is what makes one producer feeding many consumers practical. That puts the burden on the network: IGMP snooping with a working querier on the VLAN carrying the stream, and verified group membership rather than an assumption that a stream which appears at one consumer is reaching the others. A stream that works because the fabric is flooding it is a fault waiting for a load increase.
What happens if two producers publish the same tracker id?
Nothing good, and the outcome depends on the consumer rather than the protocol. Consumers may take the most recent packet, may alternate, or may behave differently from each other, which is worse because the departments then see different positions. Treat tracker id allocation as a system-wide namespace owned by one person, documented alongside the address plan, and never allocated ad hoc during a rehearsal.