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.

CC2340R5: CC2340R5 automatically selects the channel when it is powered on

Part Number: CC2340R5

Tool/software:

Dears,

1. A customer tested multiple CC2345R5 devices and found a problem. When multiple CC2345R5s are turned on at the same time, they will occupy the same 2.4G Bluetooth channel, causing the communication between the host and the Bluetooth slave to fail.
2. Is it possible to set up the CC2340R5 SDK to detect whether the 2.4G channel is occupied when Bluetooth is turned on, and automatically switch to other channels if it is occupied?

  • Hi, 

    Thank you for reaching out. 

    May I kindly ask a few more details so I am sure to well understand the issue? 

    • Is Bluetooth LE used here? 
    • You mentioned several devices are turned on simultaneously, but how many devices are we talking about? Also, why/how are they all turned on at the same time? 
    • What type of communication (advertising / connection) is used in this case? 
    • What does "communication fails" means? Is the connection terminated, data lost, etc.?
    • Does the communication eventually works (e.g. after a few seconds)?

    Best regards, 

  • Hi,

    • Is Bluetooth LE used here? 
      • BEL LE
    • You mentioned several devices are turned on simultaneously, but how many devices are we talking about? Also, why/how are they all turned on at the same time? 
      • 3 CC2340R5s, on-board anchors, external hardwire control powered up at the same time;
    • What type of communication (advertising / connection) is used in this case? 
      • broadcast mode, power up at the same time, 3 CC2340R5 initialize and start broadcasting, cell phone BLE search CC2340R5 broadcasting successfully and start connecting;
    • What does "communication fails" means? Is the connection terminated, data lost, etc.?
      • is the cell phone BLE can not quickly connect to the CC2340R5
    • Does the communication eventually works (e.g. after a few seconds)?
      • It takes about 30-120S to search CC2340R5, sometimes only 1 CC2340R5 can be searched.
        Spectrum scanning found (SPAN=0, Sweep=10ms): 2 of the CC2340R5 broadcasts partially overlap, it should be the BLE broadcasts are interfering with each other.
  • Hi, 

    The issue you are describing is pretty unlikely caused by the devices being turned on simultaneously. Actually, per Bluetooth specifications, the advertisement interval has a pseudo random part ensuring advertisements sent by two devices cannot collide indefinitely. 

    In order to further investigate the issue, I would recommend to verify the following:

    - ensure all the devices are using different addresses, and different names - otherwise the phone may be confused 

    - ensure the advertising interval is set to a low value (below 100 ms)

    - ensure the scanning parameters used by the phone maximize the listening time 

    I hope this will help,

    Best regards, 

  • Hi,

    - ensure all the devices are using different addresses, and different names - otherwise the phone may be confused 

     yes,The current setup caters for different addresses and different names

    - ensure the advertising interval is set to a low value (below 100 ms)
    yes,The currently set interval is 50ms
    In the following video
    1. It starts with a CC2340 broadcast, and the mobile phone can quickly discover BLE
    2. The sequence is two CC2340 broadcasts. When there are two CC2340 broadcasts, the broadcast spectrum obviously overlaps and the mobile phone cannot detect BLE.


    Please help to see if there are other possible causes besides the mobile phone scanning settings.

  • Hi, 

    Thank you for the additional details provided. 

    If I may, the RF analyzer is probably not the most adapted tool to detect RF collisions. You're correct all the Bluetooth LE devices advertise on the same channels (37,38,39), but each packet is very short (a few hundred micro-seconds) so you cannot "see" the collision happening with this tool. If you want to convince yourself of this, use a Bluetooth sniffer and review the timing of each advertising packet. 

    Looking at the video, I have noticed three elements:

    1. (minor/limited or no impact) The advertising interval used seems to be 100 ms (and not 50 ms) - If connection speed is important you can consider to reduce the advertising interval and use limited discoverable advertising
    2. The three devices seem to have the same name. I have seen cases where phones got "confused" by this. You should then consider using different names for each device.

     For reference, these two comments are based on ~0:07 of the video

    Best regards, 

  • Hi,

    1.The customer checked the code again and it was set to 100ms.
    2.There is no conflict in the names. 15 seconds ago in the video, a single Bluetooth was turned on and off multiple times, and 17 seconds later, two Bluetooths were turned on at the same time.

    How to confirm whether there is a conflict mechanism when testing CC254R5 SDK? The customer suspected that anti-collision was not working properly.

  • Hi, 

    How to confirm whether there is a conflict mechanism when testing CC254R5 SDK?

    You can use a Bluetooth sniffer. But, as explained before, it is statically impossible to repeatedly have collisions between independent Bluetooth LE devices. BLuetooth LE works in crowded environments (e.g. airports) so it should tolerate easily 3 devices in the same room. 

    1.The customer checked the code again and it was set to 100ms.

    My point was, if you want to speed up connection establishment, you should ensure this value is set to the smaller value possible. 

    Regards,