Custom LVDS data acquisition on a frame grabber: emulate camera timing

Your board speaks LVDS, not camera language: a 20 MHz data clock, a frame-start pulse and sixteen data lines, and no FVAL or LVAL anywhere. A Camera Link frame grabber can still digitize that stream, because a grabber is a timing machine, not an image parser: give it camera-shaped pulses and it turns ADC words into pixels on schedule. The sections below give the signal mapping, three timing layouts with the arithmetic, the camera file settings, and the software that rebuilds sample values from pixel values. They also mark the layout that swamps a host, and the point at which an FPGA capture card is the better tool. Every signal name and limit here comes from the Camera Link standard, so it applies to any Camera Link grabber regardless of vendor.

Decide first: three checks, then commit

A Camera Link grabber in the base configuration samples 24 data bits on every pixel clock and assembles them into rows and frames from three timing signals: FVAL (frame valid), LVAL (line valid) and DVAL (data valid). It neither knows nor cares whether the bits came from a sensor.

Run three checks on your source:

1. Width — up to 24 data bits per clock in base configuration. A 16-bit ADC bus fits, with 8 bits left over.
2. Clock — the standard caps the base pixel clock at 85 MHz. Your 20 MHz clock runs at about a quarter of that.
3. Timing — something must assert FVAL per frame and LVAL per line. If your board's FPGA can emit a line gate, wire it as a camera. If the board only gives you a frame start plus free-running data, use the streaming layout below.

Commit by layout: batch (Layout B) when you can edit the board's logic, stream-and-slice (Layout C) when you cannot, and an FPGA card when you need protocol decode, per-sample timestamps or more than 24 bits. For how a grabber moves frames from card to host memory, see frame grabber image acquisition for Camera Link and CoaXPress. The frame grabbers category splits by interface; only the Camera Link cards speak this LVDS timing.

The four signals your stream must imitate

The grabber is a slave device: your board plays the camera and drives everything.

• Pixel clock — your 20 MHz clock. The grabber latches the port bits on each rising edge.
• FVAL — frame valid, active high for the whole frame. Your FS pulse is falling-edge active, so invert it, or declare the polarity in the camera file if your tool exposes that setting.
• LVAL — line valid, high for every clock of a line. Synthesize it in the board's logic, or tie it high for streaming.
• DVAL — data valid per pixel. Boards without it tie DVAL to LVAL and declare the camera file accordingly.

The camera file then declares what the port carries: pixel size, image width and height, tap count. The grabber writes one pixel per valid clock, so the declared geometry and the driven timing must agree clock for clock. The same must-match discipline governs real cameras, as Camera Link camera and frame grabber compatibility: what must match lays out.

Step 1 — Wire the pairs point-to-point

Work powered off, one driver and one receiver per pair, 100 Ω differential, no stubs.

1. Fit a Camera Link pigtail or breakout for the grabber's connector; base configuration uses the 26-pin MDR shell.
2. Drive the pixel-clock pair with your 20 MHz clock.
3. Drive FVAL with the inverted FS pulse, or set active-low FVAL in the camera file.
4. Drive LVAL with your line gate, or tie it high for the streaming layout.
5. Tie DVAL to LVAL.
6. Route the 16 data lines onto the port data pairs in an order you write down. LVDS swings about 350 mV across the 100 Ω pair — exactly what the Camera Link receivers expect.
7. Keep the cable inside the base configuration's 7 m limit; shorter is better on a bench.

These are the same electrical rules that govern matching a real camera's signaling, as LVDS line scan camera to frame grabber: match the signaling first shows for line scan.

Step 2 — Choose a timing layout

One formula drives everything:

Layout A — faithful emulation. FS becomes FVAL and LVAL, so each eight-sample block arrives as one 8 × 1 image. The arithmetic kills it for continuous capture: 20,000,000 clocks/s ÷ 8 clocks/frame = 2,500,000 frames/s. The wire carries just 40 MB/s — 20 million 16-bit samples at 2 bytes each — but 2.5 million DMA transfers per second buries a host pipeline. That is the gap described in acquisition faster than processing: fix the frame rate gap. Reserve this layout for short, triggered bursts into a ring buffer.

Layout B — batched, the default choice. Edit the board's FPGA: assert LVAL for 512 clocks per line, run 16 lines per frame, and one image carries 8,192 samples. Frames per second = 20,000,000 ÷ 8,192 ≈ 2,441. Each image is 8,192 pixels × 2 bytes = 16,384 bytes, so the host sees ordinary image traffic at the same wire rate, with about a thousand times fewer transfers.

Layout C — streaming slicer. If the board cannot change, tie LVAL and FVAL high, declare a fixed geometry — 1024 × 1024, 16-bit, about 2 MB per image — and route FS onto a spare data bit instead of FVAL. The grabber slices the continuous stream into images at 20,000,000 ÷ 1,048,576 ≈ 19 images/s, and your software finds each block by the marker bit. You give up hardware framing; you keep every sample.

Step 3 — Declare the camera file

Whether your tool calls it a camera file or a set of GenICam fields, the declarations must match the timing from step 2:

1. Interface: Camera Link, base configuration.
2. Pixel size 16 bit, one tap, one sample per pixel; width and height exactly as the layout table shows.
3. FVAL active high unless the tool lets you declare the polarity; DVAL tied to LVAL.
4. Every declared row must actually be clocked. The generator may refuse some geometries — the FAQ below covers the one-row case — and a grabber left waiting forever for line 16 will time out.

A file one viewer loads and another refuses is usually a support gap, not a corrupt file; frame grabber SDK support: why one viewer works and another fails walks that failure mode.

Step 4 — Prove the mapping before trusting the data

1. Ramp test. Have the board send an incrementing 16-bit counter instead of ADC values and grab one image. Pixel k+1 minus pixel k must equal 1 everywhere; a jump or a byte swap shows exactly where the mapping bends.
2. Counter check. Read the grabber's frame counter before and after a run — your SDK exposes one under its own name. A shortfall is dropped frames.
3. Rate check. Under Layout B, count images over 10 s and expect about 24,410. Much less means the host, not the link, is the bottleneck.
4. Marker check. Under Layout C, scan the FS marker bit through one image and confirm the pulses arrive at your board's block period.

Step 5 — Rebuild samples from pixels in software

Grab continuously into a ring of buffers allocated once — reuse image buffers instead of per-frame allocation shows what per-frame allocation costs — and wait once per frame, as frame didn't arrive within timeout: one wait call per frame explains.

Then unpack, with types fixed before you start: pixels is your array of unsigned 16-bit values, channel is an index 0–15.

• Layout B: an image is 8,192 sequential samples. If the board sends the 16 channel words in rotation, channel c lives at pixels[c::16]; the ramp test confirms the word order.
• 8-bit declaration: rejoin the byte pairs, sample = (high byte shifted 8 bits left) OR low byte, in the order your wiring chose.
• Layout C: walk the marker bit to find block starts, de-interleave as above, and discard partial blocks at image boundaries.

Write down the camera file, the pair mapping and the word order together. The next engineer on this project needs all three.

When an FPGA capture card is the better tool

Move to an FPGA card when any of these holds: the source cannot produce line or frame gating and you need per-block sync in hardware; you need per-sample timestamps; the stream needs real protocol decoding; or the bus grows past 24 bits or 85 MHz. Capture synchronously — feed the 20 MHz clock into a clock-capable input and sample the data lines on it — or oversample at 2×, i.e. 40 MHz, and recover the cells digitally. The bandwidth is not in question: 40 MB/s against roughly 1 GB/s for one lane of PCIe 3.0. You trade a camera file for your own logic and host interface, which is exactly the freedom custom timing needs.

Common mistakes

• FS not inverted. FVAL is active high; an active-low frame start means the grabber never sees a frame. Scope the pair.
• Geometry and timing disagree. Declared height 16 but LVAL clocks 15 lines: the grabber waits for line 16, then times out.
• Eight-bit declaration, sixteen-bit values. Samples arrive as split bytes; rejoin them or declare 16-bit pixels.
• Trusting the first image. Bit and byte order are wiring convention, not law. The ramp test earns that trust.
• Running layout A continuously. Millions of tiny frames bury the host; batch or slice instead.

Parts and next steps

Only a Camera Link card accepts this wiring; the CoaXPress, GigE and 10GigE cards in the range speak for cameras on other physical layers. The Camera Link frame grabber we carry is the Hikrobot MV-GC1102IOL.

To settle the grabber alongside the rest of the chain, start the configurator at accessories:

If your source is stranger than clock, frame start and data — odd encodings, handshake lines, second buses — sketch the timing diagram and send it through the /contact/ page; we will tell you plainly whether a grabber or an FPGA card belongs in the slot. More acquisition plumbing lives on the systems topic page, and the accessories finder filters frame grabbers by interface and ports.