Auto-Tracking Camera Moves but Won't Follow: Diagnosing Control Protocol Compatibility

Quick answer

When an auto-tracking camera pans and zooms on command but never locks onto a person, the fault is usually not the tracking algorithm. Most "tracking is broken" tickets are really control-path problems: the video and the movement commands travel on different channels, so the tracking engine's position corrections never reach the pan/tilt head. Confirm that tracking commands actually arrive at the camera, and that the camera accepts the position format being sent, before you touch any tracking sensitivity setting.

Stop conditions: when to leave the camera alone

  • Do not open the housing, bypass a limit switch, or disable an end-of-travel or thermal cut-out to make the camera "keep tracking." A head that keeps driving past its stop is a mechanical and personal-injury risk, not a tracking bug.
  • If the head runs into its mechanical limits, grinds, or emits a continuous ratcheting noise during tracking, power it down and escalate to the vendor instead of testing further.
  • If the camera is on a ceiling or truss mount, a lift, or above a public area, do not loosen the mount or work at height to test cabling. Diagnose from the control-side logs first.
  • Any camera used as part of a broadcast, medical-adjacent, security or safety workflow: keep the manufacturer's documented operating mode, and stop testing once behaviour is outside the published envelope.

The four cause groups to separate

Cause group Typical symptom Fastest discriminator
Transport path mismatch (video protocol vs control protocol) Picture is fine, tracking never engages, manual joystick works Send a known PTZ command over each candidate transport and watch the head
Position-format gap (continuous vs absolute move) Tracking starts, then drifts, jitters or aborts Test a continuous move, then an absolute move, from a reference client
Profile / token binding Client reports no PTZ profile, or commands return a fault Check that the media profile used carries a PTZ configuration
Command contention (two controllers) Tracking works until a second app or joystick connects Watch for manual-command override and sequence-number resets in a packet capture

Safe checks, in order

1. Confirm which channel carries video and which carries movement

Auto-tracking cameras commonly send video over one protocol and PTZ commands over another. NDI, for example, carries video and audio (and in some implementations metadata) but is not a standard PTZ hardware-control protocol; the controller must still open a VISCA-over-IP or ONVIF control connection to the camera. A picture appearing in the receiver proves only that the video path works.

Check: list every connection the tracking software opens — video source, control protocol, IP address, port. If there is no control connection at all, the tracking engine is talking to nothing.

2. Prove the camera can move from an independent reference client

Before blaming the tracking software, move the head from a neutral tool: the camera's own web interface, the manufacturer's PTZ utility, or a standards-based client such as ONVIF Device Manager.

  • If the reference client cannot move the camera, the problem is on the camera, credential or network side — not the tracking logic.
  • If the reference client moves the camera but the tracking app does not, compare the two clients' protocol, port and credentials. Mismatch there is the answer.

3. Match the port and transport actually documented for your model

Port numbers are the most over-generalised fact in PTZ integration. For VISCA over IP, manufacturer documentation for Sony and AVer models specifies UDP 52381 for control and UDP 52380 for discovery; a figure of "5238" that circulates in some guides is not a universal default. Serial-side VISCA, if you are using a serial-to-IP converter, is often 9600 bps, 8 data bits, no parity, 1 stop bit, no flow control, but that is a common default rather than a standard for every camera.

Check: the control port in the camera's own manual, and whether the controller is sending UDP or TCP. Sending the right command bytes to the wrong port produces exactly this symptom: everything looks configured, nothing moves.

4. Check the camera address (ID) and command framing

Legacy VISCA addressing uses camera addresses 1–7, with the controller at address 0; some models fix the address at 1. Manufacturer guidance also calls for an address-set and interface-clear step when initialising a VISCA network. If the tracking software addresses camera ID 2 while the camera answers only to ID 1, commands are silently discarded.

Check: the camera ID set in the camera menu against the ID configured in the tracking application. Verify an inquiry/response round trip rather than only sending moves.

5. Test continuous move, then absolute move, separately

This is the check that most often separates a real tracking fault from a position-format mismatch. In ONVIF terms:

  • ContinuousMove sends a velocity until an explicit Stop (or a zero-velocity move). It does not need a physical position encoder, so most PTZ heads support it.
  • AbsoluteMove commands an exact coordinate and requires the camera to expose an absolute pan/tilt position space. If the camera has no encoder or does not publish that coordinate space, the call fails or returns a fault.

Tracking software that computes target coordinates and pushes absolute positions to a camera that only supports velocity control will look like "tracking won't hold the subject": the first correction may land, subsequent ones do not.

Check: in the camera's PTZ configuration options, confirm which velocity and position spaces are published. Then have the tracking software use one the camera actually supports.

6. Verify the profile actually carries PTZ

Under ONVIF, PTZ requests carry a profile token that must reference a media profile containing a PTZ configuration. Requesting PTZ on a profile that has no PTZ configuration should return a NoPTZProfile style fault. A camera can expose media and streaming perfectly well while the profile you selected has no PTZ binding — the tracking app connects, streams, and issues moves that are rejected.

Check: confirm that the PTZ service is present, that a media profile exists with a PTZ configuration attached, and that the tracking application uses that profile token, not a video-source or configuration token.

7. Look for command contention from a second controller

Auto-tracking fails in a very specific way when two clients address the same camera: most PTZ cameras give incoming manual PTZ commands priority over internal tracking. A second joystick, a monitoring page left open, or a controller sending a keep-alive or zero-speed move can abort tracking mid-shot. UDP-based VISCA also has no session management, so two controllers sending independent sequence numbers to the same IP and port can desynchronise the session and make the camera appear to freeze.

Check: disconnect every other client (including vendor monitoring tools and phone apps), then retest. Capture traffic for a minute and look for move commands arriving from an unexpected source address.

Interpreting the results

What you observed Most likely reading
No control connection is opened by the tracking app Transport path mismatch — configure a real control channel
Reference client works, tracking app doesn't Wrong port, wrong protocol, wrong camera ID, or wrong credentials in the app
Inquiry works, moves are ignored Command framing or camera address error
Tracking starts then drifts or aborts Position-format gap (absolute vs continuous) or unsupported coordinate space
Fault returned on PTZ calls No PTZ configuration bound to the profile token in use
Works until someone else connects Command contention / manual override priority
Movement is intermittent and session resets appear in capture UDP sequence-number desynchronisation between controllers

When to stop and escalate

  • The camera never responds to any client, including its own web interface — treat as a hardware or firmware fault and raise a support case with the camera vendor.
  • The camera reports a documented capability (for example absolute positioning) in its specification but does not publish the corresponding coordinate space — this is a firmware/vendor question, not something to work around.
  • Tracking firmware requires a newer version than the installed build, or the vendor documents a known protocol defect — escalate with the firmware version and the exact request/response you captured.
  • Any behaviour that involves a head hitting its limits, overheating, or making mechanical noise — stop testing and escalate immediately.

Useful evidence for the vendor: firmware version, protocol and port, camera ID, the profile token used, a short packet capture, and the tracking application's version and settings.

Prevention

  • Write the control plan down before installation: which protocol per function (video, PTZ, tracking), which port, which camera ID, which profile token.
  • Keep one controller authoritative for PTZ. If operators need manual override, configure it through the same control system rather than a second independent app.
  • At commissioning, prove both a continuous move and an absolute move from the reference client, and store the result in the handover pack.
  • Pin firmware versions in the documentation and re-run the two movement tests after any firmware update.
  • Prefer a wired, stable control network with a documented addressing scheme; keep the tracking controller and camera on the same subnet or on a routed path with the required UDP ports permitted.

Sources

Ports, baud rates and command sets vary by manufacturer and model; always confirm against your camera's own manual before changing a control setting.