GigE Vision stream packet loss: diagnose blank frames

A camera can appear in discovery, accept settings and still deliver no complete images. For engineers commissioning a GigE Vision station, that combination calls for transport measurements before replacing hardware or changing image-processing code. Discovery confirms only part of the communication path; it does not prove that image payload packets reach the acquisition application.

The useful distinction is between no stream traffic, incomplete frames and complete images that display incorrectly. This procedure separates those cases using a controlled connection, interface checks, packet-size tests and receiver counters. Keep a record of each change so that a successful test identifies a cause rather than merely hiding the symptom.

1. Decide what the blank window actually means

Read acquisition statistics before adjusting exposure or gain. A display window alone cannot distinguish missing image data from a rendering problem.

Start with GigE Vision stream timeout checks if you need to distinguish transport timeouts from buffer-management problems. Here, the priority is locating where expected image packets disappear after discovery succeeds.

Advancing frame identifiers show that the receiver recognizes some frame activity. They do not establish that the image payload arrived. Similarly, a nonblocking socket reporting that no data is immediately available is not, by itself, evidence of a failed network adapter.

If complete buffers arrive consistently, move to blank image window troubleshooting instead of continuing to tune the network.

2. Establish a controlled baseline

1. Record the current configuration. Save camera addressing, selected host interface, packet size, pixel format, exposure, trigger mode and requested frame rate.
2. Use one camera and one receiving application. Close other viewers and acquisition services that could control the camera or change its stream destination.
3. Simplify the network path. Use a direct data connection where camera power permits. Otherwise, retain only the required compatible power injector or switch.
4. Select a modest acquisition load. If supported, begin around 5 frames/s with a supported low-payload pixel format. Use free-running acquisition unless the test specifically requires an external trigger.
5. Measure a fixed interval. Run each comparison for 60 seconds and record complete frames, incomplete frames, missing packets, resend activity and adapter receive errors.

Use a known-good cable suitable for the interface. A direct test removes shared switch traffic, but it does not eliminate host filtering, cable problems or receiver limitations.

Do not remove required camera power when simplifying a powered network connection. Confirm the camera's documented power method before changing the topology.

For stations sharing a host, multi-camera network discovery checks help document which camera belongs to each physical interface before you simplify the setup.

3. Verify the receiving interface and addressing

A host may have physical Ethernet adapters, wireless networking, virtual adapters and tunnel interfaces. Discovery tools can enumerate several of them, while the stream receiver binds to only one address.

Check these values together:

• The physical interface connected to the camera.
• That interface's current address and subnet mask.
• The camera's current address and subnet mask.
• The stream destination address and receiving port, where the software exposes them.

For an isolated example, a host at 192.168.50.10 and a camera at 192.168.50.20, both using 255.255.255.0, share a subnet. Use such an arrangement only when it does not conflict with existing equipment. Do not copy an address plan into a production network without approval.

Link-local addressing is not inherently defective. What matters is that the camera and receiving interface can communicate and that the application selects the intended interface. Multiple host adapters using overlapping subnets can make routing and interface selection ambiguous.

Prefer the application's documented interface-selection mechanism. Avoid disabling adapters used for machine control, remote support or other production services simply to make discovery simpler.

If discovery succeeds but opening the device fails, that is an earlier failure stage. Follow camera open failure after successful discovery before diagnosing image packet loss.

4. Test packet size before increasing receive timeouts

One revealing symptom is receipt of small stream messages while most image payload packets remain missing. An incompatible packet size can produce that pattern, but the pattern alone is not proof.

For the baseline, use an IP MTU of 1500 bytes and a camera stream packet setting documented to fit that MTU. Camera software and adapter drivers may label packet size differently: an IP packet size, an Ethernet frame size and an image payload size are not interchangeable.

Stop acquisition before changing the camera packet setting. Read the setting back, restart acquisition and compare the counters. The detailed sequence is covered in setting packet size before acquisition.

A useful comparison is:

• Standard-size packets produce complete images, while larger packets fail: investigate end-to-end packet-size support.
• Both settings fail with almost no image payload received: revisit destination selection, filtering and the actual network path.
• Both settings work at low load but fail at higher load: investigate congestion and host receive pressure.

A jumbo-packet setting must be supported throughout the path, including the camera, adapter and any intervening device. Do not enable a large value on one component and assume the rest of the path accepts it.

An unavailable automatic packet-size test does not establish the correct size. Use the documented manual setting and verify image completion.

5. Calculate the image load, then test burst sensitivity

For an uncompressed, unpacked monochrome image, estimate payload traffic from dimensions, bytes per pixel and frame rate. Use the camera's reported payload size when padding, chunk data or a different pixel format changes the buffer size.

Consider a hypothetical image measuring 2048 × 2048 pixels with one byte per pixel:

• Image bytes = 2048 × 2048 × 1 = 4,194,304 bytes.
• At 20 frames/s: 4,194,304 × 20 = 83,886,080 bytes/s.
• Payload rate = 83,886,080 × 8 = approximately 671 Mb/s.
• On a 1 Gb/s link, payload serialization alone takes approximately 33.6 ms per image.

These estimates exclude protocol overhead, resends and other traffic. A payload rate below the nominal link rate does not prove the path has enough operating margin.

Packet count also matters. Assuming an illustrative 1400 image bytes per packet, the image requires approximately ceil(4,194,304 / 1400) = 2996 payload packets. That payload assumption is not a camera packet-size recommendation.

Lower the frame rate without changing image dimensions. If completion improves, load sensitivity is likely. However, cameras can transmit each frame as a fast burst even when frames are widely spaced. Where documented and supported, inter-packet delay can spread that burst; increasing it also lengthens transmission time.

For several cameras, evaluate their shared link and simultaneous transmission patterns. Separating camera timing from host arrival jitter helps avoid treating delayed delivery as a change in exposure timing.

6. Locate packet loss with receiver evidence

Compare application counters with adapter statistics and, when authorized, a packet capture on the camera-facing interface. Capture only traffic you are permitted to inspect, and protect saved files because they may contain image data.

Use the following boundaries:

• Payload visible in capture, but absent from completed application buffers: examine the receiving software, buffer handling and host processing path.
• Payload absent from capture, while smaller stream messages appear: investigate packet-size support, filtering, physical-link errors and whether the camera actually transmits the expected payload.
• Adapter errors or discards rise during acquisition: investigate the cable, port, driver and receive capacity before changing frame-completion timeouts.

Capture software can drop packets too. Check its own drop counters before interpreting an incomplete capture as proof that the camera omitted packets. Offloading and capture location can also affect what the capture shows.

A zero buffer-underrun count only addresses the receiver's definition of that counter. It does not prove that the network, driver or socket path accepted every packet.

Likewise, resend-limit messages show unsuccessful recovery, not necessarily the original cause. Raising resend limits cannot repair a path that consistently rejects oversized packets, and repeated recovery traffic consumes bandwidth.

Keep the firewall enabled during normal operation. Use narrowly scoped, documented application and network rules rather than disabling protection across the host. Firewall checks for missing GigE Vision images cover that branch separately.

7. Compare acquisition software without changing the hardware

If interface selection, addressing and standard-size packets are verified, compare the same camera with another supported acquisition application. Obtain software only from the manufacturer or its authorized distributors.

Keep the cable, host port, pixel format, packet size and acquisition load unchanged. Close the first application before opening the second.

If one application receives complete frames and another does not, investigate the failing application's transport configuration, receive backend, architecture and supported operating-system build. This comparison narrows the investigation; it does not establish that either application is defective.

If both fail identically, continue testing the common camera-to-host path. Substitute a known-good cable, then another suitable host port, changing only one item each time.

For a custom application, verify that buffers match the reported payload size and return promptly to the acquisition queue. A display or processing thread holding buffers too long is a different problem from packets disappearing before reception.

Use buffer timestamp interpretation when you need to separate exposure time, reception and application handling.

8. Choose replacement parts only after isolating a boundary

Do not replace a camera merely because discovery works but acquisition fails. Substitute components to test a specific hypothesis, then confirm that the symptom follows the component.

The LS-CMR-0053 is a GigE area scan camera. Its interface identifies it as a candidate for a GigE system, not as a guaranteed substitute for an existing camera.

Compare area scan cameras using the camera finder when the evidence supports a camera change. Check pixel format, trigger behavior, exposure requirements, optics and application compatibility before selecting a replacement.

The LS-CBL-0199 is a high-flex GigE camera cable with screw locks. Confirm connector fit and locking compatibility before ordering.

Use the cables category and accessories finder to match the connector arrangement and installation requirements. Mechanical fit alone does not establish suitability for every link or power arrangement.

For a dedicated acquisition station, vision controllers are another system option. Evaluate the actual camera-port topology, supported acquisition software and sustained receiving performance rather than choosing by connector count alone.

9. Verify recovery and preserve the working configuration

A single complete image is not enough. Repeat the baseline test, then restore production conditions gradually: image dimensions, pixel format, frame rate, additional cameras and processing load.

As an initial verification, run 10 minutes at the intended operating point. At 20 frames/s, the expected count is 10 × 60 × 20 = 12,000 frames, assuming uninterrupted free-running acquisition. Compare that expectation with complete frames and documented intentional drops. Production acceptance may require a longer test.

Before returning the station to service, check:

• Complete images: the receiver reports successful completion, not merely detected frame identifiers.
• Loss counters: missing packets, resends and adapter discards stay within the application's validated acceptance criteria.
• Restart behavior: the intended interface, destination and packet setting return after a controlled restart.
• Shared-load behavior: other cameras and processing tasks do not recreate the symptom.
• Security settings: required protection remains enabled with only necessary access rules.
• Configuration record: retain addressing, software versions, payload settings and before-and-after counters.

If packet-size changes do not alter the symptom, do not keep reducing packet size indefinitely. Return to the evidence and test the next boundary.

For help selecting a replacement or reviewing the connection plan, use the camera configuration step or contact applications support. Include the topology, selected interface, packet setting and measured counters so the next decision rests on transport evidence.