Why camera fps alternates between two values: dropped frames

The counter reads 30.10, then 15.06, then 30.10 again, and when you force the top resolution the driver refuses outright: requested 30 fps, maximum 18.9. Neither is a fault. Both are arithmetic: the time to expose, scan out, transfer and handle one frame has crossed the frame period, so frames arrive on a two-beat rhythm, and the maximum figure is the sensor's scan rate at that resolution. This guide works the numbers for a 4K and an 8K stream, shows how to measure the rate your software actually receives, and ranks the fixes — region of interest, binning, pixel format, link speed — by the frame rate each one buys back.

Why does my camera fps alternate between two values?

Because one frame no longer fits inside one frame period: at 30 fps the period is 33.3 ms, and once exposure plus readout plus transfer plus host handling exceed it, delivery settles into a two-frame beat that the counter reports as 30, then 15.

Most fps readouts invert the gap between two consecutive frames. A 33.2 ms gap reads 30.1; a 66.6 ms gap reads 15.0. When the pipeline's true period per frame sits between one and two nominal periods — around 50 ms here — the gaps alternate, and so do the readings. Two frames in 33.2 + 66.6 = 99.8 ms is 2 ÷ 0.0998 = 20.0 fps actually delivered, a number the alternating display never shows you directly.

The same beat has two outcomes. If the driver's input queue is full when the next frame lands, that frame is discarded, and ten seconds of counting gives about 150 frames — a true 15 fps. If frames are merely late, you count about 200 — a true 20 fps. Same signature, different severity, identical fix.

A clean 30/15 alternation also tells you what this is not. Cable faults, host spikes and interference produce noisy, irregular readings. A periodic halving is a capacity signature, and it obeys the same period budget as maximum frame rate on a hardware trigger: exposure plus readout time, extended by the link and the host.

What does the max fps error actually mean?

It is the sensor's scan ceiling at that resolution: the driver divides one second by the time the sensor needs to read out a full frame, gets 18.9 fps for a 33.2-megapixel frame, and refuses anything faster because the silicon cannot scan faster.

Work it through for an 8K frame:

• 7680 × 4320 = 33,177,600 pixels ≈ 33.2 MP.
• The error quotes a maximum of 18.9 fps, so one full frame takes 1 ÷ 18.9 = 52.9 ms to scan out.
• Scan throughput is 33.2 MP ÷ 52.9 ms ≈ 627 MP/s.
• Requesting 30 fps asks for 30 × 33.2 = 995 MP/s, which is 1.6 times the scan rate — refused, correctly.

The ceiling is resolution-specific: the same 627 MP/s scan rate covers a 4K frame, 8.29 MP, in about 13 ms, comfortably inside a 33.3 ms period. That is why a sensor can refuse 30 fps at 8K and sustain it at 4K, and why the 4K halving above points downstream, not at the sensor.

Exposure can overlap the previous frame's scan on many sensors, but never plan on it: when exposure plus scan crosses the frame period, the rate drops by whole frames, never by a smooth percentage.

Why is the real rate far below the sensor maximum?

Because a different stage binds first: the link moves bytes, and bytes per frame times frames per second must stay under the link's payload — an 8K 8-bit mono stream at 4 fps is 133 MB/s, the signature of a saturated 1 Gb/s-class path.

Every frame makes three crossings, and the slowest one sets the rate: the sensor scans pixels, the link carries bytes, the host copies and converts them. An 8K Mono8 frame is 33.2 MB, so a delivered 3.6 to 4.0 fps means 120 to 133 MB/s of sustained payload — 0.96 to 1.06 Gb/s. The sensor could scan 18.9 fps; something in the path moves bytes like a 1 Gb/s link, whether that is the wire itself or a stage throttled to that class.

The payloads here are typical sustained image throughput with packet sizes tuned. Raw line rates are higher — 1, 5 and 10 Gb/s — but encoding and protocol overhead claim a fifth to nearly half of them.

Read the table as a diagnosis, not a catalogue: measure where your rate lands, and the row it lands on is the stage that binds. A rate that suddenly collapses instead of capping is a different fault — start with camera fps drops suddenly: exposure, USB link, bandwidth.

Catalog ratings obey the same law. The LS-CMR-0053 is a 12 MP camera on GigE at 9 fps.

A 12 MP Mono8 frame is 12 MB; at 9 fps that is 12 × 9 = 108 MB/s. The rating fills a tuned 1 Gb/s link and stops there — data sheet, sensor and wire all agree.

How do I measure the true delivered frame rate?

Count frames over a fixed window and divide: switch every auto function off, timestamp each raw frame host-side for ten seconds, and frames divided by ten seconds is the number that matters — not the alternating instantaneous readings.

1. Turn auto exposure, auto gain and auto white balance off. Each one lengthens exposure on its own and moves the period under you — the same trap as camera fps lower than the datasheet: turn off auto functions.
2. Capture raw frames with display, decoding and compression disabled, and timestamp each arrival with a monotonic clock.
3. Count and divide: 196 frames in 10.0 s is 19.6 fps. About 150 frames per ten seconds says frames are being dropped; about 200 says they arrive late in bursts.
4. Compare your host count with the camera's delivered-frame counter when the driver exposes one: camera below configured means sensor or exposure binds; host below camera means the link or the host drops frames.

This counting method is the same one that settles stereo camera low fps, no detection: measure the delivered frame rate — the displayed rate is negotiable, the counted rate is not.

Which fix buys back the most fps: ROI, binning or pixel format?

Whichever cuts the most bytes per frame: stepping Mono16 down to Mono8 halves the stream, 2×2 binning quarters the pixels, and both together take a 4K stream at 30 fps from 498 MB/s to 62 MB/s — from needing 10GigE to fitting GigE.

Binning costs detail: 1920 × 1080 from 3840 × 2160 halves resolution on each axis. Read 4x4 binning vs 2x2: sensor readout decides your frame rate before choosing a mode, because sensor readout, not just the link, decides what binning returns.

Cropping keeps full detail where it matters: an ROI of 2560 × 1440 at 8 bits is 3.7 MB per frame, 110 MB/s at 30 fps — the exact edge of a tuned 1 Gb/s link, so crop tighter if that is your wire.

Before paying for any of it, check how many pixels the task needs. Run your field of view and accuracy target through the camera resolution calculator; 33 MP is only worth moving when the measurement genuinely resolves at that density.

If the link has headroom and the rate still sags, the host is the ceiling — speed up vision acquisition time by cutting processing load covers where the time goes.

When do I need a faster link instead of a smaller frame?

When bytes per frame times fps exceeds what your link sustains even at 8 bits: 4K at 30 fps needs 249 MB/s in Mono8, past a 1 Gb/s link and inside a USB3-class one, and 20 MP at real frame rates belongs on 10GigE.

The decision is three numbers wide: up to about 110 MB/s, GigE carries it; up to about 350 MB/s, a USB3-class link carries it; above that, order 10GigE or CoaXPress. Stay 15% under whichever line you pick — packet overhead and bursts eat the margin.

Dropping the pixel count reaches a steady 30 fps without touching the link. The LS-CMR-0166 runs 12 MP at 30 fps over USB3; the MV-CS200-10UM moves 20 MP over USB3.0.

A 20 MP Mono8 frame is 20 MB, so 15 fps draws 300 MB/s — most of a USB3-class link before anything else shares it. Give high-resolution cameras their own host controller: the budgeting in USB hub drops camera frame rate: budget the bandwidth first applies to controllers as much as hubs.

When the task needs every pixel and every frame, move the bytes instead of shrinking them. The MV-CH250-25TC-F-NF is a 25 MP camera on 10GigE with an F-mount.

A 25 MP Mono8 frame is 25 MB, and a 10GigE-class payload of 1,100 MB/s sustains 44 fps of them before any sensor ceiling applies. Filter area scan cameras by interface to see which resolutions each link class carries.

When is the alternation not a bandwidth problem?

When exposure, not bytes, crosses the period: auto exposure left free to lengthen integration in dim light pulls the period past 33.3 ms, and a driver set to exposure priority halves the rate cleanly to 15 fps.

Three impostors produce a halving with bytes to spare:

1. Exposure longer than the budget. A 40 ms exposure can never deliver 30 fps, whose period is 33.3 ms. Raise the light or the gain and shorten exposure — the same cap that guards sharpness in maximum exposure time calculation to keep blur under control.
2. Exposure priority. Some drivers trade frame rate for signal without asking; auto exposure priority: why your frame rate drops to half shows where the setting lives and what it costs.
3. Host processing slower than acquisition. The queue fills, the reader takes every other frame, and the beat appears downstream — the failure mode in acquisition faster than processing: fix the frame rate gap.

One test separates them: halve the resolution. If the delivered rate jumps, bytes were binding. If the beat persists unchanged, exposure or the host is binding, and no link upgrade will move it.

What should I check before ordering a fix?

Run the four budgets on paper first — pixels, scan rate, link payload and host throughput — because the number that comes out names the part to buy, and often it is none of them.

• Pixels per frame: width × height, in megapixels and in bytes at your pixel format.
• Sensor ceiling: the maximum fps quoted at your exact resolution; configure at or below it.
• Link payload: bytes per frame × fps against 110, 350 and 1,100 MB/s for GigE-, USB3- and 10GigE-class links, with 15% headroom.
• Exposure budget: exposure + readout inside 1 ÷ fps, or overlapped readout confirmed.
• Host: counted frame rate with display and processing disabled, before the camera takes the blame.
• Cabling: one high-resolution camera per host controller, no shared hubs at these rates.

Then decide by case:

• Delivered 15 fps and the task tolerates it: configure 15 fps. The beat disappears because the pipeline stops racing a period it cannot meet, and every frame arrives complete.
• 30 fps at 4K required: 8-bit at 249 MB/s fits a USB3-class link; 16-bit at 498 MB/s needs 10GigE.
• Every 8K pixel required: the sensor caps near 18.9 fps — wire 10GigE-class to reach the cap, and expect the cap, not 30.
• Frame rate fixed, resolution flexible: bin or crop until bytes per frame × fps fits the link you already own.

Start in the camera finder filtered by interface, or open the system configurator at the camera step. If the numbers point three ways at once, the contact page puts an applications engineer on the case — expert support is free with every order.