No data received from sensor on a CSI camera: fix the flex link

A camera that probes cleanly and then logs "No data received from sensor" — in full, a control-callback line reading "Camera control callback: No data received from sensor" — is not reporting a dead sensor. It is reporting that frame data never arrived over the MIPI CSI-2 lanes. When the same camera model with the same settings works on half your boards and fails on the rest, the varying quantity is physical: connector seating, latch position, flex orientation, flex length or routing. This guide ranks the causes in order of probability, gives a bench test for each, shows the swap matrix that isolates the faulty element in ten minutes, and works the lane-rate arithmetic that tells you whether a marginal link was ever going to hold.

What the error text tells you

A CSI link carries two channels over the same flex: a low-speed control bus that reads and writes the sensor's registers, and the high-speed differential pairs — one clock lane plus one to four data lanes — that carry pixels. The error string separates the two for you. If the control layer opened the sensor and read its ID, power and the control bus are alive, and the failure sits in the lane pairs, the clock lane, or the receiver configuration that must match them.

That is also why reseating a flex fixes it: one half-engaged contact in a lane pair kills the pixel path while the control bus, which tolerates far worse, keeps answering. Keep the two failure classes apart before choosing a fix. A sensor that is not detected at all points at rails or control bus; that path is covered in MIPI sensor detected but streaming fails: power, clocks, device tree. A sensor that answers but never streams is the case here, and sensor detected but frames time out: separating I2C from MIPI failures works that split step by step.

Why identical boards behave differently

Identical settings on every unit remove software from the suspect list, which leaves assembly variance:

• Insertion depth. The flex must bottom out in its connector. A housing that recesses the connector differently from unit to unit — a machining or stack-up tolerance — leaves some boards half-seated, with contacts that look closed but only skim.
• Latch position. A flip or slide latch that is not fully closed gives just enough pressure for the control bus and not enough for a lane pair running near 1 Gbit/s.
• Flex orientation. The contacts must face the specified side at each end. A flex flipped at one end clocks nothing.
• Flex length and build. A long, unshielded ribbon loses margin that a short molded flex keeps.
• Routing. A run taped beside an antenna or a switching regulator fails only when that source is active.
• Carrier revision. Two carrier versions can map lanes differently; the camera then works everywhere except that board.

Failures that appear only after minutes of running belong to the same family, with heat and vibration as the moving parts. Why a CSI camera times out after a working period collects those mechanisms, and they respond to the same physical checks below.

Work the causes in this order

1. Reseat both ends. Open the latch fully, withdraw the flex, re-insert it square until it bottoms out, close the latch until it stops. Then stream for ten minutes. This one step clears most "works on some units" reports.
2. Check orientation at each end. Compare the contact side with the carrier silkscreen or assembly drawing, end by end. Press lightly on each end while streaming: if the picture returns under pressure, an end is mis-inserted or unlatched.
3. Reseat the camera module's secondary connector. Modules built as a sensor board joined by a short second flex have that second connector as an equal failure point. Same procedure, both ends.
4. Swap in the shortest known-good flex. Keep the flex that shipped with the camera as your reference and measure the run you were using. Carrier manuals quote roughly 15 cm as the workable limit for a standard MIPI D-PHY flex, so a 30 cm unshielded ribbon is a suspect on its own. The length rules per connector type are in MIPI FFC cable length limits for split camera modules, and the latch and length checks for a replacement ribbon are in board-level camera ribbon cable replacement: latch and length limits.
5. Reroute the flex. Keep it clear of antennas, switching regulators and motor cables, and do not fold it sharply. Toggle the suspected source while streaming: a Wi-Fi transmit burst or a motor start that correlates with dropped frames is your answer.
6. Replace a damaged flex. Creases, a cracked stiffener or contaminated contacts do not recover. Fit a new flex to the written specification rather than straightening the old one.

Swap-test to find the faulty element

Run four combinations, using a camera and a flex that stream on another board as your known-good references:

If the suspect camera and suspect flex stream happily on the good board, the original board's assembly was the fault, and you are back at steps 1 and 2. Otherwise the decision follows the failure: a fault that moves with the flex means scrap it and fit a specified replacement; a fault that moves with the camera module means replace the module, and the board camera evaluation checklist is the acceptance test either way.

A fault that stays with the board sends you to the receiver side: check the lane count and mapping first, in MIPI 4-lane camera on a devkit carrier board: check lanes first and CSI camera carrier board compatibility: what to verify. Receiver-side faults are rare, and they fail every camera on that board rather than one assembly; why an edge-AI module's CSI link fails to deliver camera data to its video input is a worked receiver-side example.

Lane rate and margin: the arithmetic

The 15 cm figure is where signal integrity runs out of margin for a typical mode, not a magic constant in the standard. What decides it for your build is how close the mode pushes each lane to its ceiling. Allow about 20% for CSI-2 packet framing:

Take an 8 MP module in raw 10-bit mode, 3280 × 2464 pixels at 15 fps over two lanes:

• 3280 × 2464 = 8,081,920 pixels per frame
• 8,081,920 px × 15 fps = 121,228,800 px/s
• 121,228,800 px/s × 10 bit = 1,212,288,000 bit/s ≈ 1.21 Gbit/s payload
• 1.21 Gbit/s × 1.2 ≈ 1.45 Gbit/s on the wire
• 1.45 Gbit/s ÷ 2 lanes ≈ 727 Mbit/s per lane

Most application processors run MIPI D-PHY lanes up to about 1 Gbit/s per lane, so this mode asks 73% of the ceiling. A 15 cm flex holds that. A 30 cm unshielded flex closes the eye first at exactly that margin, and the failure surfaces under load as the same error string. Cut the frame rate to 8 fps and the demand falls to 8,081,920 × 8 × 10 × 1.2 ÷ 2 ≈ 388 Mbit/s per lane, 39% of the ceiling — the same hardware now runs all day.

Decision: on a flex at or beyond 15 cm, keep the required per-lane rate below about half the lane ceiling. The worked example fails at 73% and holds at 39%. Lower the frame rate, bin the sensor or drop the bit depth to get there; the lane arithmetic generalizes in MIPI CSI-2 frame rate estimation: lanes and data rate.

When the fix is a different interface

Commit to the boundaries and the choice follows:

• Camera within about 15 cm of the processor: keep CSI and fix the assembly.
• Camera fixed 0.3 to 2 m away: plain CSI is out. Move the processor board to the camera, use a serializer pair made for the distance, or change interface.
• Board has a USB3 host port: a USB3 board camera is the drop-in path. Passive USB3 holds to roughly 3 m on a proper cable; USB cable length limits for 3D cameras: keeping the data link alive works the number out.
• Longer runs or an electrically loud cell: GigE over standard Ethernet cabling reaches tens of meters and shrugs off the interference that kills a flex.

For the CSI-versus-USB question on an industrial gateway specifically, CSI versus USB camera connections on an industrial IoT gateway compares the two in that exact setting.

The board-level cameras range covers both replacement interfaces, and the camera finder filters by interface, resolution and shutter. For the USB3 path, the LS-BCM-0003 pairs a 3.1 MP IMX252 global-shutter sensor with USB3 and streams up to 120 fps.

For the longer haul, the LS-BCM-0020 is a 6.3 MP GigE board-level camera with an IMX178 rolling-shutter sensor, rated 18 fps.

Both take the same family of high-flex cables from the camera cables range:

The USB3 cable suits a drag-chain run to a moving mount; the GigE cable adds screw locks for a fixed run under constant vibration. To size the replacement link end to end, start the configurator at the camera step, and filter the cable options by length and type in the accessories finder.

Keep it from coming back

• One flex specification per build: pin count, pitch, contact type and length, written into the build sheet, and at or under 15 cm unless you have bench-proven that exact part at your frame rate.
• A latch-closed check at both ends in the assembly step, followed by a light tug on each end.
• Strain relief and a gentle bend radius, with no folds and no routing past antennas or regulators.
• A housing review before machining: every connector must be reachable and able to bottom out, and a port recessed too deep for its plug is a fault you can catch in CAD — board level camera housing design from maker STEP files shows the model-first approach.
• A burn-in of 30 to 60 minutes of continuous streaming per unit before it ships; marginal seating and half-closed latches drop out inside that window.

Work the physical causes in order, run the swap matrix before touching a driver or device tree, and size the lane rate before blaming the cable. If the matrix lands on the camera module and the pattern survives a replacement, send the swap results through the contact page — the matrix output cuts the diagnosis time sharply.