MicroLED would be the best alternative in the long term, but not now when MicroLED displays are still very expensive and prioritized for their extreme brightness rather than economy. MicoroLED displays have a very broad range of brightness and don’t suffer from burn-in, so they could be used in always on mode without a risk of damage while being more energy efficient than AMOLED. But the technology isn’t fully there yet.

@dreamer_ Thanks a lot for the very detailed feedback, really appreciate the time you took to explain and test this scenario. If possible, could you please share a full screenshot of the route you are using (showing the complete roundtrip)? I’ll try to reproduce it on my side. That said, unfortunately I have Madrid Marathon and a Trail Camp with El Corte Inglés next week, so it might take me a bit longer than usual to properly test this. In any case, I will definitely pass this to the dev team if I’m able to reproduce the behavior you’re describing. Regarding your findings, this could indeed be related to the auto-reverse logic. It’s great that the watch is able to adapt to the direction of navigation, but we introduced a safety threshold of around ~200m before switching direction. This is intentional, as switching too quickly could be problematic in some scenarios and we need to ensure the user has actually turned back and not just made a small deviation. Because of this threshold, if there is a turn event within that ~200m window after changing direction, it’s possible that the watch could still be “anchored” to the previous direction and therefore confuse turn events, like in your example. That said, I believe these are quite specific edge cases, and in most normal navigation scenarios this should not be noticeable. Also, currently turns are handled with two different behaviors: Autozoom → the map zooms in advance when approaching a turn Turn notification → triggered around ~20m before the turn And I agree with you here: depending on speed, 20m can sometimes be too short. We are currently working on unifying both behaviors, so turn notifications will be driven by a more dynamic threshold (similar to autozoom or off-route logic), which should provide more consistent and earlier alerts regardless of speed. Again, thanks a lot for the feedback ️‍ BTW, I also personally really like the idea of having a microphone and speaker. However, this is handled by our product team, and currently it introduces trade-offs with the barometer performance, which is critical for us. Hopefully we can find a good balance in future generations without compromising barometric accuracy.

@isaac.net sorry, you are on the wrong track. While probably everything might theoretically be solvable by software, I doubt that Suunto is going to invest a lot into this one. But who knows…

@Nikolai-Simonov said in Live location S+ app: It’s not a bug but feature! you don’t need to re-connect it each time, just take a 5-15 sec to connect. Thanks for all the explanations. The Bluetooth connection to the watch is a bit unclear to me, but I understand the general principle. And I confirm your explanation: even if the app says “waiting for S+ application…”, it will turn green as soon as the activity starts. However, I tried the live tracking again this evening during a run, but unfortunately, it didn’t work very well - version 1.0.16-ext (102) First, I had trouble activating tracking: the watch said it was connected (I had the GPS coordinates on the dedicated screen) and the app indicated a connection with the watch. But I still wasn’t located on the app’s map, either at the start or after a short movement. I had to stop the activity, disconnect and reconnect the app and the watch, and start a new activity to finally be located on the map and see my movement. Several kilometers later, I checked and the watch was disconnected (“DISCONECTED state:99”). I’m not entirely sure, but I think the app still indicated a connection with the watch. I tried disabling the Suunto app on the watch and then re-enabling it, disconnecting from the app and re-enabling it, several times, in various orders, but still without success. I finally gave up on LiveTracking. Last weekend, I also had some issues with version 1.0.13-ext (77) where I experienced a disconnection for a few kilometers, but the connection was restored afterward and the tracking resumed (with a long straight line corresponding to the disconnection). As I work in software development myself, I imagine it can be very difficult to diagnose with just this text information, sorry

@sky-runner I agree, the average gradient is nice for the current climb, but it would be even better to also have sectioned gradients to know whats coming because the small graphed line is hard to tell when gradients change

I can’t tell which is more accurate between Running Dynamic and Suunto Spark on the watch, so I’m not confident enough to speak about it.

@OutdoorMan said in Minimal watchface (feedback): @dreamer_ I personally just need to have a date in time only mode, because I never remember what date it is. And that’s it Totally agree. Battery icon also means you’,ll never forget charging your device but that is my feeling. I consider the rest of the things totally useless

@suzzlo said in Downloading map takes a very long time: @muurain said in Downloading map takes a very long time: Suunto’s cloud service that throttles the downloads but… you can download maps for the mobile phone that are much faster… so… if we think, same server is delivering them… this should not be the problem… Anyway, I can live with it You’re right! I didn’t even realize that, even though I did download mobile maps too And yeah this does seem like an understandable constraint of small smart devices. I too am happy to have the convenience of WiFi downloads, even if they are pretty slow compared to bigger devices. My old Garmin Fenix maps downloaded way faster, but it was via USB cable and a PC. But given the analysis here, the original post does now sound like a WiFi issue or a bug. Maybe try downloading maps on some other place or WiFi…? If the download speed is considerably less than 1GB / hour (or ~2Mbps), it should work faster and there are not many broadbands this slow.

@MdzOtt yes, SA is the one not doing it ;). In my case with Karoo Gen 3 I see same avg power with zeros included (gold standard) like you get see with garmin/Strava

@gkaempfer Same here

@Egika Yes, different colours make no difference unfortunately

@thibault-b. Good job !!! I test the last version today. It seems perfect all information I need size … thanks !

In my case, with the Vertical 1 Titanium Solar, I’m confident the issues started with version 2.43.12 released in June 2025. I had been monitoring battery consumption, which increased from about 3% per day during normal use to around 7%. It’s not a dramatic spike, but it reduces battery life from roughly 21–22 days down to no more than 14–15 days. Wouldn’t it be enough to check what changed between version 2.40.44 and 2.43.12?

@Highlands These are great! Thanks

@maszop Thanks. And weirdly it has now synced correctly some 20+ hours after finishing the activity. That’s what usually happens an hour or two after I’ve grumbled about it on here. I’m inclined to suspect some sort of Bluetooth issue but whether it’s the phone or the watch I can’t say. It’s annoying.

Very Nice!!!

Hi. I also think the Vertical is still a good sports watch. I hope that in the next v1 update they’ll be able to include the altitude in the elevation contours in the maps at zoom resolutions that the MIP screen can display. Having them is useful in some conditions.

@Egika this was exactly the bug I referred to in my post. Anyway my point is that there is a difference between fixing watch breaking busy and niggles, so it would be good to know what to expect…