• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 17 subscribers
  • Views 1305 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.

CC1101 RF Transceiver: Clear Channel Assessment vs. Interrupts

Saeb Abdallah
Intellectual 440 points
Other Parts Discussed in Thread: CC1101

My customer is using the CC1101. He has the following questions:

First of all some details of how we’re using the chip.

 

We want the chip to do an instantaneous Channel-availability check when we attempt to transmit. 

 

To this end, we set CCA_MODE TO 3.  We also set our interrupting GDO pin to mode 6,  so that the pin de-asserts (causing a negative-going interrupt) at the end of a transmitted or received packet, along with certain other conditions.

 

We also have the other available GDO pin connected to a port on the MCU so we can program that pin to give whatever auxiliary indication we wish.

 

My principal concern the case where we give the chip the TX strobe, but it remains in receive due to the channel being busy.

 

Q1. Is there is certain way to check whether the transmission took place immediately after we give the TX strobe?  If so, how? 

(I would find this approach preferable, if only because it would simplify the task of maintaining coherency between our software state variables and the state of the actual chip.  This becomes tricky if interrupts get involved.)

 

Q2.  After being issued the TX strobe, does the GDO mode 6 pin create an edge (in our case, an interrupt) in all cases, or only if the transmission successfully occurs?

 

Q3. If we do get an interrupt (as in Q2) in the channel-busy case, what do we check for to see if the message went out?  I see some interrupt service code written for this chip that checks the number of bytes in the transmit buffer (TXBYTES, addr 0x3A).  If it is nonzero, it means the FIFO didn’t empty because the TX didn’t occur, because of a busy channel.  Is this the best way?

Thanks for all replies in advance.

  • 0
    TI__Mastermind 36395 points

    Q1. Is there is certain way to check whether the transmission took place immediately after we give the TX strobe?  If so, how? 

    Yes, that should be doable. I would start with polling the MARCSTATE register found on page 50 of 

    http://www.ti.com/lit/ds/symlink/cc1101.pdf

    The CC1101 should enter "TXRX_SETTLING" or "TX MODE" when you strobe the "STX" if there is not CCA issues. The other way is to wait for "SYNC SENT" indication to become available but I do not know if that is too long, this is option (0x06) on the GDO configurations. 

    The last way I have heard people get this information out, is to use the LNA/PA control signals of the CC1101. 

     

    • 27 (0x1B) PA_PD. Note: PA_PD will have the same signal level in SLEEP and TX states. To control an external PA or RX/TX switch 
      in applications where the SLEEP state is used it is recommended to use GDOx_CFGx=0x2F instead.
    • 28 (0x1C) LNA_PD. Note: LNA_PD will have the same signal level in SLEEP and RX states. To control an external LNA or RX/TX 
      switch in applications where the SLEEP state is used it is recommended to use GDOx_CFGx=0x2F instead.

     

    Q2 After being issued the TX strobe, does the GDO mode 6 pin create an edge (in our case, an interrupt) in all cases, or only if the transmission successfully occurs?

    Yes, the GDO mode 6 goes HIGH when the Sync word has been sent/or recieved and goes LOW after the end of the packet has been sent/or received. You need to know what state the CC1101 is in when using this signal.

    Q3 If we do get an interrupt (as in Q2) in the channel-busy case, what do we check for to see if the message went out?  

    I typically use GDO mode 6 after it goes LOW. This indicates the END of PACKET. All you need to guarantee when doing CCA is that the RX did not catch a "signal" and started receiving data and provide you with an "RX end-of-packet" and not a "TX end-of-packet". So as above I would poll the TX FIFO length to ensure its 0 after you get the "end-of-packet" signal. Then if is not Zero (then you much have received something and you would need to go flush the RX FIFO anyway, then enable CCA/TX one more time.

    Regards
    /TA