Locked status on a depth camera: meaning and restrictions

The status line of your depth camera reads Locked next to the firmware version, and nobody wants to bolt a restricted device into a robot cell. This guide is for integrators commissioning depth cameras on embedded Linux controllers. In the next few minutes you will read the flag correctly, confirm it restricts nothing you use, and learn where real depth-camera limits — frame rate, precision, version mismatches — actually come from.

What the locked status on a depth camera actually means

Decision first: a locked depth camera is a normal production unit. The flag records only which grade of firmware the camera runs — the public build that ships to every customer — and says nothing else about the hardware or what you may do with it.

Camera makers build two grades of firmware. The public build goes into every unit that leaves the factory. The second grade is an internal engineering image with extra debug and development tooling, used by the maker's own engineers during sensor characterization. When your SDK or viewer reports the camera as locked, it is telling support which of the two you hold. Firmware 5.15.1 reported as locked on an embedded Linux controller is a healthy, complete camera.

The engineering image is not a hidden feature tier. Its extra tooling exists for factory bench work, it is not published for customers, and no production task needs it: acquisition, triggering, streaming and every published control behave the same on a locked unit.

What the flag restricts, checked item by item

Nothing you will touch in production. Run down the list:

• Connectivity: USB and Ethernet enumeration, IP set-up and streaming behave exactly as on any shipped unit.
• API access: every published control — exposure, resolution, triggering, depth units — is open to your code.
• Frame rate and resolution: all published modes run; the flag caps nothing.
• Accuracy: same optics, same calibration data, same depth algorithms as any other shipped camera.
• Updates: you install public firmware through the normal camera firmware update workflow.

Three things the flag is confused with, and is not:

• A license or demo lock that withholds features or stamps images until activation. A locked depth camera needs no activation and stamps nothing.
• A read-only setting. Some SDKs show individual parameters as locked — a pixel format that greys out until you set the scan type is the classic case, and it has its own fix: 3D camera pixel format locked read-only: set the scan type first.
• A region or network restriction. Depth cameras carry none.

Locked builds, extended tuning mode and presets

Some depth camera families expose an extended tuning mode above the standard controls. Its registers interact in complex ways, which is why the maker tunes shipping defaults with automated methods rather than leaving each value to users. Treat the mode as an experiment bench: change one register, log the depth map, and push a saved settings table before you ship — the procedure in depth camera calibration reverts to factory: push the saved table is the pattern to follow.

Worked example: depth precision of a locked stereo camera at 1 m

The flag never enters a performance number. Here is the proof with the standard small-disparity stereo error model, using values typical of a compact stereo depth module:

• Baseline B = 60 mm
• Output width W = 1280 px, horizontal field of view FOV_h = 90°
• Sub-pixel disparity precision σ_d = 0.25 px (typical range 0.1–0.5 px with sub-pixel refinement)
• Standoff Z = 1.0 m = 1000 mm

In words: depth noise grows with the square of the distance and falls in proportion to the focal length in pixels and the baseline. Compute the focal length in pixels, then the depth uncertainty:

Arithmetic:

• f_px = (1280 px / 2) / tan(45°) = 640 / 1.00 = 640 px
• σ_Z at 1.0 m = (1000 mm)² × 0.25 px / (640 px × 60 mm) = 250,000 / 38,400 ≈ 6.5 mm
• σ_Z at 0.5 m = (500 mm)² × 0.25 px / 38,400 ≈ 1.6 mm
• σ_Z at 2.0 m = (2000 mm)² × 0.25 px / 38,400 ≈ 26 mm

The decision: locked or engineering build, these numbers are identical, because both run the same depth pipeline — the flag does not appear anywhere in the equation. Set your threshold from the tolerance. If the inspection must hold ±2 mm at 1 m, this module misses by more than 3× at that standoff; halving the distance gives 1.6 mm, inside ±2 mm, and each halving of distance cuts the error fourfold. The 3D camera working distance and positioning guide walks the standoff choice; changing sensor class is the other lever, and it is the one the next section covers.

When a locked camera misbehaves, look here first

A locked flag beside a real symptom points at the usual suspects, in order of probability:

1. Version mismatch after an update or a shared-camera swap — detection failures and wrong ranges come from SDK, firmware and header misalignment, not the build grade: see 3D camera header version mismatch: fix firmware and SDK alignment and depth camera firmware mismatch after a shared camera swap.
2. Trigger and stream settings — low frame rate on software trigger is a trigger-mode and data-stream problem: 3D camera frame rate low on software trigger: mode and data streams. Sanity-check the budget: at 30 fps the frame interval is 1000 ms / 30 ≈ 33.3 ms, so a capture loop slower than that drops frames whatever the status string says.
3. Buffer set-up — an empty depth image is a schema-mask problem, not a lock: 3D camera SDK returns an empty depth image buffer: set the schema mask.
4. Physics — speckle, reflections and temperature move depth data more than any build grade: depth camera performance vs operational temperature range. Decode the confidence image bitflags and mask invalid pixels before you judge depth quality.
5. Timing — when capture feels slower in your code than in the viewer, compare like with like: 3D camera capture time slower in the API than in the viewer.

More depth-camera field notes sit on the 3D vision topic page.

The supported path to more control

Tune where the maker gives you room:

1. Presets and standard controls first. Resolution, ROI, exposure and emitter settings move depth data far more than any register behind them, and the depth unit and precision settings decide what actually arrives in your buffer. ROI is a genuine performance knob — for layer-by-layer scanning, see configuring depth-camera ROI for one-inch Z-layer scans.
2. Extended tuning mode, where the family offers it — validated on the bench, saved, and only then shipped.
3. Firmware from the maker's own release channel, installed through its update workflow, with SDK and firmware kept aligned.

There is no supported conversion from a public build to an engineering image, and no need for one: those builds add bench tooling, not production capability. If a capability genuinely seems missing, raise it with the maker's support channel — that request is what drives features into public releases.

After any firmware or settings change, re-check at the same standoff and angle. Mount the camera on one of the camera stands and slide stages, mark the height, and the geometry stays repeatable across the test.

Choose hardware by tolerance, not by the flag

If the error budget above says stereo cannot hold your tolerance, the fix is sensor class. For volume measurement, palletizing and coarse robot guidance, structured-light, stereo and ToF depth cameras each cover a band of the accuracy-versus-range spread:

When the tolerance at a given standoff is tighter than stereo noise, the laser-profiling class is the one to shop: a profile sensor sweeps a calibrated light line across the part and returns a height value per pixel.

Conveyor-scale 2.5D inspection pairs the sensor with line illumination: the MV-HLVS-16K100-L60 combines a 16K sensor with a 600 mm emitting area and a 120 kHz sampling rate for height and profile work at belt speed.

Browse the 3D sensors category, filter the depth camera finder, or start at the system configurator and enter standoff and tolerance first.

The decision

A locked depth camera is the public production build, and it restricts connectivity, API access, frame rate, resolution and accuracy by exactly zero. Ship it. Spend the commissioning time on standoff, calibration and settings, using the stereo error model above to set the standoff from your tolerance. If the tolerance rather than the flag sent you shopping, start from the sensor classes above; if you want a second opinion on a build of materials, the contact page reaches the application engineers.