Add device for GE Choice Alert wireless alarm sensors

[wst-tdb]

Add device for GE Choice Alert wireless alarm sensors

[zuckschwerdt]

Thanks! If there is no checksum or complicated mapping this should also work as flex decoder, e.g. try

decoder {
        name  = Jasco/GE Choice Alert Security Devices,
        modulation = OOK_PWM,
        short = 248,
        long  = 512,
        reset = 1548,
        sync  = 1540,
        bits>=25,
        bits<=27,
        get = @0:{3}:preamble,
        get = @3:{16}:id,
        get = @19:{1}:closed,
        get = @20:{6}:message,
}

[wst-tdb]

That is how I started for the most part after sniffing the data out, but it doesn't validate the preamble in packet processing. There are situations that I have seen in testing that throw valid packet length decoded transmissions that don't have the correct preamble. I also suspect that the un-decoded bits do have a checksum as all the sensors are different, and the open / closed messages are always the same... I just haven't gathered enough data to speculate further as I've only fired up a handful of the sensors at this point.

[zuckschwerdt]

Can you post a zip with a sample (-S unknown) here, and a list of codes you got so far? I'll look into the checksum then.

[wst-tdb]

there are 6 different unique packets plus (their repeats), as well as their decoded data using just the raw flex device
-X 'n=name,m=OOK_PWM,s=248,l=512,r=1548,g=0,t=0,y=1540'

Using the flex filter proposed
-X 'n=name,m=OOK_PWM,s=248,l=512,r=1548,g=0,t=0,y=1540,bits>=25, bits<=27, get = @0:{3}:preamble, get = @3:{16}:id, get = @19:{1}:closed, get = @20:{7}:message,'

does pull the unknown data to the message field.

sample.zip

[zuckschwerdt]

Oh, that's not PWM. Looks like Manchester PCM with a nice de-sync preamble of 0xFC0C (11111100000011000) ;) Inspect the PDV links. E.g.
https://triq.org/pdv/#AAB00F060105F8020C010800D0031C3AEC8055+AAB028060105F8020C010800D0031C3AEC94A2A2B2A2919192A2A2A2A2A2A1A2A291A2A2A2A292A19191A555

The raw demod is thus rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=250,l=250,r=1800' g001_318.01M_250k.cu8
The MC should be roughly rtl_433 -R 0 -X 'n=name,m=OOK_MC_ZEROBIT,s=250,l=250,r=1800,preamble=5' g001_318.01M_250k.cu8
That way you also always get a nice 32 bits. (note that preamble "5" is 0x5 == 0b0101 the badly decoded 0xfc0c)

The true codes thus are:

• g001_318.01M_250k.cu8 : 05 7f 10 6a
• g002_318.01M_250k.cu8 : 05 7f 11 6b
• g003_318.01M_250k.cu8 : e8 7b 11 82
• g004_318.01M_250k.cu8 : e8 7b 11 82
• g005_318.01M_250k.cu8 : e8 7b 10 83
• g006_318.01M_250k.cu8 : e8 7b 11 82
• g007_318.01M_250k.cu8 : 85 f3 10 66
• g008_318.01M_250k.cu8 : 85 f3 11 67
• g009_318.01M_250k.cu8 : 85 f3 10 66

The checksum is an XOR. But somehow the top bits are amiss. See this BitBench.

[zuckschwerdt]

OK, slight error: turns out the gap after the preamble is important. The preamble is exactly 0xfc0c (16 bit), the next 0 is already part of the MC. See this BitBench. Now the checksum works fine.

[wst-tdb]

That makes sense. I've updated the code to reflect this and parse out the values and all seems to be working.

One thing I noticed is that bitbuffer_manchester_decode doesn't reset the destination variable, it just adds to it - which means if you call it without explicitly clearing your destination variable every time you end up with multiple outputs packed into each row because it just keeps adding to it... which feels like a bug (though being C may be expected behaviour?). If it's expected, should a note be added so that people new to the source know that is expected? lol

[zuckschwerdt]

Also the var crc should be chk, and the output "CRC" should be "mic" (copy from any other decoder).