Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Battery drain issues #18

Open
Artaud opened this issue Dec 10, 2018 · 51 comments
Open

Battery drain issues #18

Artaud opened this issue Dec 10, 2018 · 51 comments

Comments

@Artaud
Copy link
Collaborator

Artaud commented Dec 10, 2018

Let's talk about the battery drain.

How big drain do you get on your watch model?
How big a drain is acceptable for you?
What might be the causes of the drain?
What might be done to lower it?

@MrFly
Copy link

MrFly commented Dec 10, 2018

Just an idea: I think it might not be necessary to keep all data of heartrate a.s.o. (?) What about keeping only, let's say, every tenth of it and do excessive data collecting only about half an hour (at least the smart wakeup time) before the wake up alarm?

Some "smart" logic on detecting movements could maybe help too, e.g. only submit it, if it is a xy% higher value than the one before. If an value was detected, which meets this "treshold", there could start a excessive collecting for 30secs or so...

Keyword: respect smart wakeup

@ronnyadsetts
Copy link

Is it possible to run stuff as a callback on the watch's motion detection rather than running on a timer? Garmin do their own sleep detection which I assume uses this type of thing. I guess the question is whether the public API allows for this level of integration.

I reckon about 20% average usage per night on my Fenix 5HR. I'd be happier if it were closer to 10%. It's still a world apart from the Samsung watch usage. :-).

@Artaud
Copy link
Collaborator Author

Artaud commented Dec 10, 2018

@MrFly Sorry not sure what you mean by a.s.o.?
Maybe sending HR could be delayed and just collected on the watch for a longer period.

@ronnyadsetts
There seems to be a callback for the accelerometer from CIQ 2.3.0 (https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Sensor.html).
Updating to that API level would however mean dropping support for Fenix 3 / HR (since it only supports max 1.4 API with no plans to update further) which I think is still pretty commonplace.
I guess we could fork the code to have the callback for newer watches and keep the timer for older watches.
However the app is currently written in a way that more things (like the alarm and UI) are dependent on the timer, so getting rid of it wouldn't be so easy.

@MrFly
Copy link

MrFly commented Dec 10, 2018

@Artaud a.s.o. = and so on :-)

Good idea, if it does not harm (because of the low available memory on the watches)

@ronnyadsetts
Copy link

@ronnyadsetts
There seems to be a callback for the accelerometer from CIQ 2.3.0 (https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Sensor.html).
Updating to that API level would however mean dropping support for Fenix 3 / HR (since it only supports max 1.4 API with no plans to update further) which I think is still pretty commonplace.
I guess we could fork the code to have the callback for newer watches and keep the timer for older watches.
However the app is currently written in a way that more things (like the alarm and UI) are dependent on the timer, so getting rid of it wouldn't be so easy.

I would imagine that v1 of the API needs to be supported by SaA for a good while yet (I am obviously biased here) and using the newer callback API looks like it would pretty much double the work for maintaining the App. That said, it does seem that it may be a direction to explore at some point.

@unseenuk
Copy link

How big drain do you get on your watch model?
23-30% a night on VivoActive 3 Music (1 week old)

How big a drain is acceptable for you?
Having come from an Amazfit Bip 5-10%

What might be the causes of the drain?
I thought it may have been the backlight but have disabled that now. WiFi sync is disabled and the watch face is as basic as I think I can get!

What might be done to lower it?
As has been mentioned by someone further up the thread would it not be possible to hook in to Garmin's own sleep data/api channels? Especially as the nights where I've not enabled SaA the battery usage has only been 1 or 2% over the night with Garmin still providing a sleep chart.

As a long time Beta user of SaA I came here to provide my experience so far since moving from an Amazfit to Garmin VivoActive3 Music (Thanks Jiri for pointing me here to post this). When I first saw how much battery drain occured overnight I nearly sent the watch straight back to Amazon! Comparing this against the drain of an amazfit just seems bonkers! Heck I even contemplated sending it back and paying the extra for a Fenix 5Plus (any excuse right?) but from experimenting and seeing that on it's own the Garmin uses very little power over night I think from my point of view interfacing with Garmin makes more sense?

@Artaud
Copy link
Collaborator Author

Artaud commented Dec 13, 2018

@unseenuk
Reacting to your answer to "What might be done to lower it"

Garmin is not doing the same thing with sleep tracking as we are. They are collecting all the sleep data on the watch and only sync a few times per day. We are syncing almost realtime (usually every two minutes we send a batch of sensor data), so a big part of the battery drain is not actually querying the accelerometer, but bluetooth communication.
This is mainly because we need to react to sleep events throughout the night. You can see that Garmin doesn't offer smart wakeup. It would be impossible to analyze the data directly on the watch, and they don't send it to the phone often enough to have the possibility to analyze them in time for the smart alarm.
So the data in their web APIs are there too late for us to be useful.

(Also, Garmin wants $5000 upfront to get access to their web APIs)

@unseenuk
Copy link

@Artaud
I didn't know how Garmin does the sleep but that makes sense as it's not available until you sync with Garmin connect. I understand that bluetooth may appear to be the main battery drain, but compare the battery usage of an Amazfit against the Garmin it doesn't make sense unless Garmin is very wasteful in their bluetooth functionality. In that comparison you would expect the younger (in technology terms) Amazfit to be wasteful but it's not.

Please note I'm not even a beginner programmer here so this is just a question, is there another way to access the bluetooth? Or maybe streamlining the data that is being sent to cut the usage? I ask as when I used the watch without SaA with all notifications allowed one night (I get text/whatsapp alerts through the night from servers) it used only 2-3% and yes it did wake me a number of times with the notifications.

Last night I ran with SaA and it used 25% battery so the drain seems at least consistent, this was even with all notifications stopped from being sent. For sake of argument I will try tonight without SaA but leave notifications enabled, I expect a 2-3% drop.

@swampy2b
Copy link

How big drain do you get on your watch model?
Vivoactive HR: ~10-15%
Vivoactive 3 Music: ~25-30+%

How big a drain is acceptable for you?
The 10% I get on the VAHR is fine. I still only need to charge it every 4-5 days. Anything more than 15% is pushing the limit of tolerability. If Garmin is claiming 10-days battery life, it's easy to accept sacrificing about one day's worth of charge for an ~8hr activity. I've only had it for a couple of weeks, but on its own, the VA3M only drops about 3% overnight, consistent with about 10% per day. The second time I tried SaS on my new watch was on a weekend, with about 45% battery left, and the watch died in the night; consequently, I don't trust using SaS with the VA3M with less than a full charge.

What might be the causes of the drain?
Could it be the gyroscope? It seems to be common among the devices with excessive power drain (VA3M, fenix) Whereas the VA3 and VAHR don't have it.

What might be done to lower it?
I took a brief look at the API online but didn't see an obvious way to isolate the gyroscope, maybe I missed something? Is there a way to support multiple API levels in the same app?

@fgunger
Copy link

fgunger commented Aug 23, 2019

On my Garmin Forerunner 645 Music battery is entierly drained during longer nights. During shorter ones I loose like 70-90% or so. Acceptable to me would be not more than 50%.

I noticed my display lits up several times when I try to go to sleep. If this happens throughout the night it is definitely one source for all the battery drain. If this some kind of automatic backlight that is not at all usable with my clock since it doesn't need backlight very often.

I also tried with and without the setting HR monitoring in the app but it seems to record my HR regardless. If this uses ANT+ that is also known to utilize pretty much battery for my clock.

@FuzzyMistborn
Copy link

I'm also noticing very large battery drain with my Forerunner 645 (regular). For a while it was only draining ~10-20% which was fine. I could go about 3-4 days without charging. Now I go to bed with the watch >90% and wake up and it's consistently around 30%. Something is up.

@fgunger
Copy link

fgunger commented Sep 17, 2019

...as a follow up to my ForeRunner 645 Music issues:

I found that starting the sleep monitoring though the phone pulls up a menu "Start sleep monitoring: Yes-No" on my watch. If answering "Yes" the behavior explained above applies.

As an alternative I have tried to use the "No" (or back button) on my watch. Next thing I manually start the sleep monitoring trough the activities widget installed. This makes the battery usage 30-50% during a night. This battery usage is even acceptable, even tough optimizations (including fixing the above behavior when using the "Yes" alternative) would always be welcome. =)

@FuzzyMistborn
Copy link

I can confirm the same as @fgunger. Starting from the watch manually does NOT drain the battery whereas clicking "yes" on the watch when starting from the phone causes the drain.

@Artaud
Copy link
Collaborator Author

Artaud commented Sep 23, 2019

Thanks everyone for your reports. I've received a strange report (not sure if it applies to every watch) that the drain is also linked to setting "Smart HR" measurement in your watch settings.
Whereas if you have this set to "continuous HR tracking", then there was no significant battery drain.

@champagnealexandre
Copy link

champagnealexandre commented Oct 28, 2019

Just jumping in to (mostly) confirm what has been said before.

I've done a couple tests on a FR645 Music, which lead to the following battery drains on the watch :

  • with "HR monitoring" enabled in SaA ~ 13%/h drain
  • w/ "HR monitoring" disabled ~ 9%/h drain
  • w/ "HR monitoring" enabled and by starting manually the activity on the watch ~ 4%/h drain

The relative uncertainty on those values is large because my tests were not done on full nights (just came across this post only today) but rather done on 0.5-1.5h intervals while simply wearing the watch (so battery drain could be less if I'm sleeping, I haven't looked at how the code buffers info sent to the phone).

I've stopped there in my tests because IMO 4%/h (i.e. 32% for a whole 8h night) is rather acceptable. Forces me to charge my FR every morning before I workout but it's at most a nuisance, doesn't prevent me from using SaA.

Otherwise, there is no "Smart HR" setting that I can find in the 645's menu.


edit : I might add that this battery drain does not surprise me at all from the 645, having lost some long rides in the past because the battery had died - which is precisly one of the negative points that's noted again and again in this watch's reviews

@adarazs
Copy link

adarazs commented Dec 27, 2019

Hi @Artaud, I'm using the Forerunner 935 for sleep tracking. For a while the battery drain was rather bad, then with the recent upgrades it got really good (when you reduced the sampling rate). However, Garmin released the 15.10 update for the watch a few days ago and the sleep tracking absolutely kills the battery now.

For reference, I lost about 20% per night before you reduced the sampling rate, 10% after, and now it's up to around 40% for an 8 hour sleep tracking.

Not sure what the underlying issue is, but there's this relevant looking ChangeLog entry:

Brought in support for CIQ SDK v3.1.

See the relevant garmin forum topic: https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-935/210297/forerunner-935-sw-15-10-is-live

I asked in the topic and others (probably without the Sleep As Android app on the watch) don't experience big battery drains, and it doesn't happen during the day either (I checked), so it's most probably this app. I even did a full factory reset to eliminate possible upgrade problems. Please look into it, because the watch suddenly went from needing to charge it once a week to once every 2 days. :(

Let me know if I should open a separate issue for this.

@tmladek
Copy link

tmladek commented Dec 28, 2019

Garmin Vivoactive 4S, just woke up to a dead (10%) watch, started tracking at 80% the night before.

Would gladly help with any troubleshooting, Garmin's sleep tracking is atrocious, but Sleep as Android works great.

edit: HR enabled, Pulse Ox disabled, Garmin's sleep (activity) tracking also enabled

@tof9
Copy link

tof9 commented Jan 4, 2020

Hi @Artaud, I'm using the Forerunner 935 for sleep tracking. For a while the battery drain was rather bad, then with the recent upgrades it got really good (when you reduced the sampling rate). However, Garmin released the 15.10 update for the watch a few days ago and the sleep tracking absolutely kills the battery now.

For reference, I lost about 20% per night before you reduced the sampling rate, 10% after, and now it's up to around 40% for an 8 hour sleep tracking.

Not sure what the underlying issue is, but there's this relevant looking ChangeLog entry:

Brought in support for CIQ SDK v3.1.

See the relevant garmin forum topic: https://forums.garmin.com/sports-fitness/running-multisport/f/forerunner-935/210297/forerunner-935-sw-15-10-is-live

I asked in the topic and others (probably without the Sleep As Android app on the watch) don't experience big battery drains, and it doesn't happen during the day either (I checked), so it's most probably this app. I even did a full factory reset to eliminate possible upgrade problems. Please look into it, because the watch suddenly went from needing to charge it once a week to once every 2 days. :(

Let me know if I should open a separate issue for this.

Hi @Artaud, I'd like to confirm everything in @adarazs post. I'm also using the Forerunner 935 and as soon as I updated to 15.10, the battery drains dramatically after each sleep tracking session. I basically need to charge the watch every morning now.

Thanks.

@adarazs
Copy link

adarazs commented Jan 29, 2020

I think I found a workaround for this new battery drain. So I always start tracking from my phone, which then pops up a confirmation on the watch "Launch Sleep?" with a Yes/No option, which I accept by selecting Yes.

However, for two nights I went into the activity list on my watch and launched the "Sleep" app directly aaand... voila, those nights I only lost 5% battery. The third night I tried to launch it the usual way and I was back to 40% drain over the night. Today I tried again to start it from the watch and I lost 5% again, so it seems there's something about the phone side "Garmin add-on" app that bombards the watch with requests and drains the battery.

tl;dr: Try starting the Sleep app directly on the watch.

@tmladek, @tof9 let me know if this method works for you too.

The total lack of reaction from the SaA crew to this big issue for a month makes me weary to rely on the program/Garmin support long term, but at least now I can use my watch normally again. I also submitted a bug report about this through the app 3.5 weeks ago to which I got no answer either. The lack of reactions are definitely discouraging, especially that this is a paid and non-open source app (I mean the Android app.)

@Artaud
Copy link
Collaborator Author

Artaud commented Jan 29, 2020

@adarazs Lots of thanks for finding out about this. I'm sorry I did not get back to this earlier, however just yesterday I was doing a big refactor of the phone-side addon and did some optimizations regarding exactly this - the number of requests that are sent to the watch. I'm now testing it and may release the new version as soon as today if it goes well.

@unseenuk
Copy link

unseenuk commented Jan 29, 2020 via email

@tmladek
Copy link

tmladek commented Jan 30, 2020 via email

@FuzzyMistborn
Copy link

Tested the updated version last night using the pop up instead of manually opening sleep. Battery went from 58% to dead. So update did not fix the issue.

@tof9
Copy link

tof9 commented Jan 31, 2020

tl;dr: Try starting the Sleep app directly on the watch.

@tmladek, @tof9 let me know if this method works for you too.

@adarazs Thanks for the suggested workaround. I tried it for two nights now and can confirm the workaround works.

@Artaud
Copy link
Collaborator Author

Artaud commented Feb 1, 2020

Tested the updated version last night using the pop up instead of manually opening sleep. Battery went from 58% to dead. So update did not fix the issue.

Could you please send a wearable report using Sleep > left menu > send wearable report? Thanks a lot..

@FuzzyMistborn
Copy link

Could you please send a wearable report using Sleep > left menu > send wearable report? Thanks a lot..

Done.

@tmladek
Copy link

tmladek commented Feb 3, 2020 via email

@Artaud
Copy link
Collaborator Author

Artaud commented Feb 3, 2020

As to the workaround, what exactly is supposed to be the difference in launching the tracking from the watch or the phone? Starting the activity on my 4S triggers the opening of the SaA app on my phone - and at least visually looks just the same as opening the app and starting the tracking from there - is this not the case for everyone?

Yes it is the same, except when starting from phone, you get the prompt on the watch asking whether you want to launch Sleep on the watch. Apparently there's an issue with that. I'm going through the log that @FuzzyMistborn sent and hopefully will find the cause.

@Artaud
Copy link
Collaborator Author

Artaud commented Feb 3, 2020

Oh I can't actually find the log from @FuzzyMistborn - could you please write me a line at [email protected] so I know from which email did you send the log?

@FuzzyMistborn
Copy link

Oh I can't actually find the log from @FuzzyMistborn - could you please write me a line at [email protected] so I know from which email did you send the log?

Done.

@jateitel
Copy link

jateitel commented Feb 3, 2020

I have a Vivoactive 4S and I have the battery drain issue even if I start it from the watch.

@Artaud
Copy link
Collaborator Author

Artaud commented Feb 3, 2020

Sorry - seems I had a NPE in there, causing the app to not track properly and being unable to send logs.
The updated version is here: https://drive.google.com/file/d/1CkkkE7WwcBtGWQV-1vGPqttgfnpJ0VI8/view?usp=sharing

We're rolling it out now on Play Store but just as a 10% rollout so you might have to wait if you want it through Play Store.

@tmladek
Copy link

tmladek commented Feb 4, 2020

Sorry - seems I had a NPE in there, causing the app to not track properly and being unable to send logs.

Does this mean the drain should be fixed in this version, or just the logging?

And since I also have a 4S and still get huge battery drain even with the "workaround", just like @jateitel, should I also try to send a report with the new version?

@L0rdVetinari
Copy link

L0rdVetinari commented Feb 29, 2020

I haven't tried the workaround but unfortunately at the moment sleep tracking with my Vivoactive 4s is not usable or at least very uncomfortable because of the battery drain. When almost full it's at 10% after ~8 hours of tracking. Let me know if I can help anyhow to get rid of that bug. I tried tracking with sonar but then my recordings are ruined by the chirp sound. So I would like to use my watch.

Edit: Starting from the watch doesn't drain as much as starting from the smartphone.

I also found out that during tracking the display lights on my watch go on even when DND is on and the watch is locked.

@jukkyrjo
Copy link

jukkyrjo commented Mar 7, 2020

I get a drain of 60 % overnight or about 7 %/hr on Forerunner 245.

1-2 %/hr would be nice.

I've tried

  1. Starting sleep tracking on phone app and accepting the notification on the watch
  2. Starting sleep tracking on phone app and declining the notification on the watch, then starting watch app manually
  3. Starting watch app manually without touching phone app (is this the workaround method some people have working?)

All with the same battery drain.

This morning I also couldn't turn off watch vibration alarm before or after completing phone captcha, and the Bluetooth had turned itself off on the phone. Don't know if that's connected.

@unseenuk
Copy link

unseenuk commented Mar 7, 2020 via email

@jateitel
Copy link

I'm still having trouble on my Vivoactive 4S. Even with the latest versions of everything I got 60% drain last night.

Is there anything I can do to help? Send logs? Test beta code? Donate money? Sleep tracking is one of the primary reasons I got the Garmin and the build-in one is terrible.

Jeff

@unseenuk
Copy link

unseenuk commented Apr 28, 2020 via email

@adarazs
Copy link

adarazs commented May 12, 2020

@Artaud Hi, just a follow up: I used the "starting tracking from the watch" workaround until now, which gives me an acceptable ~15%/night drain on the FR935. Though I think that is similar to the 40%/night that others are reporting other watches, as the FR935 has a huge battery with a 14 days battery life when not using SaA.

Today I tried again triggering tracking from the phone and clicking "Yes" on the watch for starting sleep and I lost 50% battery overnight. So whatever you tried to fix on the Garmin companion + connect IQ app didn't solve the drain issue. I'm running everything on the latest stable version.

@ghost
Copy link

ghost commented Feb 6, 2021

Reacting to your answer to "What might be done to lower it"

Garmin is not doing the same thing with sleep tracking as we are. They are collecting all the sleep data on the watch and only sync a few times per day. We are syncing almost realtime (usually every two minutes we send a batch of sensor data), so a big part of the battery drain is not actually querying the accelerometer, but bluetooth communication.
This is mainly because we need to react to sleep events throughout the night. You can see that Garmin doesn't offer smart wakeup. It would be impossible to analyze the data directly on the watch, and they don't send it to the phone often enough to have the possibility to analyze them in time for the smart alarm.
So the data in their web APIs are there too late for us to be useful.

Hey, I have a Garmin Venu and it's been draining around 40% battery in about eight hours of sleep for several nights now, I've tried both starting it from my phone and from my watch with no apparent differences in battery drain. I also saw that there was a major rewrite of the code around four months ago which I think should be the version I'm using as I downloaded the app from the CIQ store, correct? It says that one of the changes is "batched sensor data", does this refer to not sending data to the phone every two minutes? I'd assume the only thing the phone is needed for is for the smart wake up period, right? Wouldn't it be sufficient to save the sleep data on the watch and only send it close to the smart wakeup period? This is assuming of course that sending the data is causing the battery drain issues.
I love the work you guys have done in the phone app so it would be really awesome if this integrated well with the watch also, let me know if there's anything I can do in terms of testing.
Thanks for the great work so far!

@mattnoir
Copy link

mattnoir commented Mar 8, 2021

I have some new findings from today.
I started sleep tracking from phone and as I got a prompt (which is still kinda rare) on my watch, I did not deny, nor did I confirm start of sleep tracking, only went to the main screen of my watch (using vivoactive 4).
In the morning I found out that it actually tracked my sleep via watch, as I also got heart rate for a fraction of the night, plus I got accelerometer data.
The catch?
It drained only 8% of my battery this time. Usually it's 50-60%, so I see something interesting here.

If anyone else wants to try that as well, I would like to see the battery drain on your watches too

@petrnalevka
Copy link
Collaborator

@mattnoir I think the catch may be the phone fell back to Sonar or accelerometer.. I can tell you whjat happened if you use menu - report a bug and send us the log.. Many thanks..

@mattnoir
Copy link

mattnoir commented Mar 8, 2021

@petrnalevka I just sent the log. I don't think the phone fell back to sonar or accelerometer as I keep my phone on nightstand next to me. Accelerometer has no effect then, and sonar can't catch it either. Heart rate is showing till 4am, activity log is consistent too. I hope you will be able to find something interesting in the logs.

edit: So I checked the logs myself and it seems like garmin was not connected, or at least was not sending data as in previous instance where it was connected the whole night. So it's a little weird thing to see how it seems like sleep received data with heart rate and accelerometer when cellphone was chilling away from reach of its' own accelerometer and sonar as well, as those data and results are really completely different

edit2: Okay, change of thoughts. It may be that it managed to receive data from Google Fit. I am just not sure how it managed to do it so soon. I am checking some past graphs, and there is heart rate showing, along some activity as well, even though I had the same settings (using sleep basically just to turn on notifications until battery drain will be resolved). What I don't understand is still higher battery usage than when it's just garmin sleep tracking, or at least I believe it's like that

@mattnoir
Copy link

mattnoir commented Jun 6, 2021

@petrnalevka I was thinking.
Why exactly is the watch communicating with the phone non-stop and sending the data? Is it not possible to save the sleeping data on the watch and then sending it to the phone later?
For example if you don't have smart alarm (I don't have it enabled), it should be possible to start communication and data sync shortly before the wake up, while alarm time is synced during the first sync of the app with the phone while going to sleep.
Now again, I have no idea how garmin manages 3rd party apps and how much freedom you have, but if this was possible, it should work towards better battery usage, right?

@Artaud
Copy link
Collaborator Author

Artaud commented Jun 6, 2021

@petrnalevka I was thinking.
Why exactly is the watch communicating with the phone non-stop and sending the data? Is it not possible to save the sleeping data on the watch and then sending it to the phone later?
For example if you don't have smart alarm (I don't have it enabled), it should be possible to start communication and data sync shortly before the wake up, while alarm time is synced during the first sync of the app with the phone while going to sleep.
Now again, I have no idea how garmin manages 3rd party apps and how much freedom you have, but if this was possible, it should work towards better battery usage, right?

There's not enough runtime memory for a watch app to be able to store that much data before sending. We are actually saving some data and sending it in batches - the data are being gathered from the sensor every 100ms, but sent to the phone every 2 minutes. It's just a lot of data needed for precise movement tracking.
I guess we could squeeze out some more memory using disk storage (https://developer.garmin.com/connect-iq/api-docs/Toybox/Application/Storage.html) but I cannot predict the battery hit with that and also we would really need to think this through as the API is designed with the expectation that data would be fed every two minutes max.

@l1bbcsg
Copy link

l1bbcsg commented May 18, 2022

Could the data be compressed perhaps? Looks like its being stored and send raw.

In simplest approach, suppose we have readings of heart rate as follows: 62, 62, 62, 62, 62, 63, 65, 65, 65, 65 we could compress that to 62 x 5, 63, 65 x 4 and perhaps drop 63 to sacrifice accuracy: 62 x 6, 65 x 5.
This would reduce memory space needed to store the data and therefore allow for longer intervals between syncs.

If the data is reduced to sliding moving average window, this could reduce its size dramatically.

This sacrifices accuracy of course, but this is something that has to be done to certain degree inevitably it seems.

I'm sure there are other algorithms out there that will produce tremendous results (maybe even without accuracy tradeoff) considering the data corpus is very narrow being a small set of integers (and a range of floats in case of accelerometer).

Some other data hacks can be done. For instance, most HR readings are probably 50s, we could store those in one byte rather than uint if we substract 50 from them and either add it back before sending or do that on the Android side.
If accelerometer data is store as float, it can perhaps be represented as and integer or two.
If there are unix timestamps, the zero point for them could be redefined to be time the tracking started rather than 1970.

The messages are also sent as strings, this must introduce huge overhead and switching to raw data buffers should reduce the time it takes to send them and therefore sync session drain.

F245M, roughly 90% per sleep, I'm risking not having an alarm.

@Moohan
Copy link

Moohan commented Aug 1, 2022

How big a drain do you get on your watch model?
20% over one night ~7.5hr on a Garmin Fenix 6X Pro

How big a drain is acceptable for you?
20% is workable, but 5% or lower would be ideal. It's the difference between charging my watch at most weekly and having to do it every few days.

What might be the causes of the drain?
From reading the thread it seems like it's the large data collection and then transfers of data, which happens continually overnight. I have been starting the tracking from my phone, but some people have had success starting it from their watch instead. I wasn't quite clear if this should have been fixed.

An annoyance I had, which I thought might also contribute in a small way to the battery was the backlight coming on very brightly whenever I moved. e.g. #9 My watch's default setting was 'in activity' to turn the backlight on for 14secs at 50% brightness whilst in activity after sunset, I've now just turned this off so it's button press only.

What might be done to lower it?
Ideas mentioned, that seem reasonable to me:

  • Only send data real-time if needed for smart-alarm / anti-snoring etc. Otherwise, why not send in bulk in the morning? Data might need writing to disk to achieve this.
  • As above but for smart-alarm, only start real-time data x hours before the earliest smart-alarm time. (@huju22)
  • Data compression suggestions (@l1bbcsg) seem smart.

@hanni2301
Copy link

How big a drain do you get on your watch model?
15 % at a 6 hour rest
Venu 2 Plus
How big a drain is acceptable for you?
seems to be ok, but less would be nice, oc.
What might be the causes of the drain?
no additional observations to others in this topic
What might be done to lower it?
I use smart wake up and sleep tracking since i went to sleep. I can accept that it has to use frequent Bluetooth connection for smart wake up, but could live with less detailed graphs for the hours before. If disk space is not accessible I have no further ideas, sorry.

@TheNetStriker
Copy link

I also had about 20 to 30 percent battery drain on my Fenix 7 which is too much. I bought this watch because of the long battery life.

Yesterday i did take a look at the code and made some changes for myself. I reverted the code back to before the HTTP communication layer was added: 9859c16

I also commented out all the DebugManager.log lines, but I don't know if this made a big difference, but the app is a bit smaller and will use less memory this way.

I tested this version of the app last night and had only about 10% battery drain. I guess the HTTP requests generate much more overhead than the Bluetooth packages. I also had no connection issues during the night.

Maybe this HTTP feature should be optional via an app setting for watches that have a problem transmitting the Bluetooth packages.

@Aashishkebab
Copy link

This issue is still present. I bought a Fēnix 7s because I wanted a month of battery life, and did sleep tracking last night for the first time. Lost 40% battery overnight.

@EyalGol
Copy link

EyalGol commented Jun 24, 2024

I also had about 20 to 30 percent battery drain on my Fenix 7 which is too much. I bought this watch because of the long battery life.

Yesterday i did take a look at the code and made some changes for myself. I reverted the code back to before the HTTP communication layer was added: 9859c16

I also commented out all the DebugManager.log lines, but I don't know if this made a big difference, but the app is a bit smaller and will use less memory this way.

I tested this version of the app last night and had only about 10% battery drain. I guess the HTTP requests generate much more overhead than the Bluetooth packages. I also had no connection issues during the night.

Maybe this HTTP feature should be optional via an app setting for watches that have a problem transmitting the Bluetooth packages.

Isn't the http layer what made consistent communication possible? I remember it was added to stop missed alarms and inconsistent tracking.
I'm interested in your solution and would love the devs to comment on it, plus it would be nice if you could add the commit to your fork or the repo 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests