Help with decoding kinetic switch signals

[arktronic]

Hello,

I have a couple of no-name single-button kinetic switches, and I'm uncertain as to how to go about decoding their signals. I have captured signals using -A from both, and the modulation guess is "No clue", unfortunately.

The first switch signals include:

• https://triq.org/pdv/#AAB107005000B80030013C02CC03E4271485908090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A08655
• https://triq.org/pdv/#AAB107005000B80030013C02CC03EC27148590A090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A0B0B09655
• https://triq.org/pdv/#AAB107005000B80030013C02CC03E8271485908090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A0A655
• https://triq.org/pdv/#AAB107005000B80030013C02C803EC271485908090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A0B0B0C090A0A0A09590A090A09655
• https://triq.org/pdv/#AAB108005000BC0030013C02CC000003E4002486908090A0B0B0C090A0A0A09690A090A0B0B0C090A0A0A09690A090A0B0B0C090D755

The second switch signals are:

• https://triq.org/pdv/#AAB107005000BC0034013C01C003E827148592809090B0B0A0A090C0A0A09590A09090B0B0A0A090C0A0A095A655
• https://triq.org/pdv/#AAB108005000BC0030013C01C403E4004027148592A09090B0B0A0A090C0A0A09590A09090B0B0A0A090C0A0A09590A09090B0B0A0A08755
• https://triq.org/pdv/#AAB107005000BC0034013801C403E027148592A09090B0B0A0A090C0A0A09590A09090B0B655
• https://triq.org/pdv/#AAB107005000B8013C002C01C403E027148590809090A0A0B0B090C0B0B09590B09090A0A0B0B09655

Any help would be appreciated!

Please let me know if I need to capture more data. I'll have to find an isolated location, because currently I've got a fair bit of 433MHz noise around me.

Thanks!

[zuckschwerdt]

The signals look consistent but strange enough that a raw cu8 capture would be interesting to look at. E.g. all gaps are 80 µs so zeros are not likely to be encoded as gaps. The pulses don't show a clear timing with 48 µs, 80 µs, 184 µs, 316. µs, 712 µs. It could be that 48 is a 0, 80 is a 10, 184 is a 1110? But that's a wild guess.

[ProfBoc75]

Yes, we need cu8 samples to confirm that.

And with OOK_PCM, s = l = 45, Could be symbol 0 = 111 and symbol 1 = 100 or the reverse ? Gap is around 995 µs / 1000 µs

rtl_433 -X "n=switch,m=OOK_PCM,s=45,l=45,r=200,g=995,bits>=72,repeats>=2,symbol_zero={3}e,symbol_one={3}8"

Edit: add bits>=72 and repeats>=2 options to filter the result. 72 bits because of the symbols are 3 bit length, so 3x24 bits = 72 and repeats, because the signal repeats 3 or 4 times. Later, you can add unique option to get only one message.

Result:

switch	0 = 111 , 1 = 100	0 = 100, 1 = 111
first	{25}6c905e8	{25}936fa10
second	{25}6a4e8e8	{25}95b1710

And probably the last nibble is useless due to the start bit before the gap and then 3 byte messages {24}. For this simple device, a conf file should be enough.

Try several tests with long press, multiple quick press (2 , 3 or 4 press), to see if any changes in the result.

[arktronic]

Thanks so much, @zuckschwerdt and @ProfBoc75! I'll try to capture cu8 samples in a more isolated environment, and I'll try the -X configuration as soon as I can.

Thanks again!

[ProfBoc75]

little update: (see my previous edited post)

rtl_433 -X "n=switch,m=OOK_PCM,s=45,l=45,r=200,g=995,bits>=72,repeats>=2,symbol_zero={3}e,symbol_one={3}8"

[arktronic]

Here are the captures: rtl_433-win-x64-23.11-cu8-captures.zip

@ProfBoc75, the new -X line did not work, but the previous one (-X "n=switch,m=OOK_PCM,s=45,l=45,r=200,g=995,symbol_zero={3}e,symbol_one={3}8") was able to recognize the signals. It got some empty ones in addition to one with data.

[zuckschwerdt]

The signal is somewhat too loud (clipping) but the samples all look good.. Looking at a random sample I don't see the different pulse lengths. It looks like PWM but with very short gaps (that might not be picked up).

[ProfBoc75]

Yes, the signal is not easy to decode and we need to got through symbols to simulate the PWM from PCM.

Notice also the pulse duration is not stable along the rf signal (bigger at the beginning and smaller at the end).

My previous proposition was wrong at reset level, too short, you can try with r=2000 but the result is not good since all the repeats message are not exactly identical.

I got better results with this one: (symbol with 2 bit instead 3, so pulse is longer , symbol 0 = 11, symbol 1 = 10 )

rtl_433 -X "n=test,m=OOK_PCM,s=65,l=65,r=2000,g=800,bits>=48,symbol_zero={2}c,symbol_one={2}8" *.cu8

If repeats>=2, then no message in the g005...cu8, it's excluded since the signal is too short without repeat.

rtl_433 -X "n=test,m=OOK_PCM,s=65,l=65,r=2000,g=800,bits>=48,repeats>=2,unique,symbol_zero={2}c,symbol_one={2}8" *.cu8

result extract:

From that you can play with flex decoder:

rtl_433 -X "n=test,m=OOK_PCM,s=65,l=65,r=2000,g=800,bits>=48,repeats>=2,unique,symbol_zero={2}c,symbol_one={2}8,get=@0:{24}:code:[0x6c905e:Switch1 0x6a4e8e:Switch2]"

Or create a conf file on the same basis.

[arktronic]

Sorry about the signal quality. Is this a better capture? In -A mode, it's showing values around RSSI: -12.1 dB SNR: 13.2 dB Noise: -25.3 dB. (I'm not sure what good values should be.) Thank you!

switch1-300k.zip switch2-300k.zip

[ProfBoc75]

Hi @arktronic : your samples are worse, and too short.

Anyway, you have 2 possibilities to decode your rf signal, based on my previous analysis:

Using the small pulse at 45 µs and symbols of 3 bit , 0 = 111 and 1 = 100
Using the large pulse at 65 µs and symbols of 2 bit,  0 = 11 and 1 = 10

Both will give you the same data, {24}0x6c905e for Switch1 and {24}0x6a4e8e for Switch2. To get a better chance to have answer we can remove the repeats and just filter out the message too short:

rtl_433 -X "n=test,m=OOK_PCM,s=45,l=45,bits>=72,r=2000,g=800,symbol_zero={3}e,symbol_one={3}8,get=@0:{24}:code:[0x6c905e:Switch1 0x6a4e8e:Switch2]"
rtl_433 -X "n=test,m=OOK_PCM,s=65,l=65,bits>=48,r=2000,g=800,symbol_zero={2}c,symbol_one={2}8,get=@0:{24}:code:[0x6c905e:Switch1 0x6a4e8e:Switch2]"

I tried the both above lines from all your samples, the first with short pulse is working better on your last samples, and the second with long pulse is working better on your first samples. I can't give you better information from my side.

[arktronic]

Thanks so much! This will work for my purposes.

[arktronic]

For future reference, this is the device listing: https://www.aliexpress.us/item/3256805191409087.html

I ended up going with the following decoding to eliminate false positives: -X "n=sixwgh-kinetic,m=OOK_PCM,s=65,l=65,bits>=48,r=2000,g=800,symbol_zero={2}c,symbol_one={2}8,preamble={1}8,repeats>=2,rows<=6,get=@0:{24}:code:[24445:Switch1 30687:Switch2]"

EDIT: I am now doing get=@0:{32}:code because I got more switches that were just reporting 0.

Thanks again!