Doorbell, cant emulate

Hello guys, so home playing around with my Flipper. Trying to copy my doorbell.

I have captured the raw signal that it gives out but nothing happens when im sending it out again. See the file, thats the captured signal.The signal does look the same on flipper so I dont think its a rolling code. So maybe im in wrong amplitude, but I tried AM270 and AM650.
Maybe someone has a soloution? Eager to understand
Door.sub (1.7 KB)

1 Like

It would really help if you could post pictures of the door bell and chime units along with their respective FCC IDs (assuming you are in the US, if not post clear pictures of their labels with regulatory information).

That will allow us to start looking into what protocols and frequencies are in play with them to figure out if they are supported. Thanks!

Thank you for the reply. Here one pic of the bell, this is all information I have and im in europe.
I could try to finde some more but then it would help if you could be more specific.

I used a pulse plotter to analyze my raw signal, as litle as I understood, the guess from the site is that the modulation should be PWM with sync/delimiter. I suppose flipper dosen support that or am I out in the sky saying that? couldnt finde it on flipper tho.

I found the device. It’s one of those darned Kinetic powered devices. They tend to be less well supported. Good news is that I’ve never heard of the Kinetic devices having a rolling code.

Long shot. Have you tried teaching the doorbell the raw signal you captured? I’m assuming there is some error in the signal but maybe it’s close enough to be recognized as a different button. That one support four buttons.

1 Like

Well, I didnt even think of that, haha. Now it works after I taught the doorbell the raw signal, but first I made a new capture.
doorbell.sub (723 Bytes)

But then I wounder, why didnt it work when I have the raw signal, the capture should be like a total copy of the signal transmitted from the button, right?

With this said is there any chanse to make it like universal so there is no need to teach it again on a new one of same brand?

My theory is that the Flipper isn’t capturing the signal correctly but it’s very close so it’s recognized enough to be learned. I also suspect there are no universal codes but I can’t find enough documentation to be sure. Those kinetic buttons can come in a lot of different varieties.

1 Like

I think I have the same issue with a similar doorbell (kinetic) on 433.92Mhz
I dig a bit deeper, and it looks like the flipper isn’t capturing the signal correctly.

This is what flipper records in my case:
RAW_Data: 128325 -5760 97 -6480 133 -164 131 -294 99 -952 821 -996 99 -264 465 -100 99 -202 1429 -66 148043 -12240 165 -2024 265 -98 395 -98 359 -164 ...

I then used Hackrf and URH to capture the signal on my laptop. The signal was not very pretty, but URH had no problem demodalting it (ASK):

It was a sequence of long and short pulses (50us and 150us), each 200us apart:

I used that info to manually convert those pulses to flipper format, it looked something like this:
RAW_Data: 50 -150 150 -50 150 -50 50 -150 50 -150 50 -150 50 -150 150 ...
Uploaded to flipper and send it. The doorbell rang every time no problem.

So I guess there’s something wrong with the way the flipper demodulates the signal.


Excellent detective work!

Random thoughts:
Do the dizzy edges and decreasing power confuse some auto-tuning or auto-attenuation stuff in CC?
Can it be a bit off in frequency or bandwidth from ones in Flipper?

1 Like

Thanks to a persistent user in another topic, we have an explanation: Flipper can’t read pulses shorter than 60us, because that’s the period MCU <-> CC1101 communication line is sampled on. Details: Read RAW minimum pulse width? - #8 by nosejam

1 Like

Interesting. I 50 is close to 60… I wonder if the signal would be recognized by the doorbell if we used 60?