If you live near Schiphol, you know the noise. It's constant, it's measurable, and yet there's no real way for a resident to actually measure it. Professional sound meters cost thousands. Municipal monitoring stations are sparse. The data exists, it's just not yours.
That's what this started from. Not a market opportunity, just a genuine annoyance: why is this so hard? And then it turned into an 18-month build.
Working out the architecture
The tricky part early on was figuring out how to run continuous audio classification on a solar-powered device. Those two things don't naturally go together. Audio inference wants to run constantly; solar wants to sleep as much as possible, especially through a Dutch winter with ~8 hours of decent light.
The approach we landed on was event-driven firmware. Audio capture runs in the background via DMA with no CPU involvement, and the processor only wakes up when there's actually something worth classifying. For the LTE connection we use eDRX and PSM, which lets the modem sleep between data bursts and drops current draw from around 150 mA to under 1 mA. Paired with flash memory that buffers data locally when there's no signal, the device holds up well against both bad weather and bad coverage.
Going beyond dBa
Early on we looked at using a machine learning classifier (YAMNet) to identify sound sources like airplanes or traffic. We got it working as a proof of concept, but the more interesting problem turned out to be a different one: dBa tells you how loud something is, but not whether a person actually finds it annoying. A faint hum at the wrong frequency can be unbearable. A loud broadband rush can be barely noticeable. The number on its own doesn't capture that.
So instead we implemented the psychoacoustic metrics from the SQAT model in C, to run directly on the embedded device. Where dBa weights frequencies to approximate human hearing, psychoacoustic metrics go a step further:
- Loudness (ISO 532-1) models how the auditory system actually perceives volume
- Sharpness picks up high-frequency harshness
- Roughness measures fast amplitude modulation in the 15–300 Hz range, which is what makes some sounds feel grating
- Fluctuation strength captures slower, pulsing patterns
Together these give a much cleaner picture of why a particular noise is or isn't bothersome.
SQAT started as a MATLAB toolbox developed partly at TU Delft for aircraft noise evaluation, which made it a natural fit. Porting the algorithms to C for a constrained embedded target was the main engineering work here.
A few hardware choices worth explaining
We tested a cheap PM2.5 sensor early on, around €7, widely available. It looked fine in a controlled setting and then drifted badly outdoors, especially with humidity. The Sensirion SEN66 at €25 was the obvious replacement. It handles its own temperature and humidity compensation, measures PM2.5, PM10, VOC, CO₂, and also gives us the temperature reading we needed to compensate for MEMS sensitivity drift.
Privacy
Putting a microphone outside someone's house is a sensitive thing, and we didn't want to skip over that with a privacy policy. So there's no way for the device to store or transmit audio. Raw audio gets converted on the device straight into dBa and annoyance-metric values, and data only appears on community maps in aggregated form.
It felt important to make these constraints architectural rather than just promises.
Three properties we consider non-negotiable:
- No audio stored or transmitted. Raw audio never leaves the device. Only computed metrics are sent.
- Postcode, not coordinates. Location is only shared on postcode level.
- Aggregated on the map. Individual readings never appear publicly. Your data only contributes to area averages.
Next steps
The device is currently in the mid stages of development. We are fine tuning the firmware, algorithms and checking the performance. Follow us to stay updated on the progress!
If you're building something similar, solar-powered, connectivity-constrained, continuous sensing, the main thing we'd pass on is: design for the power budget first, everything else second. The feature list has to fit inside the energy envelope, not the other way around.