One camera in a stereo pair shows no live image: check the slot first

A stereo rig fails in a characteristic way: one viewport stays white or frozen while its partner camera streams, every status indicator shows green, and a software reinstall changes nothing. When that happens right after the PC has been opened or serviced, suspect the capture card's seat before the sensor. A dual-camera card parked in a reduced-width or chipset-attached PCIe slot cannot carry both synchronized streams, and one view dies first. This guide ranks the likely causes, gives the bandwidth arithmetic that decides the case, and walks the five-minute test that separates a seating problem from a sensor fault.

Why one blank view points at the host interface

A synchronized pair is one acquisition, not two. Whether you build it from two GigE area scan cameras, two USB3 models or an integrated stereo 3D sensor, both streams converge on one host path — typically a multi-port network card or a frame grabber — and contend for the same PCIe lane budget. Digital image correlation rigs, robot-guidance pairs and metrology benches all share this architecture. Green status lights tell you the link trained and the device answered enumeration; they say nothing about throughput. A card seated in the wrong slot still passes every detection check, then starves under load.

The camera whose stream misses its deadline first is the one that blanks, and because enumeration order is stable, it is usually the same camera every time. If the rig measured correctly before the PC was serviced, moved or upgraded, the fault almost certainly moved with the cards rather than the cameras. That is also why reinstalling the measurement software rarely changes anything: the pixels never reach the host in the first place.

Likely causes, in order of probability

If the rig worked before and failed after service, start at rank 1. If it never worked, run the single-camera checks in the lower rows first.

Ranks 1 and 2 are the same fault seen twice: the wrong seat, and the load that exposes it.

The arithmetic that decides the slot

One lane moves a fixed payload per direction: PCIe 2.0 runs 5 GT/s per lane with 8b/10b coding, leaving about 4 Gb/s of payload; PCIe 3.0 runs 8 GT/s with 128b/130b coding, about 7.9 Gb/s. Slots wired x4 or x8 multiply the per-lane payload accordingly. Chipset-attached slots reach the processor over a shared uplink that is typically about 32 Gb/s, already partly consumed by USB, storage and the onboard network. The PCIe slots and chipsets a frame grabber needs map this in detail, as does slot compatibility for GigE cameras.

A pair a narrow slot cannot carry. A 12 MP USB3 camera such as the LS-CMR-0166 streams 4000 × 3000 at 30 fps. At 8 bit per pixel, each camera puts 4000 × 3000 × 8 × 30 = 2.88 Gb/s on the wire, so the pair loads its shared host path with 5.76 Gb/s. On one dual-port controller card seated in a PCIe 2.0 x1 slot, that path offers 4 Gb/s: the pair runs 44% over budget, the second stream misses its deadline, and one viewport goes white. The same pair on a PCIe 3.0 x1 lane has about 27% headroom — workable, but tight against bursts.

A pair that fits sends you elsewhere. Two 2 MP GigE cameras at 1920 × 1200, 8 bit and 30 fps load a dual-port NIC with 1920 × 1200 × 8 × 30 ≈ 0.55 Gb/s per camera, 1.1 Gb/s for the pair. That is 28% of even a PCIe 2.0 x1 lane, so slot placement cannot be the culprit; the blank view has to come from binding, trigger or camera, in that order.

The 10GigE case. Two cameras running near full rate on a 10GigE card put close to 20 Gb/s on the board. That rules out every x1 seat and calls for PCIe 3.0 x4 (31.5 Gb/s) or wider, processor-attached.

The five-minute slot test

1. Swap the cables at the card. Exchange the two camera cables where they enter the host interface and re-enumerate. If the blank view follows the port, the fault is the card or its seat. If it stays with the same camera, go to step 6.
2. Read the negotiated link. Device Manager's Details view in Windows reports the current link width and speed for the selected card; on Linux, lspci -vv prints the negotiated width and rate in its link-status line. A multi-port card linking at x1, or at a generation below what the slot is wired for, confirms the seat.
3. Move the card. Power down and move it to the processor-attached slot: normally the longest slot nearest the CPU, wired x8 or x16 from the processor's own lanes. Seat it fully and fasten the bracket.
4. Re-read the link. After reboot the negotiated width should match the slot's wiring, and the seat should now carry the pair load you calculated above.
5. Re-bind the cameras. Port order can change after a card move, so assign left and right by serial number, not by port index.
6. Only now suspect hardware. Open the blank camera alone in a plain viewer, swap its cable, check its lens cap and trigger line. If the image is still empty, the stage-by-stage pipeline probe takes over from there.

Fix and re-pair the rig

Moving the card restores the bandwidth; the steps below keep the rig measuring afterwards.

• Bind by serial number. Re-enumerate and assign each camera to its calibrated side by serial number, never by port order — reliable port assignment in multi-camera systems shows the pattern.
• Check the trigger path. A synchronized pair lives on one shared pulse. Route that pulse to both camera inputs or generate it on the card: triggering two cameras from one input and stereo trigger synchronization cover the wiring and the timing.
• Recalibrate only if the optics moved. Swapping a card changes no geometry. If the left and right images trade places, the calibration no longer matches the rig — reassign the cameras before touching calibration.

When the slot checks out

• Changed binding. A BIOS update or a re-seated card can reorder ports, and the software then reads the wrong camera on each side. Serial-number binding fixes it in minutes.
• Trigger starvation. The blank camera free-runs happily in a single-viewer test but shows nothing in the rig: the pulse is not reaching it. That is wiring and timing, not bandwidth.
• Shared USB bandwidth. A hub is not a bandwidth multiplier. A 5 Gb/s USB3 port carries roughly 3.5-4 Gb/s of real image data, so two 12 MP, 30 fps cameras at 5.76 Gb/s combined can never share one hub; each needs its own controller root, and that controller is itself a PCIe device subject to the same seat arithmetic. The hub bandwidth budget and the two-GigE-cameras-on-one-host budget work both cases; with Ethernet, a switch's uplink must carry the aggregate too.
• Depth-side symptoms. If both views stream and the depth output jitters instead of going blank, the cause is calibration, mounting or sync. That separate failure is covered by the stereo depth jitter and IMU drift guide.
• Blank versus absent. A view that never enumerates at all is a detection fault, not a bandwidth fault; color camera not detected while monochrome streams work walks that path.

Prevent it with a slot map

After any service, a two-minute routine keeps the rig honest:

• Write the card-to-slot map into the station file, including each slot's wired width, so the next service cannot improvise.
• Read the negotiated link width after reassembly, before the first capture; firmware updates and cleared settings can change lane assignment silently.
• Keep the pair-load arithmetic beside the map, so the slot class stays a calculation rather than a habit.

Cards that carry a stereo pair

A GigE pair seats naturally on one dual-port PoE card, one camera per port, one lane budget to check.

At 10GigE the lane budget dominates; pick a card with enough ports and give it the slot class the pair-load arithmetic demands.

Frame grabbers take several cameras on one board — four GigE ports, dual 10GigE, or a four-port XoF card with 40G total bandwidth — when the rig grows beyond a pair.

Size the seat first, then the card. The accessories finder filters frame grabbers by interface and port count, the camera finder narrows the GigE area scan cameras and USB3 models, and the configurator steps through the host interface with the rest of the rig. If a blank view survives every test above, contact us with the negotiated link width and the pair load — those two numbers usually end the discussion.