Explore interactively

System flow

Explore the processing chain from the first movement to an understandable event output, step by step.

Open system flow

Sensor node

See the planned MVP sensor-node assemblies in an interactive exploded concept view.

View sensor node

The processing chain

Between a received radar echo and an alert in the control room sit several stages, each catching a different class of error.

The stages from "optional camera" onwards are development goals of the funding phase, not demonstrated product capability.

What each stage does

01

Radar front end

The radar system uses FMCW waveforms and multiple transmit and receive channels. In a MIMO configuration, transmit/receive combinations can form virtual antenna elements. The enlarged virtual aperture provides additional spatial information for angle estimation. A larger virtual antenna array does not automatically imply a correspondingly higher SNR gain; aperture, angular information and signal gain have to be considered separately.

Small drones are demanding radar targets: their radar cross section can be small and can vary strongly with aspect angle, airframe design and material. Waveform, detection and temporal processing therefore have to be matched to this target type.

  • mmWave FMCW around 77 GHz
  • Multiple TX/RX channels
  • Virtual aperture for angle estimation
02

Detection

Range and Doppler FFTs turn the chirp echoes into a range-velocity map. Adaptive clutter suppression reduces static and recurring scene content. The parametrisation aims to preserve slowly moving relevant targets as far as possible. An adaptive detection threshold follows the local interference level instead of applying a fixed value, and produces the candidate list.

  • Range-Doppler processing
  • Adaptive clutter suppression
  • Adaptive instead of fixed threshold
03

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
04

Track validity

Moving vegetation, multipath propagation and processing artefacts produce structures that look very much like a track. Track validation assesses whether consecutive detections are spatially and temporally consistent with a single target. This reduces unstable detections as well as typical clutter, multipath and processing artefacts – before any statement is made about the nature of the target. It is kept deliberately separate so clutter is not treated as an equivalent object class.

  • Spatial and temporal consistency check
  • Ghost-target handling
  • Structural false-alarm reduction
05

Semantic assessment

Only a valid airborne track is assessed: drone, bird or other airborne object, or Unknown. Classification can draw jointly on motion dynamics, micro-Doppler structures, backscatter characteristics and temporal track features. No single feature is sufficient for a dependable distinction. Processing runs locally.

  • Micro-Doppler & RCS statistics
  • Track and temporal features
  • Sequential evidence aggregation
06

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)

Architecture and operation

AspectCurrent decision
Sensor platformmmWave FMCW radar around 77 GHz
Evaluationlocal processing of the radar data
Where classification runson the edge unit, not on the radar SoC
Cloudnot required for detection and alerting
Raw data on the site networktracks, events and classification results are provided to higher-level systems; raw data can be recorded for development, validation and diagnostics
Cameraexisting PTZ, event-driven; no continuous video recording intended
Integrationdownstream path to VMS/control room; no vendor fixed
Active countermeasuresexplicitly not part of the system

Processing combines adaptive detection, clutter suppression, spatial-temporal track formation and the evaluation of characteristic radar signatures. Information from several measurement cycles is aggregated before a target is classified or treated as uncertain. Moving further steps onto the radar DSP later would be an optimisation goal, not an already demonstrated property.

How false alarms are measured

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.

StageMeasured output
Detectorraw candidates per unit time
Trackerconfirmed, fragmented and discarded tracks
Track validityphysical target tracks versus clutter/artefacts
Semantic assessmentdrone, bird/other airborne object, Unknown, and confusions
Optional cameraverified, refuted and unverifiable events
Control roomalerts 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

Frequently asked questions

What happens when classification is uncertain?

The track remains explicitly unknown. This is a deliberate system decision: a classifier that forces a class on thin or contradictory evidence produces confidently wrong decisions — precisely the kind that costs trust in a control room. Ozense therefore assesses conservatively and makes uncertainty visible.

Does processing run locally?

Yes. Detection and alert assessment are intended to run entirely on site, on one edge unit per radar node. No cloud is required for this, which reduces latency and availability dependencies. The current architecture also avoids transmitting raw data across the site network.

Are camera images processed continuously?

No, that is not the intent. The radar channel does not capture optical image data. An existing PTZ camera is only to be slewed when there is a relevant radar candidate, and only where visibility and target geometry allow it. Continuous video recording is not part of the target architecture. The automatic PTZ cueing itself is a development goal and has not been demonstrated in the field.

Does operating a 77 GHz radar require authorisation?

Stationary operation must be clarified separately and is not automatically permitted. The general assignment covering automotive short-range radar does not make fixed-site operation automatically lawful. Ozense handles this in separate stages for its own research, for fixed pilot operation on third-party premises, and for later product operation; an application for research use is pending with the German Federal Network Agency.

All answers: FAQ