Every long camera cable eventually delivers a damaged packet, and on a CSI-2 receiver that error should cost exactly one frame. Too often it costs the whole capture stack: the grab call never returns, the stop call queues behind it, and a board running six cameras goes dark until someone pulls the power. The recovery design that keeps the error contained has four parts — grab timeouts sized from the frame period, a bounded escalation ladder, one capture process per camera, and physical checks that decide whether a noisy run belongs on CSI-2 at all. It is written for engineers capturing from several CSI-2 cameras on one embedded board over SerDes links.
Why does one corrupt CSI-2 frame stop every camera?
Because the receiver below your code is shared: when a damaged packet wedges the driver or the capture service that owns the receiver, every session waiting on that hardware stops with it — on a six-camera rig, six idle cameras, not one.
A CSI-2 frame travels as packets, and every long packet ends in a 16-bit CRC the receiver can check, so the hardware always tells you which packet died. The failure is in the layers above. The MIPI CSI-2 capture pipeline runs sensor, receiver, kernel driver, user-space capture service and finally your code, and a stall at any stage below your code blocks every session that shares it. Three design mistakes turn one bad packet into a permanent hang: no grab timeout, recovery code that runs inside the faulted session, and a restart path that shares a lock with the wedged service.
What should a transmission error actually cost you?
One frame: a CRC failure damages only the packet it lands in, frames completed before it are whole, the next frame starts fresh, and the correct response to an isolated error is to drop the damaged frame and keep grabbing — no session restart at all.
Build the grab loop with three outcomes, not one. A good frame goes to processing, a flagged frame is discarded and counted, and a timeout starts the escalation ladder below.
Where your transport hands you an incomplete buffer instead of an error flag, apply the same rule: discard the incomplete frame and grab a fresh one, and never attempt to salvage a torn image. An isolated error every few hours in a 24-hour soak is a normal event on a multi-metre run. What is not normal is a rising rate at steady conditions, bursts of errors, or errors that start when one machine nearby switches on. Those signatures point at the cable, the grounding or the supply, and the checks section below tells you how to pin them down.
How long should a grab wait before you call the stream dead?
Two frame periods plus exposure and margin: at 30 fps with a 5 ms exposure that sums to about 90 ms, so set the grab timeout to 100 ms and declare the stream stalled after three consecutive timeouts — roughly a third of a second of silence.
Two rules keep the timeout honest. Never wait indefinitely: a sensor that needs a long time to leave standby tempts teams to remove the timeout, and that converts any wedge into a permanent hang — put the settle wait in the configuration step, before streaming starts, and keep the grab itself bounded. And re-run the arithmetic when the frame rate changes: a 100 ms timeout declares a 120 fps stream dead only after about twelve missed frame periods, while the same value on a 30 fps stream is the right size. Size the timeout to the stream, not to the board.
How do you keep one faulted stream from taking the others down?
Run each camera in its own capture process under a supervisor: a process you own can be terminated and restarted in about two seconds, while a wedged capture service you only call into cannot be cleared from outside, and its lock holds every session hostage.
This is the same containment argument as running one camera per process: a leaked handle or a hung call in one process cannot cross into another. Keep per-stream state — counters, last-frame timestamp, restart budget — inside each process, following the multi-camera session architecture. The supervisor checks each child's heartbeat, and if the time since the last delivered frame exceeds three times the grab timeout, it terminates the child and starts a new one.
| What the watchdog sees | What it does | Typical cost |
|---|---|---|
| One flagged frame, counters quiet | Drops the frame, keeps grabbing, logs it | One frame period (about 33 ms at 30 fps) |
| Three consecutive timeouts | Rebuilds that stream's capture process | 1-2 s |
| Five restarts in ten minutes | Power-cycles the camera head and raises an alarm | Seconds, plus an operator |
| Error counters climbing continuously | Leaves the link down and pages the cable or supply fix | Until the physical fault is fixed |
Two supporting settings make the ladder safe. Set the transport's buffer queue to newest-only so a stalled consumer never backs frames up into the receiver (stream buffer handling), and keep one long-lived session per process rather than cycling open and close — open-close cycles leak handles, so the escalation is a whole-process restart, not repeated stop-and-start inside one.
Which receiver settings decide how a bad packet behaves?
Two settings decide it: whether the receiver drops a corrupted packet or forwards it, and how long a capture request may wait, so choose drop-and-count, keep the wait at the timeout sized above, and poll the error counters from a separate logging thread.
Most CSI-2 receiver drivers, and the SerDes bridge chips ahead of them, expose the pieces you need: a lock-status register, per-stream error counters and, on many parts, a choice between discarding a damaged packet and passing it through. Drop-and-count keeps the damage at one frame; pass-through hands your pipeline a torn image dressed as a good one. Poll at about 1 Hz from a logging thread, never from inside the grab callback, and log every increment with a timestamp and the frame number in flight.
One check comes before all of this: a virtual-channel or port mapping mistake produces exactly the symptoms of a broken link, including errors that move between streams when you change the capture order. Work through the short-frame and mode-match checks before you treat the counters as evidence of a transmission fault.
When should a noisy run move off CSI-2 onto GigE?
Move the run when the cable is long, unshielded or crosses power cables: CSI-2 and its SerDes bridges have no retransmission, so every link error is a lost frame, while a GigE link reaches 100 m on standard copper and fails in ways you can isolate per port.
Capacity is the usual objection, and the arithmetic is friendly. A 2.3 MP, 8-bit mono frame carries about 2.3 MB, so 30 fps needs 2.3 × 30 ≈ 69 MB/s, inside the roughly 125 MB/s one GigE link moves (1,000 Mb/s ÷ 8). Higher resolutions deserve a closer look, and multi-megapixel 60 fps streams may want a 10GigE layout rather than one link per head.
On the host side, a standard PoE network card is the whole investment, and two options cover most layouts.
- Interface
- GigE
- Ports
- 2 ports
- Interface
- GigE
The MV-GE2002P is a dual-port PoE NIC; the LS-FGB-0004 is a four-port PoE Gigabit card on PCIe x4. At the head end, a GigE board camera removes the SerDes pair and its cabling entirely: the MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera with an M12 mount.
- Sensor format
- 1/2.9"
- Lens mount
- M12
- Interface
- GigE
- Resolution
- Up to 3 MP
Standard Ethernet does not make packets immortal — a frame can still arrive damaged — but the failure stays inside one link, the PHY retrains itself after a glitch, and a hung head can be power-cycled from the switch port without touching the capture board. Browse the GigE frame grabbers and network cards via the accessories finder, or filter board-level cameras by interface in the camera finder.
What do you check before you blame your recovery code?
Check the physical layer and the stream mapping, in that order: a counter that climbs at steady temperature is a cable, connector or supply problem far more often than a software one, so find it with a cable swap and a 24-hour soak, not with a debugger.
Work down this list:
- Flex and swap the cable under power while watching the error counter; a counter that tracks movement is your answer. On short board-to-board runs, respect the ribbon cable latch and length limits.
- Match the format end to end — lane count, resolution and data type — because a mismatch mimics corruption; the format and wiring checks cover it in order.
- Measure the remote head's supply under load, not at idle; a head that sags when its illuminator or a neighbouring motor starts produces error bursts with no cable fault at all.
- Bisect the chain by feeding the receiver from a known-good source; on boards that accept HDMI capture through a CSI-2 input, a standard HDMI source separates receiver trouble from camera trouble in minutes.
- Soak the system for 24 to 72 hours of continuous capture with the counters logging, through at least one deliberate unplug and replug, and hold the design unfinished until the supervisor has caught every injected fault within its budget.
Where does this recovery design still fail?
This design still fails in two places: a receiver that locks in hardware needs a full board power cycle that no process design can avoid, and a watchdog without a restart cap turns a dead link into an endless restart loop — cap it at five per ten minutes and escalate.
Read the two failure signatures differently. A stall — the heartbeat stops while the error counters stay quiet — means rebuild the stream process, then the head, then the board, in that order. A flood — counters climbing continuously — means the link itself is down; stop restarting and fix the cable, connector or supply, because every restart just churns a dead port. Keep the automatic path bounded and keep a manual path: the supervisor recovers wedged processes on its own, and the operator owns the power sequence.
If you are sizing a multi-camera system now, choose the transport before the frame rates: short runs inside one housing stay on CSI-2, and long or noisy runs belong on GigE. The systems topic page collects the other recovery patterns, the configurator walks the camera-to-host chain, and the contact page puts your layout in front of the applications team before you order.
Questions
How do I log CSI-2 errors without stopping capture?
Poll the receiver's error counters from a logging thread at about 1 Hz and write each increment with a timestamp and the frame number that was in flight. Never log from inside the grab callback: a slow write there is another way to stall the pipeline. Ship the counters log with any support request so failures can be matched to frames.
What does each dropped frame cost at 30 frames per second?
One frame period, about 33 ms per isolated error at 30 fps, and a burst costs several periods in a row. Downstream logic should therefore tolerate gaps: time-stamp every frame, let consumers detect missing sequence numbers, and never assume a continuous 30 fps stream when the link crosses a plant floor.
Can I just catch the error and keep grabbing?
Try that first, because drop-and-continue is the correct behaviour for an isolated packet error. Some capture stacks never return from the call after a receiver fault, though, so pair the try with the grab timeout and keep the process-restart ladder behind it. An exception handler that works on a healthy stack proves nothing about a wedged one.
How do I test error recovery without waiting for a real failure?
Inject the faults: unplug and replug the cable mid-run, wiggle the connector under power, add cable length and lower the remote head's supply margin, then run a 24 to 72 hour soak with the counters logging. The supervisor must catch every injected fault and restart within its budget; if one injected fault wedges the whole board, the design is not finished.
Does an occasional corrupt frame mean the camera is failing?
Not by itself. An isolated CRC error every few hours on a multi-metre run is normal, especially in a plant with welders, drives and contactors. The failure signature is a rising rate at steady conditions, repeated bursts, or errors that start when one specific machine switches on nearby — that points at cable, grounding or supply, not at a dying sensor.