Toybox.BluetoothLowEnergy blows through battery

i've got a background watchface that uses BLE every 5 minutes to communicate with a pi-like device. it works fine but i've noticed it uses the watch battery way faster than i think it should.

no matter whether i read 1 characteristic or 3 characteristics every 5 minutes, it uses about 3% battery per hour on a forerunner 645m (vs 0.4%/hour for a built-in basic watchface, or 1.5%/hour for a background watchface that uses communication webrequests every 5 minutes.)

then i tried disabling everything except "Ble.setScanState(Ble.SCAN_STATE_SCANNING)" and had it disable scanning and exit the background process immediately after the first scan return (onScanResults) and it still uses 3% battery per hour!

i've also tested on an Epix2 and see 0.8% battery per hour which is better but still seems a lot for an Epix2 (i haven't compared to a communications bg wf on Epix yet.)

i guess connect iq is just doing something extremely inefficient like leaving BLE radio fully enabled whenever an app uses it at all...is there anything else I can try that might reduce battery use for BLE?

Top Replies

All Replies

0 jim_m_58 2 months ago

Are you calling unpair in the background when you have your data?

0 Horsetooth 2 months ago in reply to jim_m_58

yes, i started with your examples... but the battery use doesn't get any better when i don't even pair, just exit at the first scan result...

0 jim_m_58 2 months ago in reply to Horsetooth

And you turn off scanning when you got a good scan result?

0 Horsetooth 2 months ago in reply to jim_m_58

yes, in the quick-abort test, in onScanResults:

Ble.setScanState(Ble.SCAN_STATE_OFF);
Background.exit([{},{},-1]);

0 jim_m_58 2 months ago in reply to Horsetooth

Have you compared this against any other watch faces? Just having a background can impact battery, and then doing BLE can add more. (the BLE radio on when needed vs never on)

Right now, I'm running one of my test watch faces that has a background that runs every 10 mines, scans for a pi, and if found, pairs to it and reads a couple characteristics. I fully expect it to burn a bit more battery than a very similar WF of mine with no background service that doesn't use BLE. But after a few hours of testing, I see nothing I wouldn't expect

Think of it as similar to a watch face with a background service that does a makeWebRequest to get data from another site.

0 Horsetooth 2 months ago in reply to jim_m_58

yes -> (vs 0.4%/hour for a built-in basic watchface, or 1.5%/hour for a background watchface that uses communication webrequests every 5 minutes.)

0 jim_m_58 2 months ago in reply to Horsetooth

Compare it against a few CIQ watch faces. Native ones are not written in CIQ and can be more efficient

Native ones can't do BLE either,

0 Horsetooth 2 months ago in reply to jim_m_58

this one is my web request CIQ app: 1.5%/hour for a background watchface that uses communication webrequests every 5 minutes

its pretty obvious on the fr645m that BLE is killing the battery quicker than anything else since at 3%/hour it will die in about a day, and i've had the watch for a long time and never had to charge it more than every 3 or 4 days.

i'm still testing on the Epix to see how badly BLE does there.

0 jim_m_58 2 months ago in reply to Horsetooth

The reality is the 645/645m came out something like 6-7 years ago and are past End of Life, and even if you found something there, chances of a fix are really close to nil.

0 Horsetooth 2 months ago in reply to jim_m_58

understood, i was hoping there was something in CIQ i could do differently. i can only test on what i have, and the only other watch i have is an epix2. first one i tried was fr645m - i hope the newer watches are much improved but the first test i ran on the epix2 wasn't promising. the tests take a while (i run for 12+ hours to get good data, no other settings changed between tests).