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 - packet versus transparent mode : need some arguments

Genius 3985 points
Other Parts Discussed in Thread: CC1120

Hello,
for backward legacy compatibility reasons we use CC1120 in most cases in transparent mode.

The data frames we use are different, some of them even don't have a preamble but due to repetition (old systems just repeat sending packets) the first packet is used as 'preamble' and things work. A '0' is transmitted as a bit period with 33% low and 66% high, a '1' according 66/33%.
Data rate is max. 4kbps, application is always narrow band with ~16kHz ChBw

Now we have people in fraction A  who want to use in future appications packet mode only. nice thing, no jitter, no care about data integrity etc.pp.
But this is not backward compatible.

The other fraction B want to use always transparent mode and for future packet use cases rebuild the packet engine in the encoding/decoding.
With that strucure CC1120 could be left in transparent mode and a receiver is always able to distinguish if data is from an old or new system - this isn't possible if an old system sends something to CC1120 in 'real packet mode'.

Furthermore fraction B tested, that CC1120 doesn't need a real preamble with multiple 1010 in front of a paylod, a simple '0' with one ms. length seem to be enough to trimm CC1120 - strange to me, but I didn't dig further into it.

Could you experts please hint us in the right direction before it's getting to religious and comment :-)

regards

GGA

  • The CC1120 modem is designed for packets with preamble, sync and payload. Transparent mode is supported but in transparent mode the modem doesn't do any post processing on the data which means that the MCU should oversample the datastream to filter out glitches and the radio performance will be poorer than when using a FIFO. In FIFO mode the modem do a lot of post processing which secure good performance. In addition the sync word search does not limited the sensitivity since it's correlator based.

    So when you are able to, use a FIFO based setup. In some cases transparent mode has to be used since the datarate and deviation variation is too large for the modem to handle.

    My impression is that most legacy systems sends at least 3 packets. If some of the packet content is known this can be used as sync word. Even if the known pattern is 0101 this is much better than no sync word at all, the modem is more or less dependent on sync to do byte/ bit slicing.

    CC1120 could actually work fairly well without preamble in a lot of cases. The preamble is only used to set the AGC and if max gain can be used the AGC doesn't need to adjust.

    Note also that you can send whatever is in the FIFO, eq if you want to send a packet that is compatible with the old system you turn off preamble and sync and place the packet in the FIFO. Or you can put the first 4 bytes of the packet as sync word to get interrupt when sync is sent. The packet will look the same for the receiver anyway.

    Hope that helps some
  • Torstein,
    thx. for your hints, some of them will be deeply reviewed.
    The ugly thing with our legacy packets is that
    - bit rates vary between 0.5k and 2k (some even have RC-modulated clocks :-( )
    - they are fairly different in terms of how they look like. Some very old technic uses 12Bit coding of keys in a keyfob
    So beside idealized examples there is no real prediction of what comes in.

    We have another idea, see what you think about that:
    as our old packets have this 1/3 // 2/3 duty cycle structure, we keep CC1120 in transparent mode as default.
    As soon as the uC behind CC1120 detects something which is 50/50 duty cycle, it must be a preamble and it switches CC1120 into packet mode.
    Given a long enough preamble, CC1120 will be in packet RX mode during the rest of the preamble and can detect the packet.
    Shouldn't this work?
    regards
    Gerhard
  • - Datarate: When the bit rate varies from 0.5 kbps to 2 kbps you need transparent mode since packet mode needs the programmed datarate.
    - Packet format: From what you write it sounds like nothing of the packet content is known?

    Your suggestion could work. I have a suggestion in addition: The main problem with your legacy systems is the not known datarate. But given long enough time between packets it could be possible to calculate the datarate from the incoming data and reprogram the radio to packet mode in the time between the packets. 1/3-2/3 could be fixed by setting the datarate corresponding to the 1/3 part and do some post processing of the received packet. But to do this you need something to use as a sync word.

    Your suggestion will also work given enough time to reprogram the radio.