Set GigE camera packet size before starting acquisition

A camera can appear correctly configured in a viewer yet return to a smaller packet size when your application opens it. The usual cause is a mismatch between saved driver preferences, the camera's current stream setting, and the network's supported MTU. This procedure is for applications that control GigE Vision cameras through a GenICam node map. You will set the camera value at the right point in startup, read it back, and verify that the complete network path can carry it.

Separate the three packet-size settings

Set the camera's stream packet size through its remote-device node map after opening the camera and before starting acquisition. Do not assume that a discovery parameter or a viewer preference writes the same setting.

The relevant settings live at different layers:

The GigE Vision packet-size value includes the IP, UDP, and GVSP headers, but not the Ethernet header or frame check sequence. Switch and adapter settings may use different size conventions. Compare their documented meanings rather than assuming equal-looking numbers are interchangeable.

A standard Ethernet MTU of 1500 bytes is a useful diagnostic baseline. Jumbo frames are an optimization, not a prerequisite for every GigE Vision application.

Establish a known network baseline

Before changing the camera node, identify the receiving network interface and every forwarding device between it and the camera. Include virtual interfaces or host bridges if the application uses them.

Start with a direct, controlled connection where practical. Verify camera discovery, control access, and reliable acquisition at the baseline packet size. If the camera cannot connect reliably, follow the camera network connection troubleshooting procedure before investigating jumbo frames.

Record these details:

• Camera firmware and application SDK versions.
• Host interface, driver version, and configured MTU.
• Switch ports and their maximum supported frame sizes.
• Camera stream channel, requested packet size, and actual readback.
• Any automatic packet-size negotiation enabled by the application.

Apply adapter changes using the operating system's documented procedure. Some changes require an interface restart, which interrupts acquisition. Schedule that interruption rather than changing the production network during an inspection cycle.

Open the camera and inspect the node

1. Open the camera with control access. Discovery normally provides device identity and connection information. It does not necessarily provide a writable camera node map. Complete the SDK's documented open operation before accessing remote-device features.

2. Finish configuration loading before your final packet-size write. Load any required camera user set, application profile, or transport configuration first. Otherwise, a later initialization action may replace the value you just wrote. The programmatic camera reset procedure explains why reset and configuration operations belong in a deliberate startup sequence.

3. Find GevSCPSPacketSize in the remote-device node map. Check that the integer node exists, is available, and is writable. Read its current value, minimum, maximum, and increment. If multiple stream channels are supported, select the intended channel using the camera's documented controls before reading its packet setting.

Do not confuse the remote-device node map with a local transport-layer or stream-grabber node map. Similar-looking settings can have different ownership and persistence.

If the feature is absent, stop guessing alternate parameter names. Use the GenICam feature-access troubleshooting guide to distinguish the wrong node map from an unsupported or temporarily unavailable feature.

Write a valid value before acquisition

4. Choose a value supported by both the camera and the path. Treat the camera's reported minimum, maximum, and increment as constraints. A value is not valid merely because it is a familiar jumbo-frame size or divisible by an assumed alignment.

For example, an application might request 8192 bytes on a path whose documented IP MTU is 9000 bytes. That is only a candidate: the camera must accept it, and any equipment using Ethernet-frame limits must allow the associated framing overhead.

5. Write the integer node and read it back immediately. Log both the request and the returned value. Reject an unsuccessful write or unexpected readback rather than silently continuing with your intended value.

6. Prepare reception and start acquisition using the SDK's required sequence. Some SDKs require a stream object earlier in initialization. Create it when required, but leave capture stopped while configuring writable transport features. Read the packet size again after stream preparation to detect automatic negotiation or initialization overrides.

The following is pseudocode, not a runnable SDK example. Each operation must be mapped to your SDK's documented API:

camera = open_device_with_control_access(device_identifier)
load_required_configuration(camera)

remote_nodes = get_remote_device_nodemap(camera)
select_stream_channel_if_required(remote_nodes)
packet_node = get_integer_node(remote_nodes, "GevSCPSPacketSize")

require_available_and_writable(packet_node)
requested = choose_supported_packet_size(
    packet_node.minimum,
    packet_node.maximum,
    packet_node.increment,
    validated_path_limit
)

write_integer(packet_node, requested)
require(read_integer(packet_node) == requested)

prepare_receiver_and_buffers_as_required(camera)
require(read_integer(packet_node) == requested)
start_acquisition_as_required(camera)

If preparation makes the node read-only, place the write earlier in the documented lifecycle. If preparation changes its value, inspect automatic packet-size negotiation and transport initialization before adding repeated writes.

Do not force a write through a locked acquisition state. Stop acquisition and release any transport lock through the documented lifecycle, then reconfigure.

Verify the complete jumbo-frame path

7. Acquire real images at the required operating load. A successful node write proves camera configuration, not successful packet delivery. Begin with the baseline, change only packet size, and compare receiver statistics under otherwise identical conditions.

Where the SDK provides documented packet-size discovery or test-packet support, use it to establish an initial candidate. Still verify sustained acquisition afterward. A path test may not reproduce the buffering and processing demands of a continuous image stream.

For each configuration, record:

• Completed and incomplete frames.
• Missing-packet, resend, and timeout counters where available.
• Host-interface errors and receive drops.
• Frame rate and application processing backlog.
• Packet-size readback after acquisition stops.

A large successful ping is supporting evidence only. It does not prove that the camera's image stream, receiving driver, or sustained packet rate works correctly.

If larger packets produce incomplete images, return to the baseline and repeat the same acquisition test. Reliable baseline operation with failing jumbo operation points toward a size-dependent configuration problem, but it does not identify the exact component.

Use the GigE Vision stream timeout guide when packets still disappear after configuration readback is correct. That separates path-size issues from receive buffers, packet pacing, and host scheduling.

Estimate what larger packets can change

Larger packets reduce the number of packets needed to carry an image. They do not reduce the number of image pixels, and they do not guarantee a higher usable frame rate.

Consider an illustrative uncompressed image containing 4000 × 3000 pixels, with one transmitted byte per pixel. Assume IPv4 without options, an ordinary 8-byte GVSP data header, and no additional per-packet fields.

The image contains:

With a 20-byte IP header, an 8-byte UDP header, and an 8-byte GVSP header:

The estimated image-data packet count falls by about 82%. This calculation excludes leader and trailer packets, retransmissions, Ethernet overhead, and other protocol variants. It estimates packet-processing demand, not achievable throughput.

Packed pixel formats, chunk data, and extended headers change the arithmetic. Use the actual transmitted payload and packet format when calculating your application load.

Find the startup action that changes the value

When the setting reverts, locate the lifecycle boundary where it changes. Rewriting configuration files without identifying that boundary can hide the cause.

Timestamp each readback alongside the operation that preceded it. A log containing requested value, actual value, and connection state is more useful than a screenshot of a viewer preference.

Persistence and correctness are separate decisions. An application can deliberately configure the camera on every connection. Save persistent camera settings only through the documented user-set procedure, and only when that is the intended deployment behavior.

Check hardware without assuming packet support

Packet-size troubleshooting rarely justifies replacing a camera first. Confirm that the existing camera exposes the required control and that the SDK supports its configuration lifecycle.

For a catalog camera reference, inspect LS-CMR-0053. It has a GigE interface, but that fact alone does not establish a supported jumbo-packet range or a particular SDK behavior.

Use the area scan cameras category and camera finder to narrow interface requirements. Confirm packet-size controls in the relevant manufacturer documentation before choosing a replacement.

Cabling must suit the electrical link, connector arrangement, and movement requirements. It does not set GevSCPSPacketSize. The LS-CBL-0199 is a high-flex GigE camera cable with screw locks; verify connector compatibility for the installation.

For a different routing arrangement, inspect LS-CBL-0117 and its connector details rather than treating cable length as evidence of jumbo-frame support.

Compare the cables category with the accessories finder. A replacement cable may resolve physical-link errors, but it cannot correct an incompatible switch frame limit or an application startup override.

Keep the baseline when jumbo frames add risk

Retain standard-size packets when the baseline meets the inspection requirement and the network path cannot be validated for larger packets. Shared networks, constrained virtual interfaces, and undocumented forwarding equipment can make jumbo operation difficult to maintain.

Larger packets also occupy the link longer per packet. Applications sharing a link may need deliberate packet pacing and bandwidth allocation rather than the largest possible packet size.

Before releasing the configuration, check that:

• The intended camera and receiving interface are selected.
• The remote-device node is written after configuration loading.
• The requested value respects the reported range and increment.
• Readback matches after writing and stream preparation.
• The full network path supports the selected size convention.
• Sustained acquisition meets the application's frame-loss requirement.
• Reconnection and power-cycle behavior have been verified.
• Logs retain the actual packet size, not just the requested setting.

Build the camera and interface requirements in the camera configurator. If initialization still replaces the value, send the startup sequence, readback log, and network-path details through technical support before changing more hardware.