Possible to just receive SCAN request, but not send SCAN response?

[Brian]

Hey guys,

I’m trying to come up with a way to know if an advertisement was received via BLE_GAP_EVT_SCAN_REQ_REPORT, but then not actually send the SCAN response. It’s a very low power, peripheral beacon application and all I want to know is whether an iPhone received my beacon. If so, I can stop advertising indefinitely.

If I change m_adv_param.type from BLE_GAP_ADV_TYPE_NONCONN_IND to BLE_GAP_ADV_TYPE_ADV_SCAN_IND, does that automatically make the stack send the scan response? If so, is there a way to disable the scan response but still detect that it was requested?

Working on nRF51822 and SDK9-2.

Many thanks! Brian

[endnode]

Hi Brian,

Short answer is NO, it isn't possible to detect the SCAN_REQ but not letting SCAN_RESP going out.

If you indicate to the stack that your GAP Peripheral is scannable then it automatically handles SCAN_REQ packets and replies with SCAN_RESP burst. You can get indication that SCAN_REQ packet arrived but you cannot forbid Soft Device from sending the reply. You can limit the Tx power by providing empty data (to be precise srdlen parameter set to 0) in sd_ble_gap_adv_data_set function call (see Soft Device API specification here) which will result in empty SCAN_RESP packet, but still basic packet structure will be built and sent. Btw. is the Tx for such reply really a problem? I guess you would like to safe Rx window after every advertisement Tx burst, that can make significant power consumption over Beacon's life-time. But if you are implementing mechanism where you stop advertising completely (or for some longer time) if you detect scanning activity (maybe by some specific Central address?) then that small Tx current before you go to sleep looks negligible to me. However by experiment you cannot force Soft Device to be listening to SCAN_REQ but not sending the SCAN_RESP automatically and I assume this is in order to be BT SIG compliant. If you really need full answer then wait for Nordic guys to look into Soft Device code (if there could be the way to trick it;). Alternatively would be nice to compare if using non-connectable and non-scannable advertisement doesn't reduce power consumption (I assume Soft Device then don't perform short Rx window after each Tx advertisement burst but this would need confirmation from Nordic team) enough to stop bothering about scanning and implementing some "silent" windows (btw. you really stop advertising indefinitely after very first scanning detection? That looks like a deadlock;).

Cheers Jan

[Brian]

Thanks! This is really helpful. Roughly... how much more power is consumed by turning on the RX path after TX and making the beacon scannable with BLE_GAP_ADV_TYPE_ADV_SCAN_IND? Is it doubling the power for each TX? Thanks, Brian