manchester decode

[PrinceNai]

Yes, you said they are the same. Any press on any of the remotes turns the load on? And off?

[bulut_01]

[temtronic]

hmm, looking at the data.....
it appears that 0x78 might be the 'preamble' data, used to wakeup a sleeping receiver, 0xF8 and 0x66 are the 'start of transmission' marker
the next 10 bytes are then 5 groups of 2 bytes

really need the make/model of the remote so I can ask Google to find out the real format for the unit.
obviously with 'rolling code', some bytes will always change
there's no hint of what bit of which byte IS the 'key pressed'

this is a bit of a challenge !

[bulut_01]

I gave detailed information about the remote control. The data format is Manchester and Keeloq data is sent. The aim is to find the address and button information of the remote control. If we can decode Manchester correctly, our work will be easier.

[bulut_01]

[temtronic]

well I've read a LOT of KEEloq information and please goto Microchip's website and download DS41109E, 'keeloq code hopping encoder'.
diagram, firgure 3-1 on page 11, is 'how the data is sent', though reversed of course....serial !

The problem is Keeloq is 69 bits long, you've got 96 bits !
Also serial number is 32 bits( 4 bytes) but there aren't 4 consecutive bytes with the same data for either remote. While each remote will have a different serial number, no matter what button on it you press, the 4 bytes for it's serial number cannot change.

this new info really shows 'something' is wrong, either it's not 'keeloq' coding or the data stream isn't deoded properly.
That goes back to 'how CAN a UART be used to receive KEEloq bits' ?
A UART data consists of a start bit, 8 data bits and a stop bit.
A KEYLoq data consists of 96 bits.
The problem is the UART 'throws away' both start and stop bits BUT with KEELoq they ARE valid 'data'.
I'll have to see what Google can find..........after I go shovel the snow off my sidewalk and truck...

[bulut_01]

The raw data I sent you is raw data that I read directly from the RF module with a logic analyzer. This has nothing to do with UART at this stage.

[temtronic]

found AN744 at Microchip, has CCS C code for decoder....
haven't read it all, but they use a common 'core' for the program, then use a 'header' based on which C you're using.

have a read, see if it helps
There's also AN663,

google 'microchip Keeloq decoder' for more hits.

pretty sure the problem is the logic analyzer is set to receive 'bytes' ( 8 bits) and not a stream of Manchester bits. Some LA can be setup for that....
right now I'd say you're missing 2 bits per 10 sent.

[gaugeguy]

On your logic capture, remove the UART decoding as it is invalid and is causing confusion.

[bulut_01]

[bulut_01]

We have 56 bits of data, when sent via Manchester it makes 112 bits, it makes 14 bytes of raw data. When I set the baund rate to 2400 instead of 1500, I can see 14 bytes of data on the logic analyzer, it makes 112 bits, the calculation is correct.

[gaugeguy]

The reason Manchester encoding exists and why it is used is that the clock is imbedded in the data. You don't have to know the exact clock or bit rate you just have to be somewhat close (+/- 20%). The timing resyncs on each bit as there is a level transition in the middle of each bit.

UART data has a start bit, 8 data bits, and a stop bit and it resyncs on each byte using the start bit. UART requires both sides to know the baud rate ahead of time and be within a few % of each other.

[temtronic]

The problems is that Manchester is sending 112 bits of data NOT 14 bytes.
while the 'math' (14 z 8) says they are the same they aren't.

Manchester is a series of bits, all are important !
UARTs remove the 1st and 10th bits, keep the middle 8.

As I said before ,have a read of the Microchip Appilcation Notes. THEY are the ones that invented KEELOQ ,they KNOW 'how it works' !

AN744 will work, providing you modify for your PIC type. There are LOTS of comments, to help explain why the code is there.
There are several other ANs about KEELOQ and some programs in teh 'code library' here.

[PrinceNai]

You are insisting that reading this through UART will give you correct result. It will not, ever. It is simply not the right tool for the job. Check the two pics you sent. Do you see the gaps between bytes? When your oscilloscope "sees" the byte? It needs a start bit. Depending on what bit was present at that moment, it either sees it right away or it waits for one, thus missing a bit, garbling all the rest. Where there is a framing error, stop bit is missing, which again leads to an error. Also on the pics. If they are from the same remote, look at the last part, where the data should be fixed. Do you see the same pattern? I do not. I see two options here. If the security doesn't matter (and it seems it is not, if you rely on the fixed part of the code anyway), meaning your load are not doors to a vault, use the first four bytes PIC sees, 0x78 0x78 0x78 0xF8. Those are the same every time. It is a cheat with respect to the UART, but who cares while it works. The other option is to buy a new remote. One of those with a learning code. They cost like 2€, fob and receiver and it takes all the burden of decoding from you. Key press - logic one on the pin of a receiver.

The way to get CORRECT data in is the way guys from Microchip did it. Timer interrupt with the correct interval and sampling the bits.

[bulut_01]