GigE Vision All-In packet support: why no camera lists it

You have read camera datasheet after camera datasheet looking for All-In packet support and found it nowhere. The reason is physics, not negligence: GigE Vision defines All-In packets as an optional GVSP transmission mode for blocks that fit inside a single Ethernet packet, and a megapixel frame never does. This explainer covers what the feature is, the packet arithmetic that makes it irrelevant for area-scan imaging, and the two mechanisms that actually deliver whole frames: packet resend and a large GevSCPSPacketSize. It closes with the checks worth running before you order, and the camera, NIC and cable choices that follow from the numbers. Byte counts assume 8-bit mono pixels; scale them for color or 16-bit data.

What is an All-In packet in GigE Vision?

It is one GVSP packet that carries what normally takes three: the block leader, the payload and the block trailer combined, so a small block arrives as a single datagram instead of a leader, a run of data packets and a trailer. GVSP, the GigE Vision Stream Protocol, sends each buffer in that three-part form. The leader opens the block and states the payload type, each data packet carries up to the negotiated size, and the trailer closes the block. Every packet header carries a block identifier and a packet identifier, which is how a receiver reassembles frames and notices loss.

The specification makes the combined form optional: a transmitter may fold all three parts into one packet when, and only when, the whole block fits inside one packet. Nothing forces a camera maker to build it, so most never do, and no datasheet carries a row for it. The mode does exist where payloads are tiny — a miniature region of interest, chunk data attached to a frame, or a custom embedded device streaming a few hundred bytes. If you build such a device, plan for your receiver to accept the combined form; if you buy cameras, it is not a purchasing criterion.

Why does no GigE camera list All-In packet support?

Because the mode cannot carry a real camera image: one IPv4 datagram tops out at 65,535 bytes, and every switch on the path caps packets further at its MTU, 1500 bytes by default or 9000 with jumbo frames. Run the arithmetic on a modest industrial frame: 3072 × 2048 mono pixels is 6,291,456 bytes. Even if an IP datagram could use its entire 16-bit length field, that frame still needs 96 packets, and on a real jumbo network it needs 704. The leader and trailer that the All-In mode would fold in are two packets of those 704, about 0.3 percent of the wire traffic. Vendors leave the feature out because no customer can use it, not because the cameras cut corners.

When All-In is the right answer

Only when the whole block fits one packet: about 1400 bytes of payload on a network left at the factory setting, about 8900 with jumbo frames enabled end to end. A 40 × 30 pixel thumbnail, a status block, a chunk of a few hundred bytes — that is All-In territory. An image from any sensor you would actually buy is not.

How big can one GVSP packet actually be?

Set by the smallest MTU on the path: 1500 bytes by default leaves about 1464 bytes of image data per data packet, and a 9000-byte jumbo MTU leaves about 8964 bytes once the header stack is subtracted.

Header stacks differ by a few bytes between implementations; the negotiated test packet lands on the exact number for your hardware. The camera exposes the setting as GevSCPSPacketSize, and GigE Vision negotiates it with test packets before streaming: the software probes the path with increasingly large packets and keeps the largest that survives. Set it before acquisition starts — setting the GigE camera packet size before starting acquisition covers the ordering that avoids broken first frames, and capping auto-negotiation when the packet size exceeds the MTU covers the case where negotiation overshoots a switch in the middle.

What keeps every frame whole on a real network?

Packet resend does: because each GVSP data packet carries its block and packet identifiers, the receiver detects a gap and asks the camera over GVCP to retransmit exactly the missing packets before the frame times out. GVCP, the control half of the protocol, carries those resend requests. Your host-side driver or frame grabber watches the GVSP headers, spots a missing packet identifier, and asks for it by number. This mechanism, not a special packetization mode, is what makes GigE Vision usable on real networks.

Two conditions keep it working. First, headroom: resend traffic shares the same link, so a stream already at the bandwidth ceiling has nothing left to retransmit with, and you get incomplete frames from bandwidth pressure instead of recovered ones. Second, visibility: watch the resend ratio while commissioning, because a rising ratio is the early sign of a marginal cable or a switch under load — fixing buffer timeouts from the resend ratio and diagnosing packet loss that shows as horizontal lines walk through both. When several cameras share one link, pace them with the inter-packet delay rather than letting them collide: the multi-camera walkthrough on troubleshooting frame drops with several GigE cameras covers pacing and the bandwidth split, and multiple cameras on one trigger shows the burst-collision case.

How many packets does a 20 MP frame need?

About 13,638 packets at a 1500-byte MTU, or 2229 with jumbo frames: a 5472 × 3648 mono frame is 19,961,856 bytes, and each data packet carries 1464 or 8964 bytes of it.

• 5472 × 3648 × 1 byte per pixel = 19,961,856 bytes per frame
• At 1500 MTU: 1500 − 36 = 1464 bytes per data packet; 19,961,856 / 1464 = 13,635.2, so 13,636 data packets with the last carrying 216 bytes; add leader and trailer for 13,638 packets
• At 9000 MTU: 9000 − 36 = 8964 bytes per data packet; 19,961,856 / 8964 = 2226.9, so 2227 data packets with the last carrying 7992 bytes; total 2229 packets

The frame-rate row assumes an otherwise idle link moving about 115 MB/s of the 125 MB/s theoretical line rate. The camera resolution calculator sizes the pixel count for your field of view and tolerance; multiply by bytes per pixel to get the frame bytes this arithmetic starts from.

An All-In transmission of this frame would need a single 20 MB datagram. The IPv4 length field stops at 65,535 bytes, about 0.3 percent of this frame, so the question answers itself. Catalog numbers show the same ceiling from the other side. A 4000 × 3000 mono frame is 12,000,000 bytes, and 12,000,000 bytes × 9 fps = 108 MB/s, which is the whole link nearly spent on one camera. That is why the LS-CMR-0053, a 12 MP GigE camera, is specified at 9 fps. Over USB3, the LS-CMR-0166 streams the same 4000 × 3000 resolution at 30 fps. Twelve megabytes at 30 fps is 360 MB/s, far past any gigabit link, which is exactly why that camera is not a GigE model.

How do you check a camera's GigE features before buying?

Read the GenICam XML feature list before ordering: ask the vendor for the file or the GigE Vision conformance statement, then look for the Gev-prefixed stream features whose ranges reveal how the camera packets its data.

• GevVersionMajor and GevVersionMinor report the GigE Vision version the camera implements.
• GevSCPSPacketSize: its maximum is the number you want. A maximum of 9000 or more means full jumbo frames; a maximum near 1500 means the camera expects factory-setting networks only.
• GevSCPD, the inter-packet delay, matters when several cameras share one link and you need to pace them.

On the bench the same XML is served by the camera itself over GVCP once it has an address, so you can confirm what the datasheet promised. If a sub-packet payload genuinely needs the combined form, ask in writing whether the transmitter sends All-In packets and get the answer into the datasheet; for megapixel area-scan cameras the honest answer is no.

Which camera and parts should you buy instead?

Any current GigE Vision camera whose GevSCPSPacketSize maximum reaches jumbo size and whose resend behavior you can confirm on the bench — then spend the saved effort on the link itself: a PoE network card, solid cabling and a bandwidth budget. The area scan cameras finder filters by interface and resolution; three tiers cover most of what the arithmetic above allows.

A 6 MP camera is the comfortable gigabit citizen: the 6 MP GigE mono camera with a C-mount fits here. A 3072 × 2048 mono frame is 6.3 MB, so 10 fps costs about 63 MB/s, inside one gigabit link with room for resend traffic.

At 20 MP you sit near the ceiling of one gigabit link. The MV-CS200-10GC is a 20 MP GigE camera with a 1-inch sensor in a C-mount. It lives at the 5.7 fps ceiling from the table above; for faster 20 MP streaming, step the interface up — 5GBASE-T camera bandwidth, cables and distance covers the middle step between gigabit and 10GigE.

Beyond that, buy the interface first. The MV-CH250-25TC-F-NF puts 25 MP frames on 10GigE through an F-mount. Twenty-five megapixels of mono data at 25 fps is about 625 MB/s, and color triples it; no gigabit link belongs in that conversation.

The link layer finishes the system. A dual-port PoE card powers two cameras over their data cables; the MV-GE2002P is a dual-port PoE NIC. For the run out to the camera, the LS-CBL-0117 is a locking-RJ45 camera data cable at 15 m. Keep any single 1000BASE-T run under 100 m, and treat longer distances as a job for frame grabbers with the right ports. Browse cables by length and connector when you lay out the cell.

What should you confirm before ordering?

Six checks: jumbo MTU end to end, the GevSCPSPacketSize maximum in the XML, a PoE card with room for every camera, cable runs under 100 m, a bandwidth budget with headroom, and a resend test on the bench with the final cable.

1. Match the MTU on camera, NIC and every switch — 9000 everywhere, or 1500 everywhere. One mismatched switch is the classic cause of silently broken streams; getting jumbo frames working when the MTU sits at 1500 walks the fix.
2. Confirm the GevSCPSPacketSize maximum is 9000 or more in the XML, so the camera can actually use the MTU you paid for.
3. Budget each gigabit link to about 80 percent of 115 MB/s, roughly 90 MB/s, so resend traffic has room when a frame needs recovering.
4. Keep copper runs under 100 m per segment; past that, change the topology rather than hoping.
5. Stream with your final cable for a full shift and watch the resend counter; an incomplete frame that stays incomplete should be discarded and regrabged, not patched — discard, requeue and grab a new frame explains why.
6. Get the conformance statement and the XML with the quotation, and read the Gev feature names yourself.

When the list is settled, the vision system configurator walks camera, lens, light and controller in one pass, and the contact page reaches applications engineering for the feature questions a datasheet does not answer.