Rtl_433: Support for self powered wall switch

Created on 12 Feb 2019  Â·  35Comments  Â·  Source: merbanan/rtl_433

Greetings,

I'm trying to integrate wall switches into my home automation setup similar to #543. I'd like to install several of these around the house and be able to identify when and which one was pressed.

I originally wanted to use something like described here but I can't seem to find this USB transceiver anywhere in stock. I'd be thrilled if anyone knows where to get one and whether or not this would work for my purposes.

Ultimately I wonder if it's easier/more efficient to buy a 433 receiver and rig it up to an Arduino, but I'm not even sure what kind of receiver I would need. I bought an HC-12 USB radio that supposedly operates on 433 but didn't get anything out of it. It looks like it's made to talk to only others of it's kind and has it's own protocol.

Pressing forward I borrowed a friend's SDR and I have gotten as far as determining these switches operate on 433.92Mhz using FSK but I do not know where to go from here. Forgive me for I have little experience with RF, so while I understand the basic differences between AM and FM, I'm failing to grasp much beyond that. So while the wiki tutorial specifies

have a look at the waveform to determine if it using OOK or FSK modulation

it doesn't explain how one does that. Beyond that, it doesn't explain what to do with that information once you've got it. Could anyone more experienced assist with closing the gap between making the recording and implementing support?

This is what I've been able to find in PulseView. Again, not sure what to do with this information. The guide talks about short pulses and long pulses but I see many varying lengths.

screenshot from 2019-02-12 11-53-54

Corresponding capture:
g004_433.92M_2400k.zip

I'm not sure how FM maps to FSK or what I and Q are (online reading did not clarify this, I get the gist of the math but not how this applies to real life; ie how does one capture a signal with a 90 degree phase shift? Isn't the raw data from the antenna 1-dimensional? How could it be anything else?). I'm working with little more than a high school understanding of waves so please forgive me if these are basics; if I gain a better understanding I'd be happy to contribute to the documentation to help others in my shoes.

Thanks in advance for any insight you might have.

Most helpful comment

Hi,
I'm still learning about this myself, but I'll hazard a guess and see if I'm right. Here goes

Under PCM, a bit is transmitted at regular intervals. That's what the long parameter defines, what those regular interval are.

To transmit a 1 bit a pulse is sent (so you can see a pulse using Pulseview).
To transmit a zero pulse nothing is sent (so what you see in Pulseview is nothing!).

If you have a sequence of 0's being transmitted, you will see a sequence of nothings. For the receiver to "figure out" how many zeros have been sent it needs to know how long each "bit" lasts (the long parameter). Then it can measure how long it heard "nothing", divide by long, and tell you how many zero bits it received.

There are two possibilities for what you see in Pulseview for a sequence of 1 bits.

  • The easiest to see is if the pulse is shorter than the bit width. In this case each individual pulse will be visible, because the transmission rises from no pulse (zero transmission) to some transmission (a pulse), then falls back to no transmission, and stays at that level until it is time (an amount long after the pulse started) to send the next pulse. In this case (called RZ - return to zero), all the receiver has to do is to count the number of pulses, and tell you how many 1 bits were sent.

  • But the easiest to transmit (I think) is if the length of the pulse is the same as the length of the bit width. In this case you don't see nice individual pulses, because as soon as the pulse for the first 1 bit finishes, the pulse for the next 1 bit bit starts. What you see in Pulseview is something that looks like a single extended pulse. This case is called NRZ (non return to zero). In this case the receiver has to decide how many 1 bits were sent the same way it decides how many zero bit were sent - by measuring how long the extended pulse lasted, and dividing by how long a single bit should last.

You tell rtl_433 whether to expect RZ or NRZ by telling it what the duration of a single 1 bit pulse should be, ie the short parameter. If short equals long, it is NRZ; if short is less than long it is RZ.

Although RZ is easier for a human to spot, I think NRZ is easier for the transmitter and receiver to manage (because they send and receive sequences of zero bits and one bits the same way, instead of having one rule for zero bits, and a different rule for one bits).

Finally, all this obviously depends on the transmitter and receiver keeping in step (ie having the same clock!). If one or the other is running a bit slower or faster , then counting the length of a extended pulse (for 1 bits) or an extended gap (for 0 bits) and dividing by the length of a single bit will fail if the sequence is too long. But heaps of environmental features (eg temperature) can make 'clocks' run slow or fast (especially on cheap devices), so typically, transmitters will send an agreed signal first (say a run of 1's, or a run of 10101010), so the receiver can synchronise it's clock to the clock in the transmitter. This (the clock speed changing marginally) can happen even between one transmission and the next. But as long as the receiver knows "near enough" what the pulse length and bit length are supposed to be, it can figure out the exact length for this particular transmission by using the sync signal sent at the start of the transmission. Hence the short and long values you provide are nominal, not exact (which is lucky for us I guess :-)

I hope that makes sense (and I hope it is right! - if not @zuckschwerdt will have to correct me)

All 35 comments

The signal might be clipping, try lowering the gain a little bit. The bit slicer fails to generate the correct bits from the demodulated signal. I see that you have a 2.4MS rate, try lowering the rate to 1MS and see if anything changes. And what does rtl_433 -A give?

Hi @merbanan thanks again for your quick response. Based on your comment on the other issue, I made these latest captures without the external antenna attached and it looks like it has helped. I'm not sure how to adjust the gain, what are the units in and what would be an appropriate range? I'm currently capturing with the default, auto gain.

I'll try lowering the rate, I had initially gotten bad results with the default rate so that's why I increased it.

Here's the output from rtl_433 -A while pressing the button four times.

Detected OOK package    @ 2019-02-12 13:56:48
Analyzing pulses...
Total count:    3,  width: 12.39 ms     ( 3097 S)
Pulse width distribution:
 [ 0] count:    3,  width:  552 us [544;568]    ( 138 S)
Gap width distribution:
 [ 0] count:    2,  width: 5364 us [5336;5392]  (1341 S)
Pulse period distribution:
 [ 0] count:    2,  width: 5920 us [5880;5960]  (1480 S)
Level estimates [high, low]:  15977,     37
Frequency offsets [F1, F2]:   -6410,      0 (-24.5 kHz, +0.0 kHz)
Guessing modulation: Un-modulated signal. Maybe a preamble...

Detected OOK package    @ 2019-02-12 13:56:55
Analyzing pulses...
Total count:    3,  width: 12.39 ms     ( 3097 S)
Pulse width distribution:
 [ 0] count:    3,  width:  548 us [532;568]    ( 137 S)
Gap width distribution:
 [ 0] count:    2,  width: 5368 us [5328;5408]  (1342 S)
Pulse period distribution:
 [ 0] count:    2,  width: 5916 us [5860;5976]  (1479 S)
Level estimates [high, low]:  15940,     24
Frequency offsets [F1, F2]:   -4084,      0 (-15.6 kHz, +0.0 kHz)
Guessing modulation: Un-modulated signal. Maybe a preamble...

Detected OOK package    @ 2019-02-12 13:56:58
Analyzing pulses...
Total count:    5,  width: 12.32 ms     ( 3080 S)
Pulse width distribution:
 [ 0] count:    1,  width:  512 us [512;512]    ( 128 S)
 [ 1] count:    2,  width:  132 us [124;144]    (  33 S)
 [ 2] count:    1,  width:  304 us [304;304]    (  76 S)
 [ 3] count:    1,  width:   92 us [92;92]  (  23 S)
Gap width distribution:
 [ 0] count:    2,  width: 5508 us [5424;5596]  (1377 S)
 [ 1] count:    1,  width:   80 us [80;80]  (  20 S)
 [ 2] count:    1,  width:   44 us [44;44]  (  11 S)
Pulse period distribution:
 [ 0] count:    2,  width: 5916 us [5900;5936]  (1479 S)
 [ 1] count:    1,  width:  204 us [204;204]    (  51 S)
 [ 2] count:    1,  width:  136 us [136;136]    (  34 S)
Level estimates [high, low]:   1000,     44
Frequency offsets [F1, F2]:   -7911,      0 (-30.2 kHz, +0.0 kHz)
Guessing modulation: No clue...

Detected OOK package    @ 2019-02-12 13:57:03
Analyzing pulses...
Total count:    3,  width: 12.36 ms     ( 3091 S)
Pulse width distribution:
 [ 0] count:    3,  width:  540 us [532;548]    ( 135 S)
Gap width distribution:
 [ 0] count:    2,  width: 5372 us [5344;5400]  (1343 S)
Pulse period distribution:
 [ 0] count:    2,  width: 5916 us [5884;5948]  (1479 S)
Level estimates [high, low]:   1182,     29
Frequency offsets [F1, F2]:   -5413,      0 (-20.6 kHz, +0.0 kHz)
Guessing modulation: Un-modulated signal. Maybe a preamble...

Another thing to note, as you suggested the signal strength might be too great, I can't seem to lower it too much without losing the recording entirely. Any higher and it clips. Any lower and I do not get a recording at all. Why might this be?

Bogus output, the transmission is detected but that is it. The automagic data recovery code fails on this code.

If you change PD_MIN_PULSE_SAMPLES to 5 you get better results.

With the change and this command:

rtl_433 -X "n=button,modulation=FSK_PCM,short=36,long=36,reset=3000" -r g004_433.92M_2400k.cu8

I get the following output:

time : @0.112332s
model : button count : 1 num_rows : 1 rows :
len : 140 data : d555555569c8e9c4418009796890d019aa7
codes : {140}d555555569c8e9c4418009796890d019aa7


time : @0.169396s
model : button count : 1 num_rows : 1 rows :
len : 140 data : d555555569c8e9c8830012f16890d019aa7
codes : {140}d555555569c8e9c8830012f16890d019aa7


time : @0.217552s
model : button count : 1 num_rows : 1 rows :
len : 139 data : 5555555569c8e9c8830012f2d121a03354c
codes : {139}5555555569c8e9c8830012f2d121a03354c

Can you test with the code change and trigger the transmission a few times. Is the data different each time? This looks like it is a more advanced device.

My copy was a little out of date, I just git pulled, made the suggested code change, and recompiled.

Now with rtl_433 -X "n=button,modulation=FSK_PCM,short=36,long=36,reset=3000" I'm not getting anything. Do I need to have other flags for this?

With rtl_433 -X "n=button,modulation=FSK_PCM,short=36,long=36,reset=3000" -r g004_433.92M_2400k.cu8 my output matches yours.

It's not very clear the difference between -a and -A from the README

[-a] Analyze mode. Print a textual description of the signal.
[-A] Pulse Analyzer. Enable pulse analysis and decode attempt.

Should I be using one or more of these?

Your message is ambiguous. Anyway -A is the maintained analyzer.

But if you run with -X "n=button,modulation=FSK_PCM,short=36,long=36,reset=3000" live you should be able to receive button presses.

Do I need to change the sample rate or gain from their defaults?

Ah sorry about the ambiguous comment, I just saw my error. I meant to say that I don't receive any output when running live, but I can confirm that reading from the recording my output is the same as yours.

Aha! I added -s 2400000 to match the command I had used for the recording and now I get the following output

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:05:48
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:05:48
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:05:48
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:05:50
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:05:50
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 141          data      : d555555569c8e9c8830012f16890d00cd538
codes     : {141}d555555569c8e9c8830012f16890d00cd538
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:05:50
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : 9555555569c8e9c8830012f2d121a03354e
codes     : {139}9555555569c8e9c8830012f2d121a03354e

So it seems like it's relatively consistent, occasionally gaining or losing a bit. Since the signal is sent three times with each press, is there an automated facility for correcting these errors?

I'm not sure if more samples would help, here is a few more

time      : 2019-02-12 16:08:09
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 138          data      : d5555555a723a7220c004bcb44868066a9c
codes     : {138}d5555555a723a7220c004bcb44868066a9c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:09
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 138          data      : 55555555a723a7220c004bcb44868066a9c
codes     : {138}55555555a723a7220c004bcb44868066a9c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:09
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 138          data      : 55555555a723a7220c004bcb44868066a9c
codes     : {138}55555555a723a7220c004bcb44868066a9c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:18
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:18
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:18
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:22
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:22
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:22
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:22
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:22
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354c
codes     : {139}d555555569c8e9c8830012f2d121a03354c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:23
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:23
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa6
codes     : {140}d555555569c8e9c8830012f2d121a019aa6
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:23
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:23
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:25
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:25
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:25
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:26
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:26
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:26
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:27
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:27
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:27
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:28
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:28
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:28
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:28
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:28
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : d555555569c8e9c8830012f2d121a019aa7
codes     : {140}d555555569c8e9c8830012f2d121a019aa7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-12 16:08:28
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 139          data      : d555555569c8e9c8830012f2d121a03354e
codes     : {139}d555555569c8e9c8830012f2d121a03354e

Yes, try adding preamble=0xd5555555,repeats=3

rtl_433 -X help for parameters you can play with. And try lowering the sample rate to 1MS or 0.5MS. For the record 3354e is equal to 19aa7 shifted one bit. Different short/long values might fix that. Can you grab a few more test signals?

Thanks @merbanan I'll give this a shot when I get home today.

I'm curious, do short and long values have to be the same for this protocol?

How do I derive these values myself, so I don't need to bug you in the future :smile: ?

Well the short value is probably the bit length. One needs to read the code to understand what the parameter means. Maybe @zuckschwerdt can clarify.

If you can adjust the short value so that the output is constant then the repeat can be used generate only one output. After that you can create a doorbell config entry.

It failed to set sample rate to 0.5MS:

Found Rafael Micro R820T tuner
Invalid sample rate: 500000 Hz
WARNING: Failed to set sample rate.

Here's a new batch of recordings at 1M sample rate, with gain at 60, 80, 100, and auto, three samples for each setting.
switch_recordings_at_1M.zip

Thanks again for helping me understand and debug this!

Looking at the recordings with PulseView I noticed it wasn't decoding at 1M, so I lowered PD_MIN_PULSE_SAMPLES again to 2. I'm not sure if this would have any unwanted side effects, but it seems to be decoding again. Seems as though there are not enough samples at 1M to get 5 or 10 samples per pulse.

I also didn't realize until now that I could drag the representation in PulseView around, so I laid the FM over the FSK to see how they line up and it looks good.

screenshot from 2019-02-13 14-20-47

This is with long and short set to 16, which I derived by measuring the preamble bits from one zero crossing to the next and dividing by 2.

I'm starting to understand how this works and what different values mean. I would like to help improve the documentation as it's a pretty steep learning curve if you don't know much about the software or RF.

I'm still getting some variety in the decodings. Looks like the noise at the end is sometimes interpretted as an extra 1 bit, sometimes it misses the first bit.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:47
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354c
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:48
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354c
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:49
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354c
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:50
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 138          data      : aaaaaaaad391d39106004bcb448680cd530
codes     : {138}aaaaaaaad391d39106004bcb448680cd530
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:50
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 4008aaaab4e474e4418012f2d121a03354e
codes     : {140}4008aaaab4e474e4418012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:50
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 137          data      : aaaaaaaad391d39106004bcb448680cd538
codes     : {137}aaaaaaaad391d39106004bcb448680cd538
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:54
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354d
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354d
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:55
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354c
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:23:56
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 4002aaaab4e474e4418012f2d121a03354c
codes     : {140}4002aaaab4e474e4418012f2d121a03354c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:24:02
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354e
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:24:03
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354d
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354d
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-02-13 14:24:05
model     : button       count     : 1             num_rows  : 1             rows      : 
len       : 140          data      : 6aaaaaaab4e474e4418012f2d121a03354c
codes     : {140}6aaaaaaab4e474e4418012f2d121a03354c

Not sure what could have screwed up the preamble on 4002aaaab4e474e4418012f2d121a03354c

Set the preamble to aaaab4. Then it will align the output to that pattern.

Documentation is always welcome. In this case the meaning of the bit pattern is unknown but you can at least find the stable decode parameters. For FSK_PCM I am not sure the long parameter is used.

Great, seem to be getting fairly consistent output from my workbench.

Unfortunately, no matter what I set the gain at, I can't seem to get it into a range where it's not too "loud" and not too "quiet" to receive from other places in the house.

Auto gain seems to be consistently too high. Is that a limitation of the hardware?

The closer switches are too loud while the further switches are too quiet. Are there settings I could use to increase the listening range?

Anything I can do about the noisy end bit? The repeat setting sometimes fails to filter out duplicates due to the end varying slightly between samples. Maybe if I could set the output to a fixed number of bits.

With FSK_PCM (like OOK_PCM) it's (see rtl_433 -X help):

PCM     short: Nominal width of pulse [us]
         long: Nominal width of bit period [us]

i.e. the difference here is NRZ (short=long) vs RZ (short less than long).
s.a. https://github.com/merbanan/rtl_433/blob/master/include/pulse_demod.h#L20

Thanks for chiming in @zuckschwerdt!

What do you mean by "nominal width of pulse" and "nominal width of bit period"?

Do I have it correct that short is the time it takes to transmit one bit?

What is the difference between "pulse" and "bit period" in this context?

When you say "nominal", are you saying that it will detect pulses at least this long?

Hi,
I'm still learning about this myself, but I'll hazard a guess and see if I'm right. Here goes

Under PCM, a bit is transmitted at regular intervals. That's what the long parameter defines, what those regular interval are.

To transmit a 1 bit a pulse is sent (so you can see a pulse using Pulseview).
To transmit a zero pulse nothing is sent (so what you see in Pulseview is nothing!).

If you have a sequence of 0's being transmitted, you will see a sequence of nothings. For the receiver to "figure out" how many zeros have been sent it needs to know how long each "bit" lasts (the long parameter). Then it can measure how long it heard "nothing", divide by long, and tell you how many zero bits it received.

There are two possibilities for what you see in Pulseview for a sequence of 1 bits.

  • The easiest to see is if the pulse is shorter than the bit width. In this case each individual pulse will be visible, because the transmission rises from no pulse (zero transmission) to some transmission (a pulse), then falls back to no transmission, and stays at that level until it is time (an amount long after the pulse started) to send the next pulse. In this case (called RZ - return to zero), all the receiver has to do is to count the number of pulses, and tell you how many 1 bits were sent.

  • But the easiest to transmit (I think) is if the length of the pulse is the same as the length of the bit width. In this case you don't see nice individual pulses, because as soon as the pulse for the first 1 bit finishes, the pulse for the next 1 bit bit starts. What you see in Pulseview is something that looks like a single extended pulse. This case is called NRZ (non return to zero). In this case the receiver has to decide how many 1 bits were sent the same way it decides how many zero bit were sent - by measuring how long the extended pulse lasted, and dividing by how long a single bit should last.

You tell rtl_433 whether to expect RZ or NRZ by telling it what the duration of a single 1 bit pulse should be, ie the short parameter. If short equals long, it is NRZ; if short is less than long it is RZ.

Although RZ is easier for a human to spot, I think NRZ is easier for the transmitter and receiver to manage (because they send and receive sequences of zero bits and one bits the same way, instead of having one rule for zero bits, and a different rule for one bits).

Finally, all this obviously depends on the transmitter and receiver keeping in step (ie having the same clock!). If one or the other is running a bit slower or faster , then counting the length of a extended pulse (for 1 bits) or an extended gap (for 0 bits) and dividing by the length of a single bit will fail if the sequence is too long. But heaps of environmental features (eg temperature) can make 'clocks' run slow or fast (especially on cheap devices), so typically, transmitters will send an agreed signal first (say a run of 1's, or a run of 10101010), so the receiver can synchronise it's clock to the clock in the transmitter. This (the clock speed changing marginally) can happen even between one transmission and the next. But as long as the receiver knows "near enough" what the pulse length and bit length are supposed to be, it can figure out the exact length for this particular transmission by using the sync signal sent at the start of the transmission. Hence the short and long values you provide are nominal, not exact (which is lucky for us I guess :-)

I hope that makes sense (and I hope it is right! - if not @zuckschwerdt will have to correct me)

Thanks @Geoff99! This definitely helps clear up the difference between short and long, RZ and NRZ.

I am curious if rtl_433 does the sort of clock synchronization you speak of with the preamble. That would be ideal, but as it's sometimes a little misaligned, I'm not sure this is the case.

Along these lines, if it could re-sync with each rising edge, I theorize this could also improve reliability. Does rtl_433 have this capability?

Sorry @kueblc, I'll have to leave the full answer about what exactly rtl_433 does to the experts - I'm still learning about this stuff myself.

I suspect though (it's just a guess) that the misalignment is an almost unavoidable consequence of radio transmissions in a noisy environment. Plus the tendency of transmitters especially (but also receivers) to 'sleep' between transmissions to save power (aka extend battery life).

A random spike (maybe the fridge turned on, maybe a light went off, …) could perhaps be misread as an extra pulse (ie an extra 1 bit) somewhere in the message. And not waking up quickly enough could mean a few bits get missed.

That's the other benefit of the initial sync section of a message. As long as you receive "enough" of the end of the sync (preamble) part of the transmission, you know where to start deciphering the "real" part of the message that contains information you are interested in (even if you miss a few of the sync bits at the start).

Likewise, if you can figure out how many bits there should be in a complete "good" transmission, you know when to stop listening as well.

And if you have enough data points (different transmissions by different transmitters of the same type - or maybe by the same transmitter with the batteries removed and reinserted) you may be able to decipher the meaning of the individual fields with a message (eg transmitter id, which button was pressed, plus …. there will usually be some type of error checking value, probably (but not always) at the end of the transmission (a checksum, some parity bits, or something more complicated called a CRC - cyclic redundancy check) that will let you determine whether the message has been corrupted or not. Transmitters usually send the message 2 or 3 times (at least), and receivers check the error checking value, and stop listening as soon as they receive the first good, uncorrupted transmission.

@kueblc with RZ/NRZ (PCM in rtl_433's terms) each given pulse will be divided by the expected bit length resulting in a respective run of 1's. So there is no clock skew, every edge will re-sync. The timing won't adapt to the actual pulse widths though. A slow or fast clock in the sender will mess longer sequences up.
Is there still help needed here or can this be closed?

Hey sorry I forgot to follow up here. Thanks for clearing up some details.

I have a better understanding of the rtl_433 code, but still pretty weak understanding of the physics of radio (really couldn't tell you how I and Q work, are they phase shifted or what). I would love to learn more about RF from the physics side, I'm coming at it from more of an EE/CS side.

With @merbanan's help I was able to create a template that works most of the time. This allowed me to gain a better understanding of the contents of the message, but not good enough for everyday use. Besides, I felt like running an SDR 24/7 is a little overkill for just turning on my lights.

Ultimately what I ended up doing is hacking the receiver that came with the device to pull in raw data over the serial port, something I have much more experience with. Cracking open the receiver I found an STM8 microcontroller and a CC113L on board. There were a bunch of components I didn't need on that board I could desolder, the relay and power electronics to get the AC down to 3.3 VDC.

They were also kind enough to leave labelled through holes on the edge of the board, so I hooked up the GND, 3.3V, TX, and RX to a CH340. I haven't been able to reprogram the STM8 but it looks like I won't need to. Luckily, the exposed serial port sends out data whenever the CC113L buffer fills, whether or not it matches the ID stored on the STM8.

A tiny script runs on my server and translates the raw serial stream into tokens and publishes to MQTT. Voila!

Great writeup on the hardware hacking. I also prefer these elegant and small solutions. Seems many people don't mind going to "the cloud" and back just for their doorbell…

Re IQ, both I+Q are the same signal and can be thought of being 90° out of phase (though not by time shift). The sine-wave picture is just a projection, think of the signal als a corkscrew through time. Khan Academy has a short explanation on this and 3Blue1Brown explains the basis in more detail, and w2aew shows this from an practical angle.

Thanks @zuckschwerdt for the links! Helped clear up a few things. The actual antenna itself only picks up a single wave, but that is demodulated into I and Q, do I have that right?

Yes, the I+Q representation is the result of "removing" the carrier frequency.
Here are some helpful articles to that:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Ewarren7 picture Ewarren7  Â·  11Comments

matthewwall picture matthewwall  Â·  13Comments

ALEEF02 picture ALEEF02  Â·  9Comments

niemilkm picture niemilkm  Â·  12Comments

OZ1SEJ picture OZ1SEJ  Â·  15Comments