Unexpected low battery life Garmin Vivoactive 3

[seaside1]

I'm running a Garmin Vivoactive 3 watch with surprsingly high battery usage. Without running the SD-app, it hold for 1 week or more. Running with the app I get around 4 hours on a full battery when running the app. Using an Samsung S9 phone seeing around 5 - 7s response times. I do get a periodic error message on the app "Err: Retry" but shifts back to "OK". On the Phone no errors are being displayed. The Phone reacts as expected to shaking events

Are there any setting or tricks to be taken? Using default setting of the the Android App (4.2.1). Don't see the backligt being invoked, but could be wrong.

[jones139]

Thanks for reporting this - I haven't tried the Vivoactive 3 for some time, so I'll charge mine up and see what it does - last time I used it I think it was getting of the order 14-15 hours so it sounds like there is a significant problem with yours. The ERR: Retry is saying there is something wrong with the bluetooth communications between the watch and the phone - you should not see this unless there is a lot of radio noise or you are a long way from the phone. I think that Version 1.4 of the Garmin watch app has a setting for 'Low Data Mode' - this only sends vector magnitude data rather than the three individual accelerometer axes so reduces the data transfer, which might help.

I am actually very pleased with how well the low cost PineTime watch is performing - you might want to think about trying that as an alternative?

[seaside1]

Hi! Distance is not a problem. Bluetooth works well with the same phone and pebble. I'll see if i can try out the low data mode.

Regarding pinetime, i have already ordered one, but got stuck in customs, should have it latest by end of this week. Will be interesting to test it out.

Regards, s

[pmithrandir]

Hi,

@jones139 do you remember on which version you tested the vivoactive 3 ? Is it still around 14 hours ?

On my side, I'm going to test back all builds to see if we didn't introduce a regression over time in the end. I put 1.1 this evening, will see how it goes and I'll test the other one if I get significant battery performance differences.

[pmithrandir]

BTW, I think I know why we are getting more "RETRY" message on the latest versions. The timer starts before the data are sent to the phone, and it's reseted only when the next data are sent. In the meantime, the system needs to

• send the post request
• retreive the callback and release the possibility to get another set of data to be send.
• send data when the dataset is big enough. (5sec)

Timeout being set at 5sec + 1 sec to get it checked in on tick... it's too small. PR to be validated for that issue.

[jones139]

@pmithrandir , I can't remember which version I last used on my Vivoactive 3. It's just charging up now so I'll try it on the latest release tonight and let you know.

[jones139]

@pmithrandir, I have managed to get my Vivoactive 3 charged, but I am not sure how good its battery is - it had been discharged for quite a long time. I have put the latest release of OSD on it (V1.4.1) and have noticed a couple of things:

• I see the ERR: Retry error on the screen a lot as reported by @seaside1.
• The time between updates is about 7 sec rather than the intended 5 sec, which is consistent with some bluetooth transfers failing or being slow.

I will run it overnight to see how the battery performs.

[jones139]

I got just over 6 hours on my vivoactive 3 last night, which is still barely useble. I'll recharge it and try it on 'low data mode' tonight.

[jones139]

I have enabled low data mode and that has got rid of the err:retry messages, so the Bluetooth comms must be very slow for some reason. Will see in the morning if it does anything for battery life or not. (I'm running the latest release, v1.4.1)

[pmithrandir]

It does work on my side to lower the battery consumption. I'm around 12 without it, around 15 with...

BTW, I got rid of the retry with the PR submitted yesterday evening.

I also tried to "compress" the json, but Garmin doesn't seem to provide something to do that. My assumption is that the network is consuming too much battery.

We can also check if gamin did some changes affecting the performance.

Maybe another idea would be to lower the amount of data sent to 2 sec, maybe we are having some failure / retry process going on silently. I don't have much other idea in my mind.

[jones139]

If the amount of data transfer is really the big issue we could switch to a binary data transfer rather than JSON. By default it is not very bandwidth efficient - we send both vector magnitude and the 3 accelerometer axes values in the same message - we could calculate vector magnitude on the phone to avoid that too - at the moment we send 125 off vector magnitude + 3 x 125 off acceleration values every 5 seconds - all as text strings. Low Data mode drops the 3x125 off acceleration values and only sends vector magnitude. We could go to 3x125 off 2 byte words. This is essentially what I am doing on the BLE data source for PineTime. BUT there is something odd about these Vivoactive 3 watches because the amount of data we are sending is not really very high by BLE standards, so I suspect Garmin have broken something for the communications to be working so slowly!

If you want to try implementing a binary version I could do a test build of the Android app with a different Garmin Data source which would handle it. But before going too far, I'd try a build of the watch app which does everything except send data to the phone and check that solves the battery life issue first.

On Wed, 20 Mar 2024 at 20:00, Pierre Bonneau @.***> wrote:

It does work on my side to lower the battery consumption. I'm around 12 without it, around 15 with...

BTW, I got rid of the retry with the PR submitted yesterday evening.

I also tried to "compress" the json, but Garmin doesn't seem to provide something to do that. My assumption is that the network is consuming too much battery.

We can also check if gamin did some changes affecting the performance.

Maybe another idea would be to lower the amount of data sent to 2 sec, maybe we are having some failure / retry process going on silently. I don't have much other idea in my mind.

— Reply to this email directly, view it on GitHub https://github.com/OpenSeizureDetector/Garmin_SD/issues/52#issuecomment-2010517166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLSY55OA65LU5Z45HWHULYZHTHPAVCNFSM6AAAAABE3HKST2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGUYTOMJWGY . You are receiving this because you were mentioned.Message ID: @.***>

-- Graham Jones http://google.com/+GrahamJones Hartlepool, UK.

[pmithrandir]

As we are talking about 4kbytes in full data mode, I'm surprised like you by the impact. That's why I thought maybe we could have some issues going on.

From my understanding, we could achieve the test by changing 2 methods: onTick:

• comment all line in the if except the one that does put data request boolean to 0 (to ensure that data are calculated as usual every 5 sec)
• comment the make web request line to prevent data to flow to the cellphone.

Anything else ?

[jones139]

Yes, I am thinking of commenting out the makeWebRequest calls (and force the 'request in progress' flags to false) so it does everything except actually send data to the phone - and see what that does for battery life.

On Wed, 20 Mar 2024 at 22:21, Pierre Bonneau @.***> wrote:

As we are talking about 4kbytes in full data mode, I'm surprised like you by the impact. That's why I thought maybe we could have some issues going on.

From my understanding, we could achieve the test by changing 2 methods: onTick:

• comment all line in the if except the one that does put data request boolean to 0 (to ensure that data are calculated as usual every 5 sec)
• comment the make web request line to prevent data to flow to the cellphone.

Anything else ?

— Reply to this email directly, view it on GitHub https://github.com/OpenSeizureDetector/Garmin_SD/issues/52#issuecomment-2010749733, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLSY6VD362QVDETO7EQODYZIDWXAVCNFSM6AAAAABE3HKST2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQG42DSNZTGM . You are receiving this because you were mentioned.Message ID: @.***>

-- Graham Jones http://google.com/+GrahamJones Hartlepool, UK.

[jones139]

OK, running v1.4.1 in Low Data Mode drained battery on my Vivoactive 3 from 100% to 20% in 11 hours, so would be expected to be flat in somewhat over 13 hours. I also switched the back-light gesture activation off so you have to tap the screen to switch on the light. I think it is the low data mode that had the big effect though.

So as an interim, enable low data mode, and re-start the watch app to make sure the change takes effect. This should improve the battery life and stop the err:retry warnings.

Please let us know what effect you see, @seaside1 .

Thanks Graham

[seaside1]

Turning backlight off and enabling low data mode gives 9h battery time (Measuring for 1h with the watch on so pulse and motion event are being sent), which is ofc much better than the previous 4h.

[pmithrandir]

My test so far without network.26% battery consumed in 4h30 in full data mode without O2.Meaning for 12 hours 80 to 85% ( battery drain is faster in the end for me)The impact of network data transfer doesn't seem to be very relevant.Pierre Sent from Android deviceLe 21 mars 2024 12:25, seaside1 @.***> a écrit : Turning backlight off and enabling low data mode gives 9h battery time (Measuring for 1h with the watch on so pulse and motion event are being sent), which is ofc much better than the previous 4h.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[jones139]

Lots of data, thank you - I think we need to try to summarise:

Estimated time to flatten battery	User	Normal Mode	Low Data Mode	No Network
@seaside1	4h	9h
@pmithrandir	12h	15h	16h
@jones139	6h	13h

So the ratio of Low Data to Normal mode for @seaside1 and @jones139 is similar, but @pmithrandir seems to be getting much better performance than either of us in Normal Mode. Now my watch battery had been discharged for a long time when I did my normal mode test, so that may not be valid, so I'll re-do my normal mode one next, then I think I'll try the @pmithrandir no-network test after that.

[pmithrandir]

To give more data.Watch at 47% after 8h30 of usage without network.I need to charge it back for tonight... Bad timing it's a seizure high risk for my son so I need the watch this night.Sent from Android deviceLe 21 mars 2024 14:23, Graham Jones @.> a écrit : Lots of data, thank you - I think we need to try to summarise: Estimated time to flatten battery UserNormal ModeLow Data ModeNo @.@@.*** So the ratio of Low Data to Normal mode for @seaside1 and @jones139 is similar, but @pmithrandir seems to be getting much better performance than either of us in Normal Mode. Now my watch battery had been discharged for a long time when I did my normal mode test, so that may not be valid, so I'll re-do my normal mode one next, then I think I'll try the @pmithrandir no-network test after that.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[jones139]

To give more data.Watch at 47% after 8h30 of usage without network

Thanks - I have updated the value to 16 hours in the table based on that. Still surprisingly little difference compared to your other values. If the bluetooth communication is really not causing the issue, it is as though it is CPU usage copying the 3d data causing the delay and battery use when we are not using low data mode. This is a surprise as it works fine on other watches - I wonder if there is something different about the underlying hardware in the Vivoactive 3 compared to other Garmin watches....or Garmin has done something in the Firmware of this watch which has messed it up.

[pmithrandir]

Hi @jones139 ,

How much work would it be on android to allow the data dict to be removed in normal mode ? If we have the 3D data, we don't need the data anymore, and maybe it could reduce the calculation and transfer on the watch a bit. (1600 char + square root to calculate while on the 3d data side we get 2100 char and no CPU used)

It might even be possible that 3d data are actually lower on battery than light data in the end.

---

also, I believe the options for the sensor configuration should be set up that way:

var options = {
        :period => SAMPLE_PERIOD,
        :accelerometer => {
            :enabled => true,
            :sampleRate => SAMPLE_FREQUENCY
        }
    };

Maybe it will help.

I created a branch showing my suggestion. Tell me your feedback please.

[jones139]

I have made a draft version of V4.2.3 which tries to use vector magnitude data if it is sent. If it is not, it calculates it from the 3d data if it is available. I have done a quick test and it does not appear to break the current version, so you should be able to try a version that omits the vector magnitude array and see what it does:
https://github.com/OpenSeizureDetector/Android_Pebble_SD/blob/V4.2.x_3dData/app/release/app-release-4.2.3a.apk

[pmithrandir]

Hi,

I tried to link my app version to your phone new version and I got the following logs.

13:42:16 : SDComms.sendAccelData() : sendAccelData start - data to send = {"dataType":"raw","data3D":[304,-392,-940,296,-388,-952,296,-372,-960,300,-388,-972,292,-404,-964,284,-416,-972,272,-416,-944,288,-432,-996,228,-380,-964,224,-400,-940,212,-388,-996,208,-440,-1012,200,-436,-984,160,-408,-968,116,-388,-948,92,-356,-1020,36,-300,-988,36,-356,-988,44,-344,-1004,52,-404,-988,-52,-404,-1000,-100,-536,-1020,-40,-580,-808,128,-616,-640,-124,-516,-820,-8,-416,-1004,12,-324,-964,-104,-88,-1124,-116,-136,-1160,-88,-144,-1200,-132,-184,-1088,-12,-268,-1076,0,-272,-1072,16,-284,-1076,52,-376,-1040,32,-400,-964,92,-340,-1048,0,-312,-968,-16,-280,-952,48,-344,-972,80,-356,-1040,96,-328,-992,140,-348,-984,136,-296,-960,228,-288,-892,296,-284,-776,280,-348,-748,216,-588,-1008,116,-632,-1264,248,-464,-1080,224,-432,-856,184,-444,-936,124,-424,-1000,152,-432,-960,184,-412,-952,144,-388,-972,140,-388,-936,156,-436,-856,196,-484,-860,196,-464,-912,196,-452,-952,196,-448,-984,160,-440,-1020,152,-416,-1060,152,-408,-1052,144,-400,-1020,176,-408,-992,188,-416,-968,196,-436,-944,236,-464,-924,244,-492,-940,260,-492,-960,292,-484,-960,268,-472,-968,232,-440,-992,236,-412,-1012,208,-384,-980,216,-392,-940,216,-412,-920,208,-448,-912,212,-480,-904,160,-472,-908,168,-504,-920,148,-512,-956,112,-492,-980,108,-496,-968,148,-512,-940,128,-504,-956,124,-496,-972,128,-500,-952,112,-468,-932,112,-456,-912,116,-488,-912,116,-532,-996,132,-548,-992,92,-480,-952,116,-480,-936,176,-532,-924,180,-492,-856,180,-476,-864,188,-464,-940,148,-420,-944,208,-408,-956,236,-396,-948,232,-356,-980,240,-408,-936,264,-424,-868,240,-408,-860,192,-376,-856,208,-452,-908,196,-504,-852,220,-524,-984,164,-516,-976,260,-548,-924,284,-556,-1000,208,-484,-976,124,-524,-944,76,-512,-992,76,-440,-1044,164,-396,-940,212,-448,-896,224,-544,-1092,180,-436,-988,120,-372,-864,12,-544,-1024],"HR":null,"O2sat":0,"Mute":0}
13:42:17 : SDComms.onDataReceive() : sendAccelData End - Send Duration = 1
13:42:17 : SDComms.onDataReceive() : sendAccelData End - response code = -300
13:42:17 : SDComms.onDataReceive() : sendAccelData End - data = null
13:42:18 : SDComms.onDataReceive() : Failure - code =-300

I don't know what else to do with that feedback. I checked the code on android side: https://github.com/OpenSeizureDetector/Android_Pebble_SD/blob/V4.2.x_3dData/app/src/main/java/uk/org/openseizuredetector/SdDataSource.java#L284

But no luck so far.

[jones139]

OK, running v1.4.1 in Low Data Mode drained battery from 100% to 20% in 11 hours, so would be expected to be flat in somewhat over 13 hours. I also switched the back-light gesture activation off so you have to tap the screen to switch on the light. I think it is the low data mode that had the big effect though.

So as an interim, enable low data mode, and re-start the watch app to make sure the change takes effect. This should improve the battery life and stop the err:retry warnings.

Please let us know what effect you see, @seaside1 .

Thanks Graham

[jones139]

Sorry, I don't know why the comment above appeared- it looks like an old one....

[jones139]

What I meant to say is please point me to the watch app you are using and I'll try it out this evening.

[pmithrandir]

https://github.com/OpenSeizureDetector/Garmin_SD/tree/52-no-data-and-option-corrected

I'm using that version

[jones139]

It was my fault - I hadn't told it how many acceleration measurements we had - fixed in version 4.2.3c here: https://github.com/OpenSeizureDetector/Android_Pebble_SD/blob/V4.2.x_3dData/app/release/app-release-4.2.3c.apk

It runs on my vivoactive 3 using your watch app (I haven't checked which settings to select, but it is running my code which means it has received 3d data but not vector magnitude, so the watch app is doing what you intended).

[jones139]

I have just uploaded a re-build version of V4.2.3c (to the same URL as above) - this now includes the latch alarm fix that @seaside1 identified, so should not have affected the 3d data bits - just trying to keep the branches up to date!

[pmithrandir]

It's installed and compatible.

I was not able to test the battery this evening, but I tried the version without network today and it was a bit better than the low data mode.

I believe that one of the issue is the calculation of square root and amount of data.

I see 2 others improvements:

• work with value² and not the square root in the phone algorithm (that's 25 operations saved by second + only int to be transfered)
• find a way to transfert data using ascii encoding. We would reduce the amount of data by 8 (200Bytes per 5 sec in place of 1600 with my version)
• We could also cumulate both solution.

Regards, Pierre

[jones139]

It's installed and compatible.

Excellent - as it is backward compatible with older versions of the watch app, I'll merge this change into V4.2.3, which will be the next beta test version on Play store.

I was not able to test the battery this evening, but I tried the version without network today and it was a bit better than the low data mode.

I have run it overnight. It used 60% of battery in about 8 hours, so around 13 hours life - still not great, but it meets my 12 hours specification that I consider to be acceptable. No retry warnings either, thank you!

I see 2 others improvements:

• work with value² and not the square root in the phone algorithm (that's 25 operations saved by second + only int to be transfered)

:) this is what I used to do on the Pebble to save computer power, but I have gradually modified things to make them mathematically correct! No need to do this as sending 3d data is working so the processing is on the phone.

• find a way to transfert data using ascii encoding. We would reduce the amount of data by 8 (200Bytes per 5 sec in place of 1600 with my version)

Yes, thus is possible - effectively do a binary transfer using 2 byte integers. But I think your test with no network showed it did not make so much difference? We'd need to work out a way of modifying the phone code to maintain backward compatibility as well.

[pmithrandir]

My test last evening gave me 10h30 of usage for 68% of battery used. It doesn't work for a day to day usage, but for night guarding it's enough !

[pmithrandir]

The app reached 10% battery and was shut down after 12h40 hours of usage. Battery run slowly for the first 6 hours, then it's getting faster and faster until it's empty.

[pmithrandir]

I might have 2 other ideas

• We redraw the layout every sec... while no important data are changing before 5 sec(send accel callback). We could stop displaying seconds are redraw only every 5 sec.
• We are starting the handler and stopping it very sec. I'm going to try to start it at launch time and see if it stays up and running or not and if the battery is having a better life)

[jones139]

I think I tried only drawing the screen every 5 seconds, but did not see any significant change, but it might depend which device- I tried it on a forerunner 245.

Restarting a handler does sound wrong so we should look at that - I can't think what it is doing without the code in front of me.

Thanks!

On Sat, 23 Mar 2024, 17:28 Pierre Bonneau, @.***> wrote:

I might have 2 other ideas

• We redraw the layout every sec... while no important data are changing before 5 sec(send accel callback). We could stop displaying seconds are redraw only every 5 sec.
• We are starting the handler and stopping it very sec. I'm going to try to start it at launch time and see if it stays up and running or not and if the battery is having a better life)

— Reply to this email directly, view it on GitHub https://github.com/OpenSeizureDetector/Garmin_SD/issues/52#issuecomment-2016554503, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLSY3L6DHVSEKD2WPL4R3YZW3UJAVCNFSM6AAAAABE3HKST2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGU2TINJQGM . You are receiving this because you were mentioned.Message ID: @.***>

[jones139]

I have just created a pre-release V1.5.0 based on where we are now with the development branch. I'll merge this into the main branch once V4.3.x of the Android app is the production version on Play Store, because the change to the data format needs this Android App version. I wanted to call it a release before I forget what we have changed! Thank you both @pmithrandir and @seaside1 for the efforts you have put in to this - if there are minor changes as a result of this issue, we can create a V1.5.1 etc. If we do something more major (like change the return data we expect from the phone), we'll call that V1.6. Graham

[seaside1]

Running 1.5.0 and Android app 4.2.4 I now get aroudn 20 hours on the Vivoactive 3. Which is a huge improvement.

I do however now get a periodic message "Err: Comm" on the watch, nothing visible on the app and BLE update time is consistent between 4-5 seconds. When the Err: Comm occurs you get a vibration of the watch as well, is this possible to turn off? I also notice that time between phone and watch differs with ~20 seconds.

[pmithrandir]

That's indeed a good news... I would love to have seen a similar gain on my side. (I'm stuck around 13 hours).

I'm wondering how it was possible to increase so much the battery life just with the changes we made.

[seaside1]

I only ran for 1 hour and extrapolated the time vs battery. So could very well be a lot less, but as comparison to my last measurement I went from 91% to 64% in an hour and now from 81% to 76% (also 1 hour). This was not using Low data mode. For low data mode I had 11% drain for one hour.

1.4.0: 27% (1 hour) 1.4.0 Low data mode: 11% (1 hour) 1.5.0: 5% (1 hour)

I'll try a more realistic run later to see the actual battery time.

[jones139]

Thanks for this - I'll let @pmithrandir think about this one, and I'll concentrate on PineTime for now

[pmithrandir]

I see 2 main reasons for vibration to occur:

• in the app menu, you selected vibration
• You are geting notification from your phone.

I know I disabled all notification on my watch, and I don't get that issue. If it doesn't work with that new informaion, please let me know.

[seaside1]

Vibrations are turned off, I have disabled all notifications, and this phone is off. I'll see if I can get the logs and see if that gets a hint. I got 16 hours for the full battery yesterday so yes great improvement.

[jones139]

16 hours is excellent, well done @pmithrandir for working through the code to optimise it, thank you!

[pmithrandir]

Hi @seaside1 What is the status on your side ?

With version 1.5 or 2.0 which is coming, do you get the expected battery life ?

Should we close that issue ?

Regards, Pierre

[jones139]

For info, I have run V2.0.2 on my Forerunner 245 and it looks like giving just under 16 hours battery life (has used 44% in 7 hours) - this is good because I was always disappointed in the battery life on that watch. Thanks! Will terminate that test now to go back to the VenuSQ to see if it disconnects.

[jones139]

For future reference, here is a useful discussion that @pmithrandir has been having on the Garmin forums about this issue: https://forums.garmin.com/developer/connect-iq/f/discussion/364926/any-leads-to-improve-battery-consumption?pifragment-1298=2

[seaside1]

Yes IMO you can close the issue. I built it on my own, and only using Vivoactive3 and mapped firmware.