MIPI CSI-2 frame rate estimation: lanes and data rate

You have a sensor that reaches 120 fps on the vendor's evaluation kit. Your carrier wires that sensor to two lanes at 1.5 Gbit/s per lane instead of four at 2.5, and the first bench run comes back at half the rate. That gap is arithmetic, not mystery. A MIPI CSI-2 link moves a fixed amount of payload per second, and the frame rate is that payload divided by the bytes in one frame. This page gives you the estimation in four inputs — lane count, lane speed, protocol overhead and packed bytes per pixel — so you can predict the rate before you order a board or a camera, and know which of the two caps, sensor or link, is the one actually binding. The same four numbers work for any resolution, bit depth and lane configuration.

Your frame rate is the lower of two caps

Write the whole estimation as one line:

The first term of the min() comes from the sensor data sheet: the rate it reads out at full resolution in the format you plan to stream. The second comes from the link, and it is the term engineers guess at. Usable payload means the raw line rate of lanes × lane speed with protocol overhead and blanking taken out; plan on 20%, so multiply by 0.8.

Take the smaller of the two terms and you have the answer. When the sensor term is smaller, the platform does not matter: the same sensor holds the same rate on every carrier that can carry it. When the link term is smaller, the frame rate scales with bandwidth, and every lane or gigabit you add or remove shows up in the rate.

What the link carries: lanes, lane speed and overhead

Raw bandwidth is lanes × lane speed. Entry-level embedded receivers typically clock 1.5 Gbit/s per lane; faster application processors reach 2.5 Gbit/s per lane, and a few go higher — the processor's interface documentation states the ceiling for your part. Four configurations cover most embedded builds:

The gap between raw and usable is packet headers, sync traffic and, biggest of all, the horizontal and vertical blanking windows during which the sensor sends nothing and the link idles. Field estimates for CSI-2 links land between 15% and 20% of the raw rate: the low end belongs to large frames with little blanking, the high end to blanking-heavy modes. Size the link at 20% and the estimate stays conservative. The MIPI camera lane bandwidth guide walks the same lane math from the bandwidth side.

What one frame costs: packed bytes per pixel

Count what crosses the wire, not what lands in memory. CSI-2 packs pixels into the stream without per-pixel word alignment, so the negotiated data type sets the cost:

Bytes per frame = width × height × bytes per pixel. A RAW12 1920 × 1080 frame is 2,073,600 × 1.5 = 3,110,400 B, about 3.11 MB. If a pipeline pulls RGB out of an ISP before anything sees RAW, count the RGB format instead — the RAW sensor output explainer sorts out what an ISP-less sensor actually emits. Cache lines and 16-bit memory words are your problem after the DMA, never on the wire.

Worked example: a 2 MP RAW12 sensor on two lanes at 1.5 Gbit/s

The inputs, each with its source:

• Receiver: two data lanes at 1.5 Gbit/s per lane, the configuration entry-level embedded carriers typically wire to one camera.
• Sensor mode: 1920 × 1080 at RAW12, a typical 2 MP global-shutter mode.
• Sensor limit: 120 fps at full resolution, read from the sensor data sheet — a typical figure for this class of part.

The rule in words: usable payload equals lanes × lane speed × 0.8; the link's rate equals usable payload divided by bytes per frame; the system rate is the smaller of the link rate and the sensor rate.

The arithmetic:

1. Raw link: 2 lanes × 1.5 Gbit/s = 3.0 Gbit/s.
2. Usable payload: 3.0 Gbit/s × 0.8 = 2.4 Gbit/s = 300 MB/s.
3. Bytes per frame: 1920 × 1080 = 2,073,600 pixels; 2,073,600 × 1.5 B = 3,110,400 B ≈ 3.11 MB.
4. Link rate: 300 MB/s ÷ 3.11 MB = 96.4, so about 96 fps.
5. System rate: min(96, 120) = 96 fps. The link binds, not the sensor.

The decision: a 60 fps target clears with 60% headroom (96 ÷ 60 = 1.6). Keep the target at least 25% under the estimate and this link covers targets up to 76 fps (96 × 0.8 = 76.8). A 120 fps target fails in every packed format on this link — RAW10 lifts the rate only to 300 MB/s ÷ 2.59 MB ≈ 116 fps — so the fix is link-side. Two lanes at 2.5 Gbit/s deliver 500 MB/s ÷ 3.11 MB ≈ 160 fps and hand the cap back to the sensor's 120; four lanes at 1.5 Gbit/s deliver 600 MB/s ÷ 3.11 MB ≈ 192 fps with the same result.

Which cap binds, and what that tells you

Compare the sensor's own byte rate with the usable payload: sensor bytes per second = bytes per frame × native fps. When that product sits well under the payload, the sensor never saturates the link and you will see the same rate on every platform; extra lanes buy nothing. When it sits above, the rate follows the link exactly — halve the payload, halve the rate.

A pocket check: a 5 MP RAW8 sensor (2592 × 1944 = 5.04 MB per frame) at 120 fps pushes 5.04 MB × 120 = 604 MB/s. Four lanes at 1.5 Gbit/s deliver 600 MB/s, so that sensor runs at its native rate only just, and falls to about 60 fps on two lanes (300 ÷ 5.04 ≈ 59.5). That halving is the behavior people blame on drivers. Once the link has real headroom, the bottleneck moves downstream — planning 2000 fps recording is its own data-rate exercise, covered in the high frame rate data rate plan.

What to change when the link is the limit

Ranked by what each lever buys:

1. More lanes. Payload scales exactly with lane count: two to four lanes doubles it. Check first that the receiver port wires four lanes out and that the sensor supports a four-lane mode; the case where a camera probes on two lanes but not four is covered in why the sensor probe fails on 2-lane vs 4-lane mode.
2. A faster lane rate. 1.5 → 2.5 Gbit/s per lane multiplies payload by 1.67 on the wiring you already have. The ceiling belongs to the processor, not to the camera.
3. Fewer bits per pixel. RAW12 to RAW10 cuts wire bytes by 16.7% (1.5 → 1.25 B/px) and lifts the link rate by 20% (1.5 ÷ 1.25 = 1.2); RAW8 buys another 33% if your algorithms tolerate the depth loss.
4. Fewer pixels. Binning, cropping or subsampling shrink bytes per frame in proportion and usually raise the sensor cap too, so both terms of the min() improve.
5. Tighter blanking. Some sensors let you trim vertical blanking, which recovers a few percent of overhead. Do it last.

When the lane math says pick a different link

If the target rate needs more than four lanes at the processor's ceiling — more than the ~1 GB/s of payload that 4 × 2.5 Gbit/s delivers — or the board simply has no fourth lane routed, move the stream to a host-standard interface and spend the effort elsewhere. Embedded camera interfaces from CSI-2 to GMSL2 lays the options side by side.

The payload numbers, roughly: 1 GigE sustains about 110 MB/s of image data; USB3 delivers about 350–400 MB/s to one camera before you share the port; 10GigE multiplies that by ten. The USB3 per-camera budget math and the GigE Vision frame rate fit carry each budget in detail. Where the host has no CSI-2 receiver at all, a bridge chip works, but the bridge has its own payload budget and quietly becomes the new limit — sizing the CSI-2 to USB data path shows where.

Over USB3, the compact LS-BCM-0003 board camera pairs a 3.1 MP global-shutter sensor with a 120 fps full-resolution rate, and the LS-CMR-0166 area scan camera carries 4000 × 3000 at 30 fps on the same port type.

Where the camera sits a few metres from the host, GigE stretches further than USB3: the MV-CB016-10GM-M-W board camera runs 1.6 MP global-shutter frames over GigE from an M12 mount.

Checks before you commit

• Sensor data sheet: native fps at full resolution in the exact format you will stream — the first term of the min().
• Processor interface documentation: the per-lane rate ceiling and how many lanes each port wires out — the inputs of the second term.
• Board wiring: which lanes are routed to the connector; a four-lane sensor on a two-lane carrier runs the two-lane math.
• Data type: the packed bytes per pixel of the format actually negotiated, not the sensor's ADC depth.
• Margin: target fps at least 25% under the link estimate; the worked example's 96 fps covered targets up to 76 fps.
• Total data rate: bytes per frame × target fps in MB/s, one number to sanity-check link, memory and storage together.

When the numbers close, pick the camera with the camera finder or start the camera configurator; compact builds live in the board-level cameras and area scan cameras categories.

Where the estimate breaks down

Three gaps turn up between the estimate and the bench. Blanking-heavy modes — high-fps readouts with short active time — can push real overhead past 20%, so measure the first stream; the estimate is the plan and the bench is the proof. Long or low-grade flex assemblies can force the receiver to negotiate a lower lane rate than the processor's ceiling, so keep the flex short and read the negotiated rate back from the driver. And the host can cap what the wire carries: driver buffers and downstream processing throttle the achieved rate below the link limit, which is exactly where the acquisition faster than processing fix picks up. If a capture API reports a frame rate of zero or a nonsense value, the reliable FPS read guide explains what that number really reports.

The same budget thinking runs across the systems topic page. If your two caps sit uncomfortably close to the target, send the sensor-and-carrier combination through the contact page and we will run the numbers with you.