Two different quantities are called bandwidth around event cameras, and mixing them up costs a day of tuning. One is the pixel bandwidth: the range of brightness-change frequencies that the bias_fo and bias_hpf codes let through before a pixel emits anything. The other is the event-rate budget: how many events per second the sensor's readout can arbitrate and serialize out of the array. If you record fast repetitive motion — rotating marks, vibrating parts, flowing product — and black streaks appear in the reconstruction while the counter sits near 100 Meps, you have hit the second limit, and no bias code will move it. This page separates the two quantities, works the event-rate arithmetic that predicts where your set-up crosses the line, and lists the changes that actually buy headroom. It applies to any asynchronous event sensor, whatever the bias panel names the codes.
What do the bias_fo and bias_hpf codes actually set?
They set the pixel's analog passband: bias_fo is the low-pass corner that caps how fast a brightness change a pixel can follow, bias_hpf is the high-pass corner that rejects slow drift and DC, and only fluctuations between the two corners generate events.
Inside each pixel a photoreceptor tracks log intensity, the two filters shape that signal in time, and a comparator emits an ON or OFF event whenever the filtered change crosses a threshold. The filters sit before the comparator, so the codes decide which temporal frequencies of light change can become events at all — and, as a side effect, how many events get generated. They act on generation only. The readout that carries events out of the array is a separate stage with its own fixed limit.
The numbers in the bias panel are dimensionless register codes, not hertz. Each code programs an internal bias current, and the current sets the corner frequency; the mapping from code to hertz is built into each sensor's bias generator. A code that means one corner on a VGA-class sensor means another on an HD part.
Do not confuse these analog filters with the temporal event filter, which runs after generation and discards events by timestamp — that one is covered in event camera temporal filter bias: can you target a motion frequency. A code is also not itself a threshold value; the distinction is laid out in event camera bias values are not contrast thresholds.
Do those codes raise the sensor's events-per-second ceiling?
No. The published ceilings — about 66 Meps for a VGA-class generation-3 sensor and up to roughly 1,066 Meps for a generation-4 HD part — are readout limits, set by how fast the array can arbitrate and serialize events, and no bias code moves either number.
The collision of names causes the confusion. Pixel bandwidth is in hertz: which light frequencies generate events. Output bandwidth is in events per second: how many events leave the array. A Meps rating describes the second quantity and is fixed in silicon. Turning bias_fo up raises the low-pass corner, so changes that were filtered out start to generate events — the output rate climbs because demand climbed, not because capacity did.
One code does cut demand honestly: raising the high-pass corner rejects more slow background activity and drift, which trims the stream without touching fast signal.
Why do black streaks appear near 100 Meps on a sensor rated over 1,000?
Because the streaks mark a local readout stall, not a rating being exceeded gracefully: concentrated, high-contrast motion can outrun the arbitration path at about a tenth of the rated budget, and a spinning-dot rig on one 1,066 Meps part began streaking near 100 Meps.
An event sensor does not scan. Every pixel that crosses its threshold asserts a request, per-row and periphery arbiters grant those requests in turn, and granted events are time-stamped and serialized onto the output link. Spread across the array, that chain drains at the rated rate. A tight cluster generating events faster than its shared arbiter stage can drain stalls: latency builds, then events are discarded.
A discarded event leaves a pixel-and-time slot with no data. An event carries only a polarity and a timestamp — see event camera polarity and timestamps: when events beat frames — so a reconstruction with no events in a band has nothing to draw and paints the gap dark. A run of discarded slots along the motion path reads as the black line.
The headline Meps figure is a whole-array best case, and concentration multiplies demand beyond a naive crossing count: a blurred edge swept quickly quantizes into several events per pixel instead of one clean step. Both effects pull the realistic knee for a small, fast, high-contrast target down to a fraction of the rating — around a tenth in this class of set-up. Plan around a measured knee, not the headline ceiling.
How do you calculate the speed where streaks start?
Estimate the generated rate with R ≈ N × 2 × D × v; in the worked rig below it puts the knee near 5,400 rpm, where 19 spinning marks reach 100 Meps.
A hard edge crossing produces one event per pixel: ON where the mark arrives, OFF where it leaves. A mark of image diameter D px moving at v px/s covers D × v new pixels per second at its leading edge and uncovers the same number at its trailing edge, hence the factor of two. Background activity and quantization bursts add on top, so treat the model as a floor and let the sensor's own counter give the truth.
Take a disc carrying 19 dots, each 5 mm across, imaged at magnification 0.05, so 0.25 mm in the image. Assume an 18 µm event pixel — event pixels run far larger than the 2-4 µm typical of frame sensors — and the dot measures 250 µm ÷ 18 µm = 13.9, call it 14 px. At 3,000 rpm the disc turns 50 rev/s, ω = 2π × 50 = 314 rad/s, and a dot at 0.120 m radius moves 314 × 0.120 = 37.7 m/s.
Through the lens that is 37.7 × 0.05 = 1.885 m/s, or 1,885,000 µm/s ÷ 18 µm = 104,700 px/s. The model gives R = 19 × 2 × 14 × 104,700 = 55.7 Meps. That is 5.2% of the 1,066 Meps rating — enormous headroom by the headline number, which is exactly the trap.
Set R to the observed knee of 100 Meps and solve for speed: v = 100,000,000 ÷ (19 × 2 × 14) = 188,000 px/s. Back through the optics: 188,000 × 18 µm = 3.38 m/s in the image, ÷ 0.05 = 67.7 m/s on the disc, ÷ 0.120 m = 564 rad/s, × 60 ÷ 2π = 5,390 rpm. The full 1,066 Meps would not be spent until 10.66 times that speed — near 57,000 rpm and a 720 m/s rim, beyond any spinning rig. The knee arrives at about a tenth of the rated budget because the budget is whole-array and the demand is not.
The decision for this rig: run at or below 80% of the measured knee, about 4,300 rpm, where the model gives 55.7 × 4,300 ÷ 3,000 = 80 Meps. On the VGA-class part rated 66 Meps, the same 3,000 rpm already sits at 84% of rating — there the array figure itself is the nearer constraint.
Which changes actually buy headroom?
Headroom comes from generating fewer events, never from a bias that raises capacity: halve the marks' speed and the rate halves, image fewer marks and it falls in proportion, and a tighter ROI strips the activity outside the action.
- Slow the motion or thin the pattern. The model scales linearly in v and N, so the disc example trades rpm for Meps one-for-one.
- Raise the contrast-threshold bias a step at a time. A bigger log-intensity step per event trims background noise and the partial crossings at soft edges. Re-measure the knee afterwards, because the knee moves with the threshold.
- Image the marks sharply. A blurred edge swept at speed fires a burst of quantization events per pixel instead of one clean step; crisp focus and a lens resolved for the mark size cut that multiplier.
- Crop the ROI around the action. That removes flickering lamps, background texture and noise from the stream. It does not reduce the marks' own local flux, so a saturated cluster still needs one of the fixes above.
- Raise the high-pass corner to reject slow drift — event camera bias tuning: cut noise without losing motion covers that trade — but keep it well below your signal frequencies or genuine changes vanish.
- Confirm the delivery path. Compare generated with delivered events in the SDK statistics: a saturated link or a busy host drops whole time slices that render as streaks too.
When is a frame-based camera the better answer?
When the task needs every mark resolved at every instant rather than only the changes, plan a global-shutter area scan camera around the frame rate the physics demands — and for the rig above that demand is steep.
At 3,000 rpm each 14 px dot crosses its own diameter 104,700 ÷ 14 ≈ 7,480 times per second, and resolving every crossing needs at least twice that: a 15,000 fps-class camera. That cost is probably why the event sensor was chosen. Before abandoning it, spend the fixes in the previous section; an event sensor kept under its knee delivers microsecond timing no frame camera matches.
If you do move to frames, budget exposure against blur and readout against rate — the same accounting is worked through in maximum frame rate on a hardware trigger: exposure plus readout time. Pick the sensor from the area scan cameras category with the camera finder, or size the whole chain in the camera configurator.
For fast moving parts where the deliverable is geometry — a profile, a height map, a volume — laser profilers in the 3D sensors category sample one line per trigger and shrug off 2D texture. For pure change detection, the event sensor still wins on data volume and latency.
How do you prove a set-up is safe before it runs in production?
Log the sensor's own event counter while stepping the speed up: the rate climbs linearly with rpm until the knee, where it bends over or the first streak shows — keep the production point at or below 80% of that measured knee.
- Step the speed in five to ten increments and record generated and delivered events per second at each; the gap between them is your drop meter.
- Watch the reconstruction at each step as well as the counter; the first visible streak dates the knee as surely as any number.
- Re-measure after every bias or optics change. Threshold and focus both move the knee, and a knee measured under last month's lighting is not a number to build on.
- Record raw events, not only rendered video, so dropped-event counts stay checkable after the run.
The decision in one line: bias_fo and bias_hpf tune which changes become events; the streaks are the readout running out of events-per-second capacity; and the cure is always a lower generated rate — slower, sharper, thresholded, cropped — or a frame-based instrument sized for the job. More camera-side reading sits on the cameras topic page, and if you bring the counter log and the speed sweep, contact us and we will help you size the fix.
Questions
What happens if bias_fo is set too low?
The low-pass corner drops below your signal frequencies, so fast changes reach the comparator attenuated and events thin out for exactly the fast motion the rig was built to catch. Slow motion and background activity keep generating events, so the stream looks healthy while the fast marks fade. A stream that goes quiet on fast targets but stays busy on slow ones points at the low-pass corner first.
How many events per pixel per second does a 66 Meps rating represent?
Spread it evenly and the number is small: a VGA array has 640 × 480 = 307,200 pixels, and 66,000,000 ÷ 307,200 ≈ 215 events per pixel per second. The arithmetic shows the budget is global — a few hundred pixels on one fast edge can spend it while the rest of the array is silent, which is why concentrated targets stall the readout long before the rating suggests.
Can a firmware or software update raise the Meps ceiling?
No. The ceiling is silicon: the arbitration tree and the output serializer are fixed at design time, and firmware drives the same hardware, not faster hardware. Software lowers demand instead — tighter ROI, higher thresholds, event filters — or moves processing off the critical path. The generated-versus-delivered gap you see at saturation remains a hardware property, which is why the fixes are always on the generation side.
Why do the streaks render black instead of blurred?
Because a dropped event leaves no data to draw. A frame camera at its limit averages light into blur; an event camera at its limit omits samples entirely, and the reconstruction shows an empty gap along the motion path. Re-rendering the same recording with a longer pixel decay hides short gaps but never recovers the missing events, because the information was never captured.