3D camera sequence index mismatch: fixing the imager lockup

The trace is unmistakable once you have seen it: your grab call returns a sensor timeout, the viewer shows no live image, and the sensor's trace tool prints the same three lines every couple of seconds — a sequence index mismatch in the pseudo data, a frame completion timeout of 2000 ms, and a ring-buffer slot that 'has not been locked'. This guide is for integrators running a time-of-flight or structured-light 3D sensor on a line. You will learn what each trace line means, how to read the rhythm of the log to tell a transient dropout from a true lockup, and the recovery order — power, configuration, firmware — that restores the stream with the least lost time.

What the two error lines mean

An indirect time-of-flight (ToF) imager does not capture depth in a single exposure. It illuminates the scene with modulated infrared light and records a set of raw frames at different phase offsets of that modulation — typically four, at 0°, 90°, 180° and 270°. Depth at each pixel is computed from the phase differences across the whole set. The raw per-pixel record of one phase capture is what the trace calls the pseudo data, and every capture in the set carries a sequence index.

The RawDataIntegrityCheck component compares the sequence index of the capture that just arrived with the index it expected next. The message 'Sequence index in pseudo data (2) is not equal to expected sequence index (1)' means one raw capture was skipped or duplicated — the imager waited for capture 1 and capture 2 arrived. Depth computed from a misaligned set would be wrong at every pixel, so the check discards the set.

The rejection lands in the TriggerStateMachine, which owns one acquisition from the first phase to the last. It allows the sequence 2000 ms to complete, then logs 'sequence did not complete after waiting 2000 ms -> cancel acquisition' and cancels the entire acquisition, not just the offending frame. When the fault persists, every acquisition dies this way, which is why the host sees a sensor timeout and the viewer stays empty.

The FilesystemRingBuffer warnings that trail each cancel — a slot that 'has not been locked', then a warning that the slot could not be released — are debris, not a second fault. They land within a millisecond of the cancel: the cancelled acquisition never wrote its slot, so there is nothing for the release step to free. They stop the moment the sequence error stops.

Read the rhythm of the trace before touching anything

The timestamps tell you whether you have a dropout or a locked imager before you unplug anything. Take four consecutive events: the integrity error at T = 187964.5280 s, the cancel at T = 187966.7194 s, the next integrity error at T = 187966.9278 s and the next cancel at T = 187969.1198 s.

• 187966.7194 - 187964.5280 = 2.1914 s, about 2.19 s from error to cancel: the 2000 ms completion timeout plus handling.
• 187966.9278 - 187966.7194 = 0.2084 s, about 0.21 s from cancel to the next acquisition attempt.
• 187969.1198 - 187966.7194 = 2.4004 s, about 2.40 s for one complete failure loop.

60 s / 2.40 s = 25 cancelled acquisitions per minute, about 1500 per hour, and the slot number in the ring-buffer warning climbs loop after loop (1442, 1444, 1446) because the buffer keeps advancing without releasing. That self-sustaining loop is the signature of a wedged state machine: the imager retries, fails and never resynchronises.

A single mismatch line followed by minutes of clean frames is a different problem — a lost packet or an electrical blip — and does not justify a power cycle. On 2D grab stacks a sequence counter that jumps after frame timeouts has its own causes, covered in V4L2 sequence counter jumps after frame timeouts: what it counts.

Likely causes in order of probability

Start at the top. This exact trace — a repeating loop with an empty live view — is the wedged state machine, and one full power removal clears it in most cases. A lockup that returns within hours points at rows two to four, in that order. Scattered single mismatch lines with clean frames between them point at cabling and shielding, not at the sensor's internal state.

Recovery procedure

1. Save the trace with its timestamps. If the lockup returns, the slot numbers and loop period are the evidence you will want.
2. Close every application holding the sensor — your grabber code, the viewer, any second client on the same address. Two clients contending for one imager can itself slip a sequence index.
3. Remove power completely: unplug the network cable from a PoE port or disconnect the supply for about ten seconds. A software disconnect does not restart the imager firmware; only losing power does.
4. Reapply power and wait until the sensor answers on the network. Bring the stream up in continuous mode first — after a power cycle the acquisition mode can need re-enabling before any frame arrives, as Acquisition timeout after power cycle: enable continuous transfer explains.
5. Watch one minute of trace in continuous mode. Clean lines mean the lockup is cleared.
6. Restore your application and re-enable the production trigger configuration one setting at a time, checking the trace after each change.
7. If the mismatch returns within the first minutes, stop cycling power and move to the alignment work below.

For restart failures that sit on the host side rather than inside the sensor, Diagnose camera stream restart timeouts in vision systems covers the grab-loop half of the problem.

When the power cycle does not hold

Align firmware and SDK. A sensor that locks again within hours is usually telling you its firmware and the host SDK drifted apart — one side was updated and the other left behind. Pull the sensor's firmware version string and the SDK version on the host, confirm they are a supported pair, and update them together. Two closely related failure modes are worked through in 3D camera header version mismatch: fix firmware and SDK alignment and 3D camera SDK v2 firmware version mismatch: no device found.

Check the power delivery. A ToF imager draws its highest current while the illuminator runs the phase set, and a port that sags at that instant produces exactly this class of fault. Give the sensor its own powered port instead of the far end of a shared cable bundle: the MV-GE2002P dual-port PoE NIC puts a dedicated powered port on the host, and the wider range of interface cards sits with the frame grabbers.

Check the configuration owner. Every settings change should reach the sensor from one place, with the stream stopped. Editing the imager configuration while an acquisition is mid-sequence is a reliable way to slip a sequence index. If your no-frame symptoms began right after a configuration push, read Camera configuration revision mismatch: fix no-frame errors.

Check the trigger wiring. A hardware trigger input that the configuration expects but nothing drives will cancel every acquisition, and so will a floating input picking up noise. Use shielded cable and a single trigger source, and confirm the mode latches — Hardware trigger stops after one frame: check acquisition mode describes the mild version of the same wiring fault.

Stop it coming back

• Update firmware and SDK as a pair, and retest the trace after every update on either side.
• Keep one configuration owner per sensor, and stop the stream before changing settings.
• Run shielded trigger cabling from a single source; never leave a configured hardware input undriven.
• Measure the port draw with the illuminator running, and keep supply margin at the sensor.
• Keep the housing inside its temperature rating; a warm ToF sensor locks up far more often than a cool one.
• Add a host watchdog: five consecutive completion timeouts at a 2.40 s retry period is 5 × 2.40 s = 12 s, a trip point that ignores single dropouts and catches a real lockup. Cycle power through a switched port, but keep the cycling rate low — frequent power cycling wears the illuminator, a trade-off quantified in Depth camera emitter on/off cycling: wear, power and duty cycle.

If the sensor has to be replaced

A sensor that still locks up on a matched firmware and SDK pair, a dedicated powered port and a sane temperature has a hardware fault: replace it rather than keep chasing it. Replace like for like when your measurement recipe depends on the unit's factory calibration. When you are free to re-specify, match the technology to the measurement: a depth/ToF camera for scene-level 3D, presence checks and volume, where coverage matters more than profile density.

For height and width on a moving web, a laser profiler; for static, high-detail scans of a fixed volume, projected structured light:

The full range is behind the camera finder, and more set-up pieces are on the 3D topic page. If the trace still loops after the alignment work, send it with timestamps through the contact page — free expert support comes with every order, and the loop period and slot numbers in your file get you a concrete answer fastest.