• State Verified Answer
  • Replies 12 replies
  • Subscribers 23 subscribers
  • Views 497 views
  • Users 0 members are here
Options
Related

System.getSystemStats().battery -> XX.0000 instead of XX.XXXX on newer generation watches (enduro3, fenix8, fr965)

b8fly
10 days ago

Can anyone give me a hint why this code does not work as intended on newer devices?

var myStats = System.getSystemStats();
var battraw = myStats.battery.toFloat();
var batt = 0.0; // battery percent
batt = Lang.format( "$1$%", [ battraw.format( "%2.4f" ) ] );
System.println("Batt: " + batt);

Output Fenix 8 simulator: 
Batt: 43.4567%

Output Fenix 8 real device: 
Batt: 43.0000%

Output Fenix 7 simulator: 
Batt: 43.4567%

Output Fenix 7 real device: 
Batt: 43.4567%

Only 1 per cent accuracy on the Fenix 8 - full accuracy on the Fenix 7 - Why?

  • +1 9 days ago

    The sim can be a bit "generic" in stuff like this and doesn't always look the same on a real device. 

    And how/what is shown on a real device varies by device.  I forget which devices, but I recall one where the level would only change every 10%.

    Maybe just show 1 digit after the decimal so it doesn't look so odd on a device where you only get an integer value.  Or just always show the integer value.

    you could try something like comparing the int value to the float value, and if they are the same, just show the int value.

  • 0 9 days ago

    BTW why do you need the fractions? I don't think it's that precise anyway. As a user I never felt I need more than whole percent precision.

    I'm asking this because I am adding now to one of my apps the recording of the battery percentage and I wonder if there's some reasonable use case to add decimal(s)

  • 0 9 days ago in reply to flocsy🤠

    It won't be that accurate, and even if it was, using 5 additional characters (decimal point and 4 digits) is kind of a waste of screen space IMHO.  For this I always just use the integer value in all my apps, or I use a bar or arc from 0 to 100.  And often change colors, for things like the level being <20% or if the device is currently being charged.

  • 0 9 days ago

    Thank you for your answers.

    So it is indeed relatively random whether a Garmin watch can display (with CIQ) the battery status with an accuracy of 1% or even in 10% increments or with decimal point accuracy? That seems to be the strange reality in the world of Garmin watches.... and I'm not hallucinating ;)

    An accurate display of the battery status is essential for meaningful documentation and troubleshooting of battery consumption. (With a Fenix 7X, plus minus 1% battery capacity means plus minus several hours of runtime). Apparently, Garmin watches occasionally have a problem with excessive battery consumption - a clean measurement option would be welcome (but is apparently not available for all devices)

    In my experience, the measurement (I assume the battery voltage is measured and converted into remaining capacity) is very accurate - the measurement points lie very nicely on a straight line.

    Of course, I don't need this accuracy on a watchface :) Such a highly accurate battery status is usefully displayed in a widget and recorded either manually or in the widget (battery widget)

    If anyone knows of a way around this problem, I'd be glad to hear about it.

  • 0 9 days ago in reply to FlowState

    A ten year old post when devices like the fr23x wouldn't ever be 100% with CIQ.  A known issue at the time that confused users.

    And there has been a charging flag since CIQ 3,0,0

  • 0 9 days ago

    I can't wait until you test battery in days and see how outlandishly wrong it is :-), and then there is the rounding that Garmin use, which I personally think is wrong e.g. if it's 79.6 (or 79.9) then you do NOT have 80 battery left - I won't mention rounding for days (4.43 rounded to 5 !!!!)

  • 0 8 days ago in reply to Tim

    Can you please explain in more detail what you mean?

    'Battery in days' is not a measurement, but an estimate or prediction that depends on an estimated average consumption - this can only be as accurate or incorrect as the assumed consumption rate.

    The battery status in per cent, on the other hand, is a measurement and it is very consistent and shows a nice linear decrease.

  • 0 7 days ago in reply to b8fly

    Garmin round their shown percentage to the user, so 79.6% is shown to the user as 80%. I think if something is descending then it should not be rounded up - but we know Garmin do this so we add it to our code and we move on.

    On battery in days, yes it is a calculation, and one that Garmin does not do well.

    A few months back I tested this by building a watch face that still had what I needed (time and data) and had battery in days to 6 decimal places.

    The results below (with some gaps - I occasionally have a life:-) )

    So Garmin data at the beginning shows me the user as battery = 10 days, when the actual figure is 9.384027 - that is a big rounding up.

    Now I know that day 0 it has not learnt the consumption. So lets look at day 7 - it has used 37% in 7 days, so a little over 5% a day, so lets put ourselves in Garmin shoes and be conservative and say 6% a day which would be 16.6 days, less the 7 days that have been used would equal 9+ days left yet it shows 6 (5.896528).

    Now for me the critical point for the user is how many days do I have left when it starts to get low.

    So lets go to 14 days = 23% = 5.5% a day. So to give the user a more accurate figure at this point would be 4.18 days remaining but Garmin shows 2. That is out by 100%.

    So my point is batteryInDays is not worth having, and I have even thought about removing the option from my watch faces so the users don't think it's my watch face that is rubbish.

    day	percent	decimaldays	garmindays
0	100	9.384027	10
1	95	8.871528	9
2	90	8.458333	9
3	85	7.933333	8
4	
5	75	7.029861	7
6	69	6.463889	7
7	63	5.896528	6
8
9	52	4.836528	5
10	47	4.427778	5
11	42	3.951389	4
12	36	3.413889	4
13	29	2.xxxxxx	3
14	23	2.150694	2
15	17	1.591667	2
16	13	1.228471	1