Added KeeLoq decoder

[rzondr]

Hi,
as discussed on libera chat here my PR about KeeLoq decoder
"20:55:59 rzondr: Please open a PR on the libsigrokdecode repo so we can properly keep track of your submission"
Very happy to contribute.

[antoniovazquezblanco]

Hi! I am interested in your decoder. Actually I am interested in the keeloq decoder and also your "bit" decoder...

From what I found in your source code, you have made a single decoder for what I understand may be two different things...

1. OOK (On–off keying) https://en.wikipedia.org/wiki/On%E2%80%93off_keying - It seems that you are receiving an OOK signal and from that signal you are able to extract bits. This is usefult for later decoding Keeloq but I would say that many remotes use this encoding and do not use Keeloq on top...
2. Keeloq - The digital protocol used to exchange information about the remote and the pressed keys...

I think it would be useful to separate theese two into two layers that can be used separately.

(Just to clarify, I am not part of the Sigrok team, I am just another user).

Thanks for your decoder!

[rzondr]

Antonio, let me thank you first, because it is always worth having a different point of view.You are right in thinking that OOK could be the lower layer where the ASK is implemented,
Doing so the upper layers would interpret the KeeLoq.I'll take this into consideration for the next version (V2?).
However, there are a lot of long periods of '0' and '1' in the real case scenario , which I'm not entirely sure are compatible with OOK/ASK.
With that said, I'm interested in producing a KeeLoq decoder able to decode signals transmitted by different chips.
I've really appreciated your considerations.

Kind regards,Andrea

[rzondr]

Antonio, you made me curious about the On-Off Keying so I've added it to Pulseview, making it working in parallel with my decoder.
As you can see, OOK doesn't recognizes the "0" and "1" in the same way as KeeLoq does .
Thus, definitely OOK cannot be used as the lower level of future KeeLoq Implementations.

I hope this answers to your questions.
Regards,
Andrea

[TRothfelder]

Hello Andrea,
I tried your decoder and it works, most of the time. I sometimes had trouble decoding because my remote was not as accurate as your timings were. Therefore I changed the timings to match the datasheet.

self.TE_Timing = [ 260e-6, 660e-6, 520e-6, 1320e-6, 2.6e-3, 6.6e-3 ]

I do absolutlely have no clue whether this introduces problems because of the overlapping timings of the 1s and 0s.
The second thing I corrected was the bit significance in the serial and encrypted portion. According to the datasheet, the protocol is sending LSB first. So I added

def RevBin2Hex (self):
        decimal_value = int(self.BitString[::-1], 2)
        # Convert integer to hexadecimal
        hex_value = hex(decimal_value)
        return ( hex_value.upper() )

and used this method to calculate the serial and encrypted part.

self.KeyLoq["Serial-Number"] = self.RevBin2Hex ()

self.KeyLoq["Encrypted"] = self.RevBin2Hex ()

Kind regards
Tobias

[rzondr]

HI Tobias,
I really appreciated you comments and changes.
Could you please send me some samples of your captures , as well as the integrated circuit id ?
Target for this decoder is to be compliant with a vast variety of KeeLoq ICs.

Take a look at
https://github.com/rzondr/KeeLoq_decoder?tab=readme-ov-file#how-to-contribute
About how to contribute .
Thanks in advance
Andrea

[rzondr]

Tobias,
Looking at your picture, it refers to Code Format and significance (LSB-MSB). I believe that the right sequence is reported here :

which shows that Encrypted sequence is transmitted first followed by the Fixed Portion.
I wrote the code looking at that image.

However, I compared results of my code with other tools such as Flipper Zero and they match perfectly.
What Flipper Zero doesn't show is whether the Button is kept pressed and if the Battery is Low/High.
This decoder is thought to fully show full information about the Code Word.

Thus, please send me your samples and I'll check your software changes.
Regards,
Andrea

[TRothfelder]

Hello Andrea,
sorry, I didn't read your Readme. You are right. The encrypted part is transmitted first followed by the fixed portion. Figure 9-4 shows the data on the time domain. Whereas Figure 4-1 shows the data how it would be written. So PulseView and Figure 9-4 should be identical.

The values for button status, vlow and repeat are correct. It is just about the order of the bits within the serial and within the encrypted part. You are adding the bits to a string. This means the first bit (LSB) is on the left and the last bit (MSB) is on the right since you get LSB first. Python expects the MSB on the left. ( int("10",2) is 2 not 1). It is like this right now:

I send you further information with data from my chip via mail.

Edit:
Another way would be to change

self.BitString = self.BitString + self.Decode_LogicalBit(t)

to

self.BitString = self.Decode_LogicalBit(t) + self.BitString

for serial and encryption part.

Regards,
Tobias

[rzondr]

Hi Tobias,
just to recap things : LSB is transmitted first as reported here :

But in order to convert the Binary value in Hex we must revert the bit order so that the LSB is located at the RIGHT whereas the MSB on the left.
In light of this, I've just released Version 0.2 here :
https://github.com/rzondr/KeeLoq_decoder