AX5043 - clock recovery problem and working in wire mode

in system is used old Keeloq system, which is not possible to change because of backward compatibility. In this system main problem is with gap between preamble and data packet. I assume that AX5043 is working like on preamble recovering clock and after that is sampling data incoming on RF.
HCS is sending preamble, “header” and data. Header is ~10bits, where only zeroes are and during this time clock isn’t refreshed, so receiver is losing clock settings, after that first bit of data and whole frame has error.
Ideal for customer will be – preamble receive, clock freeze for ~4ms and rececive data with stored clock.
Is there way to use transceiver in this mode with such transmission?
second question:
Has “wire mode” solution same sensitivity as in “frame mode”?

Arek S.

Hi Arek,
Our AX5043 does not have a native HW support for KeeLoq technology. In order to implement it on our chip you will need to use “Raw Mode” or “Raw, Pattern Match” and take care manually on defining the correct Preamble/Sync word/Data packets. You can find some details on our AX5043 Programming Manual, as well as at this post KB: When and How to Use Raw Mode on AX5043.
At what data-rate will you be operating, and what modulation? One option would be to exploit the three pattern match blocks available on the AX5043 to track the first real preamble, then the “silence”, then the actual sync word and packet. It is also very important to set appropriate RXPARAMSET for the “silence” part and by reduce or freeze RF frequency tracking value (with RFFREQFREEZE) so that the loop does not diverge during the silence (assuming you have an OOK signal).

Hi Georgi,

thank you - customer knows his requirements and he knows that there is no native support for “weird” now Keeloq protocol.
Right, he has in system OOK solution.

BR Arek

Hi Again,

additional problem is, that HCS has very poor clock source - +_40%(tested on many tousends of devices) , so question is if customer will have right parameters for RXPARAMSET and RFFREQFREEZE…
Could you check?



and for clarification - clock is stable during sending procedure, but depends from device to device.


Hi Arek,
AFC and AGC should survive the silence in frozen state, but there may be some issues with the bit timing (TIMEGAIN, tracking loop that detects where the individual bits start). Freezing the TIMEGAIN (=0 or =0xFF) could work but also depends on what bit-rate you are operating at and how many bit-equivalent are 4ms of silence.
Is there a syncword or another preamble after the 4ms silence?


thank you,
after preamble is ~10bits(4ms) of zeroes/silence. Of course clock of HCS is very poor as I wrote and there can be ±40% differences between devices.