• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 2024 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1200: random back-off in LBT

Matthias May
Prodigy 140 points
Other Parts Discussed in Thread: CC1200

According to the datasheet, the CC1200 supports LBT with a pseudo random part. The LBT feature is working so far, however it seems, that the random back-off is always the same.

I tested this using two CC1200 where one tries to send a packet with LBT while the other jams the channel (sends a different preamble that the first one does not recognize).

Using a logic analyzer I always measure the same delay between the point in time where the jammer stops and the packet is transmitted. In the screenshot below, the black logic channel is GPIO3 configured to CC1200 GPIO signal 17 (carrier sense) and the blue channel indicates start of transmission (GPIO signal 26: RX0TX1_CFG).

The delay is always around 7.5 ms (probably 5 ms fixed part + 2.5 ms random part), however it should vary between 5+0 ms and at least 5+5ms according to the CC1200 datasheet that follows ETSI regulations.

LBT is activated by entering TX while in RX and after RSSI is valid with the following register settings:

ANT_DIV_RX_TERM_CFG = 0

RXOFF_MODE = 0b11 (RX)

TERM_ON_BAD_PACKET_EN = 0

CCA_MODE = 0b100

Is there anything else required to enable the random back-off?

Best regards,

Matthias

  • 0
    TI__Guru* 81731 points

     Hi

    Is it possible to get more info about your test setup? I used SmartRF Studio (1.2 kbps typical settings) and changed the parameters you described + the CS threshold. I used the RF device commands to write a packet to the TXFIFO, strobe SRX and then strobe STX. A transmitter was sending preamble on the same frequency (I used SmartRF Studio on that end also). I turned off the transmitter and measured the time from the transmitter entered IDLE until a packet was sent. The first time the delay was, 11.5 ms, the second time I measured 10.2 ms.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 140 points

    Hi,

    thank you for your answer.

    We use a custom board with a microcontroller from STMicroelectronics. The radio part is based on the CC1200 reference design. The settings were based on the SmartRF Studio 38.4 kbps typical settings combined with the settings from the RX sniff mode guide.

    I already tried to find out if the problem is caused by some EWOR-related register settings, however I currently work on the hardware design of a new prototype. When I continue with the software I will look into this again (test with 1.2kbps, etc) and get back to you.

    Best regards,

    Matthias

  • 0 in reply to Siri
    Prodigy 140 points

    Hi,

    I tried to reproduce your findings and I did measure random delays around 10 to 14 ms between end of jammer and begin of packet transmission (RX0TX1 interrupts on each device) using SmartRF Studio with 1.2 kbps typical settings and the eval boards.

    The only registers I modified were the CCA_MODE and the GPIO0, 2 and 3 for the logic analyzer.

    Once again there is this surprisingly constant delay of 7.5 ms between deassertion of CS and TX, and assertion of CCA and TX, respectively.

    From the description of CCA_MODE = 0b100 I would expect the CCA status to remain low until after the random delay. However, if the total delay is random and long enough I would be fine with that behaviour:

    Indicates clear channel when RSSI is below threshold and ETSI
    LBT requirements are met

    Lowest (black) channel is RX0TX1 interrupt at the jamming cc1200:

    Then I switched to 38.4 ETSI standard typical settings and once again only measured delays around 7.7 ms with only like 0.3 ms variation (cf. second screenshot).

    The CCA assertion time once again remains at a constant 7.5 ms.

    Could you try to verify this?

    Thank you very much.
    Best regards,

    Matthias

  • 0 in reply to Matthias May
    TI__Guru* 81731 points

    Hi Matthias

    I can confirm that I am seeing the same thing. I will try to talk to the designer responsible for the CCA implementation next week. Hopefully he can give an explanation on how the algorithm is implemented with respect to the signals we are observing.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 140 points

    Hi Siri,


    Thank you very much.

    I'm looking forward to hearing from you.

    Best regards,

    Matthias

  • 0 in reply to Matthias May
    TI__Guru* 81731 points

    Hi Matthias

    Hi

    I have now talked to the designer and he can confirm that the behavior we are seeing is correct. The CCA signal behaves differently in LBT mode and is directly connected to the CS signal (when CS is de-asserted, CCA is asserted). Once CCA is asserted, the listening time is re-started. It will now be a listening time of 5 ms + random delay. The time you are measuring from CCA is asserted until TX is entered is 5 ms + a 2.5 ms “random” delay. The problem is that the random delay is always 2.5 ms and hence not very random. This is because the random generator is not enabled. This can be enabled by setting RNDGEN.RNDGEN_EN = 1. This info is unfortunately not present in the user guide, but will be added in the next revision.

    Thank you for pointing out this issue.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 140 points

    Hi Siri,

    this did the trick! I can now confirm random backoffs 5ms + x * 0.5ms as specified. Thank you very much.

    Maybe you could add a small section describing the complete procedure to enable LBT. I think somewhere in this forum, there was mentioned that waiting for RSSI is required before strobing STX which I think is also not covered by the manual.

    Best regards,

    Matthias

  • 0 in reply to Matthias May
    TI__Guru* 81731 points

    Hi

    Glad to hear everything is working well. I have added a sentence in the user guide saying that when using CCA, RSSI_VALID must be asserted.

    BR

    Siri