Triggered stereo pair plus a free-run color camera in one pipeline

You have a 3D camera with two mono sensors taking an external FSYNC trigger and a third, color sensor you want streaming all the time. The pair delivers frames; the color OutputQueue never does, has() sits at false, and deleting the trigger lines from the example pipeline changes nothing. This guide gives the diagnosis and the fix that let all three streams share one host loop: the color sensor stays in continuous mode, every stream gets its own queue, and every read blocks with a timeout instead of polling. You will see why trigger settings kill a sensor that lacks snapshot support, what a 1000 ms wait proves, and when to stop mixing modes and gate three discrete cameras on one edge.

The symptom, and what each observation proves

The failure pattern narrows the cause faster than any settings change, so start from what you already know:

That last row matters because it is the only error text you will see. An empty queue here fails silently, so the diagnosis rests on the observations above, not on logs.

Cause 1: trigger settings on a sensor with no snapshot mode

Snapshot mode is the sensor capability that lets an external edge start an exposure. Support is listed per sensor in the device's FSYNC documentation, and on this device class the color sensor does not have it. The two lines most multi-camera examples copy onto every camera node are:

camRgb.initialControl.setFrameSyncMode(dai.CameraControl.FrameSyncMode.INPUT)
camRgb.initialControl.setExternalTrigger(4, 3)

On a sensor with snapshot support, those calls start frames on the edge. On a sensor without it, frame start waits for a capability that does not exist: the sensor produces nothing, the queue never fills, and no exception names the reason. If those two lines ever landed on your color node, that alone explains a permanently empty color queue.

Deleting the lines is necessary, but on its own it is not always enough, because a second, independent fault hides behind the first.

Cause 2: polling a free-run stream with a triggered loop

has() on an OutputQueue answers one question: "is a frame buffered at this instant". It never means "no frames are coming". A free-run color sensor at 30 fps delivers a frame every 1000 / 30 = 33.3 ms on its own clock, unrelated to your trigger. A loop built around the pair wakes on trigger events, checks the color queue once, reads false, and moves on — reporting a dead stream while about three color frames per 100 ms trigger cycle arrive behind it. A false from has() almost always means "not yet"; treating it as "never" turns a live stream into a reported failure.

Setting the same FPS on all three sensors changes none of this. Equal frame rates set the cadence, not the phase: the color sensor still starts each exposure from its own clock, wherever inside your 100 ms cycle that falls. Matching numbers is not synchronization; only a shared edge on sensors that support it is.

The fix: continuous color, one queue per stream, blocking reads

Apply four changes, in this order:

1. Strip the trigger configuration from the color node. Delete both initialControl lines from camRgb and leave the sensor in its default continuous mode — the free-run discipline described in continuous camera acquisition mode for live image loops.
2. Set the trigger per node, on the pair only. Per-camera trigger configuration stops one sensor's settings leaking onto another, the habit explained in hardware trigger configuration per camera.
3. Create one OutputQueue per stream, each with its own depth. The color queue must be sized and drained for 33.3 ms arrivals, not for trigger events.
4. Read every queue with a blocking get(timeout_ms=1000). One call per frame, as covered in frame didn't arrive within timeout: one wait call per frame.

# Trigger only where the sensor supports it: the mono pair.
camLeft.initialControl.setFrameSyncMode(dai.CameraControl.FrameSyncMode.INPUT)
camLeft.initialControl.setExternalTrigger(4, 3)
camRight.initialControl.setFrameSyncMode(dai.CameraControl.FrameSyncMode.INPUT)
camRight.initialControl.setExternalTrigger(4, 3)
# camRgb carries no initialControl trigger lines: continuous free-run.

# q_left, q_right, q_color: one OutputQueue per stream, depth 4 each.
timeout_ms = 1000    # int; 30 color frame periods at 30 fps
count_pair = 0       # int; triggered stereo pairs received
count_color = 0      # int; color frames received

while count_pair < 100:              # 100 pairs = 10 s at a 10 Hz trigger
    left = q_left.get(timeout_ms)    # blocking read, own queue
    right = q_right.get(timeout_ms)
    color = q_color.get(timeout_ms)
    count_pair += 1
    count_color += 1

print(count_pair, count_color)       # expect: 100 300 (plus or minus a few)

The 10-second count is the test that proves the fix: 100 pairs and about 300 color frames, with the pair still edge-gated. Because 3 color frames arrive per 100 ms cycle but this loop consumes 1, drain the color queue each cycle or set it to keep the newest frame only — the drain pattern in latest image only returns duplicate frames: drain the buffer queue and the transport setting in stream buffer handling mode: set newest only.

Worked example: the timing budget at a 10 Hz trigger

Put numbers on the coexistence so you can tell margin from luck:

The trigger runs at 10 Hz, so one cycle is 100 ms. The pair's exposure is 5 ms; on a conveyor at 150 mm/s a part travels 150 mm/s × 0.005 s = 0.75 mm during that exposure, which is why the pair is gated to a strobe edge instead of free-running. The pair is ready about 10 ms after the edge (5 ms exposure plus 5 ms readout in this example), and your processing takes 20 ms. The next color frame is at most 33.3 ms away, because one is always in flight. Worst-case loop body: 10 + 20 + 33.3 = 63.3 ms against a 100 ms cycle, leaving 36.7 ms of margin. The 1000 ms timeout is 30 frame periods against a 33.3 ms worst-case wait, so it proves liveness without ever firing in a healthy pipeline.

Queue depth follows from the same numbers: depth 4 holds the 3 frames that arrive per cycle plus one. Drain fully each cycle, or let the queue keep newest only.

When free-run color is the wrong answer

Free-run is correct only when the color frame does not need the trigger instant. If you map color texture onto depth of a moving part, the color frame can sit up to one period away from the pair's exposure: 33.3 ms at 30 fps, which on a 150 mm/s conveyor is 150 mm/s × 0.0333 s = 5.0 mm of mismatch between what the pair measured and what the color camera saw. No queue discipline, timeout or FPS setting removes that skew — the color exposure must start on the same edge as the pair. That is a hardware decision, not a software one.

Building the rig from three discrete cameras

When the skew budget says "same edge", stop mixing modes inside one device and gate three cameras on one trigger line: two mono cameras for the pair and one global-shutter color camera, every exposure starting on the same pulse. Trigger-input CMOS cameras hold their frame rate under trigger — one current datasheet specifies 58 fps at full resolution — so a 10 Hz edge leaves a wide margin.

For the color channel, pick a global-shutter color model from the area scan cameras range, filtered in the camera finder:

The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter and a C-mount, so it gates on the shared line exactly like the mono pair. For the host, a single card carries the whole rig:

The MV-GE2002P is a dual-port PoE NIC, which hosts the pair and the color camera on one card. For trigger and power wiring at both ends:

The LS-CBL-0211 is a 5 m 12-pin I/O and power cable for the camera side; the LS-CBL-0224 is a 7 m frame grabber I/O cable, DB9F to open leads, for the host end. More host cards sit in frame grabbers, and the full trigger-wiring range sits under cables.

Three cameras on one pulse is an electrical fan-out, not just software: each opto-isolated trigger input draws current, so size the source before wiring. The resistor math is covered in fanning out one TTL pulse safely and wiring a trigger to an opto-isolated input. On the capture side, multi-image capture per trigger shows the one-edge, three-frame pattern, and setting up a stereo trigger pair covers the pair's ready and timeout handshake. If a GigE camera in the rig ignores the line, start at GigE camera ignores external trigger: check acquisition mode first, and size the transport with USB3 bandwidth for a multi-stream pipeline or acquiring from multiple cameras.

Configure the three-camera rig once you have a shortlist, or send the skew budget and trigger rate through the contact page and we will size it with you.

Checklist before you ship the pipeline

• No setFrameSyncMode or setExternalTrigger line on the color node; it runs continuous.
• One OutputQueue per stream, each read with a blocking get and a timeout.
• The 10-second count test passes: about 100 pairs at 10 Hz and 300 color frames at 30 fps.
• The color queue is drained or newest-only, sized for 3 arrivals per 100 ms cycle.
• Timestamps are logged per stream, with the accepted color-to-pair skew under the motion budget.
• Where skew must be zero, three discrete cameras share one trigger line instead of free-run color.