Connect a depth camera over IP: fix first-connection failures

The depth camera powers up, its link LED glows, and the SDK still lists no device. On a networked industrial depth camera that pattern is almost never a broken sensor — it is the network path, and the most common fault is a subnet mismatch: the camera sits at a factory address such as 192.168.1.10 while your network card took 10.0.7.x from the office DHCP server. This guide gives you the diagnosis order, the subnet arithmetic that decides whether camera and host can see each other at all, the fixes for firewall, DHCP, PoE and cabling faults, and the bandwidth numbers that decide whether the stream survives once it opens. Work the checks in order; most links come up in under ten minutes.

Read the symptom, then test in this order

Four faults cause nearly every first-connection failure, and each leaves a different fingerprint:

Work the table top to bottom: a camera with no link LED will never answer a ping, so physics first, addressing second, firewall third. Each cause below carries its test, its fix and the arithmetic behind it.

Cause 1: the camera and the NIC sit on different subnets

Discovery for GigE Vision cameras is a UDP broadcast. A broadcast reaches every device on its own subnet and stops at the first router, so a camera at 192.168.1.10 and a host NIC at 10.0.7.23 will never exchange a discovery packet, whatever the SDK tries. Read the camera's factory address from the housing label or its data sheet, then give the camera-facing network card a static address in the same subnet.

The decision is the network address — the IP ANDed with the mask:

Different network addresses mean different subnets: no broadcast crosses, and ping either times out or the office gateway replies "destination host unreachable". The fix is one static assignment. Set the camera-facing NIC to 192.168.1.50 with mask 255.255.255.0 and leave the gateway field empty — a gateway on a routerless link only confuses routing. Both sides now AND to 192.168.1.0, ping 192.168.1.10 answers in under 1 ms on a direct link, and discovery lists the camera. Pick any free address from 192.168.1.2 to 192.168.1.254 except the camera's own and the .255 broadcast; on Linux the same change is one static address on the interface, and the arithmetic does not move.

If a previous engineer reconfigured the camera to an unknown address, the maker's IP-configuration utility can force a fresh one over the raw link. That tool ignores the subnet check on purpose, which is exactly why it works when nothing else does.

Cause 2: ping works but the discovery list stays empty

When ping answers and the SDK still finds nothing, unicast works and broadcast does not. On Windows that is the firewall: discovery arrives as an inbound UDP packet to the SDK's enumeration process, and the firewall drops it silently for an unrecognized application.

Test it in one minute. Allow the SDK's tools through the firewall, set the adapter's network profile to private, and re-run enumeration. On the bench you can switch the firewall off for a single run to confirm the diagnosis; then turn it back on and add a permanent inbound rule for the SDK executables instead. Third-party security suites filter broadcasts independently of the built-in firewall, so check them too. The complete walk-through, including the case where one tool sees the camera and another does not, is in GigE Vision camera firewall: ping works, discovery fails.

Cause 3: DHCP moved the address, or the SDK bound to the wrong NIC

Two variants bite benches with several cameras. First, the NIC you meant to be static is still on DHCP and quietly took an office address — read the adapter's actual IPv4 address before anything else. Second, the PC carries two or more NICs, one to the office and one to the cameras, and the SDK enumerated on the wrong interface. Network stacks also cache bindings, so restart the SDK process after every address change.

The bring-up habit that saves hours: disable the office adapter while you work the camera link, open the stream, then re-enable the office NIC and confirm discovery lists exactly one camera per link. Ghost or duplicated devices point at interface binding, and duplicate PoE camera discovery: diagnose host interfaces walks that diagnosis interface by interface.

Cause 4: no link LED — power and cable

A camera that never lights its link LED has a physical fault, and with PoE depth cameras the usual one is power class. IEEE 802.3af supplies up to 12.95 W at the camera and 802.3at (PoE+) up to 25.5 W. A depth camera with a heater or an active projector frequently needs the larger class; on an af-only port it may boot halfway, drop the link, or fall over at the moment the stream opens and the projector fires. Read the camera's power draw from its data sheet, match the switch port's PoE class to it, or bridge the gap with a PoE+ injector.

Cabling rules are short. Cat 5e or better carries 1 GbE to the IEEE 802.3 limit of a 100 m channel. For long runs, many cameras in one bundle or high PoE power, use shielded F/UTP to keep coupling between pairs down. Test with a short patch lead on the bench before you blame the camera, and look at both link LEDs: a steady link lamp with a blinking activity lamp means the physical layer is sound. Amber light or a 100 Mbps negotiation usually means a damaged pair or a Cat 5 lead, and a depth stream starves at that rate even when it opens.

The ten-minute fix sequence

Run the steps in order and stop at the first one that fails:

1. Read the camera's factory IP address and netmask from the label or data sheet.
2. Set the camera-facing NIC to a static address in that subnet — 192.168.1.50 with 255.255.255.0 for a camera at 192.168.1.10 — and leave the gateway empty.
3. Check both link LEDs and confirm the port negotiated 1 Gbps, full duplex.
4. Ping the camera. Replies under 1 ms mean the addressing is right; a timeout sends you back to cause 1 or cause 4.
5. Run the SDK's device enumeration. Ping good and list empty is cause 2 — allow the SDK through the firewall and try again.
6. If the camera's address is unknown or clashes with another device, force a fresh one with the maker's IP-configuration utility, then match the NIC to the new subnet.
7. Open the stream, passing the camera's IP address where the SDK expects a device identifier; networked cameras accept this in place of a serial number on every mainstream SDK.
8. Camera found but the stream refuses to start? The network is done — continue with the next section.

The same sequence brings up any GenICam camera on Ethernet; Connect a GenICam camera to an industrial controller over Ethernet covers the controller side port by port.

Found, but the stream fails: bandwidth and version alignment

Two different failures hide behind a camera that enumerates yet will not stream.

Bandwidth first. A 16-bit depth frame at 1280 × 720 is 1280 × 720 × 2 B = 1,843,200 B, about 1.84 MB. At 30 fps the depth stream alone moves 1.84 MB × 30 = 55.3 MB/s. Add 8-bit RGB color at the same resolution — 2.76 MB per frame, 82.9 MB/s — and the pair demands 138.2 MB/s from a link that carries 125 MB/s on the wire and a practical GigE Vision payload near 115 MB/s. The link saturates, and the SDK reports timeouts rather than a bandwidth error.

So give each camera its own NIC port, move to a 2.5G or 10G link, or split depth and color across two ports where the camera supports it. Once the stream runs, the SDK's own procedure turns the depth frame plus the calibration into the point clouds you wanted; that step does not care how the connection was made.

Version alignment second. A camera that appears but throws a header or protocol error has firmware and SDK components out of step — 3D camera header version mismatch: fix firmware and SDK alignment is the fix path. A stereo camera that shows color but no depth map has its own diagnosis in depth camera stereo connection: diagnose depth-only failures.

Host ports and PoE in one box

Every GigE camera deserves its own port, and the math above says sharing a link is false economy. The vision controllers category lists the range with LAN-port count, PoE support and memory as filters, so matching ports to cameras takes a minute.

For a bench cell that powers its cameras separately, the MV-VC3301H-128G66 carries 5+ LAN ports, and an external PoE+ injector per camera adds power where the cable needs it.

Where the cameras take power over Ethernet, the MV-VC5525-256G70-NN provides PoE camera ports, 5+ LAN ports and 8 built-in light channels, so data, camera power and illumination wiring land in one enclosure.

For a compact cell that also wants a frame grabber or a GPU, the MV-VC4712-256G10-2TH pairs PoE camera ports with PCIe expansion. Match the controller's PoE class to the camera's draw from cause 4, and the same box powers and streams the cell.

On the camera side, the 3D sensors category groups laser profilers, stereo and structured-light cameras, and its camera finder filters the range by type and series.

Keep the link up after day one

Thirty minutes of labeling prevents most repeat failures. Write each camera's serial number, MAC address and chosen IP on the cable at both ends and keep the mapping in the install sheet. Leave the camera subnet off the office VLAN: a dedicated NIC or VLAN avoids lost broadcasts and keeps a 55 MB/s depth stream away from everyone's morning email. If a camera must stay on DHCP, bind a reservation so the address never drifts.

Enable jumbo frames end to end — a 9,000-byte MTU on the NIC and the switch port — to cut per-packet overhead, and keep it identical on both sides, because a mismatch drops large packets silently. Budget PoE with roughly 20% headroom above the camera's rated draw so a cold-morning heater never browns out the link. When a camera that ran fine starts dropping mid-shift, PoE camera stream drops: watchdog timeouts and device recovery covers the recovery settings.

Once the link holds, the next limit is optics, not networking: the 3D camera working distance and positioning guide picks up exactly there. More integration checks sit on the 3D vision topic page, and the guides hub indexes every guide. If a step above stalls, send us the outputs of steps 1 through 4 through the contact page and we will read them with you; to lay out a full cell, start at the configurator.