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.

CC1352P: When exactly is CCA used?

Part Number: CC1352P
Other Parts Discussed in Thread: SYSCONFIG

…. So using the stock dmm for Sub1GHz + BLE project; I see it calling EasyLink_transmit and EasyLink_asyncReceive for the Sub 1GHz stuff.  All good, but when I look in the .syscfg there’s this section in Easylink with the CCA parameters; that is, the Listen-Before-Talk parameters of the Sub 1GHz piece.  I am unclear if the CCA parameters are actually used or not; it USED to be that you had to call EasyLink_transmitCcaAsync(); but the fact that those parameters are included coupled with what I think I see happening makes me think they are actually being observed.

 

So to the real question(s)-

  1. Are they in fact being used (if I am only calling EasyLink_transmit, not the EasyLink_transmitCcaAsync, and if so,
  2. Is there a way to turn them off (eg if I put 0’s in some/more of the backoffs or something in the .syscfg would it stop listening?

 

I am thinking I may need to get to a ‘shout’ mode; eg if I get back’d off too many times in a row then I decide to just talk regardless.  Like anything RF, it’s a little hard to say I know exactly what’s happening; but I think I am seeing a case wherein my sensors aren’t talking like they should be in the presence of a ‘loud personality’ (that is, a really noisy environment)

-Dave

  • Hi Dave,

    What is the exact example you are using? And what SDK version?

    Thanks,
    Nikolaj

  • Hi Dave,

    When looking through the code, it seems like CCA is only used for EasyLink_transmitCcaAsync(). This is also mentioned in the description of the CCA fields in sysconfig. See below:






    So CCA will not be used, unless you are using EasyLink_transmitCcaAsync. To help with debugging your issue you can debug the application and check the status returned by EasyLink_transmit and EasyLink_transmitAsync, and also the status parameter in the callback for EasyLink_transmitAsync.

    You could also use SmartRF Studio or SmartRF Sniffer to see if the expected packet are actually being sent.

    A final suggestion is to verify that the receiver is in RX mode when the transmitter is transmitting, and that the transmitter is transmitting when you expect it to be transmitting. This can be done by using a logic analyzer and mapping RF core signals to he GPIO as described in the Debugging RF Output section in the user guide. 

    Regards,
    Nikolaj