Event conditioning
Background-activity filtering, hot-pixel suppression and compensation for the platform's own motion, so downstream stages see target-driven events rather than ego-motion.
Technology
Event-based vision, applied
A plain account of why the sensor works, how the pipeline is structured, and where the engineering difficulty actually sits.
The sensor
A conventional imager samples every pixel on a clock and ships a full frame whether or not anything changed. An event-based imager inverts that: each pixel runs its own comparator and emits an event the instant the log intensity at that pixel crosses a threshold, tagged with its coordinates, the polarity of the change, and a timestamp.
Three consequences follow, and all three matter for a seeker:
- No exposure window. Temporal precision is set by the pixel's own response, not by a frame period, so a fast crossing target produces a clean trajectory instead of a smear.
- Per-pixel logarithmic response. Dynamic range is handled locally, so a target against a bright sky or a low sun is not lost to a global exposure decision.
- Sparse output. Static background costs nothing. Data volume tracks scene change, which is what makes real-time processing feasible inside an embedded power envelope.
| Property | Frame vs. event |
|---|---|
| Sampling | Synchronous global clock → asynchronous per pixel |
| Temporal resolution | Frame period (ms class) → microsecond class |
| Motion blur | Integrates over exposure → none by construction |
| Dynamic range | Global exposure limited → per-pixel logarithmic |
| Data volume | Constant with resolution → proportional to scene change |
| Static scene | Full redundant frames → effectively silent |
| Appearance data | Rich texture → sparse; pair with a frame channel when classification needs it |
The last row is the honest trade. Event data is superb at where and when, weaker at what. That is why our dual-modality configuration exists.
Published figures
Numbers from the public literature and from sensor vendors, not from our own programs — so you can check them yourself:
| Timestamp resolution | Microsecond class |
|---|---|
| Dynamic range | >120 dB, against roughly 45–65 dB for conventional imagers |
| Temporal equivalent | >10,000 fps quoted at camera level; 50,000–300,000 fps equivalent reported depending on scene activity |
| Low-light cutoff | 0.08 lx at camera level |
| Typical resolution | 0.1–1 MP — the Sony/Prophesee IMX636 is 1280 × 720 at 4.86 µm pitch |
| Bandwidth planning | Event-rate control in the tens of millions of events per second on a 1 GigE link |
Sources: LUCID Vision Labs Triton2 EVS documentation and tech briefs; the event-camera literature summarized on Wikipedia. Figures are sensor- and scene-dependent; treat them as the shape of the technology rather than as a specification for any particular build.
Pipeline
From photons to a guidance command
Each stage is built to preserve sparsity. The moment the pipeline reconstructs a dense frame, it has given away the reason to use an event sensor at all.
Spatio-temporal clustering
Coherent structure is extracted directly from the event cloud in space and time. No frame is reconstructed; the representation stays sparse end to end.
Track formation
Clusters are associated into persistent tracks across multiple candidate targets, with custody maintained through brief occlusion and clutter crossings.
State estimation
Extended Kalman filtering fuses the visual track with inertial measurement to produce a target state the guidance law can act on, not just a pixel position.
On-edge classification
Lightweight inference separates threat air vehicles from birds, debris and background motion — optionally cross-checked against the frame channel.
Guidance output
A guidance command or fire-control solution on a defined interface, with a track quality figure so the host system knows how much to trust it.
Stage 01, in practice
Taking the platform's own motion out
An event sensor fires on any apparent brightness change, which includes every edge in the scene when the sensor itself is moving. On a ship, a vehicle or an airframe that is most of the event stream, and none of it is the target.
De-rotation compensates for the platform's own rotation before anything downstream runs, so the events that survive are the ones caused by something genuinely moving in the world. On the left is the raw stream from a rotating sensor; on the right, the same events after compensation. Gold is a brightening event, green a darkening one.
This is the least glamorous stage of the pipeline and the one that decides whether the rest of it works.
Compute
Where the work runs
Event processing is partitioned across an FPGA front end and an embedded application processor. Conditioning and clustering — the high-rate, fixed-latency stages — run in fabric, where timing is deterministic and the event rate never causes a scheduling surprise. Track logic, estimation and classification run on the SoC, where they are easier to evolve across program spirals.
That split is deliberate. It keeps the hard real-time path out of an operating system scheduler, and it keeps the parts most likely to change in software.
Dual modality
Event plus frame
For applications that need recognition as well as tracking, we field a dual-modality configuration: an event channel carrying the temporal precision and a conventional frame or GigE Vision channel carrying appearance. The two are spatially registered and temporally aligned so a track established in the event domain can be interrogated in the frame domain without a handoff penalty.
We have built and field-characterized this configuration on our own counter-UAS testbed.
On specifics. Detection ranges, sensitivity figures, guidance parameters and integration details are program-dependent and, in many cases, export-controlled. They are provided against a specific requirement under appropriate agreement — not published on a public page. Tell us the engagement and we will answer to it directly.