Is it reliable enough to use SCAN REQUEST RESPONSE as ACK?

[esonhon]

In my case, I have 50+ devices as sensor and advertising measurements every 10 seconds, ADV_DURATION = 120s, use the 1E FF manufacturer data and self defined payload protocol.

One BLE scanner/observer to keep scanning with active scan (scan response request)

When the scanner got one or more scan result in NRF_BLE_SCAN_EVT_NOT_FOUND event, buffer it.

When the advertiser received BLE_GAP_EVT_SCAN_REQ_REPORT event, which indicates the observer has received this package, then stop advertising.

After a short period test, I found that the observer always lost many advertisement pack, but the adv device DOES received BLE_GAP_EVT_SCAN_REQ_REPORT  event. 

So,  the BLE_GAP_EVT_SCAN_REQ_REPORT  do not mean the scanner actually received the advertising packet? Or I have missed some detail configuration for this usecase?

Thanks.

[Susheel Nuguru]

Hi,

When the advertiser received BLE_GAP_EVT_SCAN_REQ_REPORT event, which indicates the observer has received this package, then stop advertising.

This is not a failproof way of knowing that your scanner has received the data. If anyone is walking around with their phone bluetooth on and with active scanning on by mistake (or any other device with active scanning on). then they would send  BLE_GAP_EVT_SCAN_REQ_REPORT to your device with sensors. If you stop advertising after this, does not mean the scanner of your interest has received the advertising packet.

[esonhon]

Thanks for your reply.

Actually I use a mechanism to bond the devices to scanner's MAC. If scanner's mac is not equal to desired one, advertising continue.

[Susheel Nuguru]

if you are knowing that BLE_GAP_EVT_SCAN_REQ_REPORT   came from the scanner of your interest based on the MAC, that could work.