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: How to deal with very long preambles?

Genius 3985 points
Part Number: CC1120

We have applications where RX needs to sniff only every ~3sec (WOR).

Understanding WOR right, then I need to issue (Datarate/8 * time-between-WOR) bytes preamble, e.g. 4k/8=500 x 3s= 1500 bytes preambel.

Strange enough, but in 434MHz narrow band its possible in ETSI:
any other hint how to manage it? More than welcome..

But if I have to do so, to follow SmartRF right (it says: "Maximum preamble that can be set using the packet engine is 30bytes. To generate a longer preamble, one can disable the sync word, use fixed packet length, disable CRC and fill up the FIFO with preamble bytes. This enables another 128 bytes. For even longer preambles one can strobe TX with an empty FIFO. The chip will then send preamble until data is entered into the FIFO."

So I need just assert STX with empty FiFo, and then after n sec. put something in the FiFo and this will be sent? What about paket length, Sync word, CRC, etc.pp.; how does CC-TX know that the payload has been loaded completely and how does CC-RX sync on syncword?

thx.

  • If you want to send very long preamble you can do as you state. Just strobe STX with an empty FIFO, and then start filling up the TX FIFO when you want the packet to be transmitted. The radio will start to transmit the packet once the first data is written into the FIFO, and it will try to send x number of bytes, where x is the length byte (assuming variable packet length). The radio will then transmit the packet with the programmed sync word, CRC etc., as programmed. The only thing you need to make sure of is that you fill the FIFO fast enough. That means that you have to fill the FIFO faster than you transmit the data on the air to avoid a TX FIFO underflow situation. In theory, sending long preamle like this seems like a good idea, because the RX current will be very low since you only have to wake up every 3 s (in the case you use as an example). However, the current consumption will be very high in the cases where you actually is receiving something. If you wake up in the beginning of the preamble, you need to stay in RX for 3 s before you receive your data.

    A solution to this is to use Smart Preamble. how this can be don, you can read about here:

    http://www.ti.com/lit/swra438

    BR

    Siri
  • Siri, thx. a lot.
    Looking through the smart pre. thing, I discover ad hoc some struggles:
    - there is a 1 byte timestamp, which means max. 255 timestamps. What about theses preambles which are ~5000bytes long?
    - how does CC know how long a preamble will be, if long preambles are generated by asserting SRX and then, after a for CC unpredictable time, putting data into the FIFO?
    best regards
  • --mean 'asserting STX' of course---
    And: thanks to you guys from TI for having always a matching DN od SWRA on hand!
  • Hi

    Probably I was not clear enough. There are two methods you can use if you do not want to send a long preamble.

    1) you can send an ordinary preamble (Strobe STX with an empty FIFO) and the device will send a 010101010....sequence until you start filling up the FIFO. If this preamble is 500 ms long, you need to set a wake up interval shorter than this on the RX to be sure that you wake up within the preamble so that you will receive the sync word of the packet. The disadvantage here is that if you wake up in the beginning of the 500 ms preamble, the radio will stay in RX for 500 ms before it receives sync (and this will consume a lot of power).

    2) You can use smartPreamble instead. This is actually not a preamble, but several small packets sent back to back in front of the real data packet. To achieve this you need to use infinite packet length mode on the transmitter, and write the complete timestamp packets  (including preamble, sync, etc.) to the FIFO (explained in the app note).  How you build up these packets is up to you. If 255 timestamp packets is not enough, you can choose to use two bytes for timestamp instead of 1. Another solution is to transmit several dummy bytes in each packet, so that you need fewer packets (less than 255). The size of the timestamp packet will impact how long you need to stay in RX to be "guaranteed" that a timestamp packet will be received.

    Example:  if you need a preamble that is 5000 bytes long you can use a timestamp packet that looks like this:

    4 bytes preamble

    2 bytes sync

    1 length byte

    1 timestamp byte

    10 dummy bytes

    2 CRC bytes

    If each timestamp packet is 20 bytes, you need to transmit 250 of those to have a 5000 bytes long "preamble"

    You can also use two bytes for timestamp and transmit shorter packets (but more):

    4 bytes preamble

    2 bytes sync

    1 length byte

    2 timestamp byte

    0 dummy bytes

    2 CRC bytes

    You need to transmit 455 of these timestamp packets to have a 5000 bytes long preamble.

    BR

    Siri

  • great intro, thanks a lot