Discussion Forums

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: https://github.com/particle-iot/firmware/issues/1519.


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.


I know…old thread, but I’d like to revisit this since I am not sure I explained my issue well enough based on your response.

The stack is not blocked AND the scan callback is not firing. Something happens to the BLE radio where it seems to stop functioning. I conclude this because with packet logging enabled I no longer see any activity when interacting with the ble object. I have not been able to trace it to anything environmental (bad advertisements etc). Re-initialization (ble.deInit / ble.init) has no effect. Must reset.

I am not expecting I will find the source of the issue in the short term, but as a stop-gap perhaps a way to know if the BLE stack is operating normally. I can’t just test to see if the scan callback is firing because there legitimately may be times where there is no scanable BLE activity.

Can you think of how I might test the state of the radio as a workaround so I know when to trigger a reset.