• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 260 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1120: Looking for a reciver that deal with ancient OOK protocols

GGA
Genius 3985 points
Part Number: CC1120


Hi,

We have been working with CC112x on FSK for a decade now, largely in asynchronous "transparent" mode.
We are trying to convert all customers and products to FSK, including of course packet mode when we have new projects.

But because of history, we have thousands of keyfobs on the market that work with the old OOK protocols: 12bit or 40bit packets, between 500b and 2000b DR (you never know what will come in).
These packets are sent repeatedly with 5-30ms pauses in between - and the receiver must not try to find any bits in these pauses .... (no, no AGC/AFC...)

Unfortunately, our customers still need these receivers either for new projects (with old transmitters) or simply as spare parts.
Currently, these receivers are analog, very good natured chips, but you never know what surprises you may encounter due to differences from batch to batch (today we again have big problems).

Long story short, is there a CC1xxx chip (preferably CC1120) that you can recommend to solve this problem?

Many thanks in advance!

Translated with www.DeepL.com/Translator (free version)

  • 0
    Genius 3985 points

    In addition: I made some measurements.
    The bad thing is always the large pauses between the packets and the missing preamble. The tests I made now (CC1120) show, that even FOC_EN=off doesn't change the bad behaviour. So I tried to find more OOK-relevant parameters to get an improvement.
    - Increasing CHBW from eg. 50k to 100k makes it worse (and 100k should be minimum as TX's have certain crystal tolerances).
    - Increasing DataRate from 1 to e.g. 4k makes it worse
    - AGC_ASK_DECAY is a certain candidate, but with "5000" already at its maximum. Making it smaller makes it even worse (see pics).
    But I guess AGC is the key: if I could tell CC not to change AGC after receiving the first packet, regardless of the pauses, this could help.
    Means e.g. AGC-DECAY to ~20000 - but thats not allowed.

    Meanwhile I don't care too much if the pauses got spikes where there aren't: we are considering to make some signal processing: grabbing the whole data set and analyse it backwards from the end of a packet - which is always clean. But unfortunately the scrap in the pauses reaches into the beginng of the packet - and we can't recover destroyed bits.

    Gents, we have a real bad situation here and I ask you TI guys urgently for any hints you could give to trim CC11x to behave like it should. Maybe you have access to the old Chipcon team to adress this... ;-)?

    thx!

    Good packets (1ms/div)

    - bad packets with scrap from pauses

    very bad packets with AGC_ASK_DECAY reduced to 600

  • 0 in reply to GGA
    Genius 3985 points

    Another finding from our tests: could it be that the CC11xl is much more relaxed in this respect? I fed in a low level signal without getting these unpleasant effects...
    If so, why is that and can I trust it?

  • 0 in reply to GGA
    TI__Expert 3680 points

    Hi GGA,

    I do not have clear answer to you at the moment. I need some time to look deeper into this.

    Regards,

    HG