I took a look at the source, as I was curious about how does one perform a FFT of a signal, but stumbled upon this. Could somebody explain to me what this calculation does? (in is the audio signal, if I'm not wrong)
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)))
There's a physical product that implements the same idea [1]. I'm not sure how it actually works (presumably there's a patent somewhere, is there an alternative solution?) but it's quite a magic feeling to hear the fire alarm go off and the doors independently close by themselves. If you're in a building that uses these, you can test yourself by playing a recorded fire alarm sound - they work on quite a few different ones (and it really doesn't have to be that loud!). They also have a surprisingly long battery life, ~10 years I think so the detection mustn't take much power at all.
Is there sample audio of the fire alarm, when it is activated? Is this alarms to US standards ? It seems so,
It seems different countries have some different requirements for this audio sound? ...... There is also commercial fire alarms and residential smoke alarms. which in my country have different signals ( if my recollection is corrct )
There's an audio file in the repo to simulate an alarm (works for 3 different models bought in Germany, they all sound the same).
You can pass the target frequency, beep-length and audio threshold as parameters in the CLI (you can estimate these params with audacity).
Funny, I was just thinking about building something like this since I bought a z-wave smoke alarm listener and it does not work with my first alert system and it really annoys me. It can't be that hard, right? Even something that just detects extremely loud sounds would be useful despite false positives
I was in a similar situation, and it turns out that setting up new zigbee devices with zigbee2mqtt and a frontend was more work than just detecting the sound pattern with a few lines of Go ! Plus the fire-alarms are compulsory and already installed and managed by my building...
"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.
100% great suggestion. I found this solution the hard way, by hand, on paper, a few weeks before learning this algorithm already existed. Reminded me that a large percentage of efficient engineering is just knowing what tools you have available off the shelf.
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.
My Wyze cam does this with the included functionality. I get a text/notification when it detects the alarm. However, it does get fooled by certain sounds from the TV.
Regular interlinked alarms don't really allow this, since if one triggers they all alert.
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).
bandpass filtering in the time domain seems like it may be more efficient for this use case to me. if i'm reading the code correctly, it seems it's computing a 512 point window and fft on every non-overlapping window.
i guess it depends on what vector/matrix instructions are being used in the underlying implementations.
I'm also curious about the power draw of continuously executing FFTs on a rpi.
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.
These projects exist because modding life-critical safety equipment is usually not the best idea. You invalidate the testing originally put into the product, and it may fail when you most need it.
Then what? Run 50-200 feet of wire back to an Arduino? Or buy an Arduino and provision it for every smoke detector in the house? How do you power them? Another wall wart?
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.
Agreed, I have no idea what the sibling comments are on about with safety. A binary sensor reading the wire going to the speaker isn't some magic modification that invalidates the safety and you can get teeny tiny sensors with zigbee off the shelf.
severino|1 year ago
geolqued|1 year ago
bearbin|1 year ago
[1]: https://www.fireco.uk/products/sound-activated/dorgard/
paranoidrobot|1 year ago
> "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...
treflop|1 year ago
msla|1 year ago
Closing doors on a fire alarm seems hilariously cruel.
asdefghyk|1 year ago
pdubouilh|1 year ago
yesimahuman|1 year ago
pdubouilh|1 year ago
amluto|1 year ago
xchip|1 year ago
qwertox|1 year ago
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.
[0] https://en.wikipedia.org/wiki/Goertzel_algorithm
Prcmaker|1 year ago
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.
animex|1 year ago
pdubouilh|1 year ago
asdefghyk|1 year ago
gregmac|1 year ago
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).
doubleg72|1 year ago
a-dub|1 year ago
i guess it depends on what vector/matrix instructions are being used in the underlying implementations.
KeplerBoy|1 year ago
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.
beefnugs|1 year ago
ashleyn|1 year ago
gosub100|1 year ago
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.
Spivak|1 year ago
withinboredom|1 year ago
pdubouilh|1 year ago
unknown|1 year ago
[deleted]