Sirens are easy to miss from inside a modern car, and a warning you can only hear leaves people out. Three small devices turn what is happening around the vehicle into something you can see, hear and act on.
Designed, built and documented end to end by one engineer: the acoustic array, the firmware, the signal processing, the enclosure, the boards and this page. Every figure here is one this project earned.
Sound insulation, music and closed windows all hide an approaching siren. And a warning that only makes a noise leaves out anyone who cannot hear it. SirenSense is a set of three small devices that turn the world around the car into something visible, spoken and directional — and listening for sirens is only one of the things it does. Everything in this section is meant to be understood without any mathematics. That begins further down the page.
It listens
Four microphones in a cross, mounted outside the cabin where the road can actually be heard. It decides whether a siren is present, and which direction it is arriving from.
It shows and speaks
A small screen with one camera facing the road and another facing the driver. It shows the warning, says it out loud, and keeps the rest of the drive in one place.
It answers back
Carried by the emergency vehicle itself. It broadcasts its own position, so a nearby car can be told where the ambulance is instead of having to infer it from sound alone.
Siren detection is one feature out of twelve. Each carries a status describing the project as it stands today: implemented means working in the prototype or its software, in integration means built but not yet proven in a vehicle, and concept means a designed direction that is not presented as a certified product function. A label changes only when the matching test is complete.
A small on-device AI model listens for sirens and tells them apart from traffic, music and wind. It was trained on real roadside recordings rather than clean studio samples.
ImplementedThe four microphones work together to produce a bearing, so a warning can say left, right, ahead or behind instead of only announcing that a siren exists.
ImplementedThe front camera records the road ahead, with an interface built for full high-definition capture at 30 frames per second.
In integrationA camera facing the driver looks for signs of fatigue, distraction and phone use, and raises a warning rather than a score.
In integrationForward radar measures the distance and closing speed of the vehicle ahead, and warns when that gap is shrinking faster than it should.
In integrationAir quality, humidity and temperature are measured inside the car — useful to the driver, and a way to protect the electronics from their own enclosure.
ImplementedAn accelerometer and a gyroscope record how the car is actually moving, and can flag a collision event alongside the surrounding video.
ImplementedA vector map drawn by the device itself, so navigation and the emergency-vehicle display keep working with no phone signal and no cloud map service.
ImplementedThe interface reads the car's own diagnostic port (OBD‑II) and shows gauges and system health beside the safety alerts.
In integrationLong-range radio plus satellite position gives a participating emergency vehicle a direct line to nearby SirenSense units, naming where it is rather than merely that it exists.
ImplementedA prototype emergency mode that shares its own position with nearby units and lights the roof beacon. It is not a regulatory replacement for a certified V16 device.
Concept · not DGT certifiedBattery protection, charging, conversion and filtering are designed as part of the sensing chain rather than bolted on afterwards.
Implemented
The features above are not a list of ideas. Each one has a board, a module or a page of working behind it, and most of that work is a person at a bench with a notebook.
Everything below follows from four numbers that are facts about this build: the 190 mm microphone cross, the speed of sound at 20 °C (343 m/s), the 44.1 kHz sample rate, and the 8× interpolation used on the delay estimates. Nothing here is a measurement of accuracy; that needs field characterisation this prototype has not finished.
A plane wavefront reaches the four microphones at different instants. The extra distance the wave must travel to the far microphone of a pair is the microphone separation projected onto the wave direction:
ΔxEW = d·cos θ ΔxNS = d·sin θ
ΔxEW = 190 mm · cos θ ΔxNS = 190 mm · sin θ
The extra distance the wavefront must travel to reach the far microphone of each opposing pair, compared with the near one.
The array cannot measure an angle. It can only measure how much longer one path is than another, so the bearing has to be turned into a length before anything can be measured. Projecting the baseline onto the direction of travel is the simplest way to do that.
A distant source produces a wavefront that is effectively a plane, perpendicular to the direction the sound travels. That direction is a unit vector whose east and north components are cos θ and sin θ. The extra path along a baseline of length d is the baseline projected onto that vector: d cos θ for the east–west pair, d sin θ for the north–south pair.
| d | 190 mm — the microphone cross |
|---|---|
| θ | bearing of the source, measured from east, anticlockwise |
| Δx | extra path for one pair, in metres |
cos 137° = −0.731 and sin 137° = 0.682, so ΔxEW = −139.0 mm and ΔxNS = +129.6 mm. The minus sign is not an error: it says the wave reaches the east microphone last at that bearing.
It assumes a plane wave, which holds only while the source is far compared with the array. The array is small enough that the assumption is cheap: at the closest range the simulator allows, 3.75 m, the curvature of the wavefront across the cross is d²/8r — about 1.2 mm, under 1% of the baseline.
Dividing by the speed of sound gives the delay each pair measures:
τEW = (d/c)·cos θ τNS = (d/c)·sin θ
τ = (0.190 m ÷ 343 m/s) · cos θ = 553.9 µs · cos θ
The same path difference, expressed as a time.
Nothing in the signal chain measures distance. A digital microphone produces samples, so the only comparison the firmware can make between two channels is when a sound arrived. Dividing the path by the speed of sound converts the geometry into the one quantity the correlator can actually extract.
Time is distance over speed, τ = Δx / c. Substituting the path difference from the panel above gives (d/c) cos θ and (d/c) sin θ.
| c | 343 m/s — speed of sound at about 19 °C |
|---|---|
| d/c | 553.9 µs — the largest delay the array can ever produce |
| τ | pair delay, in seconds or in samples |
τEW = 553.9 µs × −0.731 = −405.2 µs and τNS = 553.9 µs × 0.682 = +377.8 µs. At 44.1 kHz one sample is 22.68 µs, so that is −17.9 and +16.7 samples, and the ceiling of 553.9 µs is 24.43 samples — comfortably inside the correlation window.
The speed of sound rises by about 0.6 m/s per °C, so a 10 °C swing moves both delays by about 1.8% — 343 m/s at 20 °C becomes 349 m/s at 30 °C. It moves them by the same 1.8%, which is why correcting for c does not improve the bearing. The panel on the bearing equation shows where that factor goes.
These are real inter-channel time differences only because both pairs run on one clock domain. If the pairs were clocked independently, any offset between them would appear here as a delay that is not a delay at all — the failure mode recorded in the pipeline section.
The largest delay the array can ever see is therefore d/c = 554 µs, which at 44.1 kHz is 24.4 samples — comfortably inside the correlation window.
The delays are a vector: (τEW, τNS) has magnitude d/c and direction θ. Its angle is the bearing, so the two coordinates are combined directly:
θ = atan2(τNS, τEW)
θ = atan2(+377.8 µs, −405.2 µs) = 137.0°
The bearing, from the two measured pair delays.
The single-argument arctangent sees only a ratio, so it cannot separate a bearing from that bearing plus 180°. That is exactly the ambiguity a lone microphone pair suffers from. The two-argument form reads the sign of both coordinates and returns an angle over the full circle.
Substituting the delay equations gives (τEW, τNS) = (d/c)(cos θ, sin θ). That is a vector of length d/c pointing along the bearing, and the angle of a vector is what atan2 returns. No scale factor is needed, because the length cancels in the ratio.
| τEW, τNS | the two measured delays, in one consistent unit |
|---|---|
| θ | bearing from east, anticlockwise, in degrees |
Both arguments carry the same factor d/c, so the ratio is sin θ / cos θ before the arctangent is even applied. The bearing is therefore independent of the speed of sound. This is the arithmetic reason the design declines to claim that temperature compensation improves the bearing: it corrects the delays, not the angle.
Because only a ratio survives, the estimator is blind to how large the delays were. Near a diagonal both axes are mid-scale and the ratio is well conditioned; when one axis is near zero the bearing rests on the other alone, and noise in the small axis pulls the angle. A residual clock offset between the two pairs enters as an additive delay in one axis and rotates the bearing rather than shifting it — the effect measured at roughly 9° on this build and removed by sharing one clock.
At a true bearing of 137° the pairs read τEW = −405 µs and τNS = +378 µs, and atan2 returns 137°. Both delays scale with the speed of sound, so it divides out of the ratio — which is why the design does not claim that temperature compensation improves the bearing. Correcting c changes both axes by the same factor and the angle is unchanged.
A single pair alone cannot do this. It measures one delay, which is consistent with two opposite bearings, and its sensitivity collapses toward endfire.
σθ = στ · (343 m/s ÷ 0.190 m) = στ · 1805 s−1
How an uncertainty in a delay measurement becomes an uncertainty in the bearing.
Differentiating τ = (d/c) cos θ gives dτ/dθ = −(d/c) sin θ. Inverting it gives σθ = στ c / (d |sin θ|), which diverges as the source approaches endfire. That is the rising curve in FIG. 2, and the reason one pair is not enough.
With θ = atan2(τNS, τEW) the two partial derivatives are ∂θ/∂τNS = (cos θ) c/d and ∂θ/∂τEW = −(sin θ) c/d. Combining two equal, independent delay errors, and using cos² θ + sin² θ = 1, collapses the sum to
σθ = στ · c/d — the same value at every bearing
That identity is the whole argument for the cross geometry, and it is why the dashed line in FIG. 2 is flat rather than curved. Whichever axis sits at endfire, the other sits at broadside, and the two errors trade places exactly.
| στ | uncertainty in a delay estimate, in seconds |
|---|---|
| c/d | 1805 s−1 — the conversion from a delay error to an angle |
| σθ | the resulting bearing uncertainty, in radians |
One sample of delay uncertainty is 22.68 µs. Multiplied by 1805 s−1 that is 40.9 mrad, or 2.35°. Interpolating the correlation peak 8× divides the delay step by eight and gives 0.29°.
This is a resolution figure, not an accuracy figure. It assumes the delay grid is the only source of error, and that the two axes are equally and independently uncertain. In a real enclosure, diffraction around the housing, reverberation, microphone mismatch and calibration error all contribute. This prototype has not been field-characterised, so no angular accuracy is claimed anywhere on this page.
Click anywhere in the scene to put an ambulance on the road. Every number below — the four channel delays, the pair delays, the correlation peaks, the bearing — is computed from where you clicked using the geometry above. Nothing is pre-recorded. Each panel states whether it is computed or a stand-in.
Click anywhere in the scene — or use a bearing button.
The array is drawn magnified: the real cross is 190 mm across, the car about 4.5 m. Scene scale is 40 px per metre.
The same burst reaches each microphone at a different instant; the spread is the real delay from your click, at true scale — not exaggerated.
Mel-spaced energy across one analysis window — the features the classifier consumes.
A compact network over mel features returns a siren confidence, which gates whether a warning is raised at all.
Whitening the cross-spectrum to phase alone sharpens the peak at the true delay. Peak positions are exact; the curve shape is a stand-in.
/* get_siren_heading() — as it stands in the public repository */
for (int i = 0; i < samples; i++) {
fl_e += abs(audio_FL[i]); fr_e += abs(audio_FR[i]);
rl_e += abs(audio_RL[i]); rr_e += abs(audio_RR[i]);
}
/* energy to spatial pull */
float raw_x = (float)(-fl_e + fr_e - rl_e + rr_e);
float raw_y = (float)( fl_e + fr_e - rl_e - rr_e);
vector_x = (vector_x * (1.0f - DRIFT_FILTER)) + (raw_x * DRIFT_FILTER);
vector_y = (vector_y * (1.0f - DRIFT_FILTER)) + (raw_y * DRIFT_FILTER);
float final_rad = atan2(vector_x, vector_y);
int final_deg = (int)(final_rad * 57.2958f);
if (final_deg < 0) final_deg += 360;Read this against the section above. The estimator in the public repository combines per-channel energy with atan2 and a drift filter: it does not compute time delays, and the string gcc_phat does not appear anywhere in that tree. Its channels are front–left, front–right, rear–left and rear–right, not the north–east–south–west cross described here. The delay-based path derived on this page is the documented design approach. Which of the two the current build ships should be confirmed before either is stated as fact.
Two interactive pages below run the same interfaces as the hardware. Nothing is a recording and nothing is pre-rendered: press a key and the display responds. Each page opens with a guided tour if you would rather be shown around, and every panel has a short explanation of what it does.
The display the driver looks at, and the product they actually buy.
The unit the emergency vehicle carries, so surrounding cars know it is coming.
Both pages are simulations of the device interfaces, built so the system can be examined without the hardware present. Every function shown is implemented on the bench prototype. Nothing further is claimed: turn by turn navigation, blind spot radar, OBD-II telemetry and speed camera warnings are on the roadmap and are deliberately absent from these pages.
Detection and direction are separated on purpose. The classifier decides whether the window contains a siren at all; only then is correlation spent on finding where it is. That keeps the bearing pipeline off irrelevant audio.
North, south, east and west on a 190 mm cross. Each pair shares one I²S data line by selecting the left or right slot of the stereo frame.
I²S0 (E/W, GPIO 4) is master and generates BCLK 6 and WS 5; I²S1 (N/S, GPIO 14) runs as a slave on those clocks through the GPIO matrix.
44.1 kHz, 32-bit slots, 24-bit microphone data; the correlation pipeline uses the top 16 bits.
An Edge Impulse export with mel-filterbank energy features, trained on real roadside ambulance recordings with traffic, wind and Doppler — not clean online samples.
GCC-PHAT whitens the cross-spectrum so only phase survives, giving a sharp delay peak that tolerates reverberation.
atan2 over the two axes gives the bearing; classifier confidence gates whether a warning is raised at all.
The two pairs never share a controller, so any assumed fixed offset between them is not a real delay. Subtracting one would inject a false delay into an axis, and near broadside the sensitivity is unforgiving. The build measured roughly 9° of bearing error from such a correction and removed it. Two I²S peripherals on one clock domain avoid the problem instead of compensating for it.
Rij(τ) = ∫ Xi(f) Xj*(f)|Xi(f) Xj*(f)| ej2πfτ df
Rij(τ) = ∫ Xi(f) Xj*(f)|Xi(f) Xj*(f)| ej2πfτ df → the lag at the peak of R is the estimate
The relative delay between two channels: correlate them, then find where the correlation peaks.
A plain cross-correlation weights every frequency by how much energy the signal carries there. A siren is loud in a few narrow bands, so its correlation peak is broad and its position is vague. Dividing the cross-spectrum by its own magnitude throws the amplitude away and leaves phase alone, so every frequency contributes equally. The peak becomes sharp and its position becomes a far better estimate of the delay. That division is the phase transform.
The cross-correlation of two signals is the inverse Fourier transform of their cross-spectrum, Xi(f) Xj*(f). Replacing that spectrum by its phase-only version — the spectrum divided by its own magnitude — is what turns ordinary correlation into GCC-PHAT.
| i, j | the two channels of one pair |
|---|---|
| X(f) | discrete Fourier transform of one analysis window |
| * | complex conjugate |
| |·| | magnitude — the quantity being divided out |
| τ | lag, in seconds; the lag at the peak is the answer |
| Rij(τ) | phase-transformed correlation at that lag |
The peak of REW gives τEW, the peak of RNS gives τNS, and those two numbers are the only input to the bearing equation. The lag search spans ±24.43 samples, which is the full 553.9 µs the array can produce, so no real delay falls outside it. Interpolating the peak region 8× makes the delay step 2.835 µs, which the error relation converts to 0.29°.
Dividing by the magnitude amplifies bands that carry almost no signal, so on a quiet or heavily band-limited window this estimator can do worse than plain correlation; practical implementations regularise the denominator or restrict the band. It also returns a delay and nothing else, so it is only worth spending on a window the classifier has already accepted. Status: the estimator in the public repository currently takes direction from per-channel energy with atan2, not from these delay estimates. The GCC-PHAT path is the documented design approach, as noted against the code in the simulator above.
Generalised cross-correlation with phase transform. Dividing by the magnitude discards amplitude and keeps phase, which sharpens the peak at the true delay τ and makes the estimate far less sensitive to reverberation than a plain cross-correlation.
The prototype was not assembled in one go. It ran on breadboards, then moved to a first fabricated board in a printed enclosure, then to the working three-device system. The photographs below are in that order.
An ESP32-S3 devkit on screw-terminal carriers, two I²S microphones pairs wired by hand, and GPIO assignments written on paper because nothing was fixed yet. This is where the four-channel capture was first made to work.
The hand wiring became a fabricated board carrying the same ESP32-S3, and the microphone cross got a printed housing with four ports in the lid. The silkscreen reads SirenSense · Tekkera Electronix · REV 1 · 04/2026.
Fabricated boards from JLCPCB, the roof node's battery protection, the cabin node running its interface with camera and display, and the offline vector map. The cabin UI is shown reporting an emergency vehicle and the direction to expect it.
Status labels are part of the engineering, not marketing. They change only when the corresponding test is complete.
| Four-channel synchronised capture | Implemented, with startup loopback and calibration checks |
|---|---|
| Delay and bearing mathematics | Derived and implemented; the figures on this page are resolution, not measured accuracy |
| TinyML siren classification | Working prototype; dataset expansion ongoing |
| Field bearing accuracy | Not characterised — no single guaranteed number is claimed |
| Urban LoRa range | 4 km design target — not yet field-characterised |
| Weather resistance | IP67 sealing target — not independently certified |
| V16 Pro | A materially more capable evolution of the Spanish DGT V16 beacon concept. Not DGT certified; not a regulatory replacement for a certified V16 device |
What the sections above compress into diagrams, written out: the pin map, the power chain, the cabin split and the transponder. Where a decision has a failure mode, the failure mode is stated with it.
One ESP32-S3 captures all four channels; the array is not split across two controllers. An INMP441 can be told which slot of an I²S stereo frame to drive, so each opposing pair shares one data line, one microphone on the left slot and its opposite on the right.
| East / West | I²S0 master · data GPIO 4 |
|---|---|
| North / South | I²S1 slave · data GPIO 14 |
| Shared clocks | BCLK GPIO 6 · WS GPIO 5 · routed internally through the GPIO matrix |
| Sample format | 44.1 kHz · 32-bit stereo slots · 24-bit microphone data |
| Correlator input | The top 16 bits of each sample |
| Startup check | Loopback and calibration confirm both buses are alive and aligned |
INMP441 E [L] ─┐
INMP441 W [R] ─┴─ DATA4 → I²S0 MASTER ─┐
BCLK6 / WS5
INMP441 N [L] ─┐ │ internal GPIO matrix
INMP441 S [R] ─┴─ DATA14 → I²S1 SLAVE ←┘
The second pair is a slave on clocks the first pair generates, rather than a second independent capture that would have to be aligned afterwards. The reason is in the pipeline section above: a fixed correction between independently clocked pairs is not a real delay, and applying one measured roughly 9° of bearing error on this build.
The classifier and the bearing estimator do different jobs and are not merged. The classifier is an Edge Impulse audio export using mel-filterbank energy features, trained on roadside ambulance recordings that include traffic, wind and Doppler shift rather than clean studio samples. Its confidence decides whether a window contains a siren at all.
Only windows that pass are handed to correlation. That ordering is what keeps the bearing pipeline off irrelevant audio, and it is why the simulator above labels its mel frame and classifier stage as stand-ins: the real model runs on the ESP32-S3 and this page does not pretend to reproduce it. False-positive behaviour on real roads remains an open dataset task, not a finished result.
The roof node keeps a radio, a switching converter and four digital microphones in one small enclosure, so the supply is part of the sensing problem rather than something downstream of it. The chain, in order:
The MT3608 is a boost converter here, not a buck converter: the cell sits below the 5 V rail, so a step-down part would never regulate. And the protected return must come from the BMS P− terminal — taking it from B− bypasses discharge protection and defeats the protection circuit.
The cabin architecture separates time-sensitive I/O from the richer interface. Sensor reads and the radio link stay on a microcontroller; rendering, cameras and the application live on the Pi, and the two talk over a structured UART link.
Keeping the time-sensitive path off a general-purpose operating system is the point of the split: nothing in the alerting chain depends on a desktop scheduler being in a good mood.
A separate demonstrator, carried by the emergency vehicle itself. It broadcasts a compact position message that nearby SirenSense nodes can place on their map, so a warning can name a direction and a distance rather than a bearing alone.
| Controller | ESP32-S3 |
|---|---|
| Radio | SX1278 · 433 MHz LoRa |
| Position | BN-880 GNSS receiver |
| Local interface | OLED status display |
| Packet | AES-128 protected payload |
| Channel access | ALOHA-style jitter, 800 to 1500 ms |
A perfboard demonstration unit has been built and a PCB has been designed. Radio range has not been characterised in a controlled urban field test, so the figure carried in the register above — 4 km design target — not yet field-characterised — is an engineering estimate.
The prototype has no IP certification. V16 Pro is not DGT certified and is not a regulatory replacement for a certified V16 device. No field bearing accuracy is stated, because none has been measured, and the classifier dataset is still growing. Each sentence changes only when the corresponding test is complete, in the register above.
The board layouts, the KiCad captures and the full validation register are on the technical record. Source and documentation: SirenSense and SirenSense V2 on GitHub.