CC2652R: Could CC2652 do BLE scan continuously?

Part Number: CC2652R

Tool/software:

SDK version: 7.40.00.77

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/sh
#/usr/bin/blescan.sh
tty="$(uci -q get tisbl.tisbl.tty)"
[ -z "$tty" ] && tty='/dev/ttyMSM1'
exec 100>"/var/lock/ble.lock"
flock 100
MAX_COUNT=20
count=1
com-wr.sh "$tty" 3 "\x01\x1D\xFC\x01\x00" > /dev/null # this reset command delay time must >= 3, if small than 3, the following commands will be something wrong
com-wr.sh "$tty" 1 "\x01\x00\xFE\x08\x02\x00\x00\x00\x00\x00\x00\x00" > /dev/null
com-wr.sh "$tty" 1 "\x01\x60\xFE\x04\x01\x00\x20\x00" > /dev/null
com-wr.sh "$tty" 1 "\x01\x60\xFE\x04\x01\x01\x20\x00" > /dev/null
com-wr.sh "$tty" 1 "\x01\x61\xFE\x02\x01\x02" > /dev/null
com-wr.sh "$tty" 1 "\x01\x61\xFE\x02\x01\x03" > /dev/null
com-wr.sh "$tty" 1 "\x01\x61\xFE\x02\x01\x04" > /dev/null
com-wr.sh "$tty" 1 "\x01\x61\xFE\x02\x01\x05" > /dev/null
while [ $count -le $MAX_COUNT ]
do
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This attached code is how we send commands to CC2652 per scan cycle.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/bin/sh
# com-wr.sh tty time command parser
# example com-wr.sh /dev/ttyMSM1 1 "\x01\x1D\xFC\x01\x00" | hexdump.sh --> send "\x01\x1D\xFC\x01\x00" to /dev/ttyMSM1 and then hexdump receive data until 100ms timeout
#command example "\x7E\x03\xD0\xAF und normaler Text"
usleep 10000
tty=$1
time=$2
command=$3
parser=$4
stty -F $tty time $time
exec 99< $tty
echo -en $command > $tty
cat $tty
exec 99<&-
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This attached code is how we send commands to tty

In current situation, the data which we receive from UART with command "\x01\x51\xFE\x06\x00\x00\x00\x04\x00\x02" have limit(about 16 records). 

As a result, we called the command  "\x01\x51\xFE\x06\x00\x00\x00\x04\x00\x02" each time.

We would like to know if there is any way can let CC2652 scan BLE beacon continuously.

Then we can use repeated UART data reading instead of sending scanning-related commands to the CC2652R each time.

  • Hello Tony,

    Thanks for reaching out.

    Could you please share a bit more about where (in which tool) you are running the commands? It should be possible to do continuous BLE scanning.

    For instance, you can use host_test app and Btool from the SDK to test this. Training material: Bluetooth Low Energy Fundamentals (https://dev.ti.com/tirex/explore/node?node=A__AX8fD.bKB7yAgQmXFl2j4A__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST)

    BR,

    David.

  • We use the Linux shell (on the host) to send the commands to CC2652 via UART. 

     

    These are the commands we send to CC2652:

    \x01\x1D\xFC\x01\x00                                                        HCI_EXT_ResetSystemCmd
    \x01\x00\xFE\x08\x02\x00\x00\x00\x00\x00\x00\x00         GAP_DeviceInit      
    \x01\x60\xFE\x04\x01\x00\x20\x00                                    GapInit_setPhyParam    
    \x01\x60\xFE\x04\x01\x01\x20\x00          GapInit_setPhyParam    
    \x01\x61\xFE\x02\x01\x02              GapInit_getPhyParam    
    \x01\x61\xFE\x02\x01\x03              GapInit_getPhyParam    
    \x01\x61\xFE\x02\x01\x04              GapInit_getPhyParam    
    \x01\x61\xFE\x02\x01\x05              GapInit_getPhyParam 

     

    loop start
    \x01\x51\xFE\x06\x00\x00\x00\x04\x00\x02       GapScan_enable
    \x01\x52\xFE\x00                    GapScan_disable
    loop end

     

    After sending scan command, we receive the binary result from the UART.

     

    This is our current implementation.

     

    However, currently everytime when we receive the scan result, the maximum result is 16, and we need to send scan command (GapScan_enable) periodically.

     

    We would like to check if there is method we can send one command to CC2652, and it would continuous do the BLE scan, and we can receive the result (as a pipe) continuously.

  • Hello Tony,

    I would suggest to use the HCI Tx dump from Btool (find it inside the SDK: \tools\ble5stack\btool) output as a reference and then take a look at the function GapScan_enable setting the duration equal to 0. You can do the same for the Accept list topic you mentioned over the other thread.

    Let me know how it goes.

    BR,

    David.

  • After considering your suggestions, we have made several attempts with the guid documents. Although the scanning results have improved, there are still some issues remaining.

     

    The command of blescan we send by Linux Shell  as below:

    \x01\x1D\xFC\x01\x00    # HCI_EXT_ResetSystemCmd
    \x01\x00\xFE\x08\x02\x00\x00\x00\x00\x00\x00\x00    # GAP_DeviceInit  
    \x01\x60\xFE\x04\x01\x00\x20\x00    # GapInit_setPhyParam scan interval 0x20 - 20000us
    \x01\x60\xFE\x04\x01\x01\x20\x00    # GapInit_setPhyParam scan window 0x20 - 20000us
    \x01\x61\xFE\x02\x01\x02    # GapInit_getPhyParam
    \x01\x61\xFE\x02\x01\x03    # GapInit_getPhyParam
    \x01\x61\xFE\x02\x01\x04    # GapInit_getPhyParam
    \x01\x61\xFE\x02\x01\x05    # GapInit_getPhyParam

    \x01\x55\xFE\x03\x03\x5D\x02    # Add filter for PDU type
    \x01\x55\xFE\x02\x06\x02    # Add filter for duplicated result

    loop start
    \x01\x51\xFE\x06\x00\x00\x40\x00\xFF\xFF    # GapScan_enable period: 0, duration 0x40 - 640ms, MaxNumRecords 40
    \x01\x52\xFE\x00    # GapScan_disable
    loop end

     

    In order to improve the scanning results, we have made the following adjustments:

    1.We upgrade the firmware version from 7.40.00.77 to 8.30.00.121, and then we enable the wachdog driver in CSS

     

    2.We add a filter for PDU type and add filter for duplicated result

    \x01\x55\xFE\x03\x03\x5D\x02   # Add filter for PDU type
    \x01\x55\xFE\x02\x06\x02           # Add filter for duplicated result

     

    3.We modify the parameter for GapScan_enable

    "\x01\x51\xFE\x06\x00\x00\x00\x04\x00\x02"    # GapScan_enable period: 0, duration 0x400 - 10240ms, maxNumRecords 0x200 - 512(Before)

    "\x01\x51\xFE\x06\x00\x00\x40\x00\xFF\xFF"   # GapScan_enable period: 0, duration 0x40 - 640ms, maxNumRecords 0xFFFF - 65535(After)

     

    After we made adjustments, the scan results was improved.

    However, there are still the following issues:

    1.The no response issue was improved when we add watchdog driver in new firmware, but we still would like to clarify how the watchdog works. Is there anything we need to do after the watchdog triggered, or how can we the watchdog have been trigger?

     

    2.We've tried GapScan_enable command with 0ms duration and read the output from HCI Tx dump by Btool, We have found that the CC2652R outputs results only once for each BLE record. If we need to update the scanning results every 30 seconds, we would still need to disable and then enable it again. This approach is essentially no different from the current method.The initialization what Btool do is as attached.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    [1] : <Info> - 01:07:26.080
    Port opened at 1/30/2025 1:07:26 PM
    --------------------------------------------------------------------
    [2] : <Tx> - 01:07:26.143
    -Type : 0x01 (Command)
    -OpCode : 0xFC1D (HCIExt_ResetSystemCmd)
    -Data Length : 0x01 (1) byte(s)
    Type : 0x00 (0) (Chip Reset)
    Dump(Tx):
    0000:01 1D FC 01 00 .....
    --------------------------------------------------------------------
    [3] : <Rx> - 01:07:26.427
    -Type : 0x04 (Event)
    -EventCode : 0x00FF (HCI_LE_ExtEvent)
    -Data Length : 0x05 (5) bytes(s)
    Event : 0x041D (1053) (HCIExt_ResetSystemCmdDone)
    Status : 0x00 (0) (SUCCESS)
    CmdOpCode : 0xFC1D (HCIExt_ResetSystemCmd)
    Dump(Rx):
    0000:04 FF 05 1D 04 00 1D FC ........
    --------------------------------------------------------------------
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    3.Currently, in our customer's environment, they have 1 device with 100ms broadcast interval and 2 devices with 3-4s broadcast interval. As shown in the attached image,the scanning results are relatively stable during off-hours, but there is a noticeable decline in performance once the work hours begin.

    The results during off-hours

    The results during work hours

     

    4.Our customer reported that the RSSI value of the beacon seems to be incorrect, and even if they moved the beacon(from the table to the ceiling), the value did not change. The correct RSSI is notified by powering EAP112 off and on. What could be the possible reasons causing this situation to occur?

     

    5.We also woulde like to know about what we should do if there is Wi-Fi interference, and if we are unable to detect any signals.

  • Hello,

    Glad to hear things have improved.

    1. How are you using the watchdog instance? I would suggest to take a look at the API doc here: https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.40.00.77/exports/docs/drivers/doxygen/html/_watchdog_8h.html
    2. Could you please share more info about what you mean by "outputs results only once for each BLE record", do you mean the reports? in the Btool TX information I do not see the scanning process.
    3. I assume the % values displayed are related to the number of scanning results right? Are you doing active or passive scanning (see GapScan_setPhyParams)? With the last one you are not considering scan responses/requests. You could also add a filter policy so that for instance, only devices inside the whitelist are considered. The whitelist can be populated by devices that have already bonded before with the central device.
    4. How are they reading the RSSI values?
    5. Let me gather some more information about BLE + WIFI coexistence. Do you have any specific configuration going of for that WIFI router?

    BR,

    David.

  • Here is our information in response to the previous issue.

    1.We previously only enabled the watchdog driver but did not initialize it or use any APIs. We are currently exploring how to use the watchdog API.

    2.After some testing with BTool, we found that the CC2652R outputs scan results periodically only when the period is set to a nonzero value. However, if the period is set to 0, the output stops after a while until it returns SUCCESS. Attached is the scan result using the default parameters.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    [1] : <Info> - 06:27:18.369
    Port opened at 2/4/2025 6:27:18 PM
    --------------------------------------------------------------------
    [2] : <Tx> - 06:27:18.430
    -Type : 0x01 (Command)
    -OpCode : 0xFC1D (HCIExt_ResetSystemCmd)
    -Data Length : 0x01 (1) byte(s)
    Type : 0x00 (0) (Chip Reset)
    Dump(Tx):
    0000:01 1D FC 01 00 .....
    --------------------------------------------------------------------
    [3] : <Rx> - 06:27:18.712
    -Type : 0x04 (Event)
    -EventCode : 0x00FF (HCI_LE_ExtEvent)
    -Data Length : 0x05 (5) bytes(s)
    Event : 0x041D (1053) (HCIExt_ResetSystemCmdDone)
    Status : 0x00 (0) (SUCCESS)
    CmdOpCode : 0xFC1D (HCIExt_ResetSystemCmd)
    Dump(Rx):
    0000:04 FF 05 1D 04 00 1D FC ........
    --------------------------------------------------------------------
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    3.We are currently using the default parameters, which means passive scanning.

    The customer wants to scan all devices in the environment rather than targeting specific MAC addresses. What we may need is filtering based on beacon type(like iBeacon or Eddystone).

    Additionally, we would like to understand the difference between the interval and window parameters in GapScan_setPhyParams and the scanInterval and scanWindow parameters in GapInit_setPhyParam.

    What are the exact functions of these parameters?

    4.We directly read the RSSI value from the payload and send it to the MQTT server, while the customer reads the value directly from the MQTT server.

    5.Thank you for your help. We are currently confirming with the customer if there are any specific configurations.

  • Hello,

    1. The watchdog time is used as a recovery mechanism. Please share with me some more information about the cases you are considering to use it at the moment.
    2. For continuous scanning, the duration must be set to 0, if not, scanning will stop after x ms of duration (500 in your case).
    3. Alright. However, from the controller perspective (while scanning) it is only possible to filter using peer address. Regarding the scanning window and interval, please take a look at our training material here: Scanning Basics - https://dev.ti.com/tirex/explore/node?node=A__AeE0v3645AxQnabd1AT4cA__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST
    4. Do they have some type of WIFI and BLE coexistence running on the wifi device? The signal might be getting compromised due to interference.

    BR,

    David

  • For issues No.2 and No.3, we have found some solutions based on your suggestions.

    As for the issue No.1, considering that we previously encountered CC2652 no response, we decided to add a watchdog to restart the firmware when no response occurs.

    Regarding issues No.4 and No.5, the customer has provided us with the WiFi 2.4G configuration from another AP in the environment (as shown in the attached image). We hope this helps you better understand the WiFi and BLE interference issue.








  • Hello,

    I am checking with the team to gather some more inputs about this. I am not sure from a first look at the configurations. Do you have a new status about the issue? How bad is the degradation of the RSSI when the WIFI is on?

    BR,

    David.