Black horizontal stripes on GigE camera images: causes and fixes

A live image that tears into black horizontal bands stops a line faster than most camera faults, and it almost never means the camera is broken. The bands are lost Ethernet packets: the sensor delivered the rows, the host never received them all. This guide gives you the test that separates network loss from sensor or lighting faults in a few minutes, the settings that fix the loss in the order that works, and the bandwidth arithmetic that tells you whether the link was ever big enough for the camera on it. Everything here applies to any GigE Vision camera on a PC host, from a single-camera bench to a multi-port frame grabber card.

Why does a GigE camera image tear into black horizontal stripes?

The stripes are almost always lost Ethernet packets, not a damaged sensor: when the receiving host misses packets under load, the missing bytes appear as black horizontal bands at the bottom of the image or scattered through it.

GigE Vision splits every frame into UDP packets, and each packet carries consecutive rows of pixels. The receiving driver writes them into a frame buffer as they arrive; a packet that never lands leaves a hole that the driver fills with black, and because loss is random the band sits at a new height in every grab. UDP has no retry of its own, so the hole stays unless the driver catches it and asks the camera to resend, which is the job of the SDK's performance filter driver.

Rank the causes in this order before touching the camera: a network port shared with other traffic, jumbo frames disabled on camera or host, a stream whose bandwidth exceeds the link, security software filtering the UDP stream, and power-saving features that park CPU cores mid-stream. If the stripes vanish the moment the camera moves to another computer, that is the diagnosis: the sensor is fine, the receiving side is not. The stream-level view of the same symptom is in GigE Vision packet loss: horizontal lines in live images.

How do you confirm lost packets rather than a broken sensor?

Confirm it in one minute: run continuous grabs and watch whether the stripes move, open the SDK's loss statistics while the stripes appear, and read the negotiated link speed — moving stripes, climbing counters and a 1.0 Gbit/s link mean packet loss, not a sensor fault.

Run the three checks in this order.

1. Watch for movement. Stripes at a new height on every grab point to loss. Shapes that hold the same rows across many grabs point to optics, illumination or the sensor itself; skip to the other-causes section below.
2. Read the counters. Every serious SDK reports stream health. Look for a lost-packet counter, or log errors such as 'buffer was incompletely grabbed', which is how an incomplete frame announces itself; the fix for that error walks the same packet-loss path. Some libraries word it differently: NI IMAQdx raises the loss as a buffer overflow, and the GigE camera buffer overflow checklist covers that variant.
3. Check the link speed. The adapter status must read 1.0 Gbit/s, full duplex. A link that negotiated down to 100 Mbit/s carries a 5 MB frame at roughly 2 fps and drops most of the rest; the packet size error below gigabit article covers that failure. Swap in a known-good Cat 5e or better cable and re-check.

Finish with a cross-host test: same camera, same cable, a different computer. Clean there, and the host configuration is the fault. Identical stripes there, and the camera or cable is the suspect.

Which packet size and jumbo frame setting stops the tearing?

Set the camera's packet size to 9000 bytes and set the same jumbo-frame MTU on the NIC, because a 5 MB frame then arrives as 558 packets instead of 3,343, which cuts the per-packet driver work by roughly six times.

Both ends must agree. On the camera, the GenICam feature is PacketSize in the Transport Layer category, and 9000 bytes is the value to aim for. On the host, the adapter's advanced properties expose the same ceiling as its jumbo frame or MTU setting; pick the largest offered value of 9000 bytes or more, which adapters label 9 KB or 9014.

Not every camera supports jumbo frames. Read the PacketSize range in the camera's feature list first; if a model tops out lower, set its maximum and match the adapter to that value.

Verify before you stream: most SDKs probe the path with a test packet when a new size is applied, so test packet not received covers the probe failing, packet size exceeds MTU covers an adapter that advertises a size it cannot carry, and set the packet size before acquisition starts covers the ordering that avoids both.

One more Transport Layer control earns its keep on shared links: raise Inter-Packet Delay so the camera spreads its packets evenly across the frame period instead of firing them in one burst at line rate. On a busy host, smoothing the burst is often the difference between a clean stream and a torn one.

Which network adapter and driver end the packet loss for good?

Give the camera its own network port on a dedicated adapter, because a port shared with office traffic and background software is the most common root cause of repeated packet loss on otherwise healthy cameras.

Shared is the operative word. A camera hanging off the office switch, behind a VPN client and an antivirus that inspects every packet, loses frames in ways no camera setting can repair. Put the camera on a port of its own, exclude the SDK's executable and its traffic from firewall and antivirus scanning, and switch off the adapter's power saving: Energy-Efficient Ethernet and the option that lets the operating system power the device down both produce loss that appears only under load.

Then install the SDK's high-performance filter driver on the adapter the camera uses. It changes how packets reach your process and enables the protocol's resend mechanism, and the gain is quantified in GigE Vision high-performance NIC driver: how much you gain. If loss persists after driver and jumbo frames, work through NIC tuning in the right order instead of changing settings at random.

When the bench grows, a PCIe card dedicated to cameras removes the last shared variables, and PoE models carry power over the same cable as data. The MV-GE2002P is a full-height dual-port PoE NIC. The LS-FGB-0004 is a PCIe x4 card with four PoE Gigabit ports on Intel i210AT controllers.

How much bandwidth does your camera really need?

Do the bandwidth sum before changing anything else: pixel width × height × bytes per pixel × frame rate, so a 2448 × 2048 Mono8 camera at 24 fps needs 120 MB/s ≈ 963 Mbit/s, which already saturates a Gigabit link.

Worked example, with a common 5 MP mono sensor as the illustrative input. Pixels: 2448 × 2048 = 5,013,504, and at 1 byte per pixel (Mono8) that is 5,013,504 bytes, about 5.0 MB per frame. At 24 fps: 5,013,504 × 24 = 120,324,096 bytes/s, about 120.3 MB/s, or 120.3 × 8 ≈ 963 Mbit/s. A Gigabit link passes roughly 940-950 Mbit/s of UDP payload after Ethernet and IP overhead, so the ceiling lands at 950 / 8 / 5.0135 ≈ 23.7 fps. The 24 fps this camera class runs at sits exactly on that ceiling: a clean link and a good driver hold it, and any background load tips packets over the edge.

Packet counts show why jumbo frames help even on a link that is not saturated. At a 1500-byte MTU the 5.0 MB frame needs 5,013,504 / 1500 ≈ 3,343 packets, about 80,232 packets per second at 24 fps. At 9000 bytes it needs 558 packets, about 13,392 per second: a sixfold cut in interrupts and driver work for identical pixels.

Colour multiplies the sum. RGB8 stores 3 bytes per pixel, so 2448 × 2048 × 3 × 24 × 8 ≈ 2,888 Mbit/s, which no Gigabit link carries; this is why GigE colour cameras send raw Bayer at reduced rates instead of decoded RGB.

The decision falls out of the sum. Keep the planned stream under about 80% of the practical ceiling and jumbo frames plus the filter driver will hold it. Above that, cut the stream with a frame-rate cap, a smaller region of interest or binning — 4x4 binning vs 2x2: sensor readout decides your frame rate shows how readout mode changes the data rate — or step up to a faster link class.

What else causes horizontal stripes in a live image?

Stripes that stay in the same place across grabs are not network loss: fixed dark lines point to illumination flicker, dust on the sensor or a damaged sensor, while stripes that move with every frame point back to the network.

Work down this list:

• Mains and LED flicker. Bands near a fixed height that pulse or drift slowly mean the light is beating against the exposure. Match the exposure time to the light's drive or use a DC-driven light; camera image flickers: mains beat and triggers separates the causes with tests.
• Pulsed light on a rolling shutter. A strobe fired during a rolling-shutter scan paints one bright or dark band where the scan crossed the pulse. Fire the strobe inside the exposure window or move to a global-shutter camera.
• Dust and sensor defects. Shapes that hold the same pixels across thousands of grabs, even with the camera off the network: clean the sensor and its cover glass, and if a one-pixel dark line remains, the sensor is the fault.
• Your own code. Stripes in saved images while the live view is clean means the processing touched a buffer the driver reused; copy the buffer before you queue it is the entire fix.

How do you keep several GigE cameras tear-free on one host?

On a multi-camera host, budget bandwidth per port and per CPU core before adding cameras, because two 5 MP streams at full frame rate ask one shared link for about 1.9 Gbit/s, and packet interrupts double with them.

Give each camera its own NIC port, and never bridge two camera streams through a single Gigabit uplink. The per-port and per-core budget for a two-camera host is worked through in two GigE cameras on one host: NIC ports and bandwidth budget. The jumbo-frame setting matters more here than anywhere else: four cameras at 1500-byte packets are an interrupt storm no driver absorbs.

Cameras also exist above GigE. 2.5GBASE-T and 5GBASE-T models push a single cable well past 1 Gbit/s, with the cable and distance rules covered in 5GBASE-T camera interface: bandwidth, cables and distance. The host needs ports to match:

Past that sits 10GigE, where larger sensors land: a 4000 × 3000 mono sensor at 30 fps produces 4000 × 3000 × 30 × 8 = 2,880 Mbit/s, and that is before colour. For streams of that size the host-side answer is a 10GigE card:

How do you stop the stripes from coming back?

Lock the working configuration into the start-up routine and re-run the loss test after every software change: packet size, jumbo MTU, driver settings and firewall exclusions all revert after operating system updates, and an unattended revert brings the stripes back.

Make the fix permanent with this checklist:

• Record the working values in the station file: camera PacketSize, adapter jumbo or MTU setting, filter driver version, and which camera sits on which port.
• Exclude the SDK's executable and its traffic from firewall and antivirus scanning, and re-check after every security tool update.
• After an operating system update, confirm the filter driver is still bound to the camera's adapter and that the jumbo setting survived.
• Leave adapter power saving off on camera ports; Energy-Efficient Ethernet and device power-down both reappear after driver updates.
• Soak-test for ten minutes at the production frame rate and require a zero lost-packet counter before releasing the station.
• Keep one known-good Cat 5e cable in the drawer, and after any re-cabling confirm the adapter still negotiates 1.0 Gbit/s, full duplex.

If the counters still climb after all of that, on a clean host, with jumbo frames end to end and a dedicated PoE port, the camera or its cable is the genuine suspect. Send us the counters through the contact page and we will read them with you. For the host-side parts, start at frame grabbers or the accessories finder; for cameras that outgrow GigE, browse area scan cameras, the camera finder or start the configurator.