Search code examples
linuxbluetoothdbusbluezbluetooth-device-discovery

What are the known pitfalls of periodic vs continuous Bluetooth device discovery in Bluez/Linux?


I'm developing a BLE smartwatch companion app for Linux, and it needs to automatically reconnect to the selected device whenever it's in the range. My naive implementation just starts the device discovery whenever the connection is lost. It works well, but when the watch isn't around it would just keep scanning in the background forever. I assume that's wasteful, but I don't exactly know why. Does it noticeably increase the power consumption of the Bluetooth adapter? Any other implications?

Is it better to do a periodic discovery instead? Are there any common pitfalls about it that I should be aware of? Is there an extra cost to starting and stopping device discovery frequently (besides the cost of D-Bus messages)?

I'd like keep the detection latency low, so I was thinking to use an interval between discoveries of 10-20 seconds, and a discovery duration of a 2-3 seconds (it seems enough in my tests most of the time), plus maybe a longer discovery once per couple of minutes just to be sure. Are there any obvious issues with this idea?


Solution

  • As you said, there are multiple ways to achieve this and it all depends on your power, processing, and latency requirements. If your Linux device is not battery powered, then there's no big harm to have a continuous scan or a continuous outgoing connection as Emil suggested. In other words, as soon as you get an event that your smartwatch was disconnected, your application should be in a "continuous" state trying to reconnect to the smartwatch. This would be the best option in terms of latency, but not ideal for power consumption or background processing.

    If your device is battery powered instead, then the best option is to do periodic scanning/connection attempts instead. So when your smartwatch disconnects, your Linux device would immediately scan/reconnect for 30 seconds or so, but then go into sleep for 30 seconds and re-attempt a connection afterwards. This way your device is only active 50% of the time when trying to reconnect to the smartwatch.

    Finally, you can tweak your sleep/scan duration depending on your processing requirements. I personnally don't think there would be any big processing impact for most Linux devices given that they are multithreaded and support many gigs of RAM, but it doesn't hurt to be conscious and put the device to sleep for some time after the reconnection attempt.