Live Broadcast Data Feeds

A different set of constraints

Everything else on this platform is allowed to be slow and careful. Broadcast is neither. A speed readout that appears four seconds after the sprint is worthless, and a feed that drops during the second half is worse than no feed at all. This module exists because those constraints are genuinely different from analytical processing, and pretending otherwise produces a product that is bad at both.

The live path runs separately from the analytical pipeline. Pods stream a reduced telemetry set over the venue network to an on-site edge appliance, which performs the minimum viable processing — smoothing, unit conversion, event detection for a small set of triggers — and publishes. Typical glass-to-graphics latency is under 800 milliseconds. The full-fidelity session still uploads afterwards for the analytical pipeline; the two never contradict each other because the live values are explicitly labelled provisional.

What goes out

• Instantaneous and peak speed per athlete, with a configurable smoothing window
• Distance covered, in total and within speed bands
• Sprint and high-intensity effort events, with start and end timestamps
• Acceleration and deceleration peaks above a broadcast-appropriate threshold
• Optional heart rate, where the athlete has consented to that specific field being broadcast

Note the last one. Heart rate is health-adjacent data, and broadcasting it is a materially different act from recording it for the medical department. Our consent model is per-field and per-athlete, held in the platform, and enforced at the feed publisher rather than in a downstream policy document. If an athlete withdraws consent for heart rate at 14:50, the 15:00 kick-off feed does not carry it. There is no override switch for a producer.

Delivery and integration

Two transports. A WebSocket JSON stream for graphics engines, second-screen applications and web products, with a documented message schema, sequence numbers and a replay buffer covering the last sixty seconds so a reconnecting client catches up rather than jumping. And SRT-wrapped ancillary data for broadcast chains that prefer to carry telemetry alongside video rather than out of band.

Where a league operates its own data specification, we map to it rather than asking the league to adopt ours. Field names, units, event vocabularies and timestamp conventions are all configured per competition, and the mapping is a versioned artefact so a mid-season schema change is a deliberate deployment rather than a surprise.

Reliability on match day

The edge appliance runs dual network paths, typically venue Ethernet plus a bonded cellular backup, with automatic failover. It buffers locally so a network interruption produces a brief gap rather than a lost half. Two appliances can run in active-standby for competitions where a feed outage carries a contractual penalty.

Positioning indoors uses the same ultra-wideband anchors as the analytical system, which means an arena installation serves both. Outdoors the live path uses the pod's GNSS solution directly; a stadium bowl with poor sky view is the single most common cause of degraded live speed data, and it is worth surveying before the first fixture rather than diagnosing at half time.

Commercial and rights considerations

Athlete performance data has commercial value, and who holds the rights to exploit it is contractual rather than technical. We do not sell, license or aggregate your athletes' data for our own commercial purposes, and that is written into the agreement rather than left to a privacy policy. What we provide is the pipe and the controls; the rights negotiation between club, league, athlete representation and broadcaster is yours.