Do PTZ cameras need a separate cable for control?

Not always. Over IP, one network cable can carry video, control and power together (NDI plus VISCA over IP plus PoE). Over SDI or HDMI, the video runs on its own coax or HDMI cable and control runs separately, on a serial chain or a second network connection. Either way the control path exists and gets documented, whether or not it has its own cable.

What is VISCA and do I need it?

VISCA is the control protocol most PTZ cameras and controllers speak, giving a joystick commands for pan, tilt, zoom and presets. It runs two ways. Over serial, as a wired chain of addressed cameras. Over IP, with each camera addressed on the network. A PTZ needs some control protocol to be useful, and VISCA is the common one. Check each camera's manual for its exact addressing and pinout.

SDI or NDI for a PTZ system?

SDI when you want a dedicated, deterministic run per camera and a network you do not have to trust. NDI when you want one cable per camera carrying power, video and control and you control the network it rides on. Many rooms mix both and convert at the edges. The deciding numbers (cable length and bandwidth) live in the camera and switch datasheets. Not in a rule of thumb.

How many PTZ cameras can one PoE switch power?

However many its total PoE budget covers. Not however many ports it has. A PTZ pulls more while panning and tilting than sitting still, so size against peak draw with headroom and confirm the switch's shared pool rather than the per-port class alone. Working through a PoE budget before load-in is the way to avoid cameras dropping under motion.

Can I control PTZ cameras over the same network as the video?

Yes. Over IP that is the normal setup. NDI video, VISCA over IP control, PoE power: all of it can share one cable to one switch. The catch is that the switch now has to satisfy all three at once, so plan the VLAN, the bandwidth and the PoE budget together rather than treating the network as free capacity.

PTZ Camera System Design: Video, Control, and Power

By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 11 min read

A PTZ camera is three systems in one housing. A PTZ system design has to document all three: the video path (SDI, NDI, or HDMI carrying the picture), the control path (a joystick controller driving pan, tilt and zoom over VISCA on serial or IP), and the power path (usually PoE from the switch). Each travels a different way and gets documented in a different place. Draw them as three overlapping layers on one diagram; size the switch for all the PoE and network load at once; confirm every camera has a unique control address before load-in.

The three-path model: every PTZ is three systems

Pan, tilt, zoom. That is what PTZ means: three motions the camera makes on command instead of an operator on the handle.

For that to work, three separate things have to be true at once. A command has to reach the camera. The picture has to leave it. The motors and sensor have to be powered. Those are three independent paths, and a design that tracks only the video quietly forgets the two paths that strand a camera on show day.

Over IP the three paths can share one physical cable. Which is exactly why they get missed. One RJ45 looks like one connection, and it is still doing three jobs. Each job has its own limit. Its own document. Its own way to fail. Separate them on paper first, then decide how they share cable.

The three paths at a glance

Each path uses a different carrier. It lands in a different document. And it fails in a different way.

Get all three on the drawing before you spec a single cable.

The three paths every PTZ system has to document, and where each one lives
Path	Typical carrier	Documented where	Common gotcha
Video	SDI over coax, NDI over the network, or HDMI for short runs	Signal-flow diagram + cable schedule	Format and cable-length limits, verify against the camera and cable datasheet
Control	VISCA over serial (RS-232 or RS-422), or VISCA over IP	IP/control schedule + the same diagram	Duplicate addresses, one controller ends up driving two cameras
Power	PoE from the switch, or a local supply at the camera	Power report + PoE budget on the switch schedule	A PTZ under motion draws more than at rest, and the PoE pool runs out before the ports do

These three paths overlap on the same devices, which is the whole reason a port-aware tool helps here: in WireFlow each PTZ carries its real ports (video out, a control connection, a power input), so one diagram can show all three layers and derive the cable schedule, the power report and the IP schedule from the same source instead of three drawings that drift apart.

NDI or SDI for the video path?

Because it decides whether the video path is its own dedicated run or shares the network with everything else, this is the decision that shapes the rest of the system.

SDI is a dedicated coax per camera. One direction, built for long runs and deterministic behavior. It does not touch a network, so nothing else can congest it. It carries only video. Control and power still need their own paths.
NDI puts the video on the IP network alongside your data. Alongside your control. Often alongside your power too. One cable per camera can carry all three; that is its whole appeal. The picture now depends on the network being sized and configured correctly.
HDMI shows up on smaller or consumer PTZ cameras. Fine for a short run to a nearby switcher. Any real distance needs an extender or a converter, and that converter has to make the gear list.

Choose SDI when you want a run you do not have to trust a network to protect, or when the switcher and router are already SDI. Choose NDI when you want one cable per camera position and you control the network it rides on.

Plenty of rooms mix both and convert at the edges, which is fine as long as every format transition is drawn and every converter is on the list.

Control topology: daisy-chain vs star

Two ways to wire the control path. The choice usually follows the video decision.

Serial daisy-chain (VISCA over serial): the controller feeds camera 1, camera 1 passes through to camera 2, and so on down the chain. Each camera is set to a unique address on the chain. Fewer cables, but a break or a duplicate address takes out everything downstream of the fault.
IP star (VISCA over IP): every camera sits on the network and the controller addresses each one by IP. Cameras are independent, so one fault drops that camera alone. When the video is NDI, this is the same star the video and power already ride.

Either way, the control path is real and belongs on the diagram next to the video and power. Draw the controller as a device. Draw its connection to each camera. Record the address: a serial position on a chain, or an IP on the network. That record is what stops two cameras answering to the same command.

When one cable carries power, video, and control

Take an NDI camera powered by PoE. One RJ45 to the switch now carries three things. Power in. Video out. Control both ways. Physically, a single cable. Logically, still three paths. The diagram has to keep showing three even though there is one wire.

Here is what changes about the drawing: the switch becomes the one point that has to satisfy all three paths at once. It has to deliver the PoE that camera pulls. It has to carry the NDI video with bandwidth to spare. It has to route the control traffic, ideally on a planned VLAN so the video does not fight the rest of the network. One under-sized switch strands the entire camera position. Every path at once.

Plan the network and the power together: see VLAN planning for AV systems for the traffic side and PoE budget planning for the power side.

How to document a multi-PTZ system, step by step

Same left-to-right signal flow as any diagram (see how to create an AV signal-flow diagram for the base technique), with the control and power layers added deliberately instead of assumed.

List every camera and its position. For each, note the video format it outputs, the control method (serial address or IP), and how it is powered (PoE or local).
Lay cameras as sources on the left, the controller and network switch in the middle, and the switcher, recorder, and stream on the right.
Draw the video path from each camera to the switcher or router, port to port, in that camera's actual format, and mark any format conversion with the converter that handles it.
Draw the control path from the controller to each camera, serial chain or IP star, and assign every camera a unique address as you go.
Draw the power path. Mark which cameras are PoE and which are local, and add each PoE camera's draw to the switch budget.
Where a camera is NDI over PoE, note that one cable carries all three paths, but keep the three connections visible so each derived document still sees its own.
Walk each path end to end: every camera has power, a picture that lands on a real switcher input, and a control address nothing else shares.

For a full worked build that carries these cameras through switching, audio, record and stream, walk the multicamera livestream signal flow example. For the port-to-port mechanics in the builder, check connecting devices and ports.

Common PTZ mistakes and how to catch them

Duplicate control addresses. Two cameras at the same serial address or IP, and the controller drives both or neither. Assign addresses on paper first, then verify each one is used exactly once.
PoE budget exceeded. Every camera fits a port. The switch's shared PoE pool still runs dry, and cameras drop out under motion when draw peaks. Size the switch against total draw with headroom rather than the per-port class alone.
Mixed formats never converted. An HDMI camera aimed at an SDI input needs a converter. So does an NDI camera with no path onto an SDI router. That converter is real gear and it has to appear on the list.
The control path never drawn. Video and power get documented. Control gets assumed. The joystick that does nothing on show day was never on the diagram in the first place.
The network treated as free. NDI video. IP control. PoE. All landing on a switch that was sized for none of them. Over IP, the switch is the system, so plan three things as one job: VLAN, bandwidth, PoE budget.

Frequently asked questions

Do PTZ cameras need a separate cable for control?: Not always. Over IP, one network cable can carry video, control and power together (NDI plus VISCA over IP plus PoE). Over SDI or HDMI, the video runs on its own coax or HDMI cable and control runs separately, on a serial chain or a second network connection. Either way the control path exists and gets documented, whether or not it has its own cable.
What is VISCA and do I need it?: VISCA is the control protocol most PTZ cameras and controllers speak, giving a joystick commands for pan, tilt, zoom and presets. It runs two ways. Over serial, as a wired chain of addressed cameras. Over IP, with each camera addressed on the network. A PTZ needs some control protocol to be useful, and VISCA is the common one. Check each camera's manual for its exact addressing and pinout.
SDI or NDI for a PTZ system?: SDI when you want a dedicated, deterministic run per camera and a network you do not have to trust. NDI when you want one cable per camera carrying power, video and control and you control the network it rides on. Many rooms mix both and convert at the edges. The deciding numbers (cable length and bandwidth) live in the camera and switch datasheets. Not in a rule of thumb.
How many PTZ cameras can one PoE switch power?: However many its total PoE budget covers. Not however many ports it has. A PTZ pulls more while panning and tilting than sitting still, so size against peak draw with headroom and confirm the switch's shared pool rather than the per-port class alone. Working through a PoE budget before load-in is the way to avoid cameras dropping under motion.
Can I control PTZ cameras over the same network as the video?: Yes. Over IP that is the normal setup. NDI video, VISCA over IP control, PoE power: all of it can share one cable to one switch. The catch is that the switch now has to satisfy all three at once, so plan the VLAN, the bandwidth and the PoE budget together rather than treating the network as free capacity.

Build this diagram in WireFlow

Port-aware devices, validated connections, and exports your crew can read on site. Free plan includes three editable diagrams, no credit card.

Start a free diagram · Explore the sample show first