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.

Preamble inverse bits for new chips

Other Parts Discussed in Thread: CC110L, CC1020, CC1120

Many years ago was developed customer protocol that used in our sensors in success. This protocol based on preamble 0x55 (6 bytes as was recommend CC many years ago), but new generation of TI chips like CC110L support only 0xAA preamble.

How to implement preamble 0x55 (6 bytes) for new chips, for example CC110L?

  • What is the preamble used for? What would actually happen if you used 0xAA?

    For CC110L you have to include preamble as part of the packet in Tx if you require 0x55

  • What a way to ask the question at issue?

    1) When wireless hub receive preamble 0xAA instead of 0x55 then  packet is reject

    2) In CC110L I can only change value of bytes in preamble 2...24bytes, but how inverse content from 0XAA to 0X55?

  • Hi,

    I haven't worked with this part.  But it may be a solution, if you require custom preamble pattern, to turn off preamble and sync word (if possible). Then you can define whatever bytes in your payload: preamble, sync, real_payload.

    However, I don't know how this will affect ramp-up of the PA...

    You could also use 2 byte preamble (minimum) (but the one you don't want), then configure the 4 following sync bytes to be your first 4 real preambles, then the first 2 bytes in the payload as the remaining preamble bytes, then the sync and then the real payload...?

    ???

    Regards, HC

  • Just saw this is the solution presented by TER.. sorry

  • Yes, it's clear that possible to disable preamble\sync module and operate as data stream, but I lose all features of low power solution in this design that very important for sensor that must be operate during 5-7 years.

  • Does your sensors operate only in Tx or both in Rx and Tx?

    The idea is not to operate with a datastream. You disable preamble/ sync but add preamble/ sync to the start of the FIFO. On the air it will look equal. Rx will not see a difference and will operate as normal.

    The reason I asked about 0x55 vs 0xAA is than modern radios only used to settle the AGC and the type of preamble does not matter.

  • This is security sensor, not simple tag that operate only in TX mode. In my application may be use some TX repeat points between sensor and hub, so that I need to receive response from hub on each alarm event during 0.3-1.4 sec. 

  • "The reason I asked about 0x55 vs 0xAA is than modern radios only used to settle
    the AGC and the type of preamble does not matter." - Is it correct for hub based on the CC1020?

  • That depends on how the software is written.

    Example: CC1120 only needs 4 bit preamble to settle the AGC and then it starts looking for the programmed sync word. The default sync word start with 0x93. If CC1120 receives 010110010011 or 101010010011 does not matter. But the output from the CC1020 is a bit stream and the software has to look for the start of the packet. It depends how the software is implemented if 010110010011 and 101010010011 gives the same result.

  • In your example CC1120 that was recommend as replacement for CC1020. I can't replace chip - CC1020, because it's infrastructure that operate during many years.

    Some our hub use  CC1020 other used more old chips or another vendors and all sensors use CC1020. Using CC110L,I can sniff a messages from sensors and it's confirmed by your reply about preamble usage in new chips. But hub based on CC1020 reject any messages from CC110L. According to your explanation I need following solution:

    For TX mode:

    1) Disable hardware preamble/sync.

    2) Place total packet (including preamble, sync. bytes , data and CRC) in FIFO so that first byte is preamble and last is CRC.

    3) Enable transmission in manual manner and wait when FIFO TX will be empty to finish transmission

    For RX mode:

    1) Enable hardware preamble/sync. (with 0xAA)

    2) Set conventional RX mode with HW support and wait response from hub.

     

  • I assumed that you would not be able to replace the radio, it was meant as an example that shows the difference between new and old radios.

    Your summary solution looks correct.