Get the first image on an embedded vision prototype

You need one clean frame from a camera that will eventually live inside a machine, and you need it this week. A prototype exists to prove the optics, exposure, lighting and software path before anyone commits a PCB; every week spent on interface electronics is a week not spent on image quality. Here is the decision we make on the bench, with its numbers: which camera class reaches a first image fastest, how much stream bandwidth and how many pixels the proof of concept really needs, which interface to pick, a day-one bring-up order, and the point at which a bare image sensor becomes the right answer.

Which camera gets the first image fastest?

A pre-built board-level camera on a standard USB3 Vision or GigE Vision interface gets you the first image fastest: power it from the host, open a GenICam sample viewer and capture within an afternoon, because no custom MIPI layout, sensor driver or ISP tuning sits between sensor and screen.

The reason is architectural. A USB3 Vision or GigE Vision camera is a finished device: it enumerates on a standard port, it is discovered by any GenICam-based viewer, and exposure, gain and trigger appear as named controls. A bare image sensor is a component: before one pixel reaches memory you must design and populate a PCB that carries its MIPI CSI-2 lanes, port a sensor driver, and tune an ISP. None of that work answers a single application question — is the lighting right, is the exposure in range, does the algorithm run. It only stands in front of those questions.

So the path runs one way: board camera on the bench, optics and algorithm proven, then the production integration. The module also teaches you the production requirements early — resolution band, shutter type, pixel size — so start from the board-level camera selection guide and the board-level cameras range. If the end product is a standard machine rather than an embedded device, move straight to housed area scan cameras: same first image, less integration later.

On a bench that must also catch motion, the LS-BCM-0003 is the default first pick: 3.1 MP, IMX252, 1/1.8" global shutter, 120 fps, C-mount, USB3.

How much bandwidth does the prototype stream need?

Size the stream before you buy: width in pixels × height in pixels × bytes per pixel × frames per second, kept under about 350-400 MB/s per USB3 port or about 110 MB/s on a dedicated GigE link.

Worked through: a 6 MP camera reads 3000 px × 2000 px = 6,000,000 pixels; in 8-bit mono one frame is 6.0 MB, so at 20 fps the camera pushes 6.0 × 20 = 120 MB/s. That fits a USB3 port with roughly 3× headroom and does not fit GigE, whose practical payload on a 1 Gbit/s link tops out near 110 MB/s. At 15 fps the same camera draws 90 MB/s and GigE carries it. Going to 12-bit roughly doubles the bytes unless the camera packs them: 240 MB/s at 20 fps, still inside USB3 with margin.

The GigE counterpart in this class is the LS-BCM-0020: 6.3 MP, IMX178, 1/1.8" rolling shutter, 18 fps, CS-mount.

6.3 MB per frame at 18 fps is 113 MB/s, which sits at the practical GigE ceiling: expect the rated frame rate on a short cable with jumbo frames enabled and a dedicated network card, and budget fewer frames per second without them.

How many pixels does the prototype actually need?

Work from the smallest feature the demo must show, not from the largest sensor you can find: put 3 pixels across that feature and the image width follows directly — field of view × 3 ÷ feature size, in pixels.

Worked through: the proof of concept must show 0.3 mm defects across a 90 mm field, so 90 × 3 ÷ 0.3 = 900 px — any camera from the 1.6 MP class up clears it with room to spare. Tighten the target to 0.1 mm and the requirement jumps to 90 × 3 ÷ 0.1 = 2700 px, which is the 6 MP class, not the 1.6 MP class. Note the rule's limit too: 3 pixels per feature detects; measurement wants 10 or more, which at 0.3 mm means 90 × 10 ÷ 0.3 = 3000 px.

Run your own field of view through the resolution calculator:

Which interface should the proof of concept use?

Default to USB3 for a bench prototype, choose GigE when cable length or the production network matters, and take MIPI CSI-2 only when the host is already fixed and a driver for your sensor exists on it.

USB3 Vision suits the bench: every laptop and nearly every embedded board carries a host controller, the practical payload is 350-400 MB/s per port, and passive cables reach about 3 m. The sensor trade-offs inside that range are compared in the USB3 machine vision camera selection guide.

GigE Vision suits distance and the production floor: 100 m over copper and ordinary switches, at about 110 MB/s practical per link — one camera per network card at full rate.

MIPI CSI-2 suits the final device: board-to-board runs of centimetres and no connector stack, but it needs a driver and an ISP tuned to the exact sensor, which is the work the prototype is meant to postpone. If the host only accepts CSI-2, a MIPI CSI to USB UVC bridge can put a standard camera on it instead. The embedded camera interface comparison from CSI-2 to GMSL2 maps the whole field, and camera module interface compatibility lists what to confirm before you order anything.

How do you capture the first frame on day one?

Work in this order and the first frame lands within the first hour: mount lens and light, connect one camera to one host port, set a manual exposure of about 10 ms, then adjust iris and light until the histogram centres.

1. Mount the module on a rigid stand and fit the lens; start the iris around f/4.
2. Connect one camera to one host port — no hubs, no shared controllers.
3. Open the vendor's GenICam sample viewer and switch the camera to continuous acquisition with a manual exposure of 10 ms. On 50 Hz mains the light ripple repeats every 10 ms, so a 10 ms exposure (or a multiple of it) integrates complete ripple cycles and avoids banding; on 60 Hz use multiples of 8.33 ms.
4. Raise the light or the gain until the histogram sits near mid-scale, then focus at the working distance.
5. Add triggering last: a trigger call and an exposure time are different events on the timeline, and mixing them up produces frames you cannot explain — trigger call versus exposure time separates them.

When does a bare image sensor beat a board camera?

A bare image sensor beats a board camera at the production stage, when unit cost, board space or a fully integrated optical path justify custom engineering — as a working line, above roughly 10,000 units a year; below that, the standard interface wins the entire schedule.

At volume the bare sensor repays itself: pennies per unit in the sensor die, a few square centimetres of board space, optics that fold into the product housing, no redundant connector. Its price is paid before the first frame exists: a carrier PCB with length-matched CSI-2 pairs, a sensor driver on your processor, and an ISP tuned to the part. Treat those as weeks of schedule on a new processor-sensor pair, not days.

Run the sequence one way only: prototype on the standard interface, prove image quality, then commit the production PCB — and keep one bench camera watching the same scene as the known-good reference while the custom pipeline comes up. Getting from a bench build to volume is its own discipline; the prototype-to-small-batch production guide walks that manufacturing step. Lifecycle counts too: image sensors reach end-of-line faster than most machines do, so plan the swap path with board level camera replacement when a sensor goes end of line rather than meeting it as a surprise.

What breaks on the first day and how do you fix it?

Most first-day failures come down to three causes — the host does not see the device, the frame is black, or the driver binds the wrong sensor — and each has a two-minute test.

• No device in the viewer. Swap the cable and the port before anything else: a USB 2 cable in a USB 3 port will not enumerate at full speed, and a GigE port without a link light points at power or cabling. Many board-level modules draw power on a separate feed rather than through the data connector, so check the module's power wiring as step two.
• The frame is black. Exposure is still at its default microsecond setting, the iris is closed, or the camera waits for a trigger. Force continuous acquisition with a manual exposure first; why the first camera frame stays dark walks that exact symptom.
• Frames tear or drop on GigE. Enable jumbo frames on camera and network card, shorten the cable, and confirm any switch in the path passes oversized frames.
• No frames on a CSI-2 host. Read the kernel log before writing code: in most cases the driver bound the wrong sensor or a device-tree entry is missing — camera loads the wrong sensor driver: read dmesg, fix the overlay shows the diagnosis.

What should you order for a one-day prototype bench?

For a first bench, order one C-mount board camera, one C-mount lens near your working distance, a small adjustable light, a rigid stand, a short certified cable and an ESD strap — six items that cover a full day of testing.

• Camera: C-mount or CS-mount so lab lenses fit today; the compact M12 stack comes later. Global shutter if anything moves; rolling shutter serves static scenes.
• Lens: one C-mount lens sized by the arithmetic below.
• Light: a small adjustable spot or ring light — exposure control needs intensity you can turn, and a fixed bench lamp does not turn.
• Stand: rigid, so focus and lighting findings stay valid between runs.
• Cable: a certified USB3 cable no longer than about 3 m, or a Cat 6 patch lead for GigE.
• ESD strap: bare boards and dry bench tops do not mix.

The lens follows from magnification, not guesswork:

Worked through: a 1/1.8" sensor is about 7.2 mm wide, and the sketch calls for a 90 mm field at 200 mm working distance. m = 7.2 ÷ 90 = 0.08. f = 200 × 0.08 ÷ 1.08 = 14.8 mm, so order a 16 mm C-mount lens. Check the error: at 200 mm a 16 mm lens gives m = 16 ÷ 184 = 0.087, so the field is 7.2 ÷ 0.087 ≈ 83 mm — about 8% tighter than sketched. If that margin matters, a 12 mm lens opens it to ≈ 113 mm. The lens focal length calculator runs the same numbers either way.

For a production-like compact geometry, the MV-CB016-10GM-M-W keeps the optical stack small: 1.6 MP, IMX296, Mono, M12 lens mount, GigE, Global shutter.

The MV-CS200-10UM covers the top of the bench range: 20 MP, IMX183, 1" sensor, C-mount, Mono, USB3.0. The MV-CU020-90GC is the global-shutter GigE counterpart: 2.5 MP, GMAX4002, Color, 1/1.7", C-mount. Two housed references bookend the bench range:

Filter the full range by interface, resolution band and shutter type in the camera finder, or step through camera, lens, light and controller in the camera configurator. Before the order goes out, run it against the board camera evaluation checklist — it catches the omissions that cost a second order. The other camera-side guides sit on the cameras topic page.