Building AuraSense

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 four 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 10 µA. Paired with an SD card 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 to 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.

We also talked through the microphone placement with an acoustic engineer. The instinct is to put the mic behind a long protective tube to keep rain out, but tubes resonate and mess with the frequency response. We went with a shallow dome and acoustic foam instead. Mic angled slightly downward, which helps with rain noise and keeps the pickup pattern useful for ambient monitoring.

Privacy

Putting a microphone outside someone's house is a sensitive thing, and we didn't want to paper over that with a privacy policy. So there's no way for the device to store or transmit audio, not by configuration, just by design. No GPS module either. Location is a postcode, entered once during setup, and data only appears on community maps in aggregated form. It felt important to make these constraints architectural rather than just promises.