Machine vision cameras on an ARM SoM: the Linux checks

You want the small board, not the box: a system-on-module (SoM) puts a multi-core ARM processor, a gigabit Ethernet MAC and a USB 3 controller on one carrier, and the question is whether industrial cameras behave when plugged into it. They do, and for a structural reason: GigE Vision and USB3 Vision are interface standards whose Linux support lives in userspace, above generic Ethernet and USB hardware. What decides success is bandwidth arithmetic and host buffer sizing, not a per-camera porting effort. This explainer gives the numbers for both interfaces, one worked bandwidth example you can copy, and the boundary where an ARM SoM stops being the right host.

Do machine vision cameras work on an ARM SoM at all?

Yes — any camera speaking the GigE Vision or USB3 Vision standard runs on an ARM SoM, because both interfaces are driven from userspace over generic Ethernet and USB hardware; there is no per-camera kernel port to write.

The split between the two standards matters less than people expect:

• GigE Vision cameras are reached over ordinary UDP sockets: a control protocol for discovery and settings, a streaming protocol for image packets. If your kernel runs a network stack, the camera is reachable; the camera-specific part is the GenICam feature interface, which the transport library reads at runtime.
• USB3 Vision cameras enumerate as USB devices and are driven from userspace through libusb on the xHCI controller. No vendor kernel module is part of the standard path.

So compatibility is a property of the SoM's Linux image, not of the camera maker. What you must confirm is that an aarch64 build of your acquisition layer exists — either the camera SDK for ARM64, or an open transport library that speaks both standards on Linux. This is the opposite of the MIPI CSI-2 route, where every sensor needs device-tree and driver work before it produces a pixel; the embedded camera interface comparison from CSI-2 to GMSL2 lays out that trade.

If you are choosing camera and compute together, start from area scan cameras and work back to the host, not the other way round.

What does a GigE Vision camera need from ARM Linux?

Plain Gigabit Ethernet: a GigE Vision camera needs no kernel driver, only a 1 GbE port, a socket receive buffer raised from the 212,992-byte Linux standard value to 16 MiB, and jumbo frames near a 9000-byte MTU.

The kernel ships with values tuned for general networking, not for one-socket frame capture, so three settings do most of the work on an embedded image:

1. Raise the receive buffer ceiling: net.core.rmem_max = 16777216 (16 MiB) and net.core.rmem_default to match, made permanent in /etc/sysctl.d/. Without it, image packets overflow the standard buffer and frames arrive torn.
2. Turn on jumbo frames end to end — MTU 9000 on the SoM port, on the switch and on the camera — so a 12 MP frame travels as roughly 1,300 packets instead of 8,000.
3. Give every camera a fixed IP plan. Discovery on a busy embedded network is the first thing to break, and Linux GigE Vision camera discovery troubleshooting covers the usual failure points.

Packet loss from a small receive buffer is the number-one cause of torn frames on embedded hosts; the diagnosis and exact settings are in GigE camera buffer timeouts on embedded Linux: socket buffer tuning.

Multi-camera wiring is where GigE earns its keep on a small host: several cameras share one link at a common budget, or each gets its own port — the arithmetic and port layout are in Multi-camera GigE bandwidth budget: divide the link first and Two GigE cameras on one host: NIC ports and bandwidth budget. A concrete ceiling: the LS-CMR-0053 is a 12 MP GigE camera rated at 9 fps. That rating is the copper-gigabit link budget expressed as a frame rate, as the worked example below shows.

What does a USB3 Vision camera need from ARM Linux?

A working xHCI USB 3 controller and one module parameter: the usbfs memory pool starts at 16 MB, so raise usbcore.usbfs_memory_mb to 64 MB or a 12 MP frame stream will drop on any board, x86 included.

The sequence that bites everyone: the camera enumerates, low-resolution previews look fine, then full-resolution acquisition freezes after a few frames. That is the 16 MB usbfs pool running out, because the userspace driver stages each frame through it. Set usbcore.usbfs_memory_mb=64 on the kernel command line (or at module load) and the stream holds. Two more host-side items finish the job: raise the open-file limits, covered in USB3 Vision cameras on Linux: usbfs and file limits that need tuning, and keep the controller for the camera alone.

That last point is bandwidth, not software: one 5 Gb/s xHCI controller sustains roughly 350-400 MB/s of payload, and a full-rate 12 MP camera eats nearly all of it. Sharing the controller with a second camera or a USB drive halves frame rates in practice — the numbers and the fix are in Two USB3 cameras at full resolution stream: raise the host USB buffer and USB3 hub bandwidth for multiple machine vision cameras. If the board you have in mind shares one controller across several connectors, read Choosing an ARM board for USB3 camera acquisition before committing: port count and controller count are not the same number.

When the pixel rate is fixed by the task and the link cannot carry it, cut the frame instead — region of interest, decimation or binning all divide the payload, and 4x4 binning vs 2x2: sensor readout decides your frame rate shows which of those the sensor actually allows.

How much bandwidth does one camera really use?

Plan on 360 MB/s, about 2.9 Gbit/s, for a 12 MP mono camera at 30 fps: bytes per frame times frame rate, which is 12,000,000 × 30 for a 4000 × 3000 sensor at 8 bits per pixel.

Worked example from the catalog: the LS-CMR-0166 is a 12 MP USB3 camera rated at 4000 × 3000 and 30 fps. At 8 bits per mono pixel, one frame is 4000 × 3000 × 1 = 12,000,000 bytes ≈ 11.4 MiB. At 30 fps the camera produces 12,000,000 × 30 = 360,000,000 bytes per second — 360 MB/s, or 360 × 8 = 2,880 Mbit/s ≈ 2.9 Gbit/s.

Three decisions drop out of this one sum:

• USB3 carries it, alone. A 5 Gb/s controller delivers about 500 MB/s of theoretical payload after line encoding and 350-400 MB/s sustained on a busy SoC. One camera per controller, nothing else on it.
• 1 GbE does not. The practical streaming ceiling on a gigabit link is 100-115 MB/s. 115,000,000 ÷ 12,000,000 ≈ 9.6, so about 9 fps is the most this frame will ever reach on copper gigabit — which is exactly where the GigE variant lands.
• Do not stream RGB8. Debayered color triples the payload: 12,000,000 × 3 × 30 = 1,080 MB/s, beyond any single 5 Gb/s link. Stream raw Bayer or mono and debayer on the host; as a planning figure, budget one to two cores of a quad Cortex-A55-class part for the debayer copy at this rate.

The same sensor behind the two interfaces shows which side sets the ceiling:

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

GigE or USB3: which interface suits an embedded SoM build?

GigE gives you 115 MB/s per link and 100 m of reach; USB3 gives you about 400 MB/s per controller and about 3 m of passive cable.

Choose by topology, not by peak rate:

• Cameras far from the board, or more than two of them: GigE. A switch or a multi-port card makes wiring trivial and every camera keeps its own share of the budget.
• One high-rate camera next to the compute: USB3. Nothing else on a small board moves 400 MB/s for one sensor.
• High rate at distance: neither of the above. A 2.5 or 5 GbE camera on a matching NIC is the fit, with the numbers in 5GBASE-T camera interface: bandwidth, cables and distance.

Which SoM and carrier features decide the design?

Three items decide it: a current long-term kernel — 5.15 or 6.1 class — with 64-bit ARM userspace, an aarch64 build of your acquisition library, and a carrier whose Ethernet and USB ports match the camera count.

Check these before the order goes in:

• Kernel and userland. A 5.15- or 6.1-class LTS image from the SoM vendor, 64-bit userland, and the ARM64 build of your SDK or transport library confirmed to run. Software availability sinks more ARM vision projects than hardware does; if your processing tool ships only for x86, that single fact ends the SoM discussion — some measurement suites and LabVIEW builds on a Linux ARM target are the common examples.
• Ports equal to controllers. Count xHCI controllers, not USB connectors; count Ethernet MACs, not jack holes. Two cameras need two controllers or two ports.
• PCIe, if the camera count can grow. A carrier with a PCIe slot turns "we added a fourth camera" into a card swap instead of a redesign: the LS-FGB-0004 is a PCIe x4 PoE gigabit card with a port per camera and power on the same cable.
• Thermals. Sustained capture plus processing runs the SoC near its power limit; a fanless carrier that throttles at 70 percent load will drop frames at the worst moment. Ask for the throttling curve, not the peak frequency.
• The camera itself, if it lives inside the machine. When the sensor is part of the assembly rather than cabled to it, board-level cameras remove the connector and cable problem entirely, and their selection questions are their own: Board level camera selection for embedded vision machines. Two examples span both interfaces:

The MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera with an M12 mount and a global shutter; the LS-BCM-0003 is a 3.1 MP USB3 board-level camera rated at 120 fps.

When is an ARM SoM the wrong host?

Above roughly 500 MB/s of aggregate camera traffic, or the moment you need 10GigE or CoaXPress, move to an x86 host: sustained PCIe DMA at those rates is a frame-grabber-class job, not a SoM-carrier job.

The boundary is mechanical once you see the numbers:

• 10GigE and CoaXPress cameras stream through PCIe cards. A 25 MP 10GigE camera at 30 fps and 8-bit mono is 25,000,000 × 30 = 750 MB/s of sustained DMA, and SoM carriers rarely expose the slot or the memory bandwidth for it. That is frame grabbers territory: on an x86 host the MV-GT2104 Quad-port copper 10GbE NIC is the typical landing spot.
• Hot, sealed enclosures. Sustained full load at high ambient temperature needs the thermal budget of a chassis built for it; industrial mini PCs fill exactly that slot when the SoM's heatsink cannot.
• Below that line, one or two GigE or USB3 cameras at a few hundred MB/s with standards-based software, the SoM is the right host, and the size and power savings are real.

What proves the design in the first hour on the bench?

Bring-up proof in five steps: enumerate the camera, raise the two buffer pools, run full-frame continuous acquisition for several minutes, and demand zero dropped frames with CPU headroom to spare.

1. See the camera. Ping the camera's address, or list the system's USB devices. A camera that is not visible is a wiring or power problem, not a Linux problem; if visibility comes and goes, Camera discovery after connection in a running application is the map.
2. Raise the pools. net.core.rmem_max = 16777216 for GigE, usbcore.usbfs_memory_mb = 64 for USB3, open-file limits up. Reboot once so the settings are proven persistent.
3. Stream at full size. Not a preview: full resolution, target frame rate, mono 8-bit, several minutes. Watch the dropped-frame counter, not the live image.
4. Load the CPU. Start your processing while the stream runs. If frames drop only under load, the SoC is the constraint, and the fix is a smaller frame or a bigger core budget.
5. Heat it. Ten more minutes at load, then read the SoC temperature. A design that throttles at minute eleven will fail at the customer in month eleven.

When the numbers hold, the rest is mechanical: pick the camera in the camera finder, wire the whole station through the system configurator, and read the host-side guides on the systems topic page. If the bandwidth budget needs a second opinion, bring it to the contact page.