Designing a Rail Transit PIS Video Network

What the video network has to carry

A passenger information system usually has three distinct jobs, and they do not all want the same transport. Live or scheduled programme video has to reach many screens at once. Per-screen or per-zone content has to be playable locally when the uplink is lost. Device telemetry — status, brightness, health, temperature — has to get back to the control room continuously.

The design consequence is simple but often missed: one-to-many live video is a multicast problem, while scheduled content is not. Trying to serve both from the same stream is how PIS networks end up flooding every VLAN in the station.

Transport choice: uncompressed fibre or IP encoding

There are two architectures that work, and the choice is mostly about screen count and how much logic you need in between.

Uncompressed optical

Source to optical transmitter, fibre to receiver, receiver to display. No codec, no buffering, and no electromagnetic interference — which matters trackside, in tunnels and alongside traction power. Fibre also gives galvanic isolation, so it removes the ground-loop problems that plague long copper runs between buildings with separate earthing. The cost is rigidity: roughly one fibre run per destination, and re-zoning means re-patching.

IP encoding

Encoder to switched network, decoders at the screens. It rides the data network you already have, zoning becomes configuration rather than cabling, and one encoder can feed a whole concourse over multicast. The cost is latency from compression and buffering, plus a hard dependency on getting multicast right on the switch.

Working rule: few screens, short runs, image fidelity critical — fibre. Many screens across several zones, content logic required — IP encoding. Most real projects end up hybrid: fibre for the long station-to-station backbone, IP for the last leg to the screens.

On the hardware side, the ZY-OH1301 carries 4K60 HDMI with audio and RS232 over a single-mode single-core LC link, rated 20 km and customisable beyond that. Where a whole station's screens terminate in one rack, a multi-channel fibre frame concentrates them instead of running individual pairs. On the IP side, the ZY-EH1304 takes four HDMI inputs — 2×4K@30Hz plus 2×1080P@60Hz — and pushes four streams per channel, sixteen in total, out of one 1000M RJ45 port.

Multicast, IGMP and the switch that breaks it

Live PIS video is the textbook multicast case: one source, many receivers, one copy per branch instead of one copy per screen. Three switch behaviours account for most failures we see:

• No IGMP snooping. The switch treats multicast like broadcast and floods it to every port. Your video lands on the CCTV, ticketing and signalling VLANs.
• Snooping without a querier. Group membership silently times out. Screens go black a few minutes after the stream starts — the single most reported symptom.
• "Flood unknown multicast" left on. A default on plenty of switches, and it undoes the snooping you just configured.

Practical setup: give PIS video its own VLAN, enable IGMP snooping and configure an explicit querier, keep it away from anything safety-critical, then prove it with a capture — watch a port that should not be receiving and confirm no PIS traffic appears. The protocol background is covered in Multicast, Unicast and Broadcast Explained.

Screen population and decoder placement

Count streams, not screens. A decoder's limit is decode capacity, not the number of HDMI ports on the box: the ZY-DH901, for example, does one 4K channel, or four 1080P channels, or nine 720P channels — so a wall of nine 720P platform screens fits in one unit, while a 4K concourse display consumes the whole thing.

Place decoders close to the screens and keep the encoder-to-decoder path switched rather than routed where the topology allows. Give every decoder a static address and a documented name. It sounds mundane; the ZY-DH901 has an LCD showing device name, IP address, resolution and working status, which is the difference between a five-minute check and an afternoon with a laptop on a platform.

Fibre budget and distance planning

Distance is rarely the binding constraint in a metro — connector count and patching quality are. The ZY-OH1301 is rated 20 km on single-mode single-core LC, and KVM optical transceivers such as the ZY-HDMI-KVM-T/R run 10 km standard at 1920×1200@60Hz. Those numbers describe the optics; what actually decides whether a link is stable is loss budget across every mating pair.

Budget each connector and splice, keep patch cords unkinked, and clean LC end-faces before seating them. Contamination is the top cause of intermittent optical faults, and it is entirely avoidable — see HDMI Fiber Extender Troubleshooting for the isolation sequence.

Redundancy: what to duplicate and what not to

• Worth duplicating: the encoder feeding a zone, the control-room uplink, and headend power.
• Usually not worth duplicating: individual screen decoders. Hold spares instead — a decoder swap is faster and cheaper than a redundant path to every screen.

The more valuable design decision is behavioural, not hardware: make sure screens can play locally stored playlists. Then a video-network outage degrades to "no live programme" rather than "black screen", which passengers read very differently.

Verify by unplugging things during commissioning, not by re-reading the design. Pull the primary encoder uplink and confirm the site does what the operator agreed it should do.

Commissioning checklist

Item	Pass criterion
VLAN separation	A capture on a non-PIS port shows no PIS multicast traffic
IGMP membership	Screens are still live 30 minutes after stream start
Zone sync	Side-by-side screens in one zone are within the operator's stated tolerance
Failover behaviour	Pulling the primary uplink produces the agreed degraded mode, not a crash
Optical margin	Measured power margin recorded per run at install, not just "link is up"
Labelling	Every decoder has a recorded name and address, legible on site

Where to start

FAQ

Related reading

• Multicast, Unicast and Broadcast Explained
• HDMI over Fiber Guide
• HDMI Fiber Extender Troubleshooting
• Fiber Optic Transceivers