Fire alarm audio detection, using FFTs and Go(github.com) |
Fire alarm audio detection, using FFTs and Go(github.com) |
window := make([]float64, len(in))
for i, x := range in {
window[i] = float64(x) * (0.54 - 0.46*math.Cos(2*math.Pi*float64(i)/float64(len(in)-1)))
> Setting a_0 to approximately 0.54, or more precisely 25/46, produces the Hamming window, proposed by Richard W. Hamming. That choice places a zero-crossing at frequency 5π/(N − 1), which cancels the first sidelobe of the Hann window, giving it a height of about one-fifth that of the Hann window. The Hamming window is often called the Hamming blip when used for pulse shaping.
[1]: https://www.fireco.uk/products/sound-activated/dorgard/
> "Based on UL217 and UL2034 alarm patterns."
UL217 is apparently for smoke alarms, UL2034 is apparently for CO alarms.
https://store.ui.com/us/en/collections/unifi-camera-security...
Closing doors on a fire alarm seems hilariously cruel.
Device detection is a nightmare in Zigbee, I wish they made it more robust, predictable, ...
From Wikipedia:
"The Goertzel algorithm is a technique in digital signal processing (DSP) for efficient evaluation of the individual terms of the discrete Fourier transform (DFT). It is useful in certain practical applications, such as recognition of dual-tone multi-frequency signaling (DTMF) tones produced by the push buttons of the keypad of a traditional analog telephone. The algorithm was first described by Gerald Goertzel in 1958." [0]
It's also a nice project for an ESP32 with a MEMS microphone.
The algorithm I figured out was mostly equivalent, though about 3x slower than implementing Goertzel. In my use case, it was already a win hitting the product requirements, but implementing Goertzel allowed background functionality to operate better while capturing data.
You could potentially do this with "smart" alarms, or a traditional alarm system like DSC with each detector on its own zone (the main alarm siren sounds rather than all the individual units). I'm not sure how or if this complies with current building codes though, which I believe require an audible alarm in every bedroom (which normally means an interlinked unit in every room).
i guess it depends on what vector/matrix instructions are being used in the underlying implementations.
Seems like the kind of task where one could easily burn 10 watts, if the wrong FFT Implementation is chosen. You'd absolutely want to do this in DSP hardware.
For reference, it eats ~25% of the available CPU resources on my rpi zero 2w - which draws a maximum of 350mA, so this implementation definitely draws less than 1 watt.
If audio fingerprinting can identify Miley Cyrus in background noise in a crowded bar, certainly it can identify the symmetrical piercing monotone of an alarm.
That’s where you have to be careful about what you’re calling “safety”. There’s “does this, even a little bit, make it less likely that my fire alarm will go off at the appropriate time?” and there’s “will this modification invalidate the UL certification of the fire alarm?”
If reasonably designed (e.g. not low impedance) you could pretty readily conclude that the answer to the first question is No. However… the answer to the second question is almost certainly Yes, which can transition from irrelevant to “a very big deal” if there’s an incident that gets fire marshals and insurance companies doing an investigation.
maybe could try pyfda and the filtering functions in scipy.signal to start playing around.
or if you have access to matlab it has some really excellent filter design tools.
regarding the hardware/dsp: many cpus include simd instructions these days, which basically are an interface to a hidden digital signal coprocessor. :)