Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

SCAN_REQ and SCAN_RSP logging

Hello, I have a question about the scan request event.

I checked the logs of BLE_GAP_EVT_SCAN_REQ_REPORT.  If this event is received, does Softdevice recognize the packet as SCAN_REQ properly and surely send back SCAN_RSP?  If there are any problems in receiving a SCAN_REQ packet (e.g. CRC error), can I see any logs/messages?  Or if there are any problems in sending a SCAN_RSP packet, can I see any logs/messages as well?

I am looking for any tools/methods to make sure the scan response procedure works in the software level.

[Environment]

nRF52832 custom board

nRF5 SDK 17.1.0

Softdevice S132 v7.0.1, 7.2.0, 7.3.0

Sample source code : ble_peripheral\ble_app_blinky

 

[Modification]

I added the following lines in main.c and built a debug module.  The log messages are seen.

// In advertising_init

    adv_params.scan_req_notification  = 1;

 // In ble_evt_handler

         case BLE_GAP_EVT_SCAN_REQ_REPORT:

            NRF_LOG_INFO("SCAN_REQ");

            break;

  • Hello,

    If this event is received, does Softdevice recognize the packet as SCAN_REQ properly and surely send back SCAN_RSP?

    Yes, that is correct.

    If there are any problems in receiving a SCAN_REQ packet (e.g. CRC error), can I see any logs/messages?

    You will only receive the event if the scan request was received properly. The same goes for any other BLE packet. Packets with CRC errors are not processed by the stack.

    Or if there are any problems in sending a SCAN_RSP packet, can I see any logs/messages as well?

    A scan response packet will not be acknowledged by the scanner, so there is no way for the advertiser to know if the response was received or not. In other words, if the scanner failed to receive the scan response, then it will have to send new SCAN_REQ.

    Best regards,

    Vidar

  • Hi Vidar, Thank you so much for your answer.

    I understand the first two answers.  For the third one, regardless of ACK, I wanted to know the logging mechanism to confirm that Softdevice completes the SCAN_RSP sending procedure.

    Seeing a sniffer log below, SCAN_RSP is missing after some of SCAN_REQ packets.  But the sniffer might have missed the packet and the peripheral device might have worked well.  So, the sniffer log is not helpful.  I will collect more Info, and I may ask some more questions related to this.

    Regards,

    Toru (Felipe1)

  • Hi Toru,

    No problem Slight smile The Softdevice will always send the SCAN_RSP after receiving SCAN_REQ unless there is an undiscovered bug in the stack. I think the more likely explanation is that either 1. the scan request was only received by the sniffer, but not the nRF 2. the sniffer missed the scan response packet.

    Regards,

    Vidar

  • Hi Vidar,

    Thank you for your comments.  As you wrote, the sniffer Info cannot exclude those possibilities.  Therefore I was trying to look into the device itself.  (Softdevice should work as expected, but seeing the release note of v7.3.0, DRGN-15484 would be related to SCAN_RSP.)

    But I will stop this approach and check it in another way.

    Thank you again for your support,

    Toru

  • Hi Toru,

    Thanks for making me aware of this bug. Based on the bug description, this should only occur on the last adv. event if you are advertising with a timeout, so I'm not sure if it is relevant to your case.

Related