Hardware / Sensor System Development

Sensor System Development

Multi-sensor systems and processing that runs where the data is — array geometry, synchronization across devices, sensor fusion, and results computed on the device rather than shipped somewhere else to be worked out.

What we build

Multi-sensor architecture and fusion
Array geometry and sensor placement
Distributed sensor synchronization
Real-time signal processing
Processing and results computed on the device
Custom sensing pipelines for new applications

What a multi-sensor system has to solve

Sixteen microphones, two enclosures, one clock — and a source that has to land in the same place according to both.

One of our own validation setups. Each array resolves a direction on its own; because both sample against the same clock, the pair resolves a position. Everything in this drawing is a design decision — how many sensors, how far apart, at what spacing, and how tightly they are held in time. Get any of them wrong and no amount of processing afterwards will recover it.

Built and measured, not modelled

Two assembled sensor nodes standing side by side on a bench, linked by a cable — Two nodes, one time baseSeparate devices held in the same time domain over ordinary cable, with no GNSS timing and no wireless synchronization.

The microphone array plate with its eight carrier boards mounted around the edge — The array itselfEight sensors, placed to a geometry that was chosen and then measured rather than assumed.

This capability comes out of building our own sensing product rather than out of a course. Eight microphones on one sampling clock, processing on the node, a second node held in the same time domain, and the whole thing checked against surveyed ground truth and an RTK-GPS-tracked target — with the results and their limits published rather than asserted.

The approach transfers directly to other sensor types. Vibration, pressure, current, optical, gas: what changes is the transducer and its conditioning. What does not change is the part that is hard — getting several sensors to agree in time, placing them where the physics wants them, and computing something useful on the device instead of shipping raw data off it.

See the measurements →

Four problems, in the order they bite

Geometry

How many sensors, how far apart, in what arrangement. This is fixed in the mechanical design and cannot be improved later in software, which is why it gets decided first.

Synchronization

Sampling against one clock, and separate devices held in one time domain. Without it, comparing two sensors is comparing two guesses.

Conditioning

The analog or digital front end between the sensor and the converter, and the noise it does or does not add.

Fusion and processing

Combining the channels into something that means anything, in the time available, on the part you have — not on a workstation afterwards.

Embedded Engineering

Architecture, part selection and hardware bring-up.

Connected Device Development

Device, firmware, and the service behind it.

Several sensors that have to agree?

Bring what you need to measure and how precisely. You get an honest read on whether the sensor count, the geometry and the timing budget can actually deliver it.

Discuss a project →