Fixed timing: why the fusion pipeline runs in FPGA logic
Motion prediction, the radar map match and the thermal scene check run in fixed-timing FPGA logic. What that buys, and what is still to be validated.
SenzFusion's target hardware is an FPGA system-on-chip: fixed-timing logic for the sensor pipeline, and ARM cores for the estimate update. This article explains that split — and is explicit about which parts are still a proposal.
Why timing matters
A fusion pipeline is only as good as its sense of time. The IMU predicts motion 1,000 times a second; the radar altimeter, imaging radar and thermal camera each produce readings on their own schedule. To combine them, every reading has to be placed on one consistent timeline.
General-purpose processors are flexible, but their timing varies with load. FPGA logic does the same work in the same number of clock cycles every time. The reason for putting the sensor pipeline there is simple: predictable timing. Motion prediction, the radar map match and the thermal scene check run in fixed-timing FPGA logic.
Fixed-timing logic does the repetitive work. ARM cores make the decision.
Six steps from reading to correction
The proposed processing core turns raw sensor readings into a course correction in six steps:
- Time-stamp and clean — a hardware clock time-stamps readings from all sensors; weak readings are dropped. FPGA.
- Predict motion — the IMU's position, velocity and orientation are predicted 1,000 times a second. FPGA.
- Ground profile — radar altimeter heights along the track build the terrain profile. FPGA.
- Radar map match — the profile and imaging-radar patch are matched against the stored terrain map to correct drift. FPGA.
- Thermal scene check — the thermal terrain picture is checked against the reference scene. FPGA.
- Update estimate — when radar and thermal agree, an along-track and cross-track update is applied, and a course correction goes to the autopilot over signed serial. ARM.
Barometer and airspeed also feed the core. The pattern is deliberate: the five steps that repeat constantly and benefit from deterministic timing live in logic, while the one step that weighs evidence and decides lives in software.
References in, estimates out
Matching needs something to match against. Onboard reference storage holds the terrain maps, thermal reference scenes and mission configuration for the pipeline, all prepared before flight. The flight plan is delivered to the host separately from the payload's reference data.
GNSS is wired in as a check input: it is compared against the estimate to detect a contested environment.
What is still to be validated
Everything above describes a proposed design, not a board specification. We want to be direct about that, because timing claims are exactly the kind that need measurement rather than assertion.
- Timing remains to be validated. The rationale for fixed-timing logic is predictability; the actual timing and operating envelope have not yet been validated.
- Per-platform constraints. Storage, power, heat, sensor interfaces and latency still need validation on each platform the payload is fitted to.
- Integration choices. Whether navigation and tracking share one thermal camera is decided per integration.
Those questions are answered in the engagement path with each vehicle maker: a controlled proof of concept measures accuracy, latency, power, weight and safe fallback on the host aircraft before any pilot programme.
See the full hardware breakdown on the SenzFusion page, or where the fusion kernel sits in the stack at L1 on the Platform page.
