From radar echo to verifiable alert
The Ozense processing chain: which stage solves which problem, what runs on which hardware, and where the limits of today's status lie.
Between a received radar echo and an alert in the control room sit several stages, each catching a different class of error.
77 GHz FMCW radar
│
▼
Detection range-Doppler FFT · clutter filter · CFAR
│
▼
Tracking association · Kalman state estimation · promotion
│
▼
Track validity physical target OR clutter/artefact → discard
│
▼
Semantic drone · bird or other airborne object · Unknown
assessment
│
▼
Optional camera radar-triggered PTZ cueing, where visibility allows
│
▼
Alert conservative fusion → VMS / control room
│
▼
Incident package track + image + confidence + configuration/version
The stages from "optional camera" onwards are development goals of the funding phase, not demonstrated product capability.
Radar front end
A low-cost 77 GHz single-chip FMCW radar with three transmit and four receive antennas. TDM-MIMO forms a virtual array that yields additional coherent gain and angular resolution over a single antenna. The platform comes from the automotive industry – and is therefore designed for targets with a radar cross section 25 to 35 dB larger than a small drone. Bridging that gap is a core part of the development work.
- 77 GHz FMCW
- 3TX/4RX TDM-MIMO
- COTS single chip
Detection
Range and Doppler FFTs turn the chirp echoes into a range-velocity map. An adaptive clutter filter learns the static content of the scene and suppresses it without indiscriminately deleting low-motion target content. An OS-CFAR detector then sets a threshold adapted to the local environment and produces the candidate list.
- Range-Doppler FFT
- Adaptive clutter filter
- OS-CFAR instead of a fixed threshold
Tracking
The tracker links detections over time, estimates the motion state with a Kalman filter and bridges short dropouts. A track is only confirmed after several consistent observations. That costs reaction time but prevents every chance detection from appearing as a target.
- 3D tracker with acceleration model
- Track promotion across several frames
- Coasting through short detection gaps
Track validity
Moving vegetation, multipath propagation and processing artefacts produce structures that look very much like a track. This stage decides whether a physical target exists at all – before any statement is made about its nature. It is kept deliberately separate so clutter is not treated as an equivalent object class.
- Physical target track vs. artefact
- Ghost-target handling
- Structural false-alarm reduction
Semantic assessment
Only a valid airborne track is assessed: drone, bird or other airborne object, or Unknown. The feature basis is micro-Doppler signatures, radar cross section fluctuation, and track and temporal features. The models run locally on the edge unit.
- Micro-Doppler & RCS statistics
- Track and temporal features
- Sequential evidence aggregation
Unknown as a system decision
A classifier that forces a class on thin evidence produces confidently wrong decisions. Those are the most expensive kind for a control room, because they cost trust. Ozense therefore treats uncertainty explicitly: where evidence is insufficient, the track is reported as uncertain. Uncertainty-calibration methods can only honour their guarantees under their own assumptions – they do not guarantee a field false-alarm rate.
- Calibrated uncertainty
- Defined degradation path
- Domain-shift detection (R&D goal)
| Aspect | Current decision |
|---|---|
| Sensor platform | low-cost 77 GHz single-chip radar (COTS) |
| Evaluation | one edge computer per radar node |
| Where classification runs | on the edge unit, not on the radar SoC |
| Cloud | not required for detection and alerting |
| Raw data on the site network | deliberately avoided in the current design |
| Camera | existing PTZ, event-driven; no continuous video recording intended |
| Integration | downstream path to VMS/control room; no vendor fixed |
| Active countermeasures | explicitly not part of the system |
The correct architecture claim is: low-cost single-chip radar hardware plus resource-constrained local edge evaluation. Moving further steps onto the radar DSP later would be an optimisation goal, not an already demonstrated property.
The false-alarm performance of a detection system cannot sensibly be captured by a single percentage. Ozense therefore measures it as a funnel: each stage reduces the volume reaching the next, and each stage is reported separately.
| Stage | Measured output |
|---|---|
| Detector | raw candidates per unit time |
| Tracker | confirmed, fragmented and discarded tracks |
| Track validity | physical target tracks versus clutter/artefacts |
| Semantic assessment | drone, bird/other airborne object, Unknown, and confusions |
| Optional camera | verified, refuted and unverifiable events |
| Control room | alerts actually displayed, and end-to-end latency |
Neither bird base rates nor acceptable false-alarm values are invented. Site-specific input and base rates are established in real measurement campaigns; target corridors are fixed before each formal evaluation and not moved afterwards.
Request a technical exchange.
Informed disagreement is welcome, particularly from the radar, measurement and integration side.
Request a technical exchange