Support for McPower battery-less buttons

[Sola85]

I recently bought one of these McPower 'Kinetic' Switches to play around with. They don't seem to be supported yet (and I think they are different from the ones discussed in #1790 and #2267).

I don't know yet if I'll get around to writing a decoder, but I'll share my findings here anyway, in case someone is interested.

The buttons transmit FSK'd at 433.92 MHz with PCM at a datarate of 100 kbps. Each transmission consists of a variable number of rows (depending on when the power runs out), each containing around 88 bits and starting with a preamble of aaaa.
Due to the high data rate, I only get reliable results at a sample rate of 2M.

Using -s 2M -X 'name=McPower-Kinetic,modulation=FSK_PCM,short=10,long=10,reset=10000,gap=240,preamble=aaaa', I have collected the following data:

Right button:
0ea8 2 0 40 cfa6 000000
0ea8 2 1 40 fc97 000000
0ea8 2 2 40 a9c4 000000
0ea8 2 3 40 9af5 000000
0ea8 2 4 40 0362 000000
0ea8 2 5 40 3053 000000
0ea8 2 6 40 6500 0000
0ea8 2 7 40 5631 000000
0ea8 2 8 40 460f 000000
0ea8 2 9 40 753e 000000
0ea8 2 a 40 206d 000000
0ea8 2 b 40 135c 000000
0ea8 2 c 40 8acb 000000
0ea8 2 d 40 b9fa 000000
0ea8 2 e 40 eca9 000000
0ea8 2 f 40 df98 000000
0ea8 2 0 40 cfa6 000000
0ea8 2 1 40 fc97 000000

Left button:     
0ea8 4 2 40 a2ee 000000
0ea8 4 3 40 91df 000000
0ea8 4 4 40 0848 000000
0ea8 4 5 40 3b79 000000
0ea8 4 6 40 6e2a 000000
0ea8 4 7 40 5d1b 000000
0ea8 4 8 40 4d25 000000
0ea8 4 9 40 7e14 000000
0ea8 4 a 40 2b47 000000
0ea8 4 b 40 1876 000000
0ea8 4 c 40 81e1 000000
0ea8 4 d 40 b2d0 00000
0ea8 4 f 40 d4b2 000000
0ea8 4 0 40 c48c 000000
0ea8 4 1 40 f7bd 000000
0ea8 4 2 40 a2ee 000000
0ea8 4 3 40 91df 000000
0ea8 4 4 40 0848 000000
0ea8 4 5 40 3b79 000000

No button (i.e. triggering the energy harvesting mechanism with removed button caps):
0ea8 0 7 40 50d7 000000
0ea8 0 8 40 40e9 000000
0ea8 0 9 40 73d8 000000
0ea8 0 a 40 268b 000000
0ea8 0 b 40 15ba 000000
0ea8 0 c 40 8c2d 000000
0ea8 0 d 40 bf1c 000000
0ea8 0 e 40 ea4f 000000
0ea8 0 f 40 d97e 000000
0ea8 0 0 40 c940 00000
0ea8 0 1 40 fa71 000000
0ea8 0 2 40 af22 000000
0ea8 0 3 40 9c13 000000
0ea8 0 4 40 0584 000000
0ea8 0 5 40 36b5 000000
0ea8 0 6 40 63e6 000000
0ea8 0 7 40 50d7 000000
0ea8 0 8 40 40e9 000000

Which suggests the following interpretation (ignoring the final zero's which come from the gap between rows):

    Byte 0   Byte 1   Byte 2   Byte 3   Byte 4   Byte 5
    IIIIIIII IIIIIIII BBBBSSSS xxxxxxxx KKKKKKKK KKKKKKKK 

- I = ID ??? (16 bits)
- B = Button that was pressed (4 bits, values 0, 2 or 4 seen)
- S = Sequence counter, resets after 16 button presses (4 bits)
- x = Unknown, always seen as 40 (8 bits)
- K = Checksum ??? (16 bits)

Since I only have a single unit, i cannot verify that what I think is the ID is actually an ID. I have also not yet attempted to reverse-engineer the checksum, and I guess this is rather challenging with only a single unit (and hence ID) available.

[ProfBoc75]

@Sola85

Reduce the reset value to remove the trailing zeros.

Looks good for data layout.

K is CRC-16, poly 0x1021, init 0xaa55, final XOR 0x0000

reveng -w 16 -s 0ea84040c48c 0ea84140f7bd 0ea84240a2ee 0ea8434091df 0ea844400848 0ea82040cfa6 0ea82140fc97 0ea82240a9c4 0ea823409af5
width=16  poly=0x1021  init=0xaa55  refin=false  refout=false  xorout=0x0000  check=0x45cf  residue=0x0000  name=(none)

Data layout with Bitbench

[Sola85]

Thanks @ProfBoc75! I didn't know either of these tools. Sure saves a bunch of time!