Event camera data throughput: what happens when events exceed the link

An event camera does not ship frames, so the sizing habits built around frame rate and pixel count do not transfer. The specification you meet on the front page is a per-pixel response time quoted in microseconds and marketed as an equivalent frame rate, and the question that decides an integration is what the pipeline does when the scene produces more events than the link and the host can carry. This guide lines up the three ceilings in the order they bite — sensor readout, USB 3.0 link, host consumption — with the arithmetic to place your application against each one, what overflows and what is silently discarded at each stage, and the region-of-interest and threshold moves that bound the rate at the source. It is written for engineers adding event output to high-speed counting, vibration or fast-motion tasks; if you are still weighing event output against frames, the technology trade-offs sit in event based vision vs frame cameras for fast motion.

Is an event camera's equivalent frame rate a fixed value?

No — it is a per-pixel response figure, not a stream rate: each pixel fires whenever its log intensity changes by the contrast threshold, so 100 µs temporal resolution lets one pixel fire up to 10,000 events per second and a static scene produces none at all.

The headline number describes how finely each pixel samples time, not how many events leave the chip. An event is a pixel address, a microsecond timestamp and a polarity bit, generated only when that pixel crosses threshold. Total output is a scene property: fast relative motion across a high-contrast edge produces orders of magnitude more events per second than slow motion across a uniform surface, and the same camera sits at both extremes within one shift. That spread is why sizing starts from the worst scene you will present, not from a specification line.

How many events per second can a fully moving scene generate?

A working upper bound for a VGA-class 640 × 480 sensor with everything in motion is 3.07 billion events per second — 307,200 pixels each crossing threshold once per 100 µs — and no real scene sustains it, but your pipeline still has to survive its consequences.

The bound falls straight out of the pixel budget:

Four bytes per event — address, polarity and a packed microsecond timestamp — is the payload most capture libraries use, and the worst case at that size is about 12.3 GB/s. Real scenes sit far lower because only pixels on changing edges fire. The bound still matters: it shows why a kit cannot simply buffer a spike, because the gap between what a scene requests and what a link carries can span two orders of magnitude.

How much event data can a USB 3.0 link carry?

Roughly 90-110 million events per second at 4 bytes each: USB 3.0 signals at 5 Gbit/s, delivers a sustained 350-450 MB/s after encoding and protocol overhead, and 400 MB/s divided by 4 B is about 100 Mevents/s of link capacity.

That number is the payload budget of one host controller port, and the sustained range is what bulk transfers reach on a healthy controller. Two habits keep the budget intact: keep storage and any second camera off that controller, and keep the cable short, shielded and properly strain-relieved, because a marginal link renegotiates downward and the budget collapses. The same discipline that holds frame-based USB 3.0 cameras at rate holds event kits there. The camera data cables range covers such runs; on a carriage or robot arm, high-flex drag-chain construction matters as much as length.

The LS-CBL-0219 is a 3 m USB 3.0 camera data cable with high-flex, drag-chain construction for mounts that keep moving.

What saturates first: the sensor, the link or the host?

The sensor saturates first: current USB 3.0 event sensors print maximum readout throughput between roughly 15 and 120 Mevents/s — near 50 for VGA-class kits — below the 100 Mevents/s the link could carry and far above anything the host has seen.

Readout runs through an on-chip arbitration loop with a finite service rate. When the array requests more events than that rate, the surplus is not queued: a pixel holds only its latest change until the loop reaches it, and requests arriving while the loop is busy are lost. What leaves the chip is live and correctly timestamped, just sparser than the scene produced. Against the 3.07 Gevents/s bound above, a 50 Mevents/s readout passes about 1.6% of requested events — roughly 98% never leave the chip — and the symptom is aliasing, not an error message.

Sensor saturation is invisible to the operating system. No driver error appears, RAM stays flat, and the only evidence is missing structure in the stream: an oscillating target whose events stop mid-swing, an edge whose trajectory has gaps. Size against the sensor's readout figure before anything else, because the link and the host never see the events the chip discarded.

Does the camera buffer pending events or drop them?

It drops them: the FIFOs inside the sensor and its interface bridge absorb microseconds of scheduling jitter, not seconds of backlog, so sustained overflow is discarded on-chip and the link carries only live events.

There is no megabyte-scale event store waiting to drain. That design keeps latency bounded — what you receive describes the present, which is the point of event output — but it also means a saturated window cannot be replayed or caught up later. If the application needs that window, generate fewer events during it: tighter region of interest, higher threshold, slower or smaller motion. Burst absorption beyond jitter is a host-side design job, not a camera feature.

What happens on the PC when processing is slower than the stream?

Backlog grows until memory runs out: at 2 Mevents/s arriving and 1 Mevents/s consumed, a 4-byte event stream piles up 4 MB per second, which is 14.4 GB per hour and exhausts 16 GB of free memory in about 67 minutes.

The capture library's queue policy then decides the failure mode. Bounded ring buffers wrap and discard the oldest events once full; unbounded queues keep growing until allocation fails or the process is killed. Either way a real-time consumer has already lost, because it is acting on data that is seconds old or missing entirely. The fix sits at consumption: run your algorithm against a recorded stream, time it, and keep sustained consumption above production with margin — a factor of two is a sound target for bursty scenes.

How do you bound the event rate before you integrate?

Cut generation at the source: crop the region of interest, raise the contrast threshold, and remove PWM lighting — together these three levers typically move a stream from tens of Mevents/s to single digits without touching the link or the host.

Per-pixel output follows a compact relation: a pixel fires each time accumulated log-contrast change reaches the threshold C, so its event rate is the log-intensity change rate divided by C. Summed over active pixels and capped at the readout limit, that relation gives the stream:

Doubling C halves every firing pixel's rate, which makes the threshold the cheapest lever on a live line. Cropping scales linearly with active pixels: confining a 640 × 480 array to half its width and height leaves 76,800 pixels and cuts the same scene's bound from 3.07 to 0.77 Gevents/s. Many sensors also expose dynamic region masks that switch inactive areas off entirely. Cropping the region of interest at the source is the same discipline used on frame cameras, but on an event sensor it caps generation itself, so fix the mask when you fix the inspection zone.

Give flicker special care: PWM-driven LED lighting stamps two contrast pulses per cycle onto every high-contrast edge, so a 100 Hz fixture can fill the stream from a scene a frame camera would call static. Run DC or high-frequency drive on any rig that samples light asynchronously.

How do you verify the pipeline before production?

Measure three numbers on the bench under your worst-case motion: peak events per second over one-second windows, sustained consumption of your full processing chain, and the overflow counter's rate — any non-zero drop rate means events are already being lost.

Saturate deliberately once: wave a high-contrast checkerboard quickly in front of the lens and read the counter at its plateau. That plateau is the kit's real readout limit, and every downstream decision sizes from it. On the host side, keep the controller dedicated: its roughly 400 MB/s belongs to every device on that controller, and a second camera or a storage drive on the same bus takes a proportional bite — the failure mode described in multiple USB cameras on one host: bandwidth and power budget. A hub adds a negotiation point and throttles silently; why a USB hub drops camera frame rate walks through that failure in detail.

The decision follows the bottleneck the bench exposes:

• Sensor-limited — peaks above the kit's readout figure. Buy nothing: cut the region of interest, raise the threshold, shrink or slow the motion. This is the common case, and the fix is optical and software.
• Link-limited — readout payload above the sustained budget. Shorter or better cable, a dedicated controller port, no hub, or a kit on a faster interface.
• Host-limited — consumption below production. Filter or decimate at ingest, or make the consumer faster. More RAM only moves the 67-minute wall, and only while the queue is unbounded.

When sizing shows the throughput problem is really frame-based, the same budgeting applies with easier rules: the area scan cameras category and the camera configurator walk the sensor, interface and cable choices in one pass, and the systems topic page collects the link- and host-budgeting guides for frame streams as well. For a specific integration question, the contact page reaches the applications team.