Support for McPower battery-less buttons #3102
Description
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.