Rtl_433: Add support for mightymule driveway alarm FM231

[Ewarren7]

Hi I've got a mighty mule driveway alarm from amazon that alerts when a car passes based on magnetic field change.
FCC id: I6HGTOFM231

Sorry for not posting in the tests repo, but I am on a cellular connection for time being and it was quite a large repo to clone. This is also my first time using SDR so a little behind the curve in general but this project is awesome.

When running -A and tripping the alarm I see a flurry of: a bunch of single pulses, some OOK_PWM and then a a few with a large number of pulses it cannot identify the modulation for.

On the FM231 transmitter and receiver, there are 4 pins that you set to the same one each so this should be part of the encoding. I've been trying with just the 3 pin up to look for something consistent to filter on.

Best I have come up with so far is sometimes I consistently see 1 or more OOK_PWM pulses with 1 row of value below but sometimes I do not see it at all and also there are ones with different values sometimes.

[00] { 9} 72 00     : 01110010 0

Examples

OOK_PWM - Multipulse

Detected OOK package    2020-06-15 17:54:49
Analyzing pulses...
Total count:    9,  width: 15.87 ms     ( 3967 S)
Pulse width distribution:
 [ 0] count:    5,  width: 1232 us [1188;1392]  ( 308 S)
 [ 1] count:    4,  width:  692 us [688;704]    ( 173 S)
Gap width distribution:
 [ 0] count:    8,  width:  864 us [848;888]    ( 216 S)
Pulse period distribution:
 [ 0] count:    4,  width: 2112 us [2060;2256]  ( 528 S)
 [ 1] count:    4,  width: 1556 us [1552;1560]  ( 389 S)
Level estimates [high, low]:   1002,    140
RSSI: -12.1 dB SNR: 8.5 dB Noise: -20.7 dB
Frequency offsets [F1, F2]:  -21958,      0 (-83.8 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with fixed gap
Attempting demodulation... short_width: 692, long_width: 1232, reset_limit: 892, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=692,l=1232,r=892,g=0,t=216,y=0'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 1 
[00] { 9} 72 00     : 01110010 0

Multi pulse - u/k

Detected OOK package    2020-06-15 16:54:35
Analyzing pulses...
Total count:  390,  width: 2965.90 ms       (741476 S)
Pulse width distribution:
 [ 0] count:   28,  width: 3820 us [3812;3840]  ( 955 S)
 [ 1] count:  145,  width: 1228 us [1076;1400]  ( 307 S)
 [ 2] count:  129,  width:  692 us [596;852]    ( 173 S)
 [ 3] count:   62,  width:   52 us [44;60]  (  13 S)
 [ 4] count:    6,  width:  496 us [460;528]    ( 124 S)
 [ 5] count:    3,  width:  356 us [324;384]    (  89 S)
 [ 6] count:    2,  width:  244 us [228;260]    (  61 S)
 [ 7] count:    4,  width:  936 us [900;964]    ( 234 S)
 [ 8] count:    5,  width:  184 us [176;192]    (  46 S)
 [ 9] count:    2,  width: 1884 us [1880;1892]  ( 471 S)
 [10] count:    1,  width:   40 us [40;40]  (  10 S)
 [11] count:    1,  width:   80 us [80;80]  (  20 S)
 [12] count:    2,  width: 2836 us [2692;2984]  ( 709 S)
Gap width distribution:
 [ 0] count:  279,  width:  864 us [844;880]    ( 216 S)
 [ 1] count:   92,  width: 25280 us [24968;25888]   (6320 S)
 [ 2] count:    7,  width:   64 us [56;76]  (  16 S)
 [ 3] count:    6,  width:   44 us [44;52]  (  11 S)
 [ 4] count:    2,  width:   88 us [88;92]  (  22 S)
 [ 5] count:    3,  width:  128 us [112;144]    (  32 S)
Pulse period distribution:
 [ 0] count:   29,  width: 4652 us [3844;4688]  (1163 S)
 [ 1] count:  118,  width: 2100 us [1724;2264]  ( 525 S)
 [ 2] count:  126,  width: 1556 us [1392;1656]  ( 389 S)
 [ 3] count:   92,  width: 25708 us [25024;27076]   (6427 S)
 [ 4] count:   10,  width:  992 us [840;1132]   ( 248 S)
 [ 5] count:    4,  width:  440 us [400;508]    ( 110 S)
 [ 6] count:    1,  width: 2760 us [2760;2760]  ( 690 S)
 [ 7] count:    4,  width:  640 us [584;728]    ( 160 S)
 [ 8] count:    2,  width:  324 us [316;332]    (  81 S)
 [ 9] count:    2,  width:  236 us [228;248]    (  59 S)
 [10] count:    1,  width: 3556 us [3556;3556]  ( 889 S)
Level estimates [high, low]:   1065,    142
RSSI: -11.9 dB SNR: 8.8 dB Noise: -20.6 dB
Frequency offsets [F1, F2]:  -12846,      0 (-49.0 kHz, +0.0 kHz)
Guessing modulation: No clue...

*** Saving signal to file g00

4_433.92M_250k.cu8 (783845 samples, 1572864 bytes)

g004_433.92M_250k.zip

Detected OOK package    2020-06-15 17:54:49
Analyzing pulses...
Total count:  372,  width: 2965.83 ms       (741457 S)
Pulse width distribution:
 [ 0] count:   31,  width: 3824 us [3816;3848]  ( 956 S)
 [ 1] count:  155,  width: 1232 us [1184;1408]  ( 308 S)
 [ 2] count:  124,  width:  692 us [684;712]    ( 173 S)
 [ 3] count:   62,  width:   56 us [48;72]  (  14 S)
Gap width distribution:
 [ 0] count:  279,  width:  860 us [836;876]    ( 215 S)
 [ 1] count:   92,  width: 25276 us [24956;25888]   (6319 S)
Pulse period distribution:
 [ 0] count:   31,  width: 4680 us [4680;4688]  (1170 S)
 [ 1] count:  124,  width: 2108 us [2052;2264]  ( 527 S)
 [ 2] count:  124,  width: 1556 us [1552;1564]  ( 389 S)
 [ 3] count:   92,  width: 25716 us [25024;27076]   (6429 S)
Level estimates [high, low]:   1073,    143
RSSI: -11.8 dB SNR: 8.8 dB Noise: -20.6 dB
Frequency offsets [F1, F2]:  -13098,      0 (-50.0 kHz, +0.0 kHz)
Guessing modulation: No clue...

*** Saving signal to file g011_433.92M_250k.cu8 (783846 samples, 1572864 bytes)

g011_433.92M_250k.cu8.zip

Detected OOK package    2020-06-15 18:06:52
Analyzing pulses...
Total count:  429,  width: 2965.81 ms       (741453 S)
Pulse width distribution:
 [ 0] count:    3,  width:   92 us [84;104] (  23 S)
 [ 1] count:   13,  width: 3008 us [2620;3380]  ( 752 S)
 [ 2] count:  134,  width: 1220 us [992;1396]   ( 305 S)
 [ 3] count:  136,  width:  692 us [564;856]    ( 173 S)
 [ 4] count:   22,  width:  384 us [308;468]    (  96 S)
 [ 5] count:   65,  width:   52 us [44;64]  (  13 S)
 [ 6] count:    3,  width:  144 us [132;160]    (  36 S)
 [ 7] count:   10,  width:  248 us [200;292]    (  62 S)
 [ 8] count:   10,  width:  932 us [892;976]    ( 233 S)
 [ 9] count:   15,  width: 3820 us [3812;3832]  ( 955 S)
 [10] count:    4,  width:  184 us [180;192]    (  46 S)
 [11] count:    5,  width:  512 us [476;544]    ( 128 S)
 [12] count:    1,  width:   72 us [72;72]  (  18 S)
 [13] count:    3,  width:   40 us [40;40]  (  10 S)
 [14] count:    5,  width: 1928 us [1768;2148]  ( 482 S)
Gap width distribution:
 [ 0] count:  280,  width:  864 us [732;880]    ( 216 S)
 [ 1] count:   11,  width:   44 us [44;52]  (  11 S)
 [ 2] count:   92,  width: 25280 us [24964;25892]   (6320 S)
 [ 3] count:   17,  width:   76 us [68;92]  (  19 S)
 [ 4] count:   10,  width:   60 us [56;68]  (  15 S)
 [ 5] count:    1,  width:  324 us [324;324]    (  81 S)
 [ 6] count:    7,  width:  180 us [164;212]    (  45 S)
 [ 7] count:    9,  width:  108 us [96;124] (  27 S)
 [ 8] count:    1,  width:  144 us [144;144]    (  36 S)
Pulse period distribution:
 [ 0] count:   34,  width: 1012 us [768;1228]   ( 253 S)
 [ 1] count:   24,  width: 4368 us [3520;4688]  (1092 S)
 [ 2] count:  111,  width: 2088 us [1768;2264]  ( 522 S)
 [ 3] count:  129,  width: 1540 us [1236;1632]  ( 385 S)
 [ 4] count:   14,  width:  448 us [404;512]    ( 112 S)
 [ 5] count:   92,  width: 25668 us [25024;27076]   (6417 S)
 [ 6] count:    4,  width:  224 us [200;256]    (  56 S)
 [ 7] count:    7,  width: 3032 us [2704;3396]  ( 758 S)
 [ 8] count:    4,  width:  316 us [296;344]    (  79 S)
 [ 9] count:    3,  width:  124 us [116;144]    (  31 S)
 [10] count:    6,  width:  648 us [584;716]    ( 162 S)
Level estimates [high, low]:   1111,    163
RSSI: -11.7 dB SNR: 8.3 dB Noise: -20.0 dB
Frequency offsets [F1, F2]:  -14322,      0 (-54.6 kHz, +0.0 kHz)
Guessing modulation: No clue...

g025_433.92M_250k.cu8.zip

Single pulse

Detected OOK package    2020-06-15 17:54:49
Analyzing pulses...
Total count:    1,  width: 0.05 ms      (   12 S)
Pulse width distribution:
 [ 0] count:    1,  width:   48 us [48;48]  (  12 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]:   1123,    138
RSSI: -11.6 dB SNR: 9.1 dB Noise: -20.7 dB
Frequency offsets [F1, F2]:    1293,      0 (+4.9 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...

Detected OOK package    2020-06-15 17:54:49
Analyzing pulses...
Total count:    1,  width: 0.05 ms      (   13 S)
Pulse width distribution:
 [ 0] count:    1,  width:   52 us [52;52]  (  13 S)
Gap width distribution:
Pulse period distribution:
Level estimates [high, low]:   1358,    168
RSSI: -10.8 dB SNR: 9.1 dB Noise: -19.9 dB
Frequency offsets [F1, F2]:    1308,      0 (+5.0 kHz, +0.0 kHz)
Guessing modulation: Single pulse detected. Probably Frequency Shift Keying or just noise...

[zuckschwerdt]

The tests repo is rather big, we need to come up with some other submission scheme someday ;)

The Mighty Mule FM231 Driveway Alert has a simple OOK pattern with about

• 3800 µs sync pulse
• 600 µs short pulse
• 1200 µs long pulse
• 900 µs gap between pulses.

Only the first block looks right, ignore the rest. It's better to use a flex decoder to filter all the other noise. The suggested decoder looks ok:
-X 'n=FM231,m=OOK_PWM,s=650,l=1200,y=3800,r=1100,t=200'

[Ewarren7]

-X 'n=FM231,m=OOK_PWM,s=650,l=1200,y=3800,r=1100,t=200'

Thanks so much for taking a look. I am unfortunately not having much luck with this. In most cases it isn't catching it.

Using a Raspberry Pi 4 with a RTL2832 fwiw.

-A still seems to give me what appear to me to be varying results.

Additional Samples

I have attached some more results that are what happens a few seconds after triggering the alarm from 3 different distances.

I tried from a few CM away with no antenna, about 2 feet away with an antenna on the SDR, and then about 40 ft away which is where yesterdays sample were taken from.

fm231 no antenna.txt
fm231 antenna close.txt
fm231 antenna 40 ft away.txt
cu8s.zip

Possible Interference?

The SDR is a few feet from an LTE modem active on Sprint LTE bands 25 and 26 but that isn't close to 433 so that shouldn't be much of a factor? Also about 10 ft from a Wifi AP on 2 and 5 ghz and also 10 ft behind a directional 900mhz transceiver.

[Ewarren7]

Just came across this recent post in the google group about it https://groups.google.com/u/0/g/rtl_433/c/bFjn7VxXRE4

There you all also found [00] { 9} 72 00 : 01110010 0 to be the most common thing. Oddly this comes through regardless of what you set the 4 digit code for on transmitter.

It seems that the suggestion there of rtl_433 -X 'n=driveway,m=OOK_PWM,s=670,l=1340,y=3800,r=2000,bits=9' is somewhat reliable but not always. Going to test with it some more.

[Ewarren7]

The above filter only works sometimes. Sometimes I'll see it catch a bunch after I trigger alarm only once and I can repeatedly do this and a few min later at same distance of about 40 ft it just doesn't happen even with numerous triggerings.

I discovered the continuous recording ability and figured that may help. This is from triggering the alarm twice in 12 seconds.
continuous-12secs.cu8.zip
continuous-12secs-analysis.txt

[zuckschwerdt]

That will help. I just need to get around to test why the harmless looking cu8 doesn't demodulate properly.
(sidenote: you are almost off band with the signal, you might want to offset the center frequency a third of the sample rate down, e.g. is this is with the defaults use -f 433.85. Then check that the signal is closer to the middle but not exactly in the middle.)

[Ewarren7]

Thanks, I was starting to think that was the case. However, it seems like it gets weaker even though closer to center when I do that. Less modulated encodings are detected.

Two attempts with -f 433.85M

2x continuous-12secs-with-433-85 cu8s.zip

Additional run at default 433.920MHz

This is slightly closer to the SDR antenna vs yesterdays and using the default frequency. (Same distance as the first image above in this comment)

continuous-12secs- close.cu8.zip

[mshoe007]

@zuckschwerdt wrote:

The Mighty Mule FM231 Driveway Alert has a simple OOK pattern with about

* 3800 µs sync pulse

* 600 µs short pulse

* 1200 µs long pulse

* 900 µs gap between pulses.

Only the first block looks right, ignore the rest. It's better to use a flex decoder to filter all the other noise. The suggested decoder looks ok:
-X 'n=FM231,m=OOK_PWM,s=650,l=1200,y=3800,r=1100,t=200'

I have a MightyMule FM231, and this seems to work. I added 'bits=9' since a valid data message is always nine bits long:

  bit   value
  -----------
    0:  0
    1:  1
    2:  1
    3:  1
    4:  0 -- probably a '1' if low battery ?
    5:  DIP SW #4
    6:  DIP SW #3
    7:  DIP SW #2
    8:  DIP SW #1

@Ewarren7 wrote:

There you all also found [00] { 9} 72 00 : 01110010 0 to be the most common thing. Oddly this comes through regardless of what you set the 4 digit code for on transmitter.

Make sure you remove the battery, change the DIP switches, and then reinsert the battery.

[zuckschwerdt]

Thanks @mshoe007, do you want to create a conf with this info? Look through https://github.com/merbanan/rtl_433/tree/master/conf and put this description and parameters in a new file, then PR.
(e.g. use get=@4:{1}:battery, get=@5:{1}:dip1,...)

[mshoe007]

I'd already created a .conf file, but I wasn't sure enough of it to post.

# Decoder for the Mighty Mule FM231 Driveway alarm from GTO Inc
# FCC Test report, including RF waveforms is here:
#   https://fccid.io/I6HGTOFM231/Test-Report/Test-Report-1214140.pdf

# Use the Accurite and similar convention for reporting battery.
# The name is 'battery_ok' with values 1 (ok) and 0. (which are
# numerically reversed from what the FM231 reports)

# The DIP switches for setting a unique device ID are labeled 1-4
# from left to right, but appear in the # data stream in reverse
# order.

decoder {
    name=MightyMule-FM231,
    modulation=OOK_PWM,
    short=650,
    long=1200,
    sync=3800,
    reset=1100,
    tolerance=200,
    rows=1,
    bits=9,
    get=@4:{1}:battery_ok:[0:1 1:0],
    get=@5:{4}:id:[0:0 1:8 2:4 3:12 4:2 5:10 6:6 7:14 8:1 9:9 10:5 11:13 12:3 13:11 14:7 15:15],
    unique
}

This file works for me with '-c MightMule-FM231.conf' added to the rtl_433 command line.

The DIP switches on the sensor for setting the device ID are labeled 1 to 4, left to right.

If switch #1 is the only one set, my inner geek really wanted that to be id=8, but because the bits are reversed in the data stream, get=@5:{4}:id, would report the ids incorrectly. Is there a prettier way to reverse the bits within a field?

Thanks

[zuckschwerdt]

There is no generally accepted way here. Transmitting the MSBit first seems prevalent, maybe similar to network byte order as big endian (though only MSByte there). But my OCD isn't triggering :) seeing DIP#1 as lowest order bit looks natural too.
If there is no indication to bit order on the DIPs I'd likely use just get=@5:{4}:id. Add this file as PR to the conf folder if you like, then you get proper attribution in the commits.

[Ewarren7]

@zuckschwerdt @mshoe007 Thanks so much for following back up on this and posting conf. 👍

I think my problem all along must have been RF interference, I'm guessing from the pi itself which is on poe and possibly nearby poe camera. I initially was still getting extremely sporadic results with your conf but after looking into pi sdr interference and seeing some ppl mention poe as a problem I tried a 6 ft USB extension and plugged SDR into that. If SDR is in straight line about 6 ft away from pi and position SDR on side closer to FM231 it is working so much more reliably.

Now I have combined it with https://github.com/NorthernMan54/homebridge-rtl as a motion sensor on homekit via homebridge and now have an electromagnetic car sensor which for someone reason no one natively makes.

homebridge-rtl Homebridge Integration

FYI for those curious on how to integrate with https://github.com/NorthernMan54/homebridge-rtl
I put a slightly modified version of the conf posted here into /usr/local/etc/rtl_433/rtl_433.conf so it is treated as a device. (see below)

I just added get=@0:{1}:motion:[0:true 1:true], bc that is what homebridge-rtl built in support for motion sensor device expects and it will return motion: true on any triggering. Then in homebridge, I installed his plugin and added in my conf the below where id is the ID you get from you dip switch settings and will see from just running rtl_433 '-c MightMule-FM231.conf. Now it will trigger a homekit motion sensor when car is detected and automatically turns it off after a few min.

homebridg conf

      {
            "platform": "rtl_433",
            "devices": [
                {
                    "id": "8",
                    "name": "Car Motion",
                    "type": "motion"
                }
            ]
        }

/usr/local/etc/rtl_433/rtl_433.conf

# Decoder for the Mighty Mule FM231 Driveway alarm from GTO Inc
# FCC Test report, including RF waveforms is here:
#   https://fccid.io/I6HGTOFM231/Test-Report/Test-Report-1214140.pdf

# Use the Accurite and similar convention for reporting battery.
# The name is 'battery_ok' with values 1 (ok) and 0. (which are
# numerically reversed from what the FM231 reports)

# The DIP switches for setting a unique device ID are labeled 1-4
# from left to right, but appear in the # data stream in reverse
# order.

decoder {
    name=MightyMule-FM231,
    modulation=OOK_PWM,
    short=650,
    long=1200,
    sync=3800,
    reset=1100,
    rows=1,
    bits=9,
    get=@4:{1}:battery_ok:[0:1 1:0],
    get=@5:{4}:id,
    get=@0:{1}:motion:[0:true 1:true],
    unique
}