merbanan
Support for EMOS doorbell (similar to EV1527)
I have purchased a EMOS doorbell which transmits on 433mhz using chip cmt2150L. From what I read, it should be very similar to EV1527. I'm able to receive something quite consistent using following slicer arguments: -X "n=EMOS_doorbell,m=OOK_PWM,s=60,l=272,y=672,g=132,r=1500,bits>=4,bits<=4,get=@0:{24}:id,unique"
But I'm not really sure if I'm getting a real id or something else. And the repeatability is questionable. I'm attaching few received signals.
S/N of the device is: 441539 emos-doorbell_signals.zip
It looks like each instance is 3 packets: a single pulse then a wider timing (60/260 µs pulses + 140 µs gap) then 1.5 ms pause and a narrower timing (50/150 µs pulses + 150/50 µs gaps), then ~200 ms pause and maybe the second packet again.
Hard to make out as the signal is directly on 433.92M. Try to record again on 433.85M and maybe try more distance to prevent some clipping (signal is too "loud").
I recorded it again with RTL-SDR stick on 433.85M further away. And on hackrf on 434mhz, it's repeatable, the chimes are reacting in hackrf replay. Both captures are attached.
hackrf_capture rtl433_captures.zip
It's easier to see now that the signal is just plain 50/150 µs OOK (with fixed symbol length, i.e. 150/50 µs gaps) of 24/25 bits (just like EV1527). It's repeated ~2,5 times.
Somehow rtl_433 has trouble properly demodulating the OOK at 250k sample rate. The other recording (name it BBD_0002_433.85M_1000k.cs16 to properly view it on https://triq.org/pdv3/) works well with:
rtl_433 -Y autolevel -M level -M noise -R 0 -X 'n=name,m=OOK_PWM,s=50,l=150,g=200,r=9000,bits>=24'
The code is {25}88eaae8 or more likely 88eaae as the last bit is sync.
Try -s 1024k for the RTL-SDR, it should work then.
the problem with ev1527 devices - there is no checksum test, just a couple of repeats. so u get a lot of false positives.
try rtl_433 -y {25}88eaae8
4 decoder for the same data..
but u can take one of them, change the timing as Christian stated s:50, l:150, g:200, r:9000 and compile it. i made a ev157 decoder for a 18btn switch, works really good. take this and build your own decoder. good luck..
WHere are we? We're not going to have open issues forever so people can read through lots of text and maybe find a zip. If there is a useful flex decoder there should be a PR to add it to some directory of (commented) examples.
Let's close this as it was about a bad signal not the decoder as such. Feedback or a documented decoder welcome still.