Page 1 of 1

What else can be done during a BLE Scan callback

Posted: Fri Oct 25, 2019 2:05 am
by Aussie Susan
I am writing an app that needs to scan multiple BLE devices that will be advertising intermittently (they are battery driven and so are inactive much of the time, waking briefly to advertise and see if there is a quick response before going back to a deep sleep).
This means that the ESP-IDF based code needs to respond as fast as possible when it picks up an advertising device.
I set up a scan and I can detect the advertising device via the callback. I could then remember the device's ID, wait for the scan to complete and then try to access the device, but the device will probably be back to sleep by the time.
What I would *like* to do in the scan callback code is to connect to the device immediately, read the data and then break the connection before returning from the scan callback.
My question: can I do this? Are there limitations on what other BLE API functions can be called inside a callback function? (I've looked but I can't see this documented anywhere.)
Susan

Re: What else can be done during a BLE Scan callback

Posted: Fri Oct 25, 2019 5:25 pm
by genedyne
Consider that a BLE scan involves the scanner hopping between the three 'broadcast channels', dwelling on each channel to listen for broadcasts. What you would need to do is either 'pause' or 'stop' this process, so you can make the radio link to a single device & read data.

I'd suggest you abort the scan, link with the new device & read whatever data is required, then start a new scan.

If you have control of the device code, and the data is very small, you might also consider just including the data in the advertisement packet, so there is no need to stop the scan at all.

Re: What else can be done during a BLE Scan callback

Posted: Mon Oct 28, 2019 1:47 am
by Aussie Susan
Thanks for the reply.
I had thought of sending the data in the advertisement packet but I run into size limitations of the packet.
I'll have a go at the approach you suggest. I was already needing to keep a track of the devices that I could see advertising (the will all have the same service UUID but different device IDs) so that I only try to access them once every so often and not each time I see an advertising packet,
Susan