Scan Callback - Separate Thread?




Is the Scan Callback (onScanReportCallback) executed on a different thread than loop()? I am filling a queue object in the scan callback and then flushing the queue in the loop(). Is that a recipe for issues?

Reason I ask is I am trying to track down why the BLE radio just stops working after random intervals. It can not be re-initialized and stopping/starting scanning does not work either. A hard reset is the only way to restore functionality.

I wonder if the queue object is the problem.


BLE Scanning Stops Unexpectedly

Hi @panda,

You can definitely try the SYSTEM_THREAD(ENABLED) in you sketch. This will make the loop() executed in a separated thread. I was just wondering if the loop() is blocked by the system thread. To verify my suspicion, you can blink the user LED in the loop().

Best regards,


To clarify I have already been using SYSTEM_THREAD(ENABLED) in my sketch so that there is no blocking from the particle connections.

So I gather that if the callback is on another thread I need to make the use of the queue thread safe. I am just not sure how to implement a simple FIFO queue for advertisements that is thread safe.


FYI, the BLE stack is running in a separated thread, which has the same priority as the system thread. We haven’t make it thread safe so far. A ticket has been created here:


Thanks for the info on the ticket. Should I expect this to affect the scan callback too? I make no calls to the stack once scanning starts, but would the ticket explain why BLE just stops scanning and can not be recovered without reset? I tried to make the queue object inside the scan callback thread safe, but that did not have a good result.

I know this may seem coincidental, but I have 5 test devices scanning at the same time in the same location. Most, if not all, will stop scanning at the same time when the issue occurs. It leads me to believe that the stack fails on either a bad advertisement packet some some other environmental factor. However, I can’t seem to trap the cause.



The scan callback is invoked by the stack, which is running in a separated thread. If the stack is blocked, then no callback any more.