Feature Request Emos E8737

[zenguru84]

Hello everyone!

I have a bunch of Emos E8737 and I decided to give rtl_433 a try, but it seems this kind of sensor desn't use any of rtl_433 protocols.

Sensor and receiver link: https://www.sportsrybareni.cz/eshop/lcd-meteostanice-e8737/p-4013083.xhtml

My setup:
rpi 4 with ubuntu 22.04
hackrf one with not a great antenna

I have tried to decode the sensor myself. This is what I did:

rtl_433 -d driver=hackrf -R 0 -A
returns:

Analyzing pulses...
Total count: 265, width: 1107.03 ms (276758 S)
Pulse width distribution:
[ 0] count: 265, width: 552 us [548;560] ( 138 S)
Gap width distribution:
[ 0] count: 12, width: 8932 us [8912;9048] (2233 S)
[ 1] count: 126, width: 2252 us [2232;2316] ( 563 S)
[ 2] count: 126, width: 4512 us [4492;4632] (1128 S)
Pulse period distribution:
[ 0] count: 12, width: 9484 us [9468;9600] (2371 S)
[ 1] count: 126, width: 2808 us [2788;2872] ( 702 S)
[ 2] count: 126, width: 5068 us [5044;5188] (1267 S)
Pulse timing distribution:
[ 0] count: 265, width: 552 us [548;560] ( 138 S)
[ 1] count: 13, width: 9012 us [8912;10004] (2253 S)
[ 2] count: 126, width: 2252 us [2232;2316] ( 563 S)
[ 3] count: 126, width: 4512 us [4492;4632] (1128 S)
Level estimates [high, low]: 1253, 121
RSSI: -22.3 dB SNR: 20.3 dB Noise: -42.6 dB
Frequency offsets [F1, F2]: 1188, 0 (+4.5 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
view at https://triq.org/pdv/#AAB00B04010228233408CC11A08155+AAB03504010228233408CC11A08282838382838283828383828282838382838382828382838382838283838282838382828283838283828155+AAB00B04010228233408CC11A08155+AAB03504010228233408CC11A08282838382838283828383828282838382838382828382838382838283838282838382828283838283828155+AAB00B04010228233408CC11A08155+AAB03504010228233408CC11A08282838382838283828383828282838382838382828382838382838283838282838382828283838283828155+AAB00B04010228233408CC11A08155+AAB03504010228233408CC11A08282838382838283828383828282838382838382828382838382838283838282838382828283838283828155+AAB00B04010228233408CC11A08155+AAB03504010228233408CC11A08282838382838283828383828282838382838382828382838382838283838282838382828283838283828155+AAB00B04010228233408CC11A08155+AAB03504010228233408CC11A08282838382838283828383828282838382838382828382838382838283838282838382828283838283828155+AAB00B04010228233408CC11A08155
Attempting demodulation... short_width: 2252, long_width: 4512, reset_limit: 9052, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=2252,l=4512,g=4636,r=9052'
pulse_slicer_ppm(): Analyzer Device
bitbuffer:: Number of rows: 13
[00] { 0} :
[01] {42} 35 63 65 ac c6 80 : 00110101 01100011 01100101 10101100 11000110 10
[02] { 0} :
[03] {42} 35 63 65 ac c6 80 : 00110101 01100011 01100101 10101100 11000110 10
[04] { 0} :
[05] {42} 35 63 65 ac c6 80 : 00110101 01100011 01100101 10101100 11000110 10
[06] { 0} :
[07] {42} 35 63 65 ac c6 80 : 00110101 01100011 01100101 10101100 11000110 10
[08] { 0} :
[09] {42} 35 63 65 ac c6 80 : 00110101 01100011 01100101 10101100 11000110 10
[10] { 0} :
[11] {42} 35 63 65 ac c6 80 : 00110101 01100011 01100101 10101100 11000110 10
[12] { 0} :

rtl_433 -d driver=hackrf -R 0 -X 'n=name,m=OOK_PPM,s=2252,l=4512,g=4636,r=9052'
gives:

time : 2024-09-19 08:03:44
model : name count : 15 num_rows : 15 rows :
len : 0 data : ,
len : 42 data : 356055a904c,
len : 0 data : ,
len : 42 data : 356055a904c,
len : 0 data : ,
len : 41 data : 356055a9048,
len : 0 data : ,
len : 0 data : ,
len : 42 data : 356055a904c,
len : 0 data : ,
len : 41 data : 356055a9048,
len : 0 data : ,
len : 0 data : ,
len : 42 data : 356055a904c,
len : 0 data :
codes : {0}, {42}356055a904c, {0}, {42}356055a904c, {0}, {41}356055a9048, {0}, {0}, {42}356055a904c, {0}, {41}356055a9048, {0}, {0}, {42}356055a904c, {0}

---

time : 2024-09-19 08:04:33
model : name count : 5 num_rows : 5 rows :
len : 0 data : ,
len : 42 data : 356295a504c,
len : 0 data : ,
len : 42 data : 356295a504c,
len : 0 data :
codes : {0}, {42}356295a504c, {0}, {42}356295a504c, {0}

---

time : 2024-09-19 08:04:33
model : name count : 10 num_rows : 10 rows :
len : 42 data : 356295a504c,
len : 0 data : ,
len : 41 data : 356295a5048,
len : 0 data : ,
len : 0 data : ,
len : 41 data : 356295a5048,
len : 0 data : ,
len : 0 data : ,
len : 42 data : 356295a504c,
len : 0 data :
codes : {42}356295a504c, {0}, {41}356295a5048, {0}, {0}, {41}356295a5048, {0}, {0}, {42}356295a504c, {0}

---

time : 2024-09-19 08:05:24
model : name count : 17 num_rows : 17 rows :
len : 0 data : ,
len : 41 data : 356059a1078,
len : 0 data : ,
len : 0 data : ,
len : 42 data : 356059a107c,
len : 0 data : ,
len : 41 data : 356059a1078,
len : 0 data : ,
len : 0 data : ,
len : 42 data : 356059a107c,
len : 0 data : ,
len : 39 data : 356059a106,
len : 1 data : 8,
len : 0 data : ,
len : 0 data : ,
len : 42 data : 356059a107c,
len : 0 data :
codes : {0}, {41}356059a1078, {0}, {0}, {42}356059a107c, {0}, {41}356059a1078, {0}, {0}, {42}356059a107c, {0}, {39}356059a106, {1}8, {0}, {0}, {42}356059a107c, {0}

So it seems the flex decoder doesn't work in this case.
There is a bit of inconsistency too, maybe because of the sensor freq. It sends data on 433.99MHz (checked with SDR++).

I got some codes from above and created a list while reading the temperature and humidity on the sensor display.
Here's the list with demodulated signals:

35 62 e9 b8 86 80 [27,1c - 46% - ch1]
35 42 e9 b8 81 00 [27,1c - 46% - ch1]
35 42 a9 b8 80 80 [27.0c - 46% - ch1]
35 43 69 b8 80 c0 [5.7c - 46% - ch1]
35 62 51 28 88 00 [-6.8c - 43% - ch1]
35 51 cd 2c 8a 00 [-7.8c - 43% - ch1]
35 51 e5 34 84 40 [-2.5c - 45% - ch1]
35 41 99 88 cb c0 [23.2c - 50% - ch1]

35 57 75 74 c5 80 [16.7c - 62% - ch2]
35 65 61 9c c7 80 [25.2c - 54% - ch2]
35 56 d9 8c c5 40 [23.8c - 51% - ch2]

35 69 ad b8 81 80 [27.7c - 46% - ch3]
35 49 d5 84 c9 c0 [22.4c - 49% - ch3]
35 4b d5 88 cb 40 [22.8c - 50% - ch3]

I have tried to decode it with https://triq.net/bitbench but I had no luck. Have no clue how to use it. Everything I tried doesn't match the expected result.

Do you think this can be added to some future release?

I can provide any additional info, but please be gentle and keep in mind that this is my third day (ever) playing with RF signals. :)

[ProfBoc75]

Hi @zenguru84:

Sounds like your sensor is already known as protocol 47, Conrad-S3318P, but with little different pulse width.

Sensor	Short	Long	Gap	Reset
Your	2250	4500	5200	9052
Conrad	1900	3800	4400	9400

rtl_433 -C si -M protocol -y {0},{42}356055a904c,{0},{42}356055a904c,{0},{41}356055a9048,{0},{0},{42}356055a904c,{0},{41}356055a9048,{0},{0},{42}356055a904c,{0}

Matching your first value, 27,1°C 46% CH1

rtl_433 -C si -M protocol -y {42}3542e9b88100,{42}3542e9b88100,{42}3542e9b88100,{42}3542e9b88100

May be adjust your antenna and hackrf options, reduce the bandwidth. try with options -s 1000k -t "bandwidth=1750000"

[zenguru84]

Hey @ProfBoc75!
Thanks for your reply.

rtl_433 -d driver=hackrf -s 1000k -t "bandwidth=1750000"
outputs nothing.

If I analyze with those options, the output looks almost identical as without them.
The sensor is less than a meter apart from the hackrf antenna.

[zenguru84]

@ProfBoc75
I managed to make it work.

rtl_433 -d driver=hackrf -C si -f 433.99M -s 1000k -t "bandwidth=1500000"

This is the lucky combination. :)

Thanks a lot!