Two FireWire cameras not detected: fix the bus power problem

Two cameras on one IEEE 1394 card should just work — until the second one pulls the bus power down and neither is seen again. The failure masquerades as a driver problem: one camera appears then vanishes, the acquisition tool hangs while you open its device list, and reinstalling the driver stack changes nothing for long. This is a common trap on legacy hosts, and the fastest way out is a power budget, not another driver version. Below: how much 12 V the card really has, how to add up two cameras' draw, which connectors carry power at all, the fixes, and the tests that separate power faults from cable, port and bandwidth faults.

Why did the second camera break a bus that worked with one?

Because both cameras feed from one shared 12 V supply on the host adapter: with a single camera the rail holds, and the moment the second node draws its current the voltage sags and the whole bus resets — which is exactly when cameras vanish mid-enumeration.

The signature is specific. A system that ran one camera for months turns unstable the day a second one is attached. Cameras enumerate singly, appear together once, then disappear; the acquisition tool freezes when you click a node that half-enumerated, and the application closes on its own while opening the device tree. None of that points at the driver stack.

A 1394 bus shares one supply across every node that asks for it, and camera current rises the moment streaming starts: sensor, digitizer and any illumination output all draw at once. A camera that enumerates at idle can still brown out under load. When the rail sags, nodes drop off, the bus resets and enumeration restarts — some resets look like plug-and-play events, others like crashes. Vendor documentation for 1394 camera acquisition puts it plainly: cameras powered from the PCI bus cannot get what multiple cameras require.

Swapping a 2-port card for a 3-port card to gain connector clearance changes nothing here — both feed their ports from the same slot rail. Do use the wider spacing and put the two cables on ports 1 and 3, but expect the same power limit.

How much 12 V power can a PCI FireWire card deliver?

Count on 6 W of 12 V from the slot on a classic PCI card: the PCI card specification limits a card to 0.5 A on the slot's 12 V rail, and the card's own electronics, the link PHY and every port share it.

The 1394 standard defines the negotiation on top of that. Each node declares a source power class — 15, 30 or 45 W — in the self-ID packet it sends at enumeration, and states its requirements in configuration ROM; what the host can actually deliver is system dependent. A slot-powered adapter will not honestly reach even the 15 W class.

That is why most adapters carry a 4-pin peripheral power socket: it wires the port supply straight from the PC's power supply and routes around the slot cap. If your card has that socket, fitting it is the whole fix in most two-camera cases. PCIe adapters face the same slot arithmetic and carry the same socket when their ports are meant to power devices.

How much power do two machine vision cameras need?

Work it in watts: at 12 V, every 250 mA of camera draw is 3 W, so two cameras listed at 250 to 350 mA each need 6 to 8.4 W before the card's own electronics take their share.

Get each camera's figure from its data sheet — the input voltage and current — or from the node's configuration ROM, where the 1394 standard requires the declared requirement to live.

Worked example, with a mid-size camera listed at 12 V, 350 mA:

• One camera: 12 V × 0.35 A = 4.2 W
• Two cameras: 4.2 W × 2 = 8.4 W, which is 8.4 W ÷ 12 V = 0.7 A
• The slot offers 6 W: 8.4 W − 6 W = 2.4 W short, before the card's own draw

The deficit never raises an error message; it shows up as resets and vanished nodes. Budget the peak figure, not the idle one — internal fans and illumination or trigger outputs can push a camera above its listed draw while streaming.

Which FireWire connectors actually carry bus power?

Only the 6-pin and 9-pin connectors carry the VP power pins; the small 4-pin connector never carries power, so any 4-pin port or adapter leaves the camera dependent on its own supply.

A FireWire 800 card with 9-pin ports does power cameras: a 9-pin to 6-pin cable carries the same power pair through. Power stops wherever the path ends in 4-pin. When you test, keep a 6-pin or 9-pin path end to end and set 4-pin adapters aside.

How to fix it: auxiliary card power or external camera supplies

Fit the card's auxiliary power first: the 4-pin peripheral connector from the power supply feeds the ports directly and lifts the card to an honest 15 W class, which covers two cameras with margin.

1. Shut down and unplug both cameras. Connect a lead from the power supply to the card's 4-pin auxiliary socket, then close up.
2. Boot, attach one camera and stream it at full frame rate for five minutes.
3. Attach the second camera and stream both together for five minutes. Draw peaks while streaming; idle enumeration proves little.
4. No auxiliary socket on the card? Power the cameras instead: their own 12 V DC inputs, or a bus-power injector on the 6-pin or 9-pin line. Then repeat the dual-stream test.
5. The third option is a self-powered 1394 hub as the power source — read the hub question in the FAQ before trusting one.
6. Reinstall, roll back or change the 1394 bus driver only after both cameras hold a combined stream. Then you know the stack was never at fault.

The fix is verified when both cameras enumerate immediately at boot, hold a combined stream without re-enumeration events, and survive the illumination outputs switching on. If you can reach the far connector with a meter, the VP pin should sit close to its no-load value with both cameras streaming; visible sag under load is your confirmation.

When is it not power?

If power is proven good and cameras still drop, test in this order: cable length beyond the 4.5 m per-hop limit, a damaged port or connector, and only then bandwidth — an S800 bus carries about 80 MB/s, which fits two modest cameras easily.

Cable first. The standard allows 4.5 m of cable between two nodes, and a line that passes at idle can still drop packets at 800 Mbit/s. Replace any extra-long or hand-built link before blaming anything else.

Then port and connector. Move one camera to the other port and swap the two cables: if the fault follows a port, the card is damaged; if it follows a cable, replace the cable. Corrupted enumeration on both ports, with power proven, retires the card.

Bandwidth last, because two ordinary cameras do not come close:

Two 640 × 480 mono cameras at 30 fps: 640 × 480 × 1 B × 30 = 9.2 MB/s each, 18.4 MB/s together — inside even S400 at about 40 MB/s usable. Two 1024 × 1024 mono cameras at 60 fps: 1,048,576 B × 60 = 62.9 MB/s each, 125.8 MB/s together — past S800, so cut frame rate, use partial scan, or give each camera its own card. Node count is never the issue: a 1394 bus addresses 63 nodes.

If a single camera runs but never exceeds S400, that is a different fault, with its own diagnosis in FireWire camera bus speed: diagnosing a 400 Mbit/s limit. When the failure survives proven power and good copper, the FireWire and USB camera troubleshooting on real-time targets guide covers the driver and device-tree layer.

Replace FireWire, or fix the existing card?

Fix the card if the cameras and software are proven — an auxiliary power lead is a one-hour job — and replace the interface when the host is end-of-life, rebuilding on GigE with PoE at 15.4 W per port.

PoE changes the arithmetic structurally. An IEEE 802.3af port sources 15.4 W; two ports offer 30.8 W — five times what the 1394 slot could share — and each camera feeds from its own port, so one camera can no longer brown out the other. Power and data ride one cable, and the link runs 100 m on Cat5e with no hop arithmetic. Check whether your camera supports PoE before you pick the card; on the data side, two GigE cameras on one host covers NIC ports and budget, and 5GBASE-T camera interface: bandwidth, cables and distance covers the longer-reach option.

For the rebuild, start at GigE frame grabbers: the LS-FGB-0004 is a PCIe x4 card with 4 ports of PoE Gigabit Ethernet — one port per camera, power included.

On the camera side, current area scan cameras replace a 1394 sensor one for one: a 6 MP mono GigE model with a 1/1.8-inch rolling-shutter sensor and a C-mount is the same image, over one cable.

Cabling is then one line per camera. The LS-CBL-0199 is a 3 m high-flex drag-chain GigE cable with screw locks; for a USB3 host, the LS-CBL-0219 is the 3 m USB3.0 equivalent.

USB3 carries its own power constraints when you stack cameras on one host — the bandwidth and power budget for multiple USB cameras walks that budget before you commit. Lay the whole replacement out in the system configurator, or start from camera cables if only the wiring moves.

What to check before swapping any more parts

Run this list before you order anything: auxiliary power fitted, camera draws summed against the card's real budget, both cameras streaming together for five minutes, and every hop inside the cable limit.

• Auxiliary 4-pin lead fitted and seated, or a written decision to power the cameras externally.
• Both cameras' input ratings found and summed, then compared against the card's actual source, not its marketing.
• A five-minute dual-stream test at production frame rate with illumination outputs active.
• A 6-pin or 9-pin power path end to end, with no 4-pin adapter in the chain.
• Cables within 4.5 m per hop, seated straight, with clearance between wide connector housings.
• Ports swapped once to separate a card fault from a cable fault, with the result written down.
• Drivers untouched until every item above passes; then reinstall only with a reason.

When every line passes, the system is stable and the work order is just the parts list. More multi-camera wiring notes sit under the systems topic, and if you would rather have the budget checked, bring both camera part numbers to the contact page and we will run the numbers with you.