Issues with getting scan request peer address though BLE_GAP_EVT_SCAN_REQ_REPORT event

[aeozyalcin]

Hello all,

I am trying to get the address of the scanner sent a scan request to my nRF52840 running as a peripheral and advertising. I am using SDK 15.0 and I have tried SoftDevice S140 v6.0 and also v6.1. I am using the BLE_GAP_EVT_SCAN_REQ_REPORT event and trying to extract the peer address. If it matches my RPi MAC address, it is supposed to turn on the LED on the eval board, however the LED does not turn on...

Here is my setup: I have an nRF52840 USB dongle eval board running and advertising. I have a Raspberry Pi 4 that is sending active scan requests to my eval board once every 10 seconds. I know that the Raspberry Pi is successfully sending the scan request, because it is reporting the extended UUID that my nRF52840 is advertising in its scan response. However, the LED on the nRF52840 eval board is not coming on. The raspberry pi Bluetooth MAC address is DC:A6:32:xx:xx:xx.

I read the documentation, and found that the event I need is BLE_GAP_EVT_SCAN_REQ_REPORT. I started with the BLE_app_blinky example as my foundation. Here is a snippet of my code:

Here, I enable the scan_req_notification event in the advertising_init function.

static void advertising_init(void)
{
    ...
    adv_params.primary_phy     = BLE_GAP_PHY_1MBPS;
    adv_params.duration        = APP_ADV_DURATION;
    adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED;
    //adv_params.properties.type = BLE_GAP_ADV_TYPE_NONCONNECTABLE_SCANNABLE_UNDIRECTED;
    adv_params.p_peer_addr     = NULL;
    adv_params.filter_policy   = BLE_GAP_ADV_FP_ANY;
    adv_params.interval        = APP_ADV_INTERVAL;
    adv_params.scan_req_notification = 1;
    ...
}

Here, I have the main logic for for checking scan request peer's address, and turning on the LED if the first byte of the peer MAC address matches what I expect. First byte of my RPi MAC address is 0xDC=220 integer:

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ...
        case BLE_GAP_EVT_SCAN_REQ_REPORT:
            // Event handler for when a scan request is received.
            peer_address = p_ble_evt->evt.gap_evt.params.scan_req_report.peer_addr;
            
            if(peer_address.addr[0] == 220)
            {
                bsp_board_led_on(BSP_BOARD_LED_1);
            }

            NRF_LOG_DEBUG("Scan request received.");            
            break;
    ...
}

I do think that we are going into the BLE_GAP_EVT_SCAN_REQ_REPORT event handler, but the peer address reported is just not matching what I expected. If I move the "turn on the LED" line outside of the if statement that checks for peer address, the LED does come on soon after I power up the device. That's how I know that the BLE_GAP_EVT_SCAN_REQ_REPORT event is being triggered. I have the USB dongle eval board, so I am not able to see any of the NRF log items unfortunately, which limits my debugging capability greatly.

I hope you can point out what I am missing here. Thanks!

[Edvin]

Hello,

First of all, as you probably noticed, the dongle is not really ideal for development, as it doesn't have any debug capabilities, nor logging backend support. I can really recommend you to get hold of an nRF52840 DK for development, and then you can flash the application to the dongle once it is working.

That being said, back to your question. How do you know that the Bluetooth address of the RPi is DC:A6:... ?

I have noticed that some devices report their addresses in different order (LSB/MSB). Try to check if (peer_addr.addr[5] = 0xDC)

(you can use "0x20" instead of 220.

As you say, since the LED is turned on if you move it outside the if-check, the event apparently occurs, so if you'd had a debugger, you could either have logged the addresses of the devices or set a breakpoint and checked the address.

Best regards,

Edvin

[aeozyalcin]

That was it! For some reason, the MAC address reported by scan_req_report.peer_addr was backwards. peer_addr.addr[5] ended up being 0xDC. Thank you for the idea!