Help Grandma Hear Her Doorbell!

[Salome2]

Please give me your ideas on how you experts would solve this problem.
  I am getting stuck on how to recognize the doorbell waveform to ring an extended doorchime.

(Should I post this as a new post?
-------------------------------------------------------------------------------------------

Granny is nearing 87 and  nearly deaf as a loaf of bread.

Her helper persons arrive at her apt building but often cannot get in because Granny can't hear the existing doorbell or even her Smartphone. She can't sleep with  her hearing aid on and often struggles to get them properly on her ears!

Her doorbell works 100%, it is  part of an intercom in the corridor of her apt, about 30-feet from her bedroom door, 70-ft to the kitchen. I would not like to try to mount the new doorbell ringer switch outside at the doorbell panel or tamper with in anyway the existing intercom/doorbell.

So I bought a much louder wireless door chime that works well, Granny says she can hear it well when it is placed next to her bed or even in the kitchen. It's even loud enough there for her to hear with the radio on.
Now, all I need to do is detect the old doorbell ring to ring the new extended distance door chime.

To do this, I need to build a circuit use as little power as possible to continuously monitor and detect a doorbell ring by using a small electrolet mic that will be glued to the doorbell/intercom near the front door of her apt.

I recorded the existing doorbell chime on my IPhone and played the sound back to the electrolet mic and got a good scope picture of the doorbell chime waveform.

I chose a PIC16F18456 chip to detect the doorbell sound signature because I have it on hand. This chip can run its 12-bit A2D peripheral while in sleep mode and the ADC has threshold detection to trigger an interrupt to awaken the MCU up at a set threshold value.

The idea here is to use the least amount of battery power possible, so that it would take many months to a year or so to replace/recharge the battery powering my design.

The electrolet mic uses only 133uA and the A2D by itself only uses 160uA running in MCU sleep mode.
I can use, for instance any small footprint battery, but I do have a 23A 9-V Lithium Roundcell 300mAH and also a 3.7V 2200mAH flat SmartPhone battery also on hand.

What I see viewing the chime waveform at the mic output:

Doorbell tones are bursts of a cone-shaped waveform showing a distinct chain of a 2-mSec period waveform, its highest amplitude peaks every 2-mSec (even with an async 4-th harmonic mixed in) to make a chime sound. Its just a continuous distorted 2-mSec sinewave.

The ring waveform chime is a continuous stream of a repeating 2-mSec waveform that slowly decays in amplitude until the 1/2 amplitude point is reached in about 1.8-Secs followed by a 300mS pause.

Two doorbell tones each button-press. Holding down the front door button keeps repeating the doorbell signal.

What can I write in embedded C code to accurately detect only the original ringtone without false triggering or missing any doorbell ring? With the lowest power used?

[shabaz]

Hi,

Personally I would not even bother with a microcontroller.
I'd consider (say) a BJT amplifier for the electret mic, followed by an integrator (could even be as simple as a diode rectifier and a capacitor with resistor across it), or use a low-power dual op-amp for it all perhaps. And a CMOS Schmitt trigger gate.

The above would be aimed at just detecting any loud noise that lasts long enough for the Schmitt trigger to fire. If the mic is placed very close to the existing chime speaker (could experiment with a tube or something around the mic), then that should be the loudest sound picked up anyway.

[AVI-crak]

An anecdote from childhood:
Petyka asks Vasily Ivanovich for money for experiments. Three days later, Vasily Ivanovich finds him drunk in the barn, a notebook with notes lying next to him:
“Experience one: take a cockroach, tear off two legs, whistle, the cockroach runs away.
Experience two: take a cockroach, tear off four legs, whistle, the cockroach runs away.
Experience three: tear off all the legs of the cockroach, whistle, the cockroach in place.
Conclusion: a cockroach without legs cannot hear.

[SiliconWizard]

An anecdote from childhood:
Petyka asks Vasily Ivanovich for money for experiments. Three days later, Vasily Ivanovich finds him drunk in the barn, a notebook with notes lying next to him:
“Experience one: take a cockroach, tear off two legs, whistle, the cockroach runs away.
Experience two: take a cockroach, tear off four legs, whistle, the cockroach runs away.
Experience three: tear off all the legs of the cockroach, whistle, the cockroach in place.
Conclusion: a cockroach without legs cannot hear.

Sounds like half of current scientific publication.

[Salome2]

Tovarishch AVI-crak, Is cockroach Ukraine?   

Shabas..is your circuit for detecting cockroach also?

Your approach is maybe a possible solution, and my comment is not to offend you, but to add some humor.

Your circuit probably has many uses and it lacks power usage calculation and circuit detail, and the devil is in the details. I think a MCU-based solution is viable and can be precisely tuned to detect the first bell ring. From what I guess, the simpler no-MCU approach would require tuning.

I would have to hire a cockroach to go down and keep pressing the bell button to best test and tune your idea to work without fail.     

[shabaz]

@Salome2 How is that helpful? I suggest you delete your comment.

[shabaz]

:-[Tovarishch AVI-crak
Is cockroach Ukraine?   

Shabas..is your circuit for detecting cockroach?

Reported.

[Benta]

@Salome2, why make the doorbell louder?
A standard solution for hearing-impaired people is a Flasher, which is easily installed.
In fact, you'll probably get it installed for free, if you file a request at the council (or wherever in Sweden).

[Benta]

@Salome2 How is that helpful? I suggest you delete your comment.

I have to agree. First Salome2 asks a question, shabaz gives a serious answer, then a russian troll jumps in and Salome2 plays along.

Very strange behaviour indeed. Røvsvenskere!

[Salome2]

Benta, Thank you for reminding me about my Troll Subsestence but I enjoyed the Russian tease! I deserve it! I enjoyed it!

Your light solution, this may be a solution, this idea is certainly a flash in the pan, but a flasher cannot be seen by a sleeping person or while in another room.

Grandma is prone to be napping in the morning if she is forced to wake up. She usually only begins her day after 1:30 pm when she usually goes to bed by 10 pm.

Unfortunately, she is very traumatized by having to be awake so early in the morning and she has trouble trying to staying awake to welcome her helper people who by their job schedule will choose to call on her at 8-am or even at 11-am ..so she often falls back to sleep. She is a light-enough napper to be easily awoken by a loud doorbell chime ring.

Asking the commune to help with a flasher or any other special help can take months for someone to remedy a problem.

[Benta]

In that case, why not a wrist/ankle vibrator? (Smartwatch, perhaps?)
There are so many possibilities out there apart from just turning up the volume.

[tggzzz]

It might be useful to consider another "use case": granny can't get to the door because of any/all of being too slow, has fallen, has pressed an "emergency assistance" pendant.

In the UK I believe this particular device has no insurance implications, since it is regarded as being as good as the traditional Yale door lock
https://keysafe.co.uk/products/supra-c500-pro-key-safe

[Salome2]

 tggzzz, this is not about my inquiry here. Me and Granny have made up our minds on what to do. Don't confuse us with facts.

Benta, thanks again for your advice.

 The idea about an enhanced doorbell hack to solve this problem works best because it is non-intrusive. It doesn't require Granny to wear an arm or ankle bracelet to bed like she was a closely monitored parolee. My solution should be quickly realized without more research, while a Commune solution may take weeks to months to send someone to try to solve this problem in a way that is  not at all acceptable to Granny.

With my idea, Granny  doesn't have to remember to place or wear any device. This idea will not work for her. She suffers from poor cognitive capability associated with her age and has trouble now understanding how even very simple things work and also she has trouble remembering things. I have spent hundreds of hours showing her how to do things and she now cannot remember anything or even me showing her how to do things.

She would easily fall asleep and forget to have her head turned(like if she was lying down in bed or fell asleep at a table) to always face a flashing light while she sleeps.

Other solutions, like "Key Safe" require every helper person to have an additional special gadget and this is problematical with her and some of her helper persons. She has a pill-lady to make sure her pills are arranged in labeled boxes. She has a cleaning lady to help her with cleaning. She has a shopping assistant lady that helps her order food and sundries once a week. She has food deliveries once a week.

Even if each helper person had their own key to open the front door and the door of her apartment, they would like to know that  when they climb up five flights of stairs that someone is home when they have to break in her apt.

I have successfully already tried the extended loud chime alarm solution with her and she is very picky, but likes this idea, she easily notices it.
This is what works for her to allow her to hear doorbell rings.

This idea is not a practical design in production product development, it is just a one-off solution to help Granny.

It is certainly overkill for a MCU to be used in this way, and while this problem can be solved with many other alternative solutions, this is not what I am posting about.

I am asking for help about solving this doorbell problem  using a MCU, not soliciting what would seem as more attractive solutions, nor I do not want to discuss the aptness of finding alternative commercially and economic alternatives.

Me and Granny have already made up our minds that my idea works!

Please, i am just interested in figuring out how to recognize the existing doorbell ringing by writing code to precisely and with the lowest power usage, reliably extend her doorbell's range.

[SiliconWizard]

So the core of the matter is to develop sound recognition for the particular sound of the existing door bell, while preferably be as immune as possible to any other kind of sound, I suppose.

There are several ways of tackling this, one would be to start with the recognition problem using a PC and develop this on PC. Make several recordings of the door bell and analyze them with Python or your prefered language, then see how you can adapt this to a MCU (so it would have to be relatively simple). Use simple DSP algorithms.

One other approach, even if possibly overkill (or not?) could be to use some MCU able to run Tensorflow, and generate a model for recognizing this particular sound. That seems doable, but if you're not familiar with Tensorflow, there'll be some learning curve. Benefit, it can be called "AI" and will teach you some of that, if you're not familiar yet.

Another option would be to consider one of those "voice recognition" ICs, which may work well enough for recognizing some other sounds, like this: https://www.wtsoundic.com/voice-recognition-ic/

Although, the simplest approach is probably to detect activity of the door bell by placing a device nearby (doesn't need to be connected to it) that would sense some EMI that is probably emitted by it when it rings.
You could start by experimenting to see if it's workable: place some coil nearby the door bell unit, connect it to a scope, make the door bell ring and see if you can detect something useful. If so, you can then design some conditioning amplifier and link that to a MCU, if you want flexibility, or it could just trigger some other device that produces a loud sound, or flashes of light, or something.

Hope there's an idea that may help.

[Salome2]

SiliconWizard..Thanks a million for responding to my posted topic!
The original ringer is part of an intercom/doorbell/headset/door-opening solution inside and near Gramma's apt front door.
It creates the doorbell ring using the loudspeaker within..no EMI.

I have no experience with Tensorflow and no experience with AI. I have tried to understand the advanced post-calculus concept of tensors, without any success!

However, I have already found a way to pick up the existing doorbell ringing sound using a small electrolet mic and it works well to output about .5 to 1V P-P signal ready to be precisely detected by a nearby black box that has the battery powered MCU that is wired to the new doorchime hand dongle switch to trigger the new very loud door chime at a great distance from the door. I have already posted a description of the old alarm sound waveform.

Besides, my goal to have the lowest power consumption to achieve long battery operation would not be possible at this day and age to use AI to solve this problem. Most importantly, AI would require much more battery power. The 16F18456 chip I found to use doesn't even have a built-in hardware multiplier.

Are we adding overkill to overkill?

I do have many years of playing around with C to write embedded code to do various things. Any idea of using AI would require me to study for mths to become a beginner having any ability to use this knowledge.

By that time, Granny may have shuffled off her mortal coil..so to speak.

[ledtester]

A couple of ideas...

1. Perhaps use a piezo as the microphone. If it is in contact with the bell or the bell enclosure it might better discriminate the bell versus other noises.

2. To conserve even more power maybe put the MCU into deep sleep and have it wake up with a circuit like this:

http://www.discovercircuits.com/DJ-Circuits/hourmeter.htm

A CMOS gate requires just a few microamps to operate.

[Salome2]

ledtester, I already have an electrolet 1/2-in diam mic that works well to pick up the original doorbell sound.
I don't need to try to find and mount a piezo device.

The 16F18456 I  have in stock sleeps in extremely low power mode, while its 12-bit ADC peripheral can stay alive and the ADC module allows continuous ADC operation and has a threshold determined interrupt to wake up the rest of the MCU.

[ledtester]

I'm just throwing out some other ideas. Piezo disks are very commonplace -- almost anything that makes a beep these days does so with them, e.g. kitchen timers, electronic wristwatches, smoke detectors, window alarms, ...

My understanding is that piezo disks are much more sensitive to vibrations transmitted by physically touching the vibrating body than via through the air. It might be possible for you to detect the bell ringing by simply seeing if the vibration detector circuit I linked to above is triggered for more than a certain length of time. Vibrations from the floor and walls will reach the piezo but they will probably not be as intense or as long as the what the bell produces.

As for going the DSP route, perhaps you could identify salient frequencies in the bell's sound and use the techniques in this post to detect them:

https://www.eevblog.com/forum/rf-microwave/looking-for-a-receiver-for-5-khz/msg5501425/#msg5501425

[Halcyon]

:-[Tovarishch AVI-crak
Is cockroach Ukraine?   

Shabas..is your circuit for detecting cockroach?

Reported.

I don't understand the issue?

[wofritz]

I use the attached simple circuit to connect a cheap wireless door bell to my existing old fashion 8V AC door bell.

[Salome2]

wofritz, Thank you. your idea is simple, fully meets the requirement for an intrusive wiring way to solve this problem if I was dealing with a legacy wall AC powered HV doorbell circuit. This certainly not the case with me.

But as I mentioned in my post, I don't want to have to take a risk in dissembling the intercom/bell/door-opener Sw/Handset device and play around with the wiring within.

So, this leaves me with a solution involving a small mic to be adhesively attached to the intercom etc box and already I can see this idea works fine.

The problem then only remains to pgm the MCU to precisely and accurately detect the original working first bell ring audio signal without failure.

[SiliconWizard]

To be fair, if your microphone is right against the intercom box,the sound it'll pick up from the door bell should be much, much higher in amplitude than anything else. So simple thresholding of the RMS value (can be just a simple average of the rectified signal here) may be perfectly fine.

But as it probably produces specific frequencies, further analyzing the signal to make reasonably sure it's the door bell can be added to the thresholding.
If you use a not-too-competent MCU, rather than using a full FFT, you can use the Goertzel algorithm to detect one or two frequencies of interest to discriminate the signal with a pretty reasonable accuracy. It's lightweight.

https://en.wikipedia.org/wiki/Goertzel_algorithm

[vk2jdh]

This is the simplest solution , no processor needed, comes in a kit.

https://learn.sparkfun.com/tutorials/sound-detector-hookup-guide

[Salome2]

SiliconWizard, using FFT or Goertz algorithms seem horribly too complex for me. I ain't that smart!
Horribly too complex for me. I ain't that smart as far as I can C!

I will try My Bubba's Method instead.
------------------------------
vk2jdh: About the recommended soundboard, Sparkfun says:

We do not currently have an estimate of when this product will be back in stock. Notify Me
Note: If this item is available for backorder it is subject to price changes at any time; additionally, we are unable to guarantee time frame for shipping or availability.

Grammy can't wait!

Another issue is power consumption and the ideal is the least battery drain, the better. No mention of current use for this board is given.

My ideas so far is to simply measure the raw waveform to identify a chime sound as different from voices or other noises.
If I use AC coupling to directly feed an 12-bit ADC input on the 16F18456 if I could try to set the built-in ADC threshold interrupt feature to trigger at least 50 mV above this baseline.

Almost all of the time the MCU is in deep sleep mode consuming only a few uA until a threshold in signal amplitude is reached.

The ADC module in continuous run mode awakes the MCU by the built-in ADC threshold interrupt feature.

This means the MCU uses only about 160uA until an ADC threshold interrupt signaled by any sound exceeding 200mV awakes the MCU to begin further analysis of the incoming waveform.

If I take the continuously running ADC to detect the start of a doorbell ring signal, then I can start a MCU counter to delay until the expected end of the tone burst and then I can take several time spaced ADC readings to verify that  the output expected amplitude falls back again to around 30mV P-P(the noise floor) for the next 120mS or so.

The period of  a doorbell burst must match  the measured period seen on the scope. If this match is detected, then the MCU will trigger the new chime dongle hand switch to achieve several time-spaced simulated presses using an optocoupler and then the new chime will be heard and Grammy will answer the door. The MCU should trigger the chime signal perhaps up to 3 to 4 times to make sure Granny hears it.

I could go further, and after detecting a candidate signal, measure zero-crossing of the mic signal to detect the number of 2-mS intervals between peaks and  look for a majority of 2-mS intervals (versus non 2-mS periods) between baseline biased level zero-crossings.

The programming problem right now is learning how to turn off everything to get the MCU to only activate the ADC module in deep sleep and  how to again awaken the MCU when a threshold ADC interrupt starts the apple cart rolling again.
There are so many registers to set!

Must also decide what is the optimal Fosc to use for the least battery use and how to deal with using a possible 4.2V li-Ion as an unregulated power source and yet have a consistent reference for the ADC module without the battery use  penalty of using a LDO 3.3V regulator as the ADC positive reference. The MCU FVR might be a solution here at 1.024 or 2.048-V.

[JoeyG]

[Piezo+high impedance threshold+mcu GPIO wakeup]  would probably have much less current than [microphone + analog circuit + mcu ADC]

Both still connect to mcu  but analog  circuits tend to  have much more current draw overall.

Just my 2 cents worth