You know the frequency before the camera is mounted: a strobe flashing at 30 Hz, a flickering lamp, a vibrating conveyor. The tempting move is to type that number into the temporal filter and be done. You cannot. The fall off and high pass settings on an event camera are analog bias currents, entered as dimensionless counts, and no formula converts counts to hertz. What you can do is calibrate your own unit against a signal at the frequency you care about — about twenty minutes of bench work — then set the corner with margin. This page gives the first-order corner formula, the two planning rules that fall out of it, a worked strobe example with the arithmetic shown, and the decision for each case: reject the strobe, keep it as a clock, or hand the job to a triggered frame-based camera.
What fall off and high pass actually set
An event camera fires events when light changes at a pixel, and a temporal band pass around that decision decides which changes survive. The band is set by analog reference currents on the sensor chip. Your bias panel shows them as fall off and high pass, entered as dimensionless counts.
In broad terms, one bias sets the lower corner: how quickly the pixel forgets stale activity, so a static scene stops emitting events. The other shapes the upper end, where the pixel stops following change. Which named setting does which job, and whether more counts mean a faster or a slower corner, differs by sensor family; your first sweep establishes both on your unit in minutes. The settings stay counts everywhere, including in the capture API: no field takes hertz.
Why no formula converts bias counts to hertz
The corner comes from a bias current through on-chip components whose absolute values vary with process corner, temperature and supply. The count-to-corner mapping is monotone — more of the relevant bias moves the corner one way, consistently — but it is not calibrated and does not transfer between units. Two cameras set to the same counts can sit on different corners, and the corner also spreads pixel to pixel across one array.
That is why the sensor maker's public bias guidance walks through tuning procedures and publishes no counts-to-hertz table. Treat the mapping as a per-unit calibration you perform yourself, and re-check it at operating temperature: the analog corner drifts as the chip warms.
The first-order model and the two planning rules
Near its pass band, the pixel's temporal response behaves close to a first-order high-pass with a decay time constant τ, so planning needs one formula, with f_c the corner frequency:
It is the standard first-order estimate, not a datasheet curve, and it turns the job into numbers:
- Reject a disturbance at f: set the corner at 2f. The first-order response at f is then 0.5/√(1 + 0.5²) = 0.45 of amplitude, -7 dB; at a corner of 3f it is 0.32, -10 dB. Pixel thresholds make the real fall-off steeper, which works in your favour.
- Keep a signal at f: set the corner at f/6. The signal sits at 6× the corner, where the response is 6/√37 = 0.99, or -0.1 dB: effectively untouched, while content at half the corner is already down -7 dB.
Worked example: a strobe locked to a 30 fps camera
A strobe that fires once per video frame produces one flash per frame — 30 flashes per second — and each flash edge produces an event burst at every lit pixel. Two cases, then the counts that realize them.
Case A — the strobe must not flood the stream. Set the corner at twice the flash rate, i.e. 60 Hz. τ = 1/(2π × 60 Hz) = 2.65 ms. The strobe flicker passes a first-order filter at 0.45, -7 dB; a 90 Hz corner gives 0.32, -10 dB. Point the camera at the strobe alone and watch the event rate collapse to near zero; wave a hand through the field and confirm motion events still stream.
Case B — the strobe is your clock. Set the corner at one sixth of the flash rate, i.e. 5 Hz. τ = 1/(2π × 5 Hz) = 31.8 ms. The strobe bursts pass at -0.1 dB, thermal drift at 2.5 Hz is -7 dB, and drift at 1 Hz is -14 dB (0.2/√(1 + 0.04) = 0.196). Slow background fades out while bursts keep arriving 30 times a second.
The corners come from counts, and that is the calibration. Illustrative sweep from one unit at 25 °C, on a family where higher fall off means a higher corner — your counts will differ; the method is what transfers. Read each row as "the corner sits near this frequency":
fall off (counts) |
Slowest test frequency still passing |
|---|---|
| 350 | 10 Hz |
| 520 | 30 Hz |
| 780 | 100 Hz |
For Case A's 60 Hz corner, interpolate between the second and third rows: 520 + (30/70) × 260 = 520 + 111 = 631 counts, so set about 630 and bisect on the live strobe. For Case B's 5 Hz corner, extrapolate below the first row: the local slope is (30 − 10)/(520 − 350) = 0.12 Hz per count, so step down 5/0.12 ≈ 42 counts from 350 to roughly 310, then bisect again. Linear interpolation is the approximation; the bisection on real events is the answer.
A twenty-minute calibration that holds
- Build a known-frequency stimulus: a function generator driving an LED at 10, 30 and 100 Hz, a patterned disc on a motor, or the strobe you actually run. Three well-spaced frequencies, because one point does not interpolate.
- Match deployment brightness roughly. Threshold and filter interact, so tune at a contrast close to what the scene will give.
- Sweep the bias in coarse steps, then bisect: for each test frequency find the counts where its events just die, or just appear if you are setting the other end. Record counts, and note which direction the corner moved.
- Repeat on the second bias if you need both ends of the band controlled.
- Interpolate or extrapolate locally and linearly to the corner your case needs, then bisect on the live scene and write the counts down with the date and chip temperature.
- Verify after 15 minutes of warm-up and again at operating temperature. If the counts need moving, the corner moved with them.
Where the band-pass answer breaks down
- A corner is not a notch. The filter attenuates everything on one side of the corner, so a strobe that sits inside your motion band cannot be cut without cutting the motion. Notch-like separation needs a different architecture, not a better bias value.
- The filter is phase-blind. It shapes which event rates pass; it cannot gate events to a strobe phase or deliver an image synchronized to the flash.
- Pixels differ. The corner spreads across the array, so a setting tuned on the median pixel lets early pixels leak. Add margin, or mask the leaking pixels in post-processing.
- Flicker costs throughput too. A flooding strobe can saturate the event link; killing it at the sensor fixes that as well — see what happens when events exceed the link.
The decision, case by case
- Strobe or flicker you want gone, motion content above it: calibrate, set the corner at 2-3× the disturbance — 60-90 Hz against the frame-rate strobe of the worked example — and verify the strobe-only scene is quiet.
- Strobe or flicker you want kept as a clock: set the corner at about one sixth of the flash rate, 5 Hz in the worked example, so bursts pass untouched while slower drift dies.
- Strobe inside your motion band, or a strobe-locked image required: stop with the biases. Trigger a frame-based smart camera from the strobe; synchronization is then deterministic and needs no calibration. The trade between events and frames is laid out in when events beat frames.
- Noise with no known frequency: run the same sweep-and-verify routine from bias tuning without losing motion events, minus the interpolation targets.
Before you commit: re-run the calibration after any firmware or bias-file change, keep the counts logged with temperature, and read why bias values are not contrast thresholds alongside this when the filter starts interacting with your thresholds. If the frame-based route wins your case, start from the camera finder; for a build question, the contact page reaches the applications team, and the cameras topic page collects the rest of the camera guides.
Questions
Are fall off and high pass bias settings measured in hertz?
No. They are analog reference currents entered as dimensionless counts in the bias panel and in the capture API. The corner frequency they produce depends on each chip's absolute component values, which vary unit to unit and drift with temperature, so no vendor publishes a counts-to-hertz table. You find the corner on your unit by stimulating it at known frequencies and recording where events die.
How do I remove 50 Hz mains flicker from an event camera recording?
Treat it like the strobe case worked through above. Drive a lamp or LED at 50 Hz, or tune against the flickering fixture itself, and raise the relevant bias until the 50 Hz events die while wanted motion still streams. A corner near 100-150 Hz attenuates 50 Hz by 7-10 dB on the first-order model; the flicker-only scene going quiet is the proof on your unit.
Why do two identical event cameras behave differently at the same bias values?
The current a given count produces depends on each chip's process corner, plus temperature and supply voltage. The mapping stays monotone, so the tuning direction is consistent, but the corner at a given count is per-unit. Calibrate each camera separately, log the temperature with the counts, and do not copy bias files between units expecting the same temporal band.
Can I compute the filter corner from a bias count instead of measuring it?
Not from first principles. Once you have measured the decay time constant on your unit, the first-order estimate f_c ≈ 1/(2πτ) gives the corner: τ of 2.65 ms lands near 60 Hz and τ of 31.8 ms near 5 Hz. But the time constant itself comes only from measurement, because no datasheet maps counts to milliseconds.
I need images locked to my strobe — should I tune temporal filter biases?
No. The temporal band pass is phase-blind: it decides which event rates pass, and it cannot gate events to a strobe phase or produce a synchronized frame. For a strobe-locked image, trigger a frame-based camera from the strobe itself. Keep the event stream for motion between flashes, with the corner set below the flash rate.