Starting-out with a pair of 'driveway sensors'

[Sam Lander]

[Casting this to the void. I am not sure I am asking for help, more for mutterings from fellow travellers. Thanks for listening]

Design:

Listen with rtl-433 to four driveway (PIR) sensors.

When sensor 4 pings, note it (it is probably a kangaroo) as time t4

When sensor 3 pings, note it as t3 (it might also be a wombat)

Decide: t3 - t2 > 5s and t3 - t2 < 15s? (it is probably a human visitor driving a car up the driveway) - sound the doorbell.

Using CubicSDR and this physical; setup (RTL-SDR with no antenna) 

I do: trigger unit 2, wait 3s, trigger unit 1, wait 1s, stop the device, save screengrab:

What I THINK I see:
The units send two messages , very similar looking, but shifted in frequency.

Each half transmission lasts ?about half a second?

I guess this frequency pattern is what they are calling "FHSS"?

The spread of frequencies seems very not-random, with each unit producing near-identical steps:

First transmission 434.58MHz and 434.62MHz

Second transmission at 435.43MHz and 435.47MHz.

Next for me, I think, is to tell rtl-433 to look for FSK on, say 434.58 and 434.62.
Am I thinking/doing that right?

[Sam Lander]

spreading the transmission out in time yields three probably 32 bit quantities and some framing bits in each half-send:

OK. Now I really do have a question:

Is this handle-able with an existing config file?

[Sam Lander]

It turns out that the -f should be the middle frequency.

(434.581745+434.621174) / 2 = 434.6014595

rtl_433 -f 434.6014595M -S unknown

makes four files

...

Exact sample rate is: 250000.000414 Hz
Allocating 15 zero-copy buffers
*** Saving signal to file g001_434.601M_250k.cu8 (39402 samples, 131072 bytes)
*** Saving signal to file g002_434.601M_250k.cu8 (313505 samples, 655360 bytes)
*** Saving signal to file g003_434.601M_250k.cu8 (325324 samples, 655360 bytes)
*** Saving signal to file g004_434.601M_250k.cu8 (628230 samples, 1310720 bytes)
^CSignal caught, exiting!

and

 rtl_433 -Y auto -A g003_434.601M_250k.cu8

gives:

rtl_433 version 25.02 (2025-02-19) inputs file rtl_tcp RTL-SDR SoapySDR
[Input] Test mode active. Reading samples from file: g003_434.601M_250k.cu8
Detected OOK package @0.074960s
Analyzing pulses...
Total count:  118,  width: 1070.22 ms (267555 S)
Pulse width distribution:
 [ 0] count:    1,  width: 31448 us [31448;31448] (7862 S)
 [ 1] count:    3,  width: 15664 us [15664;15668] (3916 S)
 [ 2] count:    3,  width: 10524 us [10524;10528] (2631 S)
 [ 3] count:   27,  width: 6080 us [5392;6168] (1520 S)
 [ 4] count:   84,  width: 3084 us [3080;3092] ( 771 S)
Gap width distribution:
 [ 0] count:    1,  width: 15656 us [15656;15656] (3914 S)
 [ 1] count:    3,  width: 10524 us [10524;10528] (2631 S)
 [ 2] count:   27,  width: 6072 us [5388;6164] (1518 S)
 [ 3] count:   84,  width: 3076 us [3072;3080] ( 769 S)
 [ 4] count:    2,  width: 33624 us [33624;33628] (8406 S)
Pulse period distribution:
 [ 0] count:    1,  width: 47104 us [47104;47104] (11776 S)
 [ 1] count:    3,  width: 26188 us [26188;26192] (6547 S)
 [ 2] count:    3,  width: 15916 us [15916;15916] (3979 S)
 [ 3] count:   21,  width: 9132 us [8472;9248] (2283 S)
 [ 4] count:   72,  width: 6160 us [6156;6168] (1540 S)
 [ 5] count:   15,  width: 12320 us [12320;12328] (3080 S)
 [ 6] count:    2,  width: 36712 us [36708;36716] (9178 S)
Pulse timing distribution:
 [ 0] count:    3,  width: 32900 us [31448;33628] (8225 S)
 [ 1] count:    4,  width: 15660 us [15656;15668] (3915 S)
 [ 2] count:    6,  width: 10524 us [10524;10528] (2631 S)
 [ 3] count:   54,  width: 6076 us [5388;6168] (1519 S)
 [ 4] count:  168,  width: 3080 us [3072;3092] ( 770 S)
 [ 5] count:    1,  width: 100004 us [100004;100004] (25001 S)
Level estimates [high, low]:   3719,     12
RSSI: -6.4 dB SNR: 24.9 dB Noise: -31.4 dB
Frequency offsets [F1, F2]:   22640,      0 (+86.4 kHz, +0.0 kHz)
Guessing modulation: No clue...
view at https://triq.org/pdv/#AAB00F060180843D2C291C17BC0C08FFFF8155+AAB035060280843D2C291C17BC0C08FFFF92A3B4C4B3C4B4C3C4B3C4B3C4C4C4C4B4C4C4C4C4C4C4C3B4C4C4C4C4C4C4C3C4B3C4B3C4C4C055+AAB035060180843D2C291C17BC0C08FFFF92A3B4C4B3C4B4C3C4B3C4B3C4C4C4C4B4C4C4C4C4C4C4C3B4C4C4C4C4C4C4C3C4B3C4B3C4C4C555

Some scrolling about in triq.org, thinking, guessing and experimenting leads me to this:

 rtl_433 -X "n=dwpir,m=FSK_PWM,short=3000,long=6000,reset=15000,gap=17900,sync=15660" -f 434.6014595M

gives:

Allocating 15 zero-copy buffers
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:04
model     : dwpir        count     : 2             num_rows  : 2             rows      :
len       : 127          data      : fffffffffffffffffffffffffffffffe,
len       : 0            data      :
codes     : {127}fffffffffffffffffffffffffffffffe, {0}0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:04
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 37           data      : 24bdfdff70
codes     : {37}24bdfdff70
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:04
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 37           data      : 24bdfdff70
codes     : {37}24bdfdff70
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:04
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 37           data      : 24bdfdff70
codes     : {37}24bdfdff70
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:04
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 9            data      : ff8
codes     : {9}ff8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:05
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 24           data      : efffff
codes     : {24}efffff
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:05
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 17           data      : ffff8
codes     : {17}ffff8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:12
model     : dwpir        count     : 2             num_rows  : 2             rows      :
len       : 127          data      : fffffffffffffffffffffffffffffffe,
len       : 0            data      :
codes     : {127}fffffffffffffffffffffffffffffffe, {0}0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:12
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 38           data      : 2b5efeff5c
codes     : {38}2b5efeff5c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:12
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 38           data      : 2b5efeff5c
codes     : {38}2b5efeff5c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:12
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 38           data      : 2b5e7eff5c
codes     : {38}2b5e7eff5c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2025-06-30 17:21:12
model     : dwpir        count     : 1             num_rows  : 1             rows      :
len       : 8            data      : ff
codes     : {8}ff

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rtl_433/12a1b303-8366-4759-b65a-63e490ab5bb4n%40googlegroups.com.

--

Sam Lander

0414 626 080

[Greg Troxel]

[2nd attempt to send]

You are on the right track.

-f is the LO frequency of the receiver. It's not that you need to set
it to the middle of the FSK tones. What you want is some freq f and
sampling rate r such that

(f - r) is a fair bit less than the lowest frequency you need to receive

(f + r) is a fair bit more than the highest frequency you need to receive

you don't really need to receive anything within a kHz or two of f


I realize what you are trying to do about inbound/outbound, but would
suggest:

get rtl_433 to decode each signal

run rtl_433 with "-F syslog:127.0.0.1 1433"

either write some python, or use rtl_433_mqtt_relay to home assistant,
and do automations there

Basically, let rtl_433 decode only, and put the more complicated custom
logic someplace else. The decode part is what rtl_433 does, and others
will want the same decode. Your inbound/outbound, what to do, etc. is
likely just you; others will want different logic. And perhaps want to
fuse a single such PIR sensor with some other sensors that aren't on
rtl_433.

I suspect there is disagreement about long-term use of Flex decoders vs
writing a decoder. It looks like with that flex decode, 37 or 38 is the
right length, and it's sent three times.

Next step is to log that over time and see if you can determine any
structure, or just treat it as an id with a "motion detected event".

You might look at the analog signal and see if there are a cleaner
number of bits if preamble/sync/end-of-message are more crisply
recognized.