Packet missing from image: NIC tuning in the right order

A "packet missing from image" message means the camera streamed a frame the PC never assembled: packets arrived with a gap the driver could not repair, and the frame is flagged or torn. The instinct is to slow the frame rate. Slow the camera only after the network port has been tuned, because in most installations the receiving NIC is the bottleneck, not the link or the camera. This guide gives the fix order that clears the error on GigE Vision cameras — driver, receive descriptors, interrupt moderation, jumbo frames, packet size — plus the bandwidth arithmetic that tells you when tuning cannot help, and the cost of the last-resort inter-packet delay.

What the error actually means

A GigE Vision stream is a numbered sequence of UDP packets. The driver reassembles frames from the packet numbers, and where camera and driver support it, packet resend quietly re-requests the occasional lost packet. The error fires when a gap survives: either the packet never reached the NIC, or it reached a NIC whose receive buffers were already full.

Every case falls into one of two families, in this order of probability:

1. The PC threw packets away. The receive ring ran dry during a CPU spike, the generic network driver was loaded instead of the vision filter driver, or another application was reading from the same port.
2. The packets never arrived. A switch hop without jumbo frames discards 9,000-byte packets silently, the link negotiated 100 Mbit/s instead of gigabit, or a tired cable produced symbol errors.

Measure before you change anything: read the adapter's packet and receive-error counters together with the lost-packet statistic your SDK reports. The GigE Vision stream packet loss guide walks that isolation stage by stage.

Fix the NIC first: four settings in order

All four settings live in the adapter's advanced properties (Device Manager on Windows) or in the driver package the NIC vendor ships. Change one, re-test, then move to the next.

1. Install the current driver and the filter driver

Load the NIC vendor's current driver, then register the vision filter driver your SDK provides. The filter driver catches stream packets before the OS network stack sees them, and on a stock installation the gain over the generic stack alone can end the errors. The high-performance NIC driver guide quantifies the gain on a typical port.

2. Raise receive descriptors to the maximum

Receive descriptors are the ring of buffers the NIC writes arriving packets into. Desktop defaults are tuned for bursts of small web traffic, not a steady 100 MB/s stream, so set the Receive Buffers or Receive Descriptors property to the adapter's maximum. A full ring is the most common source of this error: packets arrive, find no free descriptor, and the NIC drops them before the driver ever sees them. Enable interrupt moderation in the same dialog so bursts produce fewer, larger interrupts — unless the application needs sub-millisecond trigger-to-image latency, in which case test with moderation off and watch the counters.

3. Enable jumbo frames end to end

Set the adapter's jumbo frame property to its largest value, commonly 9,014 bytes, and repeat it on every switch port between camera and PC. Then set the camera's packet size to 9,000 bytes, before acquisition starts, so the camera sends frames the whole path accepts. One hop left at the 1,500-byte default discards every oversized packet, and the error returns no matter how the NIC is tuned. The packet-size-before-acquisition guide covers the camera-side setting, and the camera's test packet proves the full path carries the size before you go live — the test-packet guide covers that check. Some vision packages keep their own copy of the packet size in their configuration: set the same value there.

4. Match every number, then re-test

Packet size on the camera, MTU on the NIC and MTU on each switch hop must agree. Where the camera's packet size exceeds a hop's MTU, cap the packet size to the smallest MTU in the path — the auto-negotiation cap guide covers that failure. If the SDK times out instead of flagging packets, the same three settings decide that symptom too: the stream timeout checklist covers packets, buffers and MTU in one pass.

Worked example: 1080p Mono8 camera, 9,000-byte packets, one 1 Gbit/s port

Inputs, and where each comes from:

• Frame size: 1920 × 1080 Mono8 from the camera data sheet, 1 byte per pixel: 1920 × 1080 = 2,073,600 bytes per frame.
• Packet size: 9,000 bytes, the camera setting from step 3 for a 9,014-byte MTU.
• Link: 1 Gbit/s = 125,000,000 bytes/s raw wire rate. A tuned port with filter driver and jumbo frames measures 115-120 MB/s; take 118 MB/s as the working ceiling of a good installation.
• Overhead: 38 bytes per packet on the wire — 8 preamble + 14 MAC header + 4 FCS + 12 inter-frame gap.

The rule in words: required bandwidth is frame rate times wire bytes per frame, and a stream that must survive CPU spikes stays at or below 90 percent of the measured ceiling.

Arithmetic:

• Packets per frame: 2,073,600 ÷ 9,000 = 230.4 → 231 packets.
• Wire bytes per frame: 2,073,600 + (231 × 38) = 2,073,600 + 8,778 = 2,082,378 bytes.
• Required at 60 fps: 60 × 2,082,378 = 124,942,680 bytes/s ≈ 124.9 MB/s. That is 99.9 percent of raw wire rate and above the 118 MB/s ceiling. Counting IP and UDP headers as well (28 more bytes per packet) moves the frame to 2,088,846 bytes and 60 fps to 125.3 MB/s — still over.
• Safe frame rate: 0.90 × 118 MB/s = 106.2 MB/s, and 106,200,000 ÷ 2,082,378 = 51.0, so cap the camera at 50 fps.
• Delay cost, if you must pace instead of upgrade: one 9,038-byte packet takes 9,038 ÷ 125,000,000 = 72.3 µs on the wire. Pacing the stream to 104 MB/s needs a period of 9,038 ÷ 104,000,000 = 86.9 µs, so an inter-packet delay of 86.9 − 72.3 ≈ 15 µs produces the 50 fps cap on any driver.

Decision: at 60 fps this camera demands more than a GigE port can measure, so no descriptor count or driver update will save it. Cap the camera at 50 fps, crop the ROI to the region you inspect, or move the stream to a 2.5G or 10G port. At 104 MB/s — 90 percent of even the 115 MB/s low end — the stream rides out CPU spikes; at 124.9 MB/s it drops packets every time anything else runs on the PC.

When the link, not the driver, is dropping packets

Open the adapter status and confirm gigabit, full duplex. A dirty contact or a marginal run drops the link to 100 Mbit/s — 12.5 MB/s, an order of magnitude under any vision stream — and the SDK often reports it as a packet-size complaint rather than a speed one; the link-drops-below-gigabit guide covers that signature. Then reseat both connectors and swap in a known camera data cable of 3-10 m for a test. Runs past 15 m, tight bend radii and cables routed beside motor drives all raise the symbol-error count the adapter reports. Replace the cable when those errors climb: no tuning recovers bytes that never arrive as clean bits, so keep a spare on the bench.

A known-good spare to keep on the bench:

Screw locks hold both RJ45 seats under vibration, and the high-flex jacket survives drag-chain motion if the camera rides on a moving axis.

Give the stream its own port — or more bandwidth

An office NIC shared with MES clients, remote desktop and virus scans drops vision packets at the worst moment. Dedicate a port to the stream, or keep the port's combined traffic inside the 90 percent budget from the worked example.

For a single camera, give the stream a port of its own:

Two four-port paths onto one slot when several cameras share the PC:

Of the two, LS-FGB-0004 is a PoE card on Intel i210AT silicon, so the data cable powers the cameras as well. If a card enumerates in Device Manager but the SDK lists no device, the frame grabber driver installation fix is the first stop. The accessories finder filters cards and cables by interface and port count. When one GigE link no longer carries the stream, move the camera side to copper 10GbE and keep the pacing delay at zero:

The bandwidth ladder at raw wire rate: GigE 125 MB/s, 2.5GigE 312.5 MB/s, 10GigE 1,250 MB/s. Apply the same 90 percent budget to whichever rung you pick — the frame-rate-and-bandwidth guide works the arithmetic from the camera side. Beyond Ethernet, the frame grabbers category includes CoaXPress and Camera Link cards for rates and trigger timing that Ethernet cannot hold.

Raise inter-packet delay only when you cannot tune

Inter-packet delay makes the camera pause between stream packets, so it works on any driver and any OS: the camera itself slows down. That is also its cost — in the worked example, about 15 µs of delay paces the 1080p Mono8 stream to 104 MB/s, roughly 50 fps, and the frame rate falls by every microsecond you add. Reach for it when IT policy locks the PC and you can neither install the filter driver nor enable jumbo frames, or when two cameras share one port: give each camera a different delay and the packets interleave instead of colliding. The port assignment guide plans multi-camera links. Most transport tools expose the delay under stream channel controls with a frame-rate box — type the fps you want and the tool computes the delay for the current packet size.

Before pacing, confirm the bottleneck is the link and not the processing loop: the acquisition-versus-processing guide shows how to tell the two apart. A dedicated acquisition machine also removes the constraint — see industrial mini PCs if the vision PC currently doubles as the office workstation.

When NIC tuning is not the answer

• Symbol or CRC errors climbing on the adapter. The cable or connector is failing — replace it. Tuning cannot recover bits corrupted in the copper.
• No packets at all. If the SDK reports an empty stream rather than gaps, check trigger and strobe first; the blank-image probe walks the chain from trigger to stream in order.
• The error names the wrong camera. With several cards or ports installed, device order can swap channels: the device-order fix matches cameras to ports reliably.

Check any switch in the path after a firmware update too. Jumbo settings and port speeds can reset to defaults, and a hop that silently shrinks its MTU looks exactly like a NIC problem.

Prevention: keep the fix from drifting back

• Record packet size, NIC MTU and descriptor count on the machine file. OS feature updates and driver installs can reset adapter properties to defaults.
• Keep the lost-packet counter on the dashboard and watch it across a full shift; correlate spikes with scheduled tasks such as backups and scans.
• Run one high-rate camera per port; add a second only when the combined rate stays inside the 90 percent budget.
• Re-run the camera's test-packet check after any switch replacement or firmware update.
• Keep acquisition exclusive: a second application that opens the same camera competes for the link — connect only when subscribed and the link stays free.
• For runs past a few metres, use locking connectors and strain relief at both ends.

If the worked example says your stream needs more than one GigE port, size the chain in order — camera, NIC, cable — before you build:

If packets still go missing after all four settings, send the adapter properties and the counter export through the contact page — expert support comes with every order. Neighbouring faults live on the systems topic page.