Event camera bias tuning: cut noise without losing motion

An event camera out of the box streams one of two ways: a flood of background noise from a perfectly still scene, or a trickle that misses the edges you care about. Both problems live in the same place, the bias settings. This guide gives the order that works on the bench: measure the background activity first, set the event thresholds just above it, then shape the response with the filter cutoffs and the refractory period, and keep rate control as a last resort. It is written for engineers integrating event-based cameras over GigE Vision through GenICam, alongside conventional area scan cameras. You finish with a values table, an event budget your processor can absorb, and a test that proves the settings before the cell ships.

What do the bias controls change inside an event pixel?

Four controls decide what an event pixel outputs: the positive and negative event thresholds set the contrast change a pixel needs before it fires, the low-pass and high-pass cutoffs set the speed range it responds to, and the refractory period sets how soon it may fire again.

Inside the pixel, light becomes a voltage that passes a low-pass and a high-pass filter, then a comparator against the pixel's own reference. A change past the threshold fires an event carrying x, y, polarity and a timestamp, and the reference resets to the new level. Positive events report dark-to-light; negative events report light-to-dark. There is no exposure to set, because there is no integration: sensitivity lives entirely in these biases. What one event carries, and how your code reads it, is the subject of the guide to event camera data format: coordinates and timestamps, not pixels.

On the GenICam feature browser this family reads Bias Event Threshold Positive, Bias Event Threshold Negative, Bias Low Pass Filter Cutoff, Bias High Pass Filter Cutoff and Bias Refractory Period. Thresholds and cutoffs are unitless tuning integers centred on 0, where 0 is the neutral factory setting. The refractory period is a plain time. You write them over the same GenICam session you would use to set exposure through a GenICam API on a frame camera — same transport, different nodes.

How much background activity is too much?

Budget before you tune: total the events per second your processing step and your link can absorb, then treat any still-scene background rate above about 10% of that budget as too much, because real motion needs headroom to spike tens of times above the idle floor.

Background activity is the event stream you get with nothing moving: threshold noise in each pixel, plus flicker residue and thermal drift. Measure it, never estimate it. Set the lighting to its production state, leave the scene still, stream for 10 s and average. Event rates are quoted in kevents/s and Mevents/s, and your processing budget converts directly:

The link needs the same discipline. Event packets are small, but a burst from a large contrast change can exceed what the GigE Vision link carries in that moment — the guide to event camera data throughput shows what overflow does to a stream. The headroom logic is the same one that fixes acquisition running faster than processing on frame cameras.

How high should the event thresholds go?

Raise both event thresholds together, one tuning step at a time, until the still-scene background rate falls below about 10% of your event budget, then stop, because every further step buys less noise and costs latency on the real edges.

Sweep in equal steps and re-measure after each. In the example cell the sweep read 800 kevents/s at default, 250 kevents/s at +1 and 120 kevents/s at +2 — and 120,000 / 2,000,000 = 6%, so +2 on both threshold nodes is the setting. Keep the two thresholds equal unless your measurement says otherwise: background noise is usually symmetric in the two polarities.

Every step up raises the latency of real edges and shrinks the smallest contrast the sensor still reports. Commit by task:

• Moving-object detection in a conveyor or robot cell: stop at 5-10% of budget and accept the latency cost.
• Static monitoring where events are rare: push higher; latency hardly matters when nothing moves for seconds at a time.
• Low-contrast targets, such as a dark part on a dark belt: stop earlier, even at 20% of budget, and cut the remaining noise with ROI, refractory and filters.

Where should the low-pass and high-pass cutoffs sit?

Leave the low-pass cutoff at its default unless noise survives threshold tuning, because lowering it cuts noise but adds latency, and raise the high-pass cutoff until slow drift from lighting and warm-up stops producing events at idle.

Think of the two cutoffs as a speed window. The Bias Low Pass Filter Cutoff is the ceiling: a positive value keeps fast contrast changes and improves pixel latency, a negative value removes fast changes, quiets the idle stream and stretches both latency and its variation. The Bias High Pass Filter Cutoff is the floor: a positive value ignores slow changes — lighting wander, lamp warm-up, creeping shadows — while a negative value preserves slow motion and keeps the drift events too.

Decisions:

• Low-pass: stay at 0. Step down only when motion is slow, thresholds are already at their useful limit, and noise still exceeds budget. Each step down buys quiet and costs response speed, so re-test latency with a moving target after each one.
• High-pass: step up one unit at a time while a still-scene stream still shows slow, spread-out event patches, and stop when the idle goes quiet. If you must catch parts creeping a few pixels per second, keep it at 0 and solve drift at the light instead.

Periodic flicker is not the high-pass cutoff's job; that is what the anti-flicker filter is for.

How long should the refractory period be?

Divide your shortest edge-crossing time by two and use that as the refractory period: for a 0.5 ms crossing, set 0.25 ms, which caps each pixel at 1 / 0.00025 s = 4,000 events per second and swallows the duplicate echo events a bare edge produces.

After an event the pixel holds its new reference for the refractory period, and the duplicates it suppresses are pure waste: one high-contrast edge overshoots the reference, re-crosses the threshold, and one edge becomes a burst. Two numbers set the value:

Commit by what you measure, not by habit. Presence detection needs one event per crossing, so a refractory period up to the full crossing time — 0.5 ms here, capping a pixel at 2,000 events/s — works and buys extra quiet. Size or velocity measurement needs two samples per crossing, so set the period to half the crossing time, 0.25 ms here. Never go past the crossing time itself: a longer period can drop a crossing entirely.

When do the filters and rate control help — and when do they hide a problem?

Switch the anti-flicker filter on only when a lamp or LED drive modulates the light at a fixed frequency, enable the burst filter when one edge floods the output with same-polarity duplicates, and leave event rate control off until everything upstream is tuned.

The Anti-Flicker Filter removes events in a frequency band you set: mains-powered lamps flicker at 100 or 120 Hz, and PWM LED drives at hundreds of hertz to a few kilohertz. Measure the frequency, set the band, and note that the filter is invertible — it can pass only the flicker band, which turns flicker itself into a signal.

The Event Burst Filter collapses a run of same-polarity events from one edge into a single output event, keep-first or keep-second depending on the mode your camera offers. Enable it after the refractory period is set, for bursts that still survive.

Event Rate Control (ERC) is different in kind: it does not judge which events matter, it drops them wholesale to hold the output at a target. Where the camera enforces the target over each 200 µs period, a 2 Mevents/s target allows 2,000,000 events/s × 0.0002 s = 400 events per period, and the excess is discarded after filtering. Set the target at your budget — 2 Mevents/s in the example cell — and read steady ERC activity as a verdict on the earlier stages, not as a fix.

What order do you tune the biases in?

Fix the region of interest first, tune the thresholds against a measured background rate second, then the high-pass cutoff, the refractory period and the filters, because each stage changes what the next stage measures and geometry costs no latency at all.

The full sequence, start to finish:

1. Set the region of interest to the zone where motion matters. Idle noise scales with active pixel count, so cutting the area cuts the floor in proportion.
2. Bring the lighting to its production state — brightness, angle, flicker behaviour.
3. Stream 10 s with a still scene and record the background rate at default biases.
4. Compute the event budget from your processing slice, with the formula above.
5. Raise Bias Event Threshold Positive and Bias Event Threshold Negative together, one step at a time, re-measuring 10 s after each, until the background rate sits under 10% of budget.
6. Raise the Bias High Pass Filter Cutoff in single steps until slow drift stops firing at idle, and confirm your slowest real motion still appears.
7. Set the Bias Refractory Period to half the shortest edge-crossing time in the scene.
8. Enable the Anti-Flicker Filter at the measured lamp frequency if flicker survives the threshold step; enable the Event Burst Filter if single edges still produce duplicate bursts.
9. Set the Event Rate Control target to your budget and leave it engaged as an overflow guard.
10. Store the tuned values in the camera's user set and load that set at startup, so a power cycle cannot revert them.

How do you prove the tuning worked before it ships?

Run three checks before you freeze the values: a 10 s still-scene stream that must stay under 10% of budget, a worst-case moving target that must draw a connected event trace, and a triggered latency test that must land inside your control loop's allowance.

Idle floor. Stream 10 s with the scene still. The example cell must read under 200,000 events/s — 10% of 2 Mevents/s — and it reads 120,000, so it passes with margin.

Worst target. Run your lowest-contrast, fastest part at production speed across the whole ROI. The trace must be continuous, a line rather than scattered dots, and each crossing must deliver at least two events where you measure size or velocity. Scattered dots mean the thresholds are one step too high or the light is too weak; step back once and re-run the idle check.

Latency. Trigger a known motion — a flag on a solenoid, a part breaking a photocell — and subtract the trigger timestamp from the first event timestamp. The gap must fit your loop's allowance with margin for the variation that higher thresholds add, and you re-run it after every cutoff change.

Mistakes that pass the bench and fail the line:

• Tuning under bench lighting and then relamping the cell: the idle floor moves, so re-measure.
• Leaving an earlier experiment's rate control target engaged: its silent drops read as sensor silence.
• Judging by preview frames alone: accumulation time shapes the picture, not the stream.

If you are still choosing hardware rather than tuning it, start with the comparison of event based vision vs frame cameras for fast motion, then size the rest of the station with the camera finder or the camera configurator. The other integration guides sit on the cameras topic page, and the application team answers specific tuning questions through the contact page.