WS2032 - not working only 1024k

[vampywiz17]

Hello there,

Some week ago, my WS2032 only work, that i set the sample rate to 1024k. The problem is that some of my devices (Kerui doorbell for example) not working in this sample rate.

It possible to fix it, or possible to change something with my Kerui doorbell config, that will working on 1024k?

Here my Kerui config:

decoder {
        n=kerui_doorbell,
        m=OOK_PWM,
        s=68,
        l=264,
        g=500,
        r=1800,
        match={14}e1d0,
        }

Here the issue that integrate the ws2032 decoder: #1200

@zuckschwerdt Possible you able to help me.

[klohner]

@vampywiz17 Could you provide some .cu8 sample files from your Kerui doorbell at 1024k?

[vampywiz17]

@klohner

I only record it with 250k it help you?

g001_433.92M_250k.cu8.zip

[klohner]

So, there's a few things going on here. It may be helpful to first visualize this .cu8 file to see what we're working with. Here's a spectrogram view from URH:

Right away I see what looks like three different things going on in this sample.

• There's a strong signal you can see bottom left. This is your WS2032 weather sensor. If you're curious, you can pick out its PWM data with rtl_433 -R 0 -s 250k -r g001_433.92M_250k.cu8 -X n=WS2032,m=OOK_PWM,s=500,l=1000,y=2000,r=3000,invert,bits=112 -Y level=-2. Note that I had to provide a manual detection level (-Y level=-2) in order to get rtl_433 to see this signal in your sample file.

• There's some other burst that repeats 3 times every second throughout the whole sample file. Each burst is 121 short 90μs pulses separated by 180μs gaps. That doesn't seem like useful data and not sure what is causing it, but it might be causing intermittent issues with you not able to receive your doorbell signal if it ever overlaps. You can pick these signals out with rtl_433 -R 0 -s 250k -r g001_433.92M_250k.cu8 -X n=unk1,m=OOK_PWM,s=90,l=180,r=3000,bits=121

• Your Kerui doorbell is about 1/3 of the way into this file. This signal looks like an OOK_PWM signal where symbols are 67μs with 3 symbols in each bit period. This signal probably repeats several times (7 times in your sample) with about 1350μs gap between each repetition. Here's what it looks like (after applying a band pass filter in URH):

Without that band pass filter, it's not cleanest signal, and that may be the first issue here. Regardless, after this clean-up, it's easy to visually pull out the symbols in one repetition of this signal:

100100100110100110110100110100110100100100100110100100110110110110100110100

This is {75}9269b4d34926936da68 in rtl_433 notation. But, let's see how rtl_433 sees these same symbols.

$ rtl_433 -R 0 -s 250k -r g001_433.92M_250k.cu8 -X n=kerui,m=OOK_PCM,s=67,l=67,r=175,bits=75
[...]
time      : @2.041144s
model     : kerui        count     : 1             num_rows  : 1             rows      :
len       : 75           data      : 9279fcf3c92793ffe78
codes     : {75}9279fcf3c92793ffe78
[... 6 more repetition of this code ...]

Hmm, that's not the same thing. Let's compare as symbol bits:

I see:        100100100110100110110100110100110100100100100110100100110110110110100110100
rtl_433 sees: 100100100111100111111100111100111100100100100111100100111111111111100111100

It seems that rtl_433 is consistently misinterpreting any single contiguous gap as a pulse, probably due to the signal quality. Here's that same signal without any clean-up:

It's more difficult to pick out the symbol bits properly with this S/N ratio.

However, you're decoding this signal as PWM (as you should) instead of PCM, so this is masking this error. Essentially, with PWM decoding, rtl_433 is treating contiguous gaps as delimiters, and treating long pulses as a logical 0 bits and short pulses as logical 1 bits.

Let's see what this would do to the PCM signal we just saw:

rtl_433 sees (as PCM):       100100100111100111111100111100111100100100100111100100111111111111100111100
1=short pulse, 0=long pulse: 1--1--1--0-----0--------0-----0-----1--1--1--0-----1--0--------------0-----
PWM bits:                = : 11100001110100
PWM:                     = : {14}e1d0

$ rtl_433 -R 0 -s 250k -r g001_433.92M_250k.cu8 -X n=kerui,m=OOK_PWM,s=67,l=134,r=210,bits=14
[...]
model     : kerui        count     : 1             num_rows  : 1             rows      :
len       : 14           data      : e1d0
codes     : {14}e1d0
[...]

So, that's why you're seeing that {14}e1d0 from your doorbell. That's not really what it's sending, though, it's just how rtl_433 is misinterpreting it due to signal quality.

When you bump up to using a 1024k sample rate instead of the 250k rate, I'd guess maybe rtl_433 is doing a better job of interpreting your doorbell signal. Here's what should be correct:

your doorbell code (as PCM): 100100100110100110110100110100110100100100100110100100110110110110100110100
1=short pulse, 0=long pulse: 1--1--1--0--1--0--0--1--0--1--0--1--1--1--1--0--1--1--0--0--0--0--1--0--1--
                         = : 1110100101011110110000101
as PWM code:                 {25}e95ec28

So, all this is a long-winded way of saying, maybe this will work better for you:

$ rtl_433 -s 1024k -X n=kerui_doorbell,m=OOK_PWM,s=67,l=134,g=500,r=1800,bits=25

or, maybe this will work with both 250k and 1024k sample rates:

$ rtl_433 -s 1024k -X n=kerui_doorbell,m=OOK_PWM,s=67,l=134,g=500,r=1800,match={4}e,repeats=3

or maybe:

decoder {
        n=kerui_doorbell,
        m=OOK_PWM,
        s=67,
        l=134,
        g=500,
        r=1800,
        match={25}e95ec28,
        }

[vampywiz17]

Thanks the detailed answer! I will try all possible options tomorrow!

There's some other burst that repeats 3 times every second throughout the whole sample file. Each burst is 121 short 90μs pulses separated by 180μs gaps. That doesn't seem like useful data and not sure what is causing it, but it might be causing intermittent issues with you not able to receive your doorbell signal if it ever overlaps.

Yes i receive a brutal noise in my house every time... I try to figure out a many time what causes this, but i not find it... (i can not learn my doorbells inside my house because the receivers learn the noise constantly not the button signal) i need to go to garden if i want to enroll a doorbell...

[merbanan]

Try adjusting the frequency to see if that helps. This bursting issue makes reception really hard.