Common Mistakes When Setting Up Remote Camera Control

The most frequent mistake I see is a team buying heads, controllers and licences before anyone has written down what the programme needs from its cameras. The shopping list grows out of a catalogue instead of a shot list, and the result is a system that can do many things but struggles with the five moves the show repeats every night.

Start with the format. How many presenters, how many positions, how often do you cut to a wide, and does anything move during a bulletin? A two-person desk with fixed framings needs a very different setup from a live stage show with tracking moves and quick recalls.

Write those answers on one page and take it to every supplier conversation. It keeps the discussion anchored to your output, and it makes quotes easier to compare because each supplier answers the same brief rather than selling their strongest feature.

• List every shot the programme repeats
• Note which moves are live and which are preset
• Count operators available per transmission
• Agree a spare-unit policy before purchasing

Remote heads depend on a network, yet in many refits the control traffic ends up sharing switches with office data, file transfers and guest wireless. It works in the first week. Then a large file moves across the same link during a bulletin and a camera lags or drops its connection.

Give camera control its own segment, or at least its own managed switch with clear priorities. Keep addressing documented and fixed, not handed out automatically, so that a head which reboots comes back with the same identity the controller expects.

Cable runs deserve the same care. Label both ends, keep copper lengths within the limits for the equipment, and leave service loops near each head. Most outages I am called about trace back to a loose connector or an undocumented patch rather than to the cameras themselves.

• Separate control traffic from general data
• Use fixed addresses and keep a written list
• Label both ends of every cable run

Presets are only as good as the day they were stored. A head that has been bumped, re-seated or powered down without homing will recall a position that looks close but is not right, and the operator finds out on air. Teams then lose trust in recalls and go back to steering by hand.

Build a short start-of-day routine: home every head, recall each stored shot, and check it against a reference mark or framing chart on the set. It takes a few minutes and catches drift before the first rehearsal.

Name presets consistently as well. A shot called Wide 2 means nothing to a relief operator, whereas a name that matches the running order is understood immediately. Keep a printed copy of the preset map at the desk, because screens fail at awkward moments.

• Home all heads before the first check
• Verify presets against a marked reference
• Use names that match the running order

Remote control reduces the number of people on the floor, and it is tempting to reduce it further than the production can bear. One person watching six camera outputs, adjusting exposure and recalling moves has little attention left when something unexpected happens in the studio.

Look at the busiest ten minutes of the programme, not the average. Count the actions an operator must perform in that window, and be honest about whether a single pair of hands can manage them without shortcuts.

Layout matters too. Group the controls the operator needs most within easy reach, keep monitors at a consistent angle, and avoid menus that require several presses to reach a basic function. A well-arranged panel saves more time than a faster processor, and it makes training a new colleague far simpler.

• Plan for the busiest window of the show
• Keep frequent controls within easy reach
• Train a second operator on every setup

A system installed by one engineer and understood only by that engineer is a risk. When the person is away, a simple fault turns into an afternoon of guessing, and nobody dares to change settings in case something else stops working.

Keep a plain document next to the equipment: network addresses, head models, firmware versions, preset maps, and the order in which to power things up and down. Add a short fault list that describes what has gone wrong before and what fixed it.

Review it whenever something changes. Firmware updates in particular should be recorded and tested on a spare unit before they reach the live chain. A written trail does not feel urgent while everything works, but it is the first thing a new technician will ask for.

• Record firmware versions after every change
• Store the power-up sequence beside the rack
• Keep a log of past faults and their fixes

Every setup fails sometimes, and the question is whether the team knows what to do when it does. A fallback that has never been rehearsed tends to be discovered for the first time in front of an audience, which is the worst moment to learn that the manual joystick is in a cupboard.

Decide in advance what happens if a head stops responding, if the controller freezes, or if the network drops. Agree who calls it, which camera takes over, and how the presenters are told. Run each case once in a quiet slot.

Keep the fallback simple. A locked-off wide shot on a spare camera is often enough to keep the programme running while the fault is cleared. Rehearsing it costs very little compared with the confusion of improvising during transmission.

• Define who decides when to switch to fallback
• Rehearse a head failure and a network drop
• Keep a manual option within reach