GMSL camera not streaming over the serial link: isolate the fault

One camera on a two-camera GMSL head streams perfectly. Its identical twin refuses to stream over the same serial link, yet runs flawlessly the moment you flip it to its USB mode. That pair of facts — one interface healthy, one dead — is not a driver problem waiting for a better log line. It is a short fault tree, and every branch ends in a decision: fix the host, replace a coax, or condemn the camera and claim a replacement. This guide gives you the swap test that separates the branches, the evidence the control channel hands you for free, and the proof set a warranty claim needs. It is written for anyone integrating GMSL 3D cameras on embedded robot heads, AMRs and fixed inspection cells.

What the symptom already proves

A GMSL link — Gigabit Multimedia Serial Link — is a serializer at the camera joined to a deserializer at the host by one coaxial cable. That single cable carries two services at very different rates: the forward video stream, up to 6 Gbps on GMSL2-class parts, and a bidirectional control channel, up to 187 Mbps, that tunnels I2C between host and camera.

Video gets roughly 32 times the bandwidth of control. Any fault gentle enough to leave the control channel answering — firmware flash over the link, device metadata, temperature readback, IMU telemetry — has been tested 32 times harder on the video side and failed there. So your signature splits five ways: a link that never locks (control dead too), a marginal coax or connector, a dead port, a host configuration problem, or a dead video path inside the camera. The swap test below picks one branch with evidence instead of a hunch.

Clear the simple causes first

Work down this list before touching any connector. Each item clears a branch that mimics a dead camera.

1. Selector and seating. Dual-interface 3D cameras pick USB or the serial link with a switch or a separate connector. Confirm the selector sits fully in the link position, then reseat the coax at both ends. A half-mated connector passes the low-rate control channel and still starves the video.
2. Firmware. Flash both twins to the same build over whichever interface works, then retest. Twins on different builds produce exactly this one-camera failure, and the firmware mismatch after a shared camera swap article walks that case end to end.
3. Host drivers and deserializer configuration. A GMSL capture board needs its driver stack loaded and its deserializer configured for the camera's lane mapping. On a stock host image, the control channel still enumerates the camera while video never starts — the symptom looks identical to dead silicon. Run the capture board's set-up procedure first.
4. Launch the unit alone. Multi-camera example scripts that bind devices by index can silently skip one camera, and the skip looks like a dead link.

Only when all four come back clean does the swap test earn its verdict.

The swap test: convict or clear each part

Change one thing at a time, and reboot between changes — most hosts lock the link at boot, so a hot swap can mask a fix.

1. Pick the reference: the twin that streams on this head.
2. Move the suspect camera onto the reference camera's connector and coax — a port and cable that are streaming video at that moment.
3. Reboot the host, launch the suspect unit alone, and record whether video starts.
4. Put the reference camera back on the same connector and confirm it still streams. Now the port and coax are proven good twice over.
5. Interrogate the suspect over the link: run a firmware check, read device metadata and temperature. If those answer, the link lock and control channel are alive and the fault is the forward video path.

If the suspect stays silent on a port that streams the reference, and its own control channel answers over the same coax, the video path inside the suspect is dead. If the suspect streams on the borrowed connector, walk the fault back: retest the original coax on the reference camera, then the original port. The USB link checks after a cable swap method applies to the seating and wiring steps either way.

Worked case: two cameras, one head, one verdict

A real head, run to ground: two identical 3D cameras on one multi-port GMSL capture board, both twins on the same firmware build. Unit A streams on every connector it touches. Unit B streams over its USB mode and does nothing over the link — no video on its own connector, no video on Unit A's connector, no video after a reboot on either. Over the link, Unit B's control channel answers every question: the firmware update runs, device metadata and temperature read back, and the IMU streams. The vendor's tools reach the device over the link and still refuse to start a stream, and the SDK logs add nothing — normal for this signature, because the control layer reports success while the video pipeline never sees a frame.

The verdict follows from the table: proven port, proven coax, live control channel, dead video — the video serializer in Unit B has failed. The camera maker confirmed a hardware fault and issued a replacement; the evidence above is what closed the claim in one pass.

The decision for each outcome

Match your swap-test result to a branch and act on it:

• Control dead over the link, on any connector or coax. The link never locked. Seat the coax, try another, then check the capture board's driver and deserializer set-up.
• Control alive, video dead on every port and coax. The camera's video serializer has failed. Claim the replacement — this is the worked case above.
• Suspect streams on the reference's coax, same port. The camera is fine; the coax is not. Retire it and fit a new one from the camera maker's accessories.
• Suspect streams on the reference's port, same coax. The port or its connector is the fault. If neighbouring ports stream, treat the one port as a deserializer fault and leave it out of the head.
• The reference camera also fails on a given port. Host fault: driver, deserializer configuration or dead port. The cameras are innocent.

A unit that fails the swap test inside its warranty window goes back for replacement, and cameras we ship carry at least a 3-year warranty — a confirmed hardware fault costs you the claim paperwork, not a repair bill. Where the symptom is repeats rather than one dead unit, the fault isolation for repeatable unit-specific failures procedure is the companion method.

Run the head over USB until the replacement lands

The USB mode is a working fallback, not a demo: the sensor and depth engine are the same silicon, so bench validation, calibration and low-rate tasks can continue while the claim runs. Three limits decide whether it carries your task:

• Cable length. Passive USB 3 copper manages a few metres at best; the USB cable length limits for 3D cameras guide has the working numbers per standard. A short certified lead from the camera data cables range or the accessories finder covers the physical side.
• Bandwidth. Depth plus colour can saturate a 5 Gbps USB 3 port once anything else shares the host controller. The depth and colour stream bandwidth check shows the test that catches it.
• Two cameras on one host. The bus is shared, not switched: run one camera per controller where you can. The bandwidth and power budget for multiple USB cameras and the interface-claim fix for two depth cameras cover the two classic pitfalls.

Treat USB as scaffolding. The whole reason the head speaks GMSL is reach and timing beyond USB; once the replacement is mounted, re-run the GMSL path and retire the fallback.

Prevent it on the next head

• Commission with a swap record. Stream every camera on two connectors before you close the panel. A unit that has only ever worked on one coax is hiding a marginal cable or port.
• Keep twin firmware matched, and write the build numbers on the head's label next to each connector.
• Log control readbacks as a go/no-go. Temperature and metadata over the link at every power-up take seconds and prove the link locked.

When the claim closes and the head needs a new unit, spec the family before the model: the 3D camera finder filters the 3D sensor range by type. Projected structured-light stereo covers dense depth at close range, and ToF sensing covers volume and navigation:

Build the rest of the head around the camera in the system configurator. If a claim needs a second opinion on the evidence pack, the contact page reaches the applications team, and more fault-isolation procedures sit on the 3D vision topic page.