4 Replies Latest reply on Nov 6, 2018 12:27 PM by JeHu_3414236

    BLE scan response not being reported

    JeHu_3414236

      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.

        • 1. Re: BLE scan response not being reported
          ShipingW_81

          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.

          • 2. Re: BLE scan response not being reported
            JeHu_3414236

            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.

            • 3. Re: BLE scan response not being reported
              ShipingW_81

              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.

              • 4. Re: BLE scan response not being reported
                JeHu_3414236

                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.