Datafield Idea: Better ETA

I am frustrated with the standard ETA field from my Garmin Fenix. It takes the average speed from the whole activity as basis and therefore is not suitable at all for activities with changing speed, e.g first biking relatively flat and then start climbing. 

It would already be a great advantage if the field used e.g. a 5 minutes rolling average instead of the average of the whole activity. 

I found some alternative ETA data fields in IQ store, but only for Edge devices. 

  • Looks like this field does what you want: ETA - Estimated time of arrival. Only thing is:

    - it displays the estimated finish time (i.e. more like the "Set a Target" feature, which shows predicted finish time for a race.)

    - it uses a fixed distance

    Contrast with the Garmin ETA field, which shows estimated time of day at arrival at the finish of the course.

    If it's not available for your device, or doesn't meet your needs, you might be able to use my data field Appbuilder 5, which is like Excel for your watch.

    Use the following settings:

    Label: ETA (or whatever you want)

    Format: Time

    Formula: timer + (42195 - distance_raw) / ((distance_raw - prevt(distance_raw, 300)) / ((timer - prevt(timer, 300))))

    In the formula, 300 is the size of the rolling average speed window in seconds, and 42195 is the activity goal distance in metres.

    The result will be the estimated total activity time when you reach the goal distance. (I'm aware this isn't the garmin definition of ETA haha).

    If you would prefer to use the distance to the end of the course, as opposed to a fixed activity distance, replace (42195 - distance_raw) with distanceToDestination_raw.

    If you want:

    - the estimated remaining time (Garmin ETE), remove timer + from the beginning of the formula:
    (42195 - distance_raw) / ((distance_raw - prevt(distance_raw, 300)) / ((timer - prevt(timer, 300))))

    - the estimated time of day at the finish (Garmin ETA):

    24h clock:

    (timeofday + (42195 - distance_raw) / ((distance_raw - prevt(distance_raw, 300)) / ((timer - prevt(timer, 300))))) mod 86400

    12h clock:

    setv(0, (timeofday + (42195 - distance_raw) / ((distance_raw - prevt(distance_raw, 300)) / ((timer - prevt(timer, 300))))) mod 86400); ifs (getv(0) lt 3600, getv(0) + 43200, getv(0) gte 46800, getv(0) - 43200, 1, getv(0))

  • Thanks a lot for your super detailed answer! I will test your AppBuilder as soon as I get my replacement watch. 

    The linked ciq datafield I already found on the store, but it is not what I was looking for as it only works with a fixed distance, not with the course destination. 

  • No problem!

    The formulas above only take 10 samples for the rolling period (regardless of the window size), in order to save memory. That means your estimate would only update once per 30 seconds, for a 300 second window.

    If you are using a newer watch (Fenix 7) or any of the pro/plus variants of Fenix 5/6, you can make the estimate a bit more precise by replacing

    ((distance_raw - prevt(distance_raw, 300)) / ((timer - prevt(timer, 300))))

    with

    ((distance_raw - prevt(distance_raw, 300, 300)) / 300)

    The latter snippet will take one sample per second for the rolling period (which is max frequency for updating/calculating data in a CIQ data field), so your estimate will be updated constantly.

    Sorry, wish it were simpler. There's a few compromises I had to make so this app could run on older watches and even some of the newer ones with less memory (like Vivoactive 4). (There's a lot of overhead associated with allowing the user to enter any formula they want, as opposed to hardcoding functionality in the app itself)

  • I am getting a Fenix 7x as replacement for my 6x, so the per second sampling should be no issue. I think what I am aiming for is this then (Garmin ETA in 24h Format):

    (timeofday + distanceToDestination_raw / ((distance_raw - prevt(distance_raw, 300, 300)) / 300)) mod 86400 

    I was missing one ) after copy pasting this together from your suggestions. I added it after the last 300 because it seemed to be missing there. Does that make sense?

    And if I would like to display both, the ETA at destination and at the next course point in one field, could I do so by adding to the above something like:

    +' / '+(timeofday + distanceToNextPoint_raw / ((distance_raw - prevt(distance_raw, 300, 300)) / 300)) mod 86400

    Is the font size adjusted to fit all data field sizes or will it be cut off if the 2 values will not fit?

    And if I would like to play with the rolling averate sample size, I would need to change all the occurances of 300 to another value in seconds, right?

  • Yes, you have the correct amount of parentheses. I think the suggestions are correct, it just might be tricky to do the replacement as the original has 5 ")" after the 300, and the suggestion asks you to replace 4 ")" with 1, leaving you with a total of 2. You can confirm this with a search and replace of the exact before and after strings in a text editor.

    But like I said, this stuff is a bit too complicated :/. I should've just typed out all the formulas in full, but there's a lot of combinations.

    I should probably add a time of day display format so things like "mod 86400" and the 12h clock adjustments don't have to be part of the formula.

    Is the font size adjusted to fit all data field sizes or will it be cut off if the 2 values will not fit?

    The font size will be adjusted. Any time you convert the field value to text (by using '...' in the formula), a smaller font will be used.

    And if I would like to play with the rolling averate sample size, I would need to change all the occurances of 300 to another value in seconds, right?

    Yes

  • Thanks again! Ah, yes, I did not pay enough attention and mistook 5 by 4 ")". 

    Last question before I try it out in the wild: is it possible to add a newline inbetween the two values so that they are stacked above each other instead of one after each other?

  • No, newlines don’t work. It’s a “simple” CIQ data field, which means that rendering is handled by Garmin’s code, not the app code, which saves a lot of memory. Garmin’s rendering code won’t handle newlines as expected.

    There’s actually 3 additional clones of Appbuilder 5 in the store (for a total of 4), so you could add a 2nd instance of Appbuilder to your activity. There is a limit of 2 CIQ data fields per activity, though. And of course it would take up a 2nd data field on your screen.

  • Okay thanks. I will experiment a little on how much I can fit into one field. Because of the 2 field per profile limitation I would like to avoid adding 2 AppBuilder fields