First long run test: maps vs battery, other tidbits

jakubdr

Hello,

So I just had my “practice race” before my main races: 45 k trail race, so I wanted to test Suunto Vertical, especially the battery when maps is nonstop on display (as it is asked quite a lot).

Conditions: mostly sunny, but has been running in forests and shade, never pointed watch towards the sun, the widget shows that 50k lux was never reached (5-10k at most). Brightness set to low, backlight to wrist movement only. Otherwise everything at the best performance settings.

Maps always on since the start to the end. Loooked at it quite peridocally and often.

The result: after 6 hours of running, Suunto lost 9 % of battery. LIKE - HOLY SH*T. Also considering the smoothness of the map (way better than Garmin), this beats my old Fenix 7 to the dust!! Amazing job Suunto!!

Also like the outdoor map graphics, much easier to read than Garmins version.

Other tidbits and notes/bugs:

the ETA field is calculated based on current pace, which was odd at first but then I realized it gives better indication than Garmins floating average: i.e. It tells me “if I continue this pace I will be at the finish at this time”.
elevation chart bug - sometimes the elevation chart displayed many blank spots, sometimes was OK.

… old Fenix 7 …

Garmin can’t come out with 7 Pro soon enough!

trailcafe

@jakubdr Regarding ETA: I would prefer having ETA based on rolling pace or something “even more fancy” because I do lots of uphills and downhills. Having ETA/ETE based on my current pace doesn’t help me a lot

Stefan Kersting

Had a backcountry skiing tour today ans started with 96%. It was noe direct sun, just overcast and gray. After 4,5 hours of skiing and with the solar power the clock was at 90 %. Not bad I think.

Dimitrios Kanellopoulos

@trailcafe I would argue on this. A rolling pace looses the entropy of being able to speed up and test against how soon can you arrive on finish if you speed up or go slower

Aka " guys we the pace we are going we are not going to make it in time"

If you want to see how it would be with the avg pace just go on avg pace for a few mins.

DMytro

@Dimitrios-Kanellopoulos then I believe two different metrics could be offered to choose from. I’d rather have a rolling pace bc terrain can be different, ups and downs, etc. Also I don’t see the problem introducing weights for the algorithm s.t. the past matters less than the present and so if it’s the matter of catching the last train, you’d still get a decent estimate. Tbh I think ideally the watch should start with some dummy algo e.g. assume vertical speed of 600hm/hour for ascent 800hm/hour for decent and 5km/h horizontal and then upon data acquisition estimate speed for different slope and extrapolate for any slope and give time estimate for the chosen route from there.

Egika

@DMytro this ETE is what I came up with for a ski tour S+ app.
Calculate the time en route based on remaining asc (300m/h) + remaining distance (5km/h).

Here’s how it looks atm

DMytro

@Egika Nice! But can watch ‘learn’ your average ascend/descent/horizontal speed during the activity? I think this would be much more useful, while initial values can be indeed the ones you set.

isazi

@DMytro the watch could learnt, yes, but maybe that’s too complex. Another option would be to set your speed in the app yourself.

DMytro

@isazi well, if that would be possible, then maybe the app could ‘learn’ doing post-workout analysis, depending on the weather, activity type, slope, length, etc. Would be really could if something semi-reliable would come out of that.

Egika

@DMytro too much unknown in this, I think.
Like if you are alone or with a group, training or racing, difficulty of terrain, there is no limit of factors…
User input into apps is something that will most likely be the next step for apps. As Isazi said, I think it would be useful here.

DMytro

@Egika fair enough