Advice for decoding Radio Shack mailbox notifier

[dosman33]

Greetings,

So I'm trying to learn how to do some signal analysis and hitting a wall, any advice would be appreciated. I took a swag at trying to decode a very simple but old mailbox sensor to learn how to use rtl_433 for decoding unknown signals. I have two captures, one for two of the three different identifiers the device can transmit (an A/B/C switch to uniquely identify this mailbox transmitter to the receiver). I made some captures like this: rtl_433 -S unknown

Then I ran the analysis like this: rtl_433 -r g001.cu8 -a 4 -A

That gave me some output which included this: ... Guessing modulation: Pulse Width Modulation with multiple packets Attempting demodulation... short_width: 252, long_width: 1724, reset_limit: 13488, sync_width: 0 Use a flex decoder with -X 'n=name,m=OOK_PWM,s=252,l=1724,r=13488,g=1724,t=588,y=0'

So the flex string does not seem to really work, at least its not giving me any data that changes when the A/B/C switch changes. Looking at the waveform in URH I suppose it could be PWM, but it really seems more like some form of Manchester to my untrained eye. It seems to me there is a clue in the notch that immediately follows the wide pulses, but I don't seem to have enough brain cells firing to go any further than that. The yellow trace is for the "B" identifier, and the black trace is for the "A" identifier. Any suggestions would be appreciated.

Thanks, -dosman

chanA_g002_315M_250k.cu8.zip chanB_g001_315M_250k.cu8.zip

[dosman33]

And to clarify, the sensor is a Radio Shack brand mailbox notifier from the early 2000's, schematic available here: https://fccid.io/AAO6301110/Schematics/Circuit-Diagram-109112

[merbanan]

Can you post the complete analyzer (-A) output? You can tell alot from it.

[zuckschwerdt]

If you convert the samples (cu8) to Pulse text (ook) you can see what the waveforms above decode to (AM modulation). Then drop the file in https://triq.org/pdv/ to visualize and play with decoding.

rtl_433 -w chanA_g002_315M_250k.ook chanA_g002_315M_250k.cu8

[zuckschwerdt]

Ok, one step before that (the ook shows broken data). Drop the cu8 file on https://triq.org/iqs/ and you can see that the signal frequency is barely in range. Better tune to -f 315.1M and get another sample.

[dosman33]

Thanks for the quick responses. I will capture another packet tonight after work at 315.1M. Here is the complete -A output though in the mean-time:

rtl_433 -r chanB_g001_315M_250k.cu8 -a -A rtl_433 version unknown inputs file rtl_tcp RTL-SDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "rtl_433.conf"... Trying conf file at "/home/dosman/.config/rtl_433/rtl_433.conf"... Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"... Trying conf file at "/etc/rtl_433/rtl_433.conf"... Reading conf from "/etc/rtl_433/rtl_433.conf". Protocol [31] "TFA-Twin-Plus-30.3049, Conrad KW9010, Ea2 BL999" does not take arguments ", Conrad KW9010, Ea2 BL999"! Protocol [33] "WT450, WT260H, WT405H" does not take arguments ", WT260H, WT405H"! Protocol [40] "Acurite 592TXR Temp/Humidity, 5n1 Weather Station, 6045 Lightning" does not take arguments ", 5n1 Weather Station, 6045 Lightning"! Protocol [42] "HIDEKI TS04 Temperature, Humidity, Wind and Rain Sensor" does not take arguments ", Humidity, Wind and Rain Sensor"! Protocol [73] "LaCrosse TX141-Bv2, TX141TH-Bv2, TX141-Bv3 sensor" does not take arguments ", TX141TH-Bv2, TX141-Bv3 sensor"! Protocol [74] "Acurite 00275rm,00276rm Temp/Humidity with optional probe" does not take arguments ",00276rm Temp/Humidity with optional probe"! Protocol [75] "LaCrosse TX35DTH-IT, TFA Dostmann 30.3155 Temperature/Humidity sensor" does not take arguments ", TFA Dostmann 30.3155 Temperature/Humidity sensor"! Protocol [78] "Fine Offset Electronics, WH25, WH32B, WH24, WH65B, HP1000 Temperature/Humidity/Pressure Sensor" does not take arguments ", WH25, WH24, WH65B, HP1000 Temperature/Humidity/Pressure Sensor"! Protocol [79] "Fine Offset Electronics, WH0530 Temperature/Rain Sensor" does not take arguments ", WH0530 Temperature/Rain Sensor"! Protocol [95] "Schrader TPMS EG53MA4, PA66GF35" does not take arguments ", PA66GF35"! Registered 106 out of 136 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-103 108-116 119 121 124-128 130-135 ] Test mode active. Reading samples from file: chanB_g001_315M_250k.cu8 *** signal_start = 21373, signal_end = 41376, signal_len = 20003, pulses_found = 1 Distance coding: Pulse length 2

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 2 bitbuffer:: Number of rows: 0 Detected OOK package 2020-03-10 11:18:15.898163 Analyzing pulses... Total count: 828, width: 2153.05 ms (538263 S) Pulse width distribution: [ 0] count: 92, width: 1724 us [1720;1740] ( 431 S) [ 1] count: 736, width: 252 us [244;272] ( 63 S) Gap width distribution: [ 0] count: 92, width: 236 us [228;244] ( 59 S) [ 1] count: 690, width: 1708 us [1692;1720] ( 427 S) [ 2] count: 45, width: 13476 us [13472;13484] (3369 S) Pulse period distribution: [ 0] count: 782, width: 1960 us [1956;1976] ( 490 S) [ 1] count: 45, width: 13728 us [13724;13736] (3432 S) Level estimates [high, low]: 2751, 166 RSSI: -7.7 dB SNR: 12.2 dB Noise: -19.9 dB Frequency offsets [F1, F2]: 20266, 0 (+77.3 kHz, +0.0 kHz) Guessing modulation: Pulse Width Modulation with multiple packets Attempting demodulation... short_width: 252, long_width: 1724, reset_limit: 13488, sync_width: 0 Use a flex decoder with -X 'n=name,m=OOK_PWM,s=252,l=1724,r=13488,g=1724,t=588,y=0' pulse_demod_pwm(): Analyzer Device bitbuffer:: Number of rows: 25 [00] {18} 77 ff c0 : 01110111 11111111 11 [01] {18} 77 ff c0 : 01110111 11111111 11 [02] {18} 77 ff c0 : 01110111 11111111 11 [03] {18} 77 ff c0 : 01110111 11111111 11 [04] {18} 77 ff c0 : 01110111 11111111 11 [05] {18} 77 ff c0 : 01110111 11111111 11 [06] {18} 77 ff c0 : 01110111 11111111 11 [07] {18} 77 ff c0 : 01110111 11111111 11 [08] {18} 77 ff c0 : 01110111 11111111 11 [09] {18} 77 ff c0 : 01110111 11111111 11 [10] {18} 77 ff c0 : 01110111 11111111 11 [11] {18} 77 ff c0 : 01110111 11111111 11 [12] {18} 77 ff c0 : 01110111 11111111 11 [13] {18} 77 ff c0 : 01110111 11111111 11 [14] {18} 77 ff c0 : 01110111 11111111 11 [15] {18} 77 ff c0 : 01110111 11111111 11 [16] {18} 77 ff c0 : 01110111 11111111 11 [17] {18} 77 ff c0 : 01110111 11111111 11 [18] {18} 77 ff c0 : 01110111 11111111 11 [19] {18} 77 ff c0 : 01110111 11111111 11 [20] {18} 77 ff c0 : 01110111 11111111 11 [21] {18} 77 ff c0 : 01110111 11111111 11 [22] {18} 77 ff c0 : 01110111 11111111 11 [23] {18} 77 ff c0 : 01110111 11111111 11 [24] {18} 77 ff c0 : 01110111 11111111 11 ... Maximum number of rows reached. Message is likely truncated.

Iteration 1. t: 0 min: 0 (0) max: 0 (0) delta -727379968 Iteration 2. t: 0 min: 0 (0) max: 0 (0) delta 0 Distance coding: Pulse length 0

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 0 bitbuffer:: Number of rows: 0

---

And I guess I should do full-disclosure. I had tried the auto-generated flex string to decode the live signal but it was decoding garbage from noise so that really threw me and made me think it's not properly decoding the signal. However it seems to decode my capture files perfectly every time though which adds to my confusion here. Thanks.

[klohner]

The signal seems to be repetitions of a message as shown in this bitbench.

This worked for me to decode one of the sample files:

rtl_433 -r chanB_g001_315M_250k.cu8 -X n=RS_Mail_Guard,m=OOK_PWM,s=240,l=1680,r=10000,invert

[klohner]

@dosman33, I see you're using URH to view the signal. Here's my method for doing a signal cleanup in URH to get nice looking data:

1. Change view to Spectrogram and highlight the narrow horizontal band of the signal that looks like data. When I look at chanA_g002_315M_250k, this is about 32KHz of bandwidth near the top of the signal. Right-click on the signal and choose Apply Bandpass Filter.

2. In the result, highlight the part of the sample which includes the signal. In this example, it's the last half of the sample. Right-click and Crop To Selection.

3. In Analog view, highlight a bit of the noise between each data repetition. Right-click and choose Set Noise Level From Selection.

4. Switch to Demodulated view. Look at the width of one of the smallest pulses. Set the Samples/Symbol value to this width. In this example, 60 looks about right.

After these steps, you should get data like I put in the bitbench link above.

[dosman33]

Thanks to everyone for the advice and input, I greatly appreciate it. And thanks for the signal cleanup guide on URH, that helps a lot, I was largely unaware of what all one could do to the signal in the interface.

So in response to the flex decoding string like this one : rtl_433 -r chanB_g001_315M_250k.cu8 -X n=RS_Mail_Guard,m=OOK_PWM,s=240,l=1680,r=10000,invert

This works on my captured samples just as the ones I've provided. However when running them against live data being captured they produce endless garbage false-positives. I found one partial solution was to add "repeats>=10" or similar to the string, but now I'm getting intermittent results even with that. Is this normal, to get false-positives on live data from a flex string that otherwise works on captured samples? Ultimately I'd like to put this into my config file so it automatically captures this sensor just like any of the built-in decoders, but as it stands I can't do that as it will log tons of garbage false-positives. Thanks.

[zuckschwerdt]

If you only care about a single valid code then use e.g. ,match=77ff, where 77ffis a fixed part of the code.

[zuckschwerdt]

re false-positives, yes PWM will match easily. Some way to reduce that is to demand a minimum number of cleanly decoded bits bits>=18 or even a fixed size bits=18.