Possible false scan requests.

[Al Bundy]

I have set up a simple test to check if scan request can be used as an acknowledgement for advertising packets. I send some distinct advertising packets and multiplex them when I receive BLE_GAP_EVT_SCAN_REQ_REPORT from particular mobile phone (I check its MAC address). I log advertising data on both endpoints and I have realized that sometimes I get BLE_GAP_EVT_SCAN_REQ_REPORT from my mobile, however the advertising data is not delivered to the mobile application. 

I think 2 scenarios are possible. The first one is that there is a bug in Softdevice (I use S110 from SDK 9.0.0). The second one is that the advertising data is lost in bluetooth adapter/driver/stack on mobile (Android 7.0 Nougat on Samsung Galaxy S6 used for tests).

Do you know what might be the problem?

[MartinBL]

Hi,

The APIs in Android doesn't necessarily deliver each and every advertising event to your application instantly. It can be configured to deliver a batch of advertising reports every other second for example. In other words, it is not certain that the advertising event that the mobile is replying to is delivered to your application immediately. If, for example, during 2 seconds of scanning your phone receives 20 advertising packets from 4 different devices, it will pick one packet from each of the four devices and deliver only those. I'm not sure what happens if the content of your advertising packet changes while your phone collects advertising reports. Could this be relevant to your problem?

Also remember that there is no guarantee that your phone receives 100 % of the packets. 

[Al Bundy]

I know that's why I want to use Scan Request as an acknowledgement. 

My beacon advertises with 4 seconds interval. If I get Scan Request I change the data and ADV with new data takes places 4 seconds later. I think that should be enough for mobile BLE stack to deliver data to my application.

[MartinBL]

Hi,

I'm not sure I understand how it could be a bug in the Softdevice causing this. Anyway, I suppose a sniffer trace would could be useful. It would show exactly what advertising packet (and its content) the mobile responds to. If you have an extra Nordic dev kit to spare you can use our nRF Bluetooth Sniffer solution.