Scanning callback sometimes is not getting called, for minutes. #553
-
So this is the code I am using to keep scanning continuously for BLE devices with a specific Service UUID. It works fine most of the time. With the results I am maintaining a list, and I am keep refreshing the list with "nearby" devices when the same device has been found again ( just like light blue app does ). Now what happens is that, sometimes for reaons I do not really understand the callback will not be called, at times for minutes altough checking at that same time ( when the callback is not called ) with light blue I can see the devices just fine. Do you have any explanation as to why that might happen? Can it be that because of the "allow duplicates" I am somehow filling / exhausting some internal buffers? Because the callback is indeed getting called hundreds of times / minute when it works.. Best Regards and thanks for this amazing Plugin. |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
@sanastasiou what are you passing in for |
Beta Was this translation helpful? Give feedback.
-
I have tried all the three available modes. At some point later than the others it always stopped delivering any results. I was always checking with another device to make sure the BLE was keep advertising. So I figured out the issue is the power consumption - battery life OS restrictions. I read somewhere that one could perform 5 scans per 30 seconds, but I find this to be highly untrue. I have now completely changed my code, to just do one scan and instantly connect to a device, for which I have implemented a basic ping pong characteristic which requires no authentication.. That way I know if my device is in the area ( requirement ).. In case no ping received for X seconds or disconnected I know that my device is gone.. I think this way is much more robust than having to rely on scan. Your thoughts? |
Beta Was this translation helpful? Give feedback.
-
Yeah, that 5-per-30 is a rough guide... manufacturers can be quite flexible on this front. Out of interest, under previous circumstances how many times were you starting a new scan? What you are describing sounds a bit more like a BLE beacon type of thing. For my own uses where I'm dealing with an intermittently available devices, I tend to start a single scan in low-power mode and let it run continuously. There's no general requirement to stop scanning when attempting to connect. During deeper doze modes Android may drop this to opportunistic temporarily (i.e., only reports BLE devices when another app is scanning too), but generally speaking I found this fairly reliable. Triggering a new scan to start when the app comes back into the foreground (whilst being careful of that 5-per-30 limit) can help ensure the app shows devices quickly while the user is working with it. |
Beta Was this translation helpful? Give feedback.
-
Oh.. wasn't aware that one could forever scan with low power mode.. In fact I would swear I read the exact opposite.. https://github.com/iDevicesInc/SweetBlue/wiki/Android-BLE-Issues#scanning-issues To answer your question. Before I rewrote my code.. I would continuously scan for like 1 second, stop, wait 10 seconds and start again. Not only that did not work ( no results callback ) but using another app on the same phone e.g. LightBlue was also not delivering results.. Then, after letting the phone cool down a bit, it would work again.. So now I have an initial scan of 5s, which until now always works and if nothing is found, I am trying as backup direct connections to previously connected devices ( I am saving their IDs into non volatile memory in the app ).. I have another question there as well about getDevices for ios.. Will open up another discussion for that. Would u have to have some example of this continuously working scan mode ? And have you also tested that in iOS as well? Best Regards and thanks for answering! |
Beta Was this translation helpful? Give feedback.
-
Yeah... that page is about 6 years old now, and definitely a lot has changed with Android's scanning behaviours since then 😅 . Definitely on modern Android, starting one long-running scan will perform much better than repeated launching a new scan (which quickly hits the throttling you've discovered).
What you've written above is immediately usable for continuous scanning. The two key things is to
You need to connect to a device while still scanning. requestLEScan doesn't stop until you explicitly tell it to, so... scan away! iOS works in the same way, just be aware that you need to take extra steps to allow Bluetooth scanning to continue in the background: https://github.com/capacitor-community/bluetooth-le#ios You'll want to subscribe to Bluetooth enabled notifications, as you'll need to restart the scan if Bluetooth is disabled and then re-enabled again. |
Beta Was this translation helpful? Give feedback.
-
Oh exzellent. I think I am going to incorporate the continuous scanning in my code.. It can be easily done now, so I don't have this one-off scan at startup. OK, I am gonna try it out and let you know! Thanks! |
Beta Was this translation helpful? Give feedback.
-
Thank you @peitschie for your valuable insight and sharing your knowledge here. |
Beta Was this translation helpful? Give feedback.
Yeah... that page is about 6 years old now, and definitely a lot has changed with Android's scanning behaviours since then 😅 . Definitely on modern Android, starting one long-running scan will perform much better than repeated launching a new scan (which quickly hits the throttling you've discovered).
What you've written above is immediately usable for continuous scanning. The two key things is to
onBluetoothDevi…