Enumerate cameras on USB and FireWire buses in one list

You are building a camera-selection screen for a setup that mixes IEEE 1394 (FireWire) IIDC cameras with the occasional USB webcam. The USB side hands you a list of attached cameras from one call; the 1394 side hands you the bus, because the FireWire driver enumerates nodes and interfaces while the camera layer stays silent. This guide walks both enumerations, merges them into one picker the user selects by name, and keeps that selection valid across replugs, reboots and added cameras. It closes with the bandwidth arithmetic that sets how many 1394 cameras one bus really carries, and the decision on when to stop buying them.

Why does the USB camera list appear but not the FireWire one?

Because the USB stack registers each camera as a system device while a 1394 stack exposes the bus itself: FireWire organizes devices in a tree topology of up to 63 nodes per bus, and your cameras are nodes you must walk yourself.

The difference is who owns enumeration. A USB webcam loads a class driver, the class driver registers the device with the operating system, and every capture API above it inherits the list — which is why the USB acquisition palette can ship a single VI that returns attached camera names, while the 1394 palette has no counterpart. A 1394 camera runs IIDC firmware on a bus whose devices form a tree with a root, branches and leaves; nothing in that structure says "camera", so the listing code has to walk it. The 1394 tree topology and its node addressing is worth ten minutes of reading, because it explains every quirk below: bus resets when you plug in, node numbers that shift after a reset, and the 63-device ceiling per bus.

Windows adds its own surprise. Device Manager files a 1394 card under FireWire Controllers, Network Adapters or Imaging Devices, so code that scans one device class to find "the FireWire card" misses machines where the card landed elsewhere. Enumerate by bus, never by device class.

How do you enumerate cameras on a FireWire bus?

Walk each 1394 host adapter separately, read its node list after the bus reset, and open every node whose configuration ROM declares an IIDC unit directory; the EUI-64 GUID in that ROM is your stable ID.

In order:

1. Enumerate the 1394 host adapters. Each card is one bus with its own node address space.
2. Wait for (or force) a bus reset, then read the node list on each bus.
3. Read each node's configuration ROM and keep the nodes that declare an IIDC unit directory.
4. Take the EUI-64 GUID as the camera's permanent ID, and the vendor and model strings for display.

The GUID is burned into the camera, so it follows the camera to another socket, another card, another PC. The socket number and the node number do not: both change with the physical layout and with every bus reset. Acquisition drivers that do support 1394 expose exactly this two-step shape — list interfaces, one per card, then list cameras on each interface — so if your palette has an interface-listing call, that is your entry point, not a missing feature. On Linux the IIDC capture stack walks buses and reports cameras with their GUIDs the same way.

How do you enumerate the USB cameras in the same pass?

Use the same API to enumerate that you will use to open — DirectShow on Windows, V4L2 on Linux — and keep two strings per camera: the friendly name for display and the device path as the saved ID.

The device path encodes the USB vendor ID, product ID and instance. For a camera with a unique serial it is stable across sockets and reboots; the friendly name is decoration, and duplicate names are the norm — two identical webcams can both list as "USB Video Device". A camera can also show a generic name until its driver entry is rebuilt, and reinstalling the device entry is that fix. Microsoft's walkthrough of selecting a capture device in DirectShow shows the moniker loop that returns both strings.

On Linux the pairing is the kernel's device node versus a stable path: node numbers follow enumeration order, and stopping device path conflicts is the same rule on that side. Opening by index is legitimate within one run of the program; the moment the list can change between runs, persist the path. Opening cameras by index marks exactly where that stops being safe.

How do you merge both lists into one picker?

Build one record per camera from both enumerations — bus, stable ID, friendly name, open handle — sort by name, and store the user's choice as the stable ID, never as a position in the list.

Pseudocode; every name stands for the equivalent call in your SDK.

CameraRecord { string bus; string stable_id; string friendly; handle open; }
List(CameraRecord) merged = empty

for d in usb_enumeration():
    merged.add(CameraRecord{ "USB", d.device_path, d.friendly_name, d.handle })

for card in firewire_card_enumeration():
    for node in card.node_list():
        if node.has_iidc_directory:
            merged.add(CameraRecord{ "1394:" + card.index, node.guid,
                                     node.vendor + " " + node.model, node.handle })

sort merged by (friendly, stable_id)

test: pull one camera cable, re-enumerate,
      expect the count to drop by exactly one and all other stable_id values to match

At every program start, re-enumerate both buses, match the saved IDs against the fresh list, and open the match. Report a missing ID by name — "the camera on the second 1394 card is gone" — instead of falling back to list position zero, which is how a picker quietly grabs the wrong camera. If your APIs return interface names rather than cameras, an index loop over interface names is the outer loop you are missing.

How many FireWire cameras fit on one bus?

Topology allows 63 devices per 1394 bus, but bandwidth gives out long before that: an S400 bus sustains roughly 320 Mbps of isochronous video, about 80 percent of its 400 Mbps line rate after packet overhead, so pixel count times frame rate sets the real camera count.

Take one IIDC camera at 640 × 480 pixels, 8-bit monochrome, 30 fps:

• bits per frame: 640 × 480 × 8 = 2,457,600 bits
• one camera: 2,457,600 × 30 = 73,728,000 bit/s ≈ 73.7 Mbps
• two cameras: 147.5 Mbps — comfortable
• three cameras: 221.2 Mbps — fits with margin
• four cameras: 294.9 Mbps — under 320 Mbps on paper, but bus resets and isochronous overhead eat the tail

Commit to three cameras of this format per S400 bus and buy a second card for the fourth. A 16-bit-per-pixel colour mode doubles each camera to 147.5 Mbps, and the same bus then carries two. The fuller treatment of budgeting the 320 Mbps FireWire cap runs the sum for other formats, and the USB side obeys the same arithmetic with far more headroom (multiple USB cameras: bandwidth and sync).

Why does a listed camera fail to open?

Three causes cover almost every case, in this order: the camera is already open in another process, the camera has no bus power, or the app that lists it uses a different enumeration layer than the app that opens it.

1. Already open elsewhere. A camera held by a vendor tool left running, or last week's debug build, enumerates fine and refuses to open. Close the holder; freeing the device is the same fix in a GenTL stack.
2. No bus power. A 6-pin 1394 cable carries bus voltage on two of its lines; the 4-pin variant carries none, and a bus-powered camera on a 4-pin port drops off the bus mid-listing.

Two FireWire cameras not detected traces this failure end to end.

3. Different enumeration layers. The device lists in one app and not another when the first uses DirectShow and the second GenTL, or the OS class list versus the vendor transport — that is listed in one app but not another. For cameras that never appear at all, diagnose the host path before touching code. On real-time targets the bring-up order matters as well; troubleshooting LabVIEW RT USB and FireWire cameras covers that stack.

Should you keep buying FireWire cameras or move on?

Keep the 1394 cameras you own and buy every new camera on USB3 or GigE: the enumeration work above is the last software chore the 1394 bus should cost you.

FireWire cameras are legacy hardware. The IIDC specification made them interoperable, but the bus is gone from new PCs and its bandwidth ceiling is fixed. Keep the working cameras on their card, and standardize new purchases on two interfaces: GigE for fixed positions at distance, USB3 for bench and lab work. The trade shows in two cameras from the same sensor family:

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The LS-CMR-0166 is the USB3 pick at 30 fps; the LS-CMR-0053 is the same 12 MP sensor on GigE at 9 fps. GigE reaches 100 m on Cat5e; USB3 holds a few metres before it needs a powered hub or an adaptor card. The camera finder filters by interface and mount, and the configurator walks the whole chain in one pass.

For the GigE chain, a 4-port PoE card such as the LS-FGB-0004 powers the cameras over the data cable:

On the USB3 side, keep the webcams on their own controller and cable them for movement:

The LS-CBL-0219 is a 3 m USB3.0 camera cable rated for drag chains, and the MV-GU2204 adds quad USB3 ports where the PC has none. Cards and cables of both kinds are in the frame grabbers and cables ranges, and the accessories finder filters them by interface. A camera that drops off the list is often a connector, so keep labelled spares. Every camera above comes from the area scan cameras range with a 3-year warranty minimum, and in-stock items ship within one business day.

What should you check before you ship the picker?

Run these eight checks before release; each one catches a failure that otherwise surfaces on the floor, when a camera is replugged or a second camera of the same model appears.

• Re-enumerate both buses at every start; cache nothing but the saved IDs.
• Save the 1394 GUID or the USB device path; refuse to persist a list index.
• Show bus and socket in the displayed name whenever two cameras share a model.
• Unplug test: pull one camera; exactly one ID goes missing, every other ID survives.
• Replug test: move a webcam to another socket; if its ID changes, prompt the user once rather than failing.
• Budget each 1394 bus with the bit-rate sum before adding camera three or four.
• Keep one acquisition object per camera inside the process (one acquisition object each).
• Power audit: every 6-pin run powered, every 4-pin camera on its own supply.

When the picker is done, the configurator sizes the rest of the chain, more integration notes are on the systems topic page, and the applications team answers selection questions through the contact page.