showstack

Start with something you already use

What is actually inside Google Maps

The blue dot looks like one measurement. It is at least five, and every one of them is unreliable on its own.

GNSS gives position outdoors to a few metres — and, more importantly, the time. It fails indoors, in tunnels, and among tall buildings where the signal arrives by reflection. Cell and Wi-Fi fill that gap: the set of towers and network names your phone can hear is itself a rough location, available where satellites are not. The IMU and compass keep dead reckoning going when both drop out — that is why the dot keeps moving sensibly through a tunnel. Map data arrives over an ordinary web API and supplies the constraints: you are on a road, the road is one-way, its limit is 50. And everybody else's anonymised speed becomes the traffic layer.

None of that is a positioning system. The positioning system is the fusion: a running estimate that weighs each source by how much it can currently be trusted, and reports a confidence — which is the circle around the dot.

The first shared fact

A clock everything reads

Give three devices their own crystal and they will each run at very slightly the wrong speed. Nobody is faulty. Over a three-hour show those tiny errors accumulate into a lip-sync problem, a video frame tear, or a lighting cue that lands after the downbeat.

Fixing it means one clock and a way of distributing it. Which one depends on what you are locking: LTC and MTC carry a running show time so departments know where they are in the running order; PTP and word clock carry a sample-accurate time so audio converters agree on individual samples; genlock carries a frame-accurate time so cameras and displays start each frame together.

A show usually needs all three, from one house reference, and confusion between them is a classic fault: a system perfectly locked to PTP can still be a second late in the running order, because sample lock and show time are different questions.

The second shared fact

A coordinate system everything shares

The moment two departments both need to know where something is — a followspot and a sound object, a camera and a render engine — they need to agree not just on a number but on an origin, an orientation and a unit.

This is the part that gets skipped. The lighting plot is in metres from the centre line of the stage; the audio designer's room model has its origin at the front-of-house desk; the render engine is in Unreal units with Z up. Every one of those is internally correct, and none of them will tell you they disagree — the light will simply be two metres out and everyone will blame the tracking.

Protocols like PosiStageNet and RTTrPM exist to carry positions between departments, but they carry coordinates, not agreement about coordinates. The survey happens first.

Showcase one

Tracked followspot and object audio

A performer wears a tag. Depending on the system that tag is ultra-wideband, infrared, or a hybrid with an inertial sensor for when line of sight is lost. A tracking server turns the raw ranges into a position in the venue's coordinate system, at something like 50–100 updates a second.

That position then leaves the tracking system over PSN or RTTrPM and is consumed twice: the lighting system pans and focuses fixtures at the point, and the audio system moves a sound object to the same point so the voice comes from where the performer is standing rather than from the PA.

One measurement, two departments, no operator — and the reason it looks like magic is that both departments are reading the same number in the same coordinate system.

Showcase two

An LED volume, and why it needs genlock

Virtual production replaces a green screen with a wall of LED showing the environment. The trick is that what the wall displays depends on where the camera is, so the wall must be re-rendered every frame from the camera's point of view.

The camera's position and lens data leave the tracking system over FreeD. A render engine draws the world from exactly that viewpoint and sends it to an LED processor, which drives the panels. Only the region the camera can see — the inner frustum — needs to be perspective-correct; the rest of the wall carries a coarser version whose job is lighting the scene and reflecting off surfaces.

And all of it hangs on genlock. The camera shutter, the render output and the LED panel refresh must all start their frames together, because an LED wall does not display a frame all at once — it refreshes in a scan. A camera shutter that opens out of step with that scan photographs a wall mid-refresh, and you get banding that no amount of grading will remove.

Showcase three

AR, VR and XR — what the letters mean and what is underneath

The three words describe how much of what you see is real, and they are used loosely enough on riders that it is worth being precise.

The four hard parts

Tracking. Six degrees of freedom — position and orientation — recovered many times a second. Modern headsets do this inside-out, running SLAM (simultaneous localisation and mapping) on their own cameras rather than relying on external base stations. Broadcast AR does the opposite: a camera whose position is measured by encoders on the crane or by an optical system, streamed as FreeD.

Motion-to-photon latency. The time from your head moving to the light for that new viewpoint reaching your eye. Above roughly 20 ms this stops being a technical figure and starts being nausea, which is why headsets predict where your head will be rather than waiting to find out.

Rendering enough pixels. Two eyes, high refresh, wide field of view. Foveated rendering — full detail only where the eye is actually looking, tracked in real time — is the standard way out.

Registration. The graphic has to sit still relative to the real world. That is the coordinate-system problem again: a virtual object that slides slightly when the camera moves has a lens calibration or an origin that disagrees with reality.

Showcase four

The spine that holds a stadium show together

On a large show, almost nothing is triggered by anything else. Departments are not chained — they are each independently reading the same running time.

A master clock generates timecode. Playback, lighting, audio, video, automation and the pyro or drone operator all follow it. Cues are not "go when the previous thing finishes"; they are "go at 01:14:22:06". Nothing is waiting on a message that might not arrive.

This is why it survives. A department that glitches recovers on the next timecode frame and rejoins, because it can see exactly where the show has got to. A chained system, where each step triggers the next, stops dead at the first missed message and cannot recover without a human.

Putting it back together

The two questions worth asking at the start of any integration

When someone asks whether two systems can work together, the useful questions are not about brands.

What clock are they both reading, and at what resolution? If the answer is "each has its own", the integration will look fine in a demo and drift in a show.

What coordinate system are they both using, and who surveyed it? If the answer is "we will line it up on the day", budget the day.

Everything else — which protocol, whose console, what the API returns — is an implementation detail by comparison. Those are covered on the software, network and connectivity pages; this is the layer above them.