What else can be done during a BLE Scan callback

Aussie Susan
Posts: 30
Joined: Thu Aug 22, 2019 3:48 am

What else can be done during a BLE Scan callback

Postby Aussie Susan » Fri Oct 25, 2019 2:05 am

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

genedyne
Posts: 15
Joined: Wed Jun 06, 2018 12:47 pm

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

Postby genedyne » Fri Oct 25, 2019 5:25 pm

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.

Aussie Susan
Posts: 30
Joined: Thu Aug 22, 2019 3:48 am

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

Postby Aussie Susan » Mon Oct 28, 2019 1:47 am

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

Who is online

Users browsing this forum: Google [Bot] and 58 guests