Fire alarm audio detection, using FFTs and Go | Hacker News Reader

Fire alarm audio detection, using FFTs and Go

github.com

62 pointspdubouilh48 comments

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)))

Thanks

It looks like a windowing function. Used to turn continuous data into segments of data for FFT processing. https://en.m.wikipedia.org/wiki/Window_function

From that article, that's the original Hamming windows with a_0 = 0.54 and a_1 = 0.46.

> 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.

This is the kind of discovery that settles all debate in my mind that I could have ever been an electrical engineer, or any kind of mathematician.

This is pretty much how I feel every time delving into FFTs. Like, I get the concept, but something in my brain just shuts off when it comes to actually trying to grok it. I do however very much appreciate those that have created software where I just provide --input and they handle the rest.

I also have trouble wrapping my head around all of this, and complex numbers, for that matter. Never mind that I'm employing this stuff all the time in GNU Radio.

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.

[1]: https://www.fireco.uk/products/sound-activated/dorgard/

Ubiquiti also has a battery powered alarm-sound sensor in their Unifi Protect lineup[1]

> "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...

> it's quite a magic feeling to hear the fire alarm go off and the doors independently close by themselves

Closing doors on a fire alarm seems hilariously cruel.

It prevents the fire from quickly moving through the building...

Also, people.

Yeah, that's a given, but the point of fire doors is to maximize overall survivability instead of the "average doors crossed per minute" stat in isolation.

The doors don't lock, they just close.

In many large buildings (schools, etc. in particular), you want the internal fire doors to close to keep the fire from spreading. Of course, exits must be provided for each isolated section.

These are installed on doors that have an auto-closer anyway. They deter people from propping them open permanently with a wedge or a chair.

You can also enable fire alarm audio detection on iPhones, HomePods and other home smart hubs.

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...

After a few years using Z2M I moved to the native ZHA. It detects devices better in my case.

Device detection is a nightmare in Zigbee, I wish they made it more robust, predictable, ...

The First Alert RM4 is an officially supported first-party product and costs $25. It really ought to work reliably.

you dont need a FFT you can use a Goertzel band pass filter

I was thinking the same.

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

Thanks for this, I'll toy with implementing that instead of a full FFT

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.

This is smart - minut sensors are also doing the same (afaiu).

It is also quite useful to know exactly which alarm triggered. It would seem it is not feasible to have a DIY system to implement this

I didn't click the link yet, but one could easily DIY with a microcontroller at each alarm, picking up the alarm signal in some fashion or another.

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.

yeah using a DSP for this definitely makes more sense - but I'm lacking experience in the field. Same goes for using a discrete band-pass filter. This project is more of an attempt at "how can I build something in 2 hours that works reliably" !

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.

Nice to see that it consumes barely any power. Looks like a fun and useful project!

yes and it's very cool! if you're interested in learning, i'd look into the filtering approach.

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. :)

1W of continuous power consumption is not great. To put it into perspective: that’s 1x24x365Wh, almost 9kWh per year. A kettle (1.8-2kW) can run for 4-5 hours for that amount of energy. If getting a kettle to boiling takes 5 minutes, that’s almost 50-60 kettles. That’s two month of boiling one kettle a day.

Or, at the rate of $0.30/kWh in California for residential use, $2.70/year. Lowering power usage on embedded devices is important when you're producing thousands, but for a hobbyist it doesn't really matter.

Just solder a wire in there somewhere. Even if you knew absolutely nothing about electronics, 50 trial and error solder points sounds like less work.

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 put up two fire alarms, one unmodified and one where you replace the speaker with an Arduino that does whatever you want with the signal. They only cost $10 a piece. Or I guess buy one with wifi or zigbee connectivity, but then you don't have a project anymore.

Yeah, everything that touches them needs to be UL listed. Commercial alarm panels have approved relay modules that can be used to output to various unregulated devices without affecting the electronics inside the panel for this reason. They also use cellular now and have to use a special modem that is UL-listed to connect.

I agree ! But I have a few fire alarms, and 2 water leak alarms, that would be a lot of wires lying around, and this solution is wireless :)

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.

An arduino BLE, 18650 battery will probably run you about 50 bucks (retail, one-off). From experience, that will run for at least 4+ years in low-power mode -- maybe even decades. Announce a BLE service with the alarm status.

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.

> A binary sensor reading the wire going to the speaker isn't some magic modification that invalidates the safety

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.

It'd be even simpler to set up a piezoelectric sensor or a mic right on the device. If the device is vibrating, there's a 99.9% chance its going off.

Reply on news.ycombinator.com