BLE scan response not being reported

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JeHu_3414236
Level 5
Level 5
10 likes received First like received

I am seeing a case where I receive an advertisement packet in CY_BLE_EVT_GAPC_SCAN_PROGRESS_RESULT but not the corresponding scan response.  The scan response may be lost due to bad RF or some other reason.  In this case, I am no longer able to receive the scan response from the same device.

This looks like the operation of scan response from the stack:

If stack receives an advertisement/scan response from device A, it will no longer send any reports for device A unless 1) a new scan is started or 2) device A is not in the list of cached scan results, with cache size 8~10 devices.

If stack receives an advertisement but not the following scan response from device A, it will behave the same as above even if the scan response is received later.

I would like the stack to report the scan response if it is received later, even if the initial advertisement packet was already reported. Is this change in the stack possible?  I don't want to wait for the scan to timeout and start a new scan.

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Attached log capture of simulated bad RF case. As you said, some scan response packets are lost under this condition.

The lost packets mean they might be broken when received on PHY layer and then being discarded, nothing related to stack packet filtering way.

I believe there would be little enhancement space in terms of BLE stack or SW. Trying to improve RF performance or avoid bad RF condition should be right direction.

View solution in original post

0 Likes
4 Replies
ShipingW_81
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

I tested this issue on 062 DVK board, not found any scan response missed, even though adv/scan response packet from same device has ever been received. Please find below UART log during this process:

GAPC_START_SCANNING

...

-------------------------------------------------------------------------

uuid: BAS SERVICE - YES, added to the connect list 

ADV type: 0x0 address: 00a050000002, rssi - -36 dBm, data - 02 01 05 0e 09 42 61 74 74 65 72 79 20 4c 65 76 65 6c 05 03 0a 18 0f 18

-------------------------------------------------------------------------

////////////////////////////////////FIRST ADV PACKET FROM 00a050000002//////////////////////////////////////////////

ADV type: 0x4 address: 00a050000002, rssi - -36 dBm, data - 0e 09 42 61 74 74 65 72 79 20 4c 65 76 65 6c

////////////////////////////////////FIRST SCAN RESP PACKET FROM 00a050000002////////////////////////////////

ADV type: 0x0 address: 5e670a606e46, rssi - -96 dBm, data - 02 01 1a 0a ff 4c 00 10 05 01 1c 53 0a 63

ADV type: 0x0 address: ee4e031ad5db, rssi - -100 dBm, data - 02 01 06 07 09 6d 6f 62 69 6b 65 13 ff b3 04 01 60 ee 4e 03 1a d5 db 02 16 82 17 11 00 00 00

ADV type: 0x4 address: ee4e031ad5db, rssi - -99 dBm, data -

ADV type: 0x0 address: 611928b068d7, rssi - -102 dBm, data - 02 01 1a 0a ff 4c 00 10 05 0b 1c 57 aa df

ADV type: 0x0 address: 5afab830b0eb, rssi - -100 dBm, data - 02 01 1a 0a ff 4c 00 10 05 0b 1c 6b 1b 18

ADV type: 0x0 address: 00a050000002, rssi - -35 dBm, data - 02 01 05 0e 09 42 61 74 74 65 72 79 20 4c 65 76 65 6c 05 03 0a 18 0f 18

////////////////////////////////////SECOND ADV PACKET FROM 00a050000002//////////////////////////////////////////////

ADV type: 0x4 address: 00a050000002, rssi - -35 dBm, data - 0e 09 42 61 74 74 65 72 79 20 4c 65 76 65 6c

////////////////////////////////////SECOND SCAN RESP PACKET FROM 00a050000002/////////////////////////////////

ADV type: 0x0 address: 5f3d8537e4bc, rssi - -68 dBm, data - 02 01 1a 0a ff 4c 00 10 05 0b 1c c5 74 e4

ADV type: 0x4 address: 5f3d8537e4bc, rssi - -68 dBm, data -

ADV type: 0x0 address: ee4e031ad5db, rssi - -98 dBm, data - 02 01 06 07 09 6d 6f 62 69 6b 65 13 ff b3 04 01 60 ee 4e 03 1a d5 db 02 16 82 17 11 00 00 00

ADV type: 0x0 address: 4542e9b77efb, rssi - -92 dBm, data - 02 01 1a 0a ff 4c 00 10 05 03 1c f5 28 06

ADV type: 0x0 address: 6b830a8ddb8d, rssi - -91 dBm, data - 02 01 1a 0a ff 4c 00 10 05 0b 1c 1d e0 3f

ADV type: 0x0 address: 00a050000002, rssi - -35 dBm, data - 02 01 05 0e 09 42 61 74 74 65 72 79 20 4c 65 76 65 6c 05 03 0a 18 0f 18

ADV type: 0x4 address: 00a050000002, rssi - -35 dBm, data - 0e 09 42 61 74 74 65 72 79 20 4c 65 76 65 6c

ADV type: 0x0 address: 5afab830b0eb, rssi - -102 dBm, data - 02 01 1a 0a ff 4c 00 10 05 0b 1c 6b 1b 18

ADV type: 0x0 address: ee4e031ad5db, rssi - -98 dBm, data - 02 01 06 07 09 6d 6f 62 69 6b 65 13 ff b3 04 01 60 ee 4e 03 1a d5 db 02 16 82 17 11 00 00 00

ADV type: 0x4 address: ee4e031ad5db, rssi - -97 dBm, data -

...

All above log recorded in a single scan process. For a same device, the central can always receive both adv packet and scan response packet only if scan is not terminated. Active scan needs to be enabled for receiving scan response.

The test code is the one attached in another CDC thread Cy_BLE_GAPC_ConnectDevice returns CY_BLE_ERROR_INVALID_OPERATION​. What I modified is just enabling UART printing once scan response received.

Please check if it helps on your application scenario.

0 Likes

I only see the problem with missing scan response when the peripheral has bad RF performance.  I capture the packets with a Frontline BPA analyzer and I can see sometimes up to 80% CRC error.  Can you test at long range or simulate bad RF?  From your log I can see many other devices.  If there are many devices, I will eventually get the scan response also once the filtering cache overflows because I will keep getting duplicate advertising packets also.

0 Likes
lock attach
Attachments are accessible only for community members.

Attached log capture of simulated bad RF case. As you said, some scan response packets are lost under this condition.

The lost packets mean they might be broken when received on PHY layer and then being discarded, nothing related to stack packet filtering way.

I believe there would be little enhancement space in terms of BLE stack or SW. Trying to improve RF performance or avoid bad RF condition should be right direction.

0 Likes

When there are very few advertisers around, if only the scan response is missed the first time the scanner will not report it until a new scan is started.  Everything will be filtered out even good scan responses which was never reported.

0 Likes