Why a raw UDP camera is not detected by your vision SDK

The symptom is always the same: the camera streams packets onto the wire, your UDP receive loop prints the bytes, and the SDK's device list stays empty no matter what you do with IP addresses. This is for engineers integrating a camera that speaks a private or half-documented protocol. You will learn why no discovery-based SDK can ever list such a camera, a five-minute test that separates a protocol problem from a network problem, and the arithmetic — packets per frame, bytes on the wire, megabits per second — that tells you whether decoding the stream yourself is realistic. Then the decision: vendor firmware, your own receiver, or a standard camera.

Why doesn't the camera appear in your SDK's device list?

Because a vision SDK lists only the cameras that announce themselves on a protocol it supports, and a raw UDP streamer never announces anything — an empty device list is the discovery mechanism working as designed, not a fault that a driver reinstall can fix.

Device lists are built at enumeration time, before any open call. A GigE Vision SDK broadcasts a discovery request on the protocol's reserved UDP port and lists every camera that answers with a valid protocol reply. A webcam-class camera is enumerated by the operating system's USB video class driver and handed to the SDK from there. FireWire and Camera Link cameras are listed through their frame grabbers.

Your camera does none of these: it simply starts sending datagrams. UDP is a transport, not a protocol the SDK knows; nothing in the camera answers a discovery request, so no enumeration call ever returns it. If a camera that does claim GigE Vision support stays invisible, that is a different fault with its own fix chain, covered in GigE Vision camera not detected in software: fix the enumeration chain. Most faults in this family, from enumeration chains to packet timeouts, are collected on the systems topic page.

Which cameras do vision SDKs enumerate automatically?

Three families enumerate on their own: GigE Vision cameras answer a discovery broadcast, USB video class cameras register with the operating system's driver stack, and frame-grabber cameras are listed by the grabber itself — every other protocol stays invisible to the SDK.

For network cameras the mechanism is a question and an answer: the SDK broadcasts a discovery request, and each GigE Vision camera on the subnet replies with its identity — model, serial number, current IP configuration and its feature set. That reply becomes the list entry. USB video class cameras register with the operating system when plugged in, so the SDK reads them from the OS enumeration. Frame-grabber cameras are enumerated by the grabber driver, which knows what it plugged into.

All three cases share one order of operations: the camera speaks a defined protocol first, and the SDK discovers it second. A private UDP stream has no discovery reply and no registration, so it fails at step one on every SDK. That is why two cameras can share a switch and a subnet while only one of them appears.

Why does the data arrive but the SDK still can't open the camera?

Because a socket receive proves only IP connectivity, while the SDK's open call needs a device handle from enumeration — no IP address, port or firewall change can turn raw datagrams into something the SDK can open.

Your receive loop and a ping both work at the IP layer: datagrams reach the host and the host answers ICMP. Enumeration and open live one layer up, in the protocol. Every open call — including any open-by-address variant — selects among devices the transport layer has already enumerated; it cannot invent a device that never announced itself. That is why the same camera that works as a string source can never feed the SDK's image acquisition: the bytes are there, the device is not.

Virtual machines produce a misleadingly similar symptom, with ping working while the discovery list stays empty, but for a different reason — worth reading before changing anything: WSL2 GigE camera discovery: why ping works and the list is empty.

What does it take to decode a raw UDP video stream yourself?

Five facts from the camera's interface document: header layout, pixel format and bytes per pixel, payload size per datagram, the stream port, and the end-of-frame rule — with those five, the receiver is a page of code, and without them it is guesswork.

The receiver itself is short: bind the stream port, read datagrams, strip the header, write each payload at the offset it declares, and detect the frame boundary by the rule the document gives — a new frame ID, a tail packet or a length counter. Treat a gap in frame IDs or offsets as a lost packet: skip the frame, count it, move on. A supported stack instead requests a resend and reports the ratio; the timeout side of that is covered in GigE stream packet resend ratio: fix buffer timeouts. When loss does slip through a supported stack, it surfaces as an incomplete grab with its own diagnosis — GigE camera buffer was incompletely grabbed: fix lost packets.

Worked example with example numbers, yours to take from the camera's document: a 1024 × 768 Mono8 frame carries 1024 × 768 × 1 = 786,432 bytes of pixels. If the document defines 1,578-byte payloads with a 24-byte header per packet, one frame travels as ceil(786,432 / 1,578) = 499 packets — 498 full and a last one with 588 bytes. On the wire that is 786,432 + 499 × 24 = 798,408 bytes ≈ 0.80 MB per frame. At 30 fps the link carries 798,408 × 30 ≈ 24.0 MB/s ≈ 192 Mbit/s, about 19% of a GigE link's raw 1,000 Mbit/s: comfortable headroom for this sensor size. The socket must also swallow 499 × 30 ≈ 15,000 datagrams per second, so the receive buffer should hold at least two frames — about 1.6 MB — to survive scheduling jitter.

Which fix do you choose for a raw UDP camera?

Flash GigE Vision firmware if the vendor offers it for your model, write your own receiver only for one-off lab capture, and replace the camera with a standard GigE Vision camera for anything that runs in production — the hand-written stack never stops demanding engineering hours.

Commit to the firmware path whenever it exists: it converts the camera into a standard citizen and every tool you already have starts working. The custom receiver is a lab instrument. The same trade-off runs through industrial networking generally: a device that exposes a documented service layer instead of raw TCP or UDP reduces integration to configuration, which is the argument behind HTTP web services rather than raw TCP or UDP for tag writes.

Which camera and controller make the problem disappear for good?

Any area scan camera in the shop that prints GigE as its interface answers the same discovery broadcast at power-up, so the SDK lists it on the first enumeration pass — no receiver code, no header parser and no loss handling of your own.

The area scan cameras category holds 1,287 models, 597 of them on a GigE interface; the camera finder filters them by resolution, shutter and sensor format. Three GigE options, mono and colour, across the common range:

The machine that runs the SDK is the same box that would run your receiver: a vision controller. The category is filtered by LAN port count, USB 3 port count and built-in light channels, so one unit can take the camera stream, drive the strobe and talk to the PLC. The MV-VC3301H-128G66 pairs an Intel Core i3 with 8 GB of memory, 5+ LAN ports and 4 built-in light channels, and includes the VM6200Pro runtime license. A 30 fps GigE stream like the worked example sits easily inside that.

On a standard stack, packet size and timing are negotiated with the camera at stream start; when that handshake fails you see GigE Vision test packet not received: fix packet size negotiation instead of silence — one more class of problem your own receiver would have left entirely to you.

To size camera, controller and lens as one system, start the configurator at the camera step:

How do you keep this off the next project?

Make the protocol a purchase-line item: write the standard by name on the order — GigE Vision, USB3 Vision, CoaXPress or Camera Link — and run a five-minute enumeration test on a bench before the camera is bolted into the machine.

The test costs one laptop and ten minutes: camera and laptop on the same subnet, SDK open, list entry within a minute of power-up. Everything after that is recording what you already know:

• The purchase line names the standard, never just 'Ethernet camera'.
• The commissioning record keeps the discovery reply — model, serial number, IP configuration.
• One network interface per camera stream, firewall off on that adapter during commissioning.
• If the only data sheet says 'UDP stream', ask for GigE Vision firmware before accepting the delivery.
• A custom receiver, if one must exist, stays in the lab source tree, never in production.

The decision in one line: firmware if it exists, a receiver for the lab, a standard camera for the machine. If the interface document you hold is thin and you want a second opinion on whether the stream is decodable — or would rather replace the camera with one that enumerates — the contact page is the fastest way to reach us.