FireWire hub camera not detected: isolate the hub in three steps

Your FireWire camera enumerates straight into the PCI card, then vanishes the moment a powered hub sits between them. That pattern puts the hub at the top of the suspect list, not the driver: a 1394 hub has to repeat the bus in both directions and keep the bus power lines alive for cameras that feed off the cable, and a brand-new unit fails either job often enough that the box being new proves nothing. The three checks below isolate the fault in one bench session — a direct-connection baseline, a DC meter reading across the hub's power pair, and a test in the camera maker's own viewer — and end in a firm verdict: bind a driver, replace a cable, or replace the hub. If the chain has already cost you a deadline, the final section covers the PoE GigE rebuild that removes the power-pin failure mode entirely.

Why does my camera disappear when I add a FireWire hub?

Because a hub that fails to repeat the 1394 bus, or fails to pass bus power to a camera that needs it, leaves nothing for the host to enumerate — the camera shows nowhere, the same symptom a dead cable produces.

A hub sits in both paths at once. Electrically it must pass or regenerate the two power lines of the 6-pin connector; logically it must repeat the two differential data pairs and keep the camera's isochronous stream reaching the host controller. Fail either job and the operating system sees an empty bus, so nothing about the camera — its driver, its identifier, its settings — ever comes into play.

Run the likely causes in this order for a 'direct works, hub fails' symptom: a dead or under-rated power stage in the hub, a dead data repeater in the hub, a marginal 6-pin cable, and only then the host controller or driver. Prove the baseline first — a camera that enumerates direct on the card clears the card, cable and camera in one move, the same opening step as when a frame grabber is not detected and the card needs clearing before the driver. Two cameras change the power side as well; the FireWire bus power problem article covers that budget directly.

Which three checks isolate the hub fault?

Three checks decide it: confirm the camera still enumerates directly on the card, meter the hub's power pair for roughly 25 V, then run camera-plus-hub in the camera maker's own viewer — the pattern of pass and fail names the faulty part.

1. Baseline, direct. Disconnect the hub and connect the camera straight to a card port. Enumerating here clears card, cable and camera; failing here is a different fault — work the card before touching the hub.
2. Meter the power pair. Power the hub from its adapter with no camera attached, set a multimeter to DC volts, and read across the two power lines on each downstream 6-pin port. A working powered hub reads near 25 V; the limits are in the next section.
3. Split host from bus. Reconnect the camera through the hub and open the camera maker's own viewer or demo utility. Live video means hub and bus are good and the remaining fault is host-side driver binding; no video keeps the fault bus-side — cable or hub.

Read the three results against each other:

In the failure this procedure was built for, a brand-new hub read near zero volts on every downstream port while its adapter LED glowed; the identical camera and card enumerated the moment a replacement hub went in. That is the whole cost of skipping the meter: days of driver reinstalls for a hardware fault a ten-second reading names.

What should a working hub's 6-pin power pins read?

With the adapter powered and no camera drawing, a working powered hub holds its downstream power pair near 25 V DC — 1394 bus power is unregulated, so anything up to about 30 V is in spec, while single digits or zero mean the hub's power stage is dead.

The number comes from the specification itself: the six-pin connector carries two differential data pairs and two power lines, the bus voltage is unregulated and nominally about 25 V, and a port can supply up to 45 W at up to 30 V (IEEE 1394 summary on Wikipedia). Worst-case current per port follows:

Metering procedure: adapter connected and hub powered, camera unplugged, meter on DC volts (auto-range or a 200 V range), probes across the two power lines of each downstream 6-pin port — the pair that carries bus voltage, not the data pairs. Meter every port rather than one, because ports fail individually. Expect the reading to sag a few volts with a camera drawing from the port; the fault sign is a near-zero reading with the adapter powered.

If your camera has its own power input, bus power drops out of the diagnosis entirely — go straight to the viewer test.

Does the camera maker's own viewer change the diagnosis?

Yes — the maker's viewer splits the fault in half: live video through the hub proves the hub and bus are good and moves the suspect to the host-side driver binding, while no video keeps the fault on the bus side with the hub or its cable.

The split is clean because DCAM cameras enumerate as bus devices independently of any acquisition package, and the maker's viewer drives the camera through its own stack. If that viewer shows video through the hub, the bus, hub and camera are all proven, and whatever remains wrong lives in your acquisition software's configuration — the next section covers it. If the maker's viewer also fails, no amount of host-side work helps: swap the cable, then the hub.

One software-side check comes first: a FireWire port on the host is not by itself DCAM support, and the DCAM versus TWAIN distinction explains why the driver stack, not the connector, decides which software can open the camera.

Detection and bandwidth are separate verdicts too. A hub adds no bandwidth — everything downstream shares one 1394 bus, with a practical budget near 320 Mbps of the 400 Mbps an S400 bus offers; the 1394 bandwidth budget and the bus speed diagnosis cover why cameras enumerate and still drop frames.

Why does the same setup fail on a laptop's 4-pin port?

A 4-pin port carries only the two data pairs, so it never supplies the bus voltage that the two extra pins of a 6-pin connector carry; an externally powered hub must generate its own bus power, and if it cannot, the camera stays invisible there too.

The laptop changes nothing about the hub's obligations, so a hub that failed the meter on the desktop fails identically on the laptop — repeat the same readings instead of re-diagnosing from scratch. The one laptop-specific check: the hub's adapter is plugged in and live, because a 4-pin upstream connection supplies no power at all and the adapter is the hub's only source. With the adapter healthy, the 4-pin port is fine for data.

Watch the adapter's total load once two cameras draw from the bus. A hub adapter sized for one camera can sit near its limit with two, and a port that reads healthy unloaded can sag far enough under load to brown out a camera — meter again with the cameras connected if the set-up only fails with both attached.

Which driver does a DCAM camera need after the hub checks out?

Once the hub passes power and the maker's viewer shows video, a camera missing from your acquisition software is a driver binding problem: the first time Windows meets an IEEE 1394 camera, no acquisition driver is associated with it until you bind one.

The fix is the acquisition vendor's documented association step, done once per camera: in Windows Device Manager, find the camera's entry on the 1394 bus, bind it to the 1394 camera driver that ships with your acquisition package, then rescan. The camera then appears in that package's device list. Every DCAM acquisition package documents this step under driver association or camera installation; the pattern is the same and only the driver name changes.

Verify the binding the same way every time: the camera appears in the acquisition device list and grabs a frame without the maker's viewer open. If it appears but the grab fails while the viewer works, that is a format or bandwidth setting, not detection — the enumeration question is closed.

Is a PCI expansion box a substitute for the hub?

No — a PCI expansion chassis is not a hub and adds a second bridge the 1394 stack never asked for; its host link, ExpressCard or otherwise, must pass bus-master DMA and interrupt cycles transparently, and many do not, so it is a lab experiment, not a fix.

A 1394 host card leans on bus-master DMA for every isochronous frame. Put the card behind a notebook-to-PCI bridge and the bridge has to carry those cycles and the interrupts without intervention; where it falls short, the symptoms look exactly like the fault you started with — devices that enumerate sometimes, cameras that vanish after a bus reset, frames that arrive corrupted. The intermittency is what makes this path expensive in weeks.

If the goal is more ports, the direct answers are a hub that passes the meter test or a host card with more ports. If the goal is a laptop capture chain, the rebuild at the end of this guide is the honest answer.

How do I stop a hub fault from costing another day?

Meter every new hub's downstream ports on arrival, keep one camera connected direct to a card port as the reference, and label the cables that pass a direct-connection test — those three habits turn a two-week mystery into a ten-minute reading.

• Meter on arrival. About 25 V on each downstream 6-pin port, recorded on the asset tag. The hub that passes today is the one you can trust after the next shutdown.
• Keep a reference chain. The least-used camera stays direct on a card port, so a hub fault always has a live A/B comparison on the same host.
• Label cables that pass. A marginal 6-pin cable can carry bus power while dropping a data pair, and its symptom is close to indistinguishable from a dead hub.
• Buy powered, with power downstream. A data-only hub has no adapter rating big enough to fix the missing power pins — check the port layout before you order, not after.

More fault isolation at this level lives on the systems topic page.

When is replacing the FireWire chain the better fix?

If the chain keeps failing, the modern equivalent of a FireWire PCI card plus a powered hub is a PoE GigE setup: one network cable per camera carries both data and power, so the bus-power failure mode you just debugged cannot recur.

Power over Ethernet negotiates power over the same cable that carries the image data under the IEEE 802.3 PoE standards, so there is no separate power pair to meter and no hub trusted with the camera's supply. GigE Vision cameras enumerate through a host network card the way DCAM cameras did through the 1394 card, and port count scales with the card instead of a hub.

A desktop rebuild starts at the host card: the LS-FGB-0004 is a PCIe x4 4-port PoE Gigabit Ethernet card, and the MV-GE2002P is a dual-port PoE NIC, full height V2.0, for hosts short on slots or cameras. Both live in the frame grabbers category.

One cable per camera closes the loop. The LS-CBL-0199 is a 3 m GigE camera cable, high-flex for drag-chain runs, with screw locks. Longer and shorter runs live in the cables category, from under 1 m to over 20 m.

Plan the port budget with a spare port on every card and check bandwidth the way you would on any shared switch — the two GigE cameras on one host article walks that port and bandwidth arithmetic. If the rebuild wins, start at the accessories step of the configurator; if you would rather keep the 1394 chain, the three checks above are the whole job, and the contact page turns your camera count and cable runs into a parts list.