Board-level camera LVDS to USB: what the link really needs

A tiny camera module with four pins invites an easy mistake: assuming a 4-pin-to-USB cable will put images on a computer. It will not. Those pins carry a serial LVDS pixel stream, and a USB port only ever talks to a device that contains a USB controller and answers enumeration. Every working path adds a powered receiver — the module maker's evaluation kit, or an FPGA or bridge design you build — that decodes the pairs and hands the PC a standard USB3 or GigE camera. This guide covers what the output actually is, why no passive cable can work, the bandwidth arithmetic that decides whether USB3 can carry the frames, and the decision for each case, including when a standard USB3 board-level camera is the better buy.

What the four pins actually carry

A module of this class fits 1 mm × 1 mm of silicon and, in the smallest versions, a 249 × 250 pixel array with 3 μm rolling-shutter pixels. On the data side it contains a serializer and nothing else: a supply pin, ground, and one or two differential pairs that stream pixels continuously, plus optional lines that drive an illuminator LED. When the LED lines go unused they are simply left unconnected; they never become spare data lines.

There is no USB engine anywhere in that silicon: no endpoint descriptors, no enumeration state machine, no way to answer a host. The pair runs on the module's own clock, all the time, whether or not anything is listening. That one fact decides everything downstream.

LVDS in the numbers that matter

LVDS, defined in the TIA/EIA-644 electrical standard, sends data as a small differential signal. The driver switches about 3.5 mA through a 100 Ω termination at the receiver, producing roughly a 350 mV swing across the pair. The small swing and the equal-and-opposite currents make the interface fast, quiet and frugal: a few hundred megabits per pair in simple designs, far more with specialised deserializers.

A camera module uses that electricity to ship raw pixels. One bitstream, a fixed frame timing set by the sensor clock, horizontal and vertical blanking between the active lines, and a Bayer payload at the chip's bit depth. Some modules run a separate clock pair; others embed the clock in the data and let the receiver recover it. Either way, the output is a continuous serial waveform, not packets.

Why no passive cable or adapter can work

Three independent reasons, and any one of them is fatal.

Protocol. USB is a host-scheduled bus. A device must present descriptors and answer coded handshakes before any data moves. The module cannot: with no USB controller it never enumerates, and a device that has not enumerated transfers nothing.

Electrical levels. USB signalling is not LVDS. Amplitude, termination and timing differ, and the USB lines form a bidirectional, half-duplex packet bus rather than a dedicated one-way stream. Putting the module's pair on D+ and D− connects two networks that share nothing but a connector drawing.

Control direction. Even with matched levels, the host initiates every transfer, and the module has nothing on board that could respond.

So there is no LVDS-to-USB cable, and there cannot be one. Conversion needs a powered receiver with a deserializer on one side and a USB device controller on the other.

What a working receiver looks like

The chain has five stages. Skip any one and there is no image.

1. Terminate and receive. Each differential pair ends in 100 Ω at an LVDS-capable receiver input.
2. Recover the clock and align words. The deserializer finds word boundaries against the recovered or supplied clock. This is the classic bring-up failure: wrong frequency, wrong phase or wrong edge, and the receiver aligns to noise. A wrong LVDS receiver clock on an embedded board: the failure and the fix walks one real case and the measurement that finds it.
3. Rebuild pixels. Pack the serial words back into image rows, in the sensor's Bayer order and bit depth.
4. Buffer frames. Write complete frames into memory so the output side can pace itself.
5. Speak USB. A USB3 device controller enumerates the whole assembly as a standard camera — typically USB Video Class (UVC) or USB3 Vision — and the PC opens it with ordinary drivers and viewers.

You can buy stages 1 to 5 assembled. Evaluation kits built for these modules terminate the pairs, decode the stream and enumerate as a standard device; bridge-class designs stream 1080p at 60 fps to a PC as UVC or USB3 Vision from a BT.1120-style camera feed. Or you build the chain in an FPGA, which is what a production design does when the module's footprint forces the choice.

The arithmetic: pair rate and link margin

Example 1 — the miniature module. Take the 249 × 250 array at an assumed 8 bits per pixel and 60 fps, with blanking consuming 30% of the frame time.

• 249 × 250 = 62,250 pixels per frame
• 62,250 × 8 = 498,000 bits per frame
• 498,000 × 60 = 29.9 Mbit/s of pixel payload
• pair rate ≈ 29.9 / 0.7 ≈ 43 Mbit/s

A single LVDS pair at 43 Mbit/s is loafing. Bandwidth was never the barrier; the protocol and the receiver are.

Example 2 — does USB3 carry a real stream once bridged? A 1920 × 1080 sensor at 60 fps:

• raw 8-bit: 1920 × 1080 × 8 × 60 = 995,328,000 bit/s ≈ 995 Mbit/s ≈ 124 MB/s
• YUV422, the common uncompressed UVC pixel format, at 16 bits per pixel: 1,990,656,000 bit/s ≈ 1.99 Gbit/s ≈ 249 MB/s

USB3 runs a 5 Gbit/s line rate; after 8b/10b coding and packet overhead, practical bulk throughput is about 400 MB/s. The YUV422 stream fits with (400 − 249) / 400 ≈ 38% headroom. GigE offers roughly 118 MB/s usable — 1 Gbit/s minus Ethernet overhead — so the YUV422 stream does not fit; 1080p raw 8-bit at 30 fps, 497,664,000 bit/s ≈ 62 MB/s, fits with about 47% headroom.

The decision falls straight out of the arithmetic: with a real receiver in place, USB3 carries this class of camera with room to spare. The engineering risk lives in the receiver, not in the wire.

Three paths to a picture

Evaluation kit. The module maker sells an interface box exactly for this: it terminates the pairs, decodes the stream and enumerates, so the camera appears in a viewer with no firmware from you. It is the right tool for judging image quality — the board camera evaluation checklist lists what to record while it is on the bench — and the wrong tool for a production run.

FPGA or SoC receiver. This is what goes inside an endoscope processor or any product that must keep the 1 mm module. The FPGA takes the pairs on IO banks that support the input standard, deserializes, buffers, and drives USB3 or GigE out. Budget weeks for clock-and-alignment bring-up, and match the host side early: the USB3 bridge-board matching guide covers the failures that appear after the receiver already works.

Skip the problem. If the module caught your eye because it is small rather than because the application demands a 1 mm sensor, buy the interface built in. Two miniatures from our board-level cameras range show how small standard-interface modules now get:

For throughput, the LS-BCM-0003 delivers 3.1 MP frames at 120 fps over USB3, with a global shutter and a C-mount.

For a bare board you package yourself, the MV-CB060-10UM-B streams 6 MP over USB3.

When the usual answer is wrong

The buy-a-standard-camera shortcut fails in three situations, and in each the LVDS work is unavoidable.

• The 1 mm sensor is the requirement. An endoscope tip, a dental handpiece, a bore inside a machine: when the optical aperture is a couple of millimetres, no board camera fits. Qualify the image with the evaluation kit, then commit to the FPGA receiver for production.
• The module is not actually LVDS. Many small modules speak MIPI CSI-2 or a parallel digital video port. CSI-2 needs a CSI-capable host at short range, and the same rule holds: never a passive adapter to USB. What raw sensor output means on a CSI camera with no ISP explains that path, and the checks for camera module interface compatibility are the short version before you design anything.
• The cable run is long. LVDS survives centimetres to a few metres with twisted pairs and clean termination. Beyond that, GigE, designed for 100 m cable runs, is the honest choice.

One caution: if the host is an embedded board rather than a PC, confirm its USB3 controller sustains a few hundred megabytes per second in practice. The host-side budget is the first thing board level camera selection for embedded vision machines tells you to size.

Checks before you wire or order anything

• Pin map from the datasheet. Identify supply, ground, data pair(s), clock pair or embedded clock, LED lines and any control pins, then check them against the real connector. The camera IO board pin alignment check catches swapped pairs before they cost hardware.
• Payload arithmetic. Width × height × bits × frame rate, plus blanking, against the receiver's per-pair limit and the USB3 or GigE margin, exactly as in the worked example above.
• Output protocol. Confirm the kit or bridge enumerates as UVC, USB3 Vision or GigE Vision and that your software stack opens it. Before you write host code, the raw image capture check catches format surprises.
• Power. The exact rail voltage and sequencing from the datasheet; the pixel pairs tolerate nothing wrong on the supply pin.
• Termination and layout. 100 Ω differential at the receiver, twisted pairs, no stubs, and a module-to-receiver cable you have tested at speed.
• Control path. Exposure, gain and LED drive go through registers via the kit or your FPGA, never through the pixel pairs.

The decision, case by case

• Images from one module, soon. Buy the maker's evaluation kit for that module. Nothing soldered in an afternoon will do the job.
• A product that must contain the miniature module. Design the FPGA receiver and the USB3 bridge. The 38% USB3 margin in the worked example says the link is not your risk; clocking, termination and descriptors are.
• You chose the tiny module only because it is tiny. Choose a USB3 or GigE board-level camera instead and spend the saved weeks on the inspection itself. Start with the camera configurator or the camera finder. If you genuinely must keep the LVDS module, send its datasheet through the contact page, and we will help you scope the receiver.

More bring-up and selection guides sit under the cameras topic page.