Depth camera 4 second image latency: fix subnet and network path

A depth camera that connects cleanly and then shows every move 4 seconds late is almost never a broken camera — it is a network path that cannot carry the stream. The picture arrives, so discovery and login worked; the delay means frames are queueing, retransmitting or taking a route they were never meant to take. This guide is for anyone wiring a PoE depth camera to a Linux or Windows host through a switch. You will fix the subnet mismatch first, check the negotiated link speed, budget the bandwidth with real arithmetic, and prove the path with a five-minute direct-cable test. Work the steps in order and the scene tracks your hand live again — tens of milliseconds behind reality, not seconds.

Why the image lags by seconds instead of slowing down

A depth stream does not degrade gracefully — it queues. The camera sends frames at its fixed frame rate; the host drains its receive buffer as fast as the path allows. When the path delivers less than the camera offers, the buffer grows, and the image you see is the buffer's tail. Packet loss adds a second mechanism: a GigE Vision driver re-requests dropped packets, and the resends arrive behind everything already queued. A 4-second lag at 30 fps is roughly 120 frames — about 246 MB of depth data — sitting in queues along the path. No camera does that on purpose; the path is draining at a fraction of its fill rate.

The arithmetic is direct. At 30 fps a frame is due every 33.3 ms. A 1280 × 800, 16-bit depth frame is 2.05 MB, which a healthy gigabit link moves in about 17 ms at roughly 950 Mbit/s of usable payload — comfortable margin. The same frame on a path stuck at 100 Mbit/s needs about 170 ms, five times the frame interval, so the delay compounds for as long as the stream runs.

Counting seconds aloud instead of measuring will argue with you. Compare the frame's capture timestamp against the host clock — the buffer timestamp latency guide shows which fields to read. The rest of the depth-camera wiring and settings guides sit on the 3D camera topic page.

The five likely causes, in order

Work down the list; each item has a two-minute test.

1. Negotiated speed fell to 100 Mbit/s. One damaged pair or a legacy port cuts the path to a tenth of its rate. Test: read the negotiated speed on the NIC and the switch port.
2. Host NIC outside the camera's subnet. Camera-bound packets get handed to the default gateway; where a route exists at all, it runs over hops never sized for a video stream, and the driver retransmits what dies on the way. Test: ping the camera, then check reply time and that the route stays inside the subnet.
3. Stream bigger than the link. Depth plus color at full frame rate can pass 1 Gbit/s on paper. Test: the bandwidth sum in the budget section below.
4. Switch saturated or dropping. A congested uplink, buffer overflow or a pegged management CPU adds exactly this lag. Test: the port's CRC error and discard counters.
5. MTU mismatch. 9000-byte camera packets meeting a 1500-byte hop force fragmentation and loss. Test: confirm one packet size end to end.

Fix the subnet first

The examples below assume a camera at 192.168.1.10 with mask 255.255.255.0 — a common factory default and an example, not a spec. Read your camera's real address from the SDK device list or its label before changing anything.

1. Read the camera's address. The device list prints the IP address and mask once the camera enumerates. If it vanished after a firmware update, re-read it: updates can reset the camera to DHCP, which is why the static IP and firmware update guide recommends pinning the address before updating.
2. Give the host NIC a static address in the same subnet. Camera 192.168.1.10/24 → host 192.168.1.50, mask 255.255.255.0, gateway left empty on a direct link. Never reuse an address another device already holds. With a link-local 169.254.x camera, give the NIC a static 169.254.x address and a 255.255.0.0 mask instead.
3. Remove the competing routes. A second NIC already on 192.168.1.x, or a VPN adapter claiming that subnet, hijacks the path. Disconnect or re-address them.
4. Ping, then time it. On a direct link every reply should return in well under a millisecond with 0% loss; through a clean gigabit switch, the same. Double-digit reply times or any loss means the path still leaves the local subnet.
5. Wave at the lens. If the scene now tracks your hand live, the subnet was the whole fault. If it still lags by seconds, the subnet was layer one — continue with speed and bandwidth.

For the failures that come before all this — the camera that never appears in the device list — the first-connection guide covers enumeration, interfaces and firewalls.

Check the negotiated link speed

A gigabit path is gigabit only if both ends agreed on it. Check the NIC status (on Linux, ethtool prints the negotiated speed; Windows shows it on the adapter status page) and the switch port's own status. Both must read 1000 Mbit/s, full duplex. A single marginal pair in a cable drops negotiation to 100 Mbit/s — pings still pass, so the link looks alive while the stream suffocates. Reseat both ends, then swap the cable before suspecting the camera.

1000BASE-T is specified to 100 m on Cat5e or better, so run length is almost never the culprit in a machine cell; terminations are. For the bench, keep one cable whose history you know: the LS-CBL-0199 is a 3 m GigE camera cable with screw locks and a high-flex, drag-chain-rated jacket.

Budget the bandwidth before blaming the switch

Run the sum for an uncompressed stream before touching hardware:

Example streams — substitute your camera's real format and frame rate:

Depth row: 1280 × 800 × 2 × 8 × 30 = 491,520,000 bit/s ≈ 492 Mbit/s.

A 1000BASE-T link carries roughly 950 Mbit/s of payload — protocol overhead takes 3-5% depending on packet size. Depth alone fits with half the link to spare. Add full-rate color and demand is 1229 Mbit/s, more than the link can drain. The backlog grows at about 279 Mbit/s ≈ 35 MB per second; every second adds roughly 0.3 s of latency, so about 14 s after the stream starts you are 4 seconds behind, and falling further.

On a path stuck at 100 Mbit/s the collapse is faster. Usable capacity is about 95 Mbit/s ≈ 12 MB/s against a depth-only demand of 61.5 MB/s, so latency grows by more than 4 seconds for every second of streaming — which is exactly how a scene that 'updates every 4 seconds' feels from the outside.

Two transport-layer controls fix an oversubscribed camera, and both live in the driver's connection settings rather than the image settings: packet size and device throughput limit. Set 9000-byte packets end to end — NIC, switch ports and camera — which cuts the packet count about sixfold against the 1500-byte default and, with it, host CPU load and drop risk. Then cap the total at about 850 Mbit/s: 90% of the usable link for the stream, the rest as headroom for retransmissions and control traffic. Trimming the color rate works from the other side: 492 + 368 = 860 Mbit/s with color at 15 fps, still over the cap, so take color to 10 fps (492 + 246 = 738 Mbit/s total) and you sit comfortably inside.

Prove the path: direct cable first, then the switch

One test isolates everything: connect the camera straight to the host NIC with the known-good cable. If the scene is live over the direct link and seconds late through the switch, the finding is the switch. Check its port counters for CRC errors and discards, confirm no congested uplink carries your stream, and move the camera to ports away from heavy traffic. A switch whose management CPU is pegged stalls forwarding too; a reboot or a dedicated switch settles it.

When the camera must sit further away, add length with cable, not with a second hop. The LS-CBL-0117 is a 15 m camera data cable with RJ45 ends and locking studs.

Keep the route local: camera and host on the same switch, with no router or wireless bridge between them. A path that leaves the subnet pings fine and streams badly — that hairpin is a classic source of seconds-level lag. For multi-camera cells, the GigE camera network planning guide budgets switch ports and bandwidth properly.

Decision rule: direct link live and the budget under the cap → fix or bypass the switch; direct link live but the budget over the cap → rate-limit or drop a stream; direct link still seconds late → suspect host CPU, then the camera.

When the network is innocent

If the direct link passes, the budget holds and the lag survives, look at the host. A CPU pegged by point-cloud conversion or rendering starves the receive loop, and the buffer grows exactly as if the link were thin; the acquisition faster than processing guide separates the two. On embedded boards, USB and memory contention produce the same symptom — the frame drops on embedded boards guide works that isolation step by step.

Exposure adds latency on its own scale: a 30 ms exposure delays each frame by up to 30 ms — tens of milliseconds, never seconds. If the camera itself ends up the suspect after all this, the 3D sensors range covers laser profilers, stereo and structured-light cameras, and the 3D camera finder filters by type and interface.

Prevention checklist

• Host NIC static in the camera's subnet — a DHCP flap at boot otherwise re-routes the whole station.
• Auto-negotiation on at both ends — or identical fixed values; one forced end is a duplex mismatch.
• Stream total under about 850 Mbit/s — 90% of the usable link, keeping headroom for retransmissions.
• 9000-byte packets end to end — a single 1500-byte hop reintroduces fragmentation and loss.
• One switch, no router or WLAN hop — the route stays inside the camera's subnet.
• Port counters cleared and logged at commissioning — CRC or discard growth later points straight at cabling.

For cabling and accessories matched to your interface and run length, the cables range splits by type and length, and the cable finder filters both:

To wire the whole station in one pass, the configurator starts at the cabling and accessories step: