Help Grandma Hear Her Doorbell!

[Salome2]

JoeyG: I agree, but to get this project working, I will use the mic I have on hand. I don't have any piezo's.

[ledtester]

Another issue is power consumption and the ideal is the least battery drain, the better.
...

My advice is to first get the detection algorithm working and then worry about power consumption - which is something we definitely can help out with.

[Salome2]

E Z 4 U 2 say.

[Postal2]

I have experience with a deaf grandmother and a doorbell. I used a telephone bell from an ancient telephone in an ebony case with huge bell cups.
Perhaps this knowledge will help you choose the timbre.

[SteveThackery]

Back in the 1980s I designed a device for almost the exact same thing: in my case the detection of a telephone bell.

The exact details escape me, but it was all done without a microcontroller in sight. A crystal microphone was placed near the phone (crystal because they have a usefully high output but are "peaky" in their response, which is ideal for the job).

The microphone signal was amplified and put through a bandpass filter centred around a frequency that was very strong in the bell sound but above normal voice pitch (maybe 1kHz or 2kHz - I can't actually remember).

The next stage was to convert the filtered sound signal into DC. I used the signal to trigger a retriggerable monovibrator of some kind, such that while the bell was ringing it produced a DC output signal, which disappeared almost immediately the bell stopped ringing.

This signal went into a very basic RC integrator, the output of which ramped up over around half a second (I think). After half a second the DC voltage was enough to trigger a 555 timer, set as a monostable which - via a relay - rang the repeater bell. The 555 timer allowed the repeater bell to ring for as long as necessary to get attention.

The bandpass filter stopped the circuit being triggered by normal speech sounds or dog barks. The integrator in the signal path avoided false triggering on very brief, but wideband, sounds such as a clap or a door slam. The bell sound had to be of sufficient volume, in the correct frequency range, and sustained over a minimum period.

The circuit worked perfectly and never suffered a false trigger (that I know of).

[Salome2]

ledtester

At last I've got my old IPhone to transfer files to my PC.
Looking close at the picture attached, you can see that my previous description of the waveform were about as accurate as recent reports of immigrants woking local yokel's dogs.

In this photo, the time/div is 500mS/div and the amplitude is 100mV/div. The IPhone sound playback is low in volume.
I might expect that attaching this same mic to the existing doorbell contraption would produce a much larger mic output but I donno, didn't bring my big scope with me when I recorded the doorbell rings! Might be two pushes or just holding down the outside push-button.

Note the short no-tone silent period between chime bursts.  I think this snapshot shows two outside doorbell pushes. I can't be sure because the cockroach I hired didn't quite follow my requests to ring shouting out the window.

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

My idea was based on sampling the waveform picked up by the mike but the 12-bit ADC of pic16F18456 is not fast enough to do this!

(Should I post this as a new post?

[SiliconWizard]

My idea was based on sampling the waveform picked up by the mike but the 12-bit ADC of pic16F18456 is not fast enough to do this!

According to the datasheet, the ADC of the PIC16F18456 can sample at up to 140 ksps. How can it be not fast enough? Puzzled.

[Salome2]

SiliconWizard, thanks so much for your help.

Here's my under-developed understanding, so far:
 
1)For the ADC to run in sleep mode, ADC Clock must only use slow FRC which results in not the fastest ADC conversion speed possible. The min Tad period is >500nS and the FRC clock period is 1-6 uSec(2-uS ?). An ADC 12-bit conversion takes 25 Tad's or so when including minimal acquisition time.

2)I I may be my wrong about "too slow" when my strategy was to write code to compare  the ADRES to a threshold value indicating a possible start of a bell tone burst. This assumes I can start an ADC cycle at the right time to trap this event.

The optimal goal would be to have three ADC readings around the peak of the waveform such that M1 < M2 >M4 where M1,M2 and M3 are as close together as possible.

3)I am still trying to understand the operation of this complex ADC module, which seems by design to be optimized to precise very slow events most accurately and also allow easy touch-control.

4) I am now aware the ADC CALC feature allows a threshold comparison to set an interrupt if Threshold Upper Level (ADUTH) is compared to an ADC result(but this seems to occur during the PRECHARGE phase of at least a second conversion??).
Perhaps I can manually assert ADRES from the scope display,

5) My idea is to trap the amplitude of a bell tone burst by catching the maxima of the first pulse by ADUTH of a possible tone burst which is always at the beginning of a stream of a 2-mSec continuously repeating pattern, but the maxima of the first pulse transition only lasts at most a few tens of uS but this maxima would be hard to catch with a slow A2D attempting multiple conversions.

From looking carefully at my scope waveform:

Once the magnitude of the very start of the first tone burst pulse is known (at a threshold of ~50mV amplitude), I can see whether I am trapping a burst bell event or just noise by starting a counter that then takes an A2D readings next at the known end of the tone burst(at ~700mSec), and at which point the bell sound waveform is is followed by a 130mSec baseline(no-sound output)level before the next bell tone burst. Always two bell bursts per front button push.

If these events match I can assume an automatic second tone burst must follow and when I repeat this test on the second burst,  know that I can be sure enough that I  have succeeded in trapping a tone-burst event and trigger a remote wireless chime receiver box.

That's my plan..am I barking up the wrong tree?

Perhaps best to use one of the MCU's comparators while MCU is in sleep mode instead to best catch the start of a possible tone burst?

[Gyro]

Are you doing this as an educational / coding exercise?

If not, you simply need to amplify and clip the microphone signal input. You could then just feed it into a GPIO (or ADC if you really prefer) and verify the time between transitions (+/- a few %) with a detection threshold of a however many cycles (you have plenty). You seem to be making heavy weather of it.

[Salome2]

Gyro, thanks for this idea.

No education for me! Ignorance is bliss. I'm doing it all for Granny.

A need to clip the mic signal is something I haven't considered useful. I am interested in ID'ing a valid belltone burst waveform versus just noise pickup and the waveform is a mixture of at least two frequencies with different amplitudes, but would clipping and counting transitions help me  by yielding a consistently singular constant sum of all transitions result over varying battery voltages and mic amplitude?

When you introduce the idea of clipping, then low noise levels will be able to very often trigger a 700 mS count of transitions, and this means a lot of battery use. To compensate for noise sensitivity, I would have to set a threshold for clipping somewhat higher than most noise and this threshold would have to be adj. for mic distance from the intercom to the black box, and also adj. for battery voltage, but this must not result in noise rejection so high as to not always detect a doorbell burst waveform.
 
It would be a circuit design challenge to design a very low power circuit to serve opposing goals of having a  high noise threshold and yet have high amplification necessary to achieve clipping over a range of battery voltages(unless the undesirable adding a micropower comparator chip?) Using an external or a built-in comparator of the MCU would mean the MCU is to be awake to do the data processing.

With my current idea, the first test of ID'ing that fails ends the bell tone event trapping and MCU goes deaf as Granny and beddy-bye again for the CPU for about 700mS. This deaf period still allows a second bell tone burst to be detected after the CPU first having a nap.

[SiliconWizard]

One simple approach would be to just implement a crude envelope detector, threshold the envelope to get the width of the tone bursts and discriminate against just that, without any frequency analysis. The probability that just random noise would  trigger it is pretty low.

[tooki]

This discussion reminds me of a related challenge, namely that of fire alarms for the deaf. Many people simply sleep through flashing light, especially if sleeping face down. (Not to mention the existence of people who are deaf and blind.)

One really interesting solution, which doesn't appear to be available for sale anymore, is the wasabi-based alarm, which sprays wasabi essence into the air. (Our sense of smell is actually disabled while sleeping, so we cannot smell smoke as such. But wasabi is an irritant, and apparently a very effective one.)

https://blog.nms.ac.uk/2018/08/29/why-would-you-want-a-wasabi-fire-alarm/
https://www.popularmechanics.com/technology/a7253/our-favorite-ig-nobel-the-wasabi-fire-alarm/


With that said, bed shakers are a perhaps more sensible soundless alarm for many users. 

[tggzzz]

Use one of these existing commercial devices: https://www.connevans.co.uk/catalogue/215/Doorbells---chimes---wirefree

I used something similar, but used my existing button to power the radio button, which then caused the alerting device to sound and flash. Yes, I did add a couple of wires to my existing button.

[Salome2]

tggzzz, I tried to get cockroaches to shake Granny's bed when the doorbell rings, but as hardworking as they are, it does no good when she is in the TV room napping. She would go postal over a wasbi solution! I would get my head handed to me if I tried wasabi spray..Granny, like a lot of  Scandinavians, don't like any hot sauce!

Silicon Wizard, After reading the specsheet for hours, I am just now getting to try getting some of the PIC16F18456 peripherals to work.

I will try to make an envelope detector, but right now, I am relaxing at bit after so much study of the specsheet and I am sitting on the front steps waiting for the mailman to come by to give me a few hints.

[Bryn]

What's this talk about cockroaches all of a sudden? Yes, I saw one nonsensical post about it and I'm surprised it had caught on... and I'm as equally surprised that the OP went along with it

Anyway, good luck with making the new doorbell for her. I'm sure she'll appreciate it in the long run

[tggzzz]

tggzzz, I tried to get cockroaches to shake Granny's bed when the doorbell rings as hardworking as they are, it does no good when she is in the TV room napping. She would go postal over a wasbi solution! I would get my head handed to me if I tried wasabi spray..Granny, like a lot of  Scandinavians, don't like any hot sauce!

OK; you're a troll.

Anybody with a tiny bit of imagination would think of either getting one for each room or moving one between two rooms.

[Salome2]

The problem with some of you guys..no sense of humor!

I am trying to get the PIC16F18456 comparator to function as I would want to catch the peak amplitude from the amplified mike to trigger the PIC16F18456 comparator, but so far no luck.  I connect the comparator minus input to FVR Buffer set at 2.048V and feed the amplified VCol DC coupled output of the mike amp directly to the comparator + input, but when I feed the +  input with a 1.5V Peak signal, nothing happens. Only if I bang the small mike with my finger tip nail do I see a comparator spike from 0 to Vdd.

I have a 200K pot connected from ground to the base of the 1-transistor pre-amp and have set VCol at 1.8V quiescent, so I would expect a 1.5V swing to trigger(which I cansee clearly on the scope) the comparator when the inv. input is held at 2.048V by the FVR.
The Vcol swing should certainly trigger the comparator. I have verified the waveform to be as described at AN3 comp + input.

I am monitoring the comp 1 output mapped to RC5 TRISC5=0  ANSEL5=0 so  RA5 is set as a digital output.
Here's my setup so far!
//Note. Normal MCU PIC16F18456(no sleep, etc) operation with Fosc=16MHz VBat=4.2V. MCU Vdd=VBat
//-----------------------------
void init_Cmp1(void)
{
  FVREN=1;           //Enable FVR
  CDAFVR1=2;         //FVR=2.048V to comparator
  CM1CON0bits.EN=1;  //Enables Comparator 1
  CM1NCHbits.NCH=6;  //Comp Neg Inp connects to FVR Buffer 2
  CM1PCHbits.PCH=1;  //Comp Pos Inp connects to CM1IN1+ AN3
  CM1CON0bits.POL=0; //If C1VP>C1VN the output=1
  CM1CON0bits.OUT=0; //Noninverted polarity
  CM1CON0bits.HYS=1; //25mV hysteresis
  CM1CON1bits.INTP=1;//Interrupt triggered by 0-->1
  C1IE=0;            //Disable Comparator 1 Int
  TRISA3=1;          //Comparator + input connected to RA3/AN3
  ANSA3=1;
  RC5PPS=0x11;       //Comparator 1 output mapped to RC5
}
//---------------
If I connect the cmp neg inp to an external pin and adj. this pin voltage with a pot adj. over 0-5V, I can find a cmp Vneg inp ~<2V setting that works!

Something is wrong with the FVR or connecting the cmp Neg Inp to FVR,
I checked my settings several times against as shown above, but cannot find anything wrong! 

Can anyone tell me what's nfg with using the FVR?

Note: I realize you would find it much more easy to help me if you had the 16F18456 specsheet, but its 9-meg!..too big to attach!

[Salome2]

 tggzzz

I have already installed(put on a table in the bedroom and kitchen) wireless doorchime receivers and of course, they work perfect when I manually push the wireless hand switch..but the  point is, the whole idea is get my black box MCU gizmo to detect the existing doorbell sound and trigger the hand button doorchime switch using an optocoupler when it detects a doorbell ring.

[SiliconWizard]

I will try to make an envelope detector, but right now, I am relaxing at bit after so much study of the specsheet and I am sitting on the front steps waiting for the mailman to come by to give me a few hints.

 

[SiliconWizard]

I connect the comparator minus input to FVR Buffer set at 2.048V and feed the amplified VCol DC coupled output of the mike amp directly to the comparator + input, but when I feed the +  input with a 1.5V Peak signal, nothing happens. Only if I bang the small mike with my finger tip nail do I see a comparator spike from 0 to Vdd.

Sorry if I'm missing something here as I haven't looked at the datasheet in details, but if you set the threshold to 2.048V (- input), how can the comparator trigger with a 1.5V peak signal (+ input)?

[Salome2]

SiliconWizard, Thanks for appreciating my sense of humor!

The output of the mic 1-transistor amp is direct coupled to the Cmp Neg Inp so the 1.5V P-P max signal  has a d.c. baseline  that can be set from 0 to Vbat and presently set at the transistor's collector V  of ~1.8V. 

[SiliconWizard]

Ok then.

I had to take a more detailed look at the datasheet for the register definitions and take a guess from your posted code and the way Microchip usually defines registers in their header files.

So, my best guess at this point is with the initialization of the FVR buffer. First two lines:

Code: [Select]

FVREN=1;           //Enable FVR
CDAFVR1=2;         //FVR=2.048V to comparator
Microchip has those confusing definitions (and multiple ways of accessing register fields, probably for legacy reasons). I recommend using a consistent way of accessing those bit fields - will make your life easier and avoid some mistakes. But I'm guessing that you may have found this excerpt above in some example code.

My suggestion is to change the two above lines to:

Code: [Select]

FVRCONbits.CDAFVR = 2;
FVRCONbits.FVREN = 1;
(hopefully those are correct - I don't have the compiler installed or at least the support header files for this MCU, so if that doesn't compile, you'll probably figure it out easily. For instance, if the 'FVREN' field does not exist, try just 'EN' instead.)

The most probable reason this would work, but not your 2 lines above, is with the "CDAFVR1=2;" line. From what I get (from usual Microchip "legacy" stuff), CDAFVR1 is (again, most likely, but not 100% sure) bit 1 of the CDAFVR field of the FVRCON register, and not the whole CDAFVR[1:0] field (there must be a definition for CDAFVR0, which will confirm that). So if you assign 2 to it, it's the same as assigning 0 to bit 1 (2 = 0 mod 2). And that's the same as having CDAFVR[1:0] = 00 (as I suppose the reset value of bit 0 is also 0), which is "buffer off".

And, I prefer enabling the FVR after setting the gain, but that wouldn't change much in practice.