@André-Faria said: @sky-runner at least on the race s is there,down button and it will lock the screen If you mean button shortcuts, I already use them for other functions - one for the flashlight and another for the “Find my phone” function that I use often. Locking the screen via the control panel requires a lot of steps. As I said, not activating the touch until one of the buttons is pressed would be a perfectly usable solution. Another solution would be a touch unlock by swiping the screen similar to what Garmin has. When under rain or shower, a natural droplet movement direction across the screen is either right to left (this is how the watch enters control panel) or left to right, or bottom to top. Garmin requires top to bottom swipe to unlock the touch which doesn’t occur naturally when droplets hit the screen.

I like the wind direction arrow the best. I’ll have to use it during a real exercise to see how well it works. But I see it’s potential for cycling (to avoid head on wind) and sailing. Of course, the issue is always where from the weather data comes. Unfortunately, usually, it is not overly granular.

I had 4 restarts out of the blue. Activities with SuuntoPlus, Activities without, even once in the middle of the night. And I had massive problems using a wall plug in my last holidays, as I have written before. But all of this is stretched over almost 2 years. So, yeah, I’m still using the watch. But my life does not depend on it…

@pavel.samokha done, shared in Teams

@snow 5, just as a watch, it hasn’t been working for 7 days; generally, 5-6 days max. This all started after the firmware upgrade. Otherwise, it used to give 10+ days on a charge as a watch, and with 10+ hours of GPS-only (no heart rate), it used to give me 7 days of battery easily. (Don’t have Bluetooth on for any notifications) I have noticed that 2 to 3 hours of GPS use drains 6-8% of the battery. I have already lost hope with Suunto on this matter.

@snow Thanks, but that still requires you to sign up for API access, and based on Suunto’s own disclaimer, you can’t do this unless you’re a company.

@Peter-Pan-0 It should all still be on the watch. You can check by going to the Logbook. If it has all the stats just like the activity summary screen, especially the graphs (HR, zone chart, elevation profile), then all the data should still be on the watch. If it only shows a small summary of distance and time, then the full dataset is not on the watch. Activities are deleted from oldest to newest to free up room when necessary. I’ve had to recover activities stored on the watch before and it isn’t totally straight forward. I think the process goes something like this: Delete the activity from SA Unpair watch from SA and remove SA connection from watch (Settings > Connectivity > Paired devices > MobileApp) Remove watch from phone’s BT connection Sign out of SA (this removes an activity data saved to the device) Close SA (you can go one step further and delete/redownload SA, but I don’t know if that’s necessary) Open and sign back in to SA Re-pair watch When the watch is re-paired, SA will look for any stored activities on the watch that are not already attached to your account. Honestly, all you might need to do is delete the activity and then sign out and back in to SA. The above just covers all the bases. I’ll stress that this has worked for me in the past, but, obviously, make sure you save a backup of the activity before you delete it! Either directly from the Suunto App or from another connected service. If, for some reason, the above doesn’t work, there are ways to get the .FIT file back on to your Suunto account, although that’s not straight forward either.

I agree with the points above, the app is absolutely useless at this point. There should be a dedicated app for Suunto diving products.

I had the same issue today: dive logged as 0 minutes, 0 meters depth. On top of that, I got an algorithm deviation warning. My theory is that the logged dive didn’t match what the algorithm had actually calculated internally, which triggered the deviation warning (but this is what i speculate). It seems impossible that my dive itself caused a deviation, because it was no deeper than 5 meters, with an average depth of 2.5 meters, for 1 hour. No rapid ascents or anything unusual. I’ve had this computer for 3 months now, 42 dives so far. This is the first time I’ve encountered this issue. Not exactly reassuring when it comes to trusting this computer underwater. Is Suunto aware of these issues? [image: 1786728393340-img_5912.jpeg]

@Ldive It’s a matter of respect for those who bought a Nautic and placed their trust in Suunto. Unfortunately, I shouldn’t have

@Speed-Man said: @brave_dave Are you sure? Try running in 35°C heat and see for yourself. And I’ll add try running 2 or 3d after a hard race and see for yourself. AT and LT will be wildly different than the values prior to the race if you are well trained and tapered. ZS is real time for effort, I do not use ZS to set my zones as they vary a lot. This has been discussed many, many, many times here.

@hhouter I also lean towards Ocean/Nautic firmware optimizations (pod/watch position is also important). Received back POD from service, still having hard time connecting before dive (previous firmware version worked way better: turn on gas, watch connects and you don’t have to worry again). Now I constantly need to bring back watch close to POD before dive or connection is lost. Underwater looks like transmission is OK, mainly drop outs occur out of water. ps. My suspicion is with this new feature in newest firmware, probably it brought some additional complexity and stability issues: “Possibility to link two tank pods to same gas If two tank pods are linked to same gas, the tank pressure field will show two tank pressures during dive”

During last 6 months my S9PP stopped HR moritoring / sleep tracking, so this is somehow related to last sw update as noticed already. Earlier this happened only once a month and always in the middle of the month, 17th-19th of the month. Now in August this was getting worst, 2 times in the beginning of the month and now again on last night (14.8)

Follow-up: I ran the test, and I can answer my own question 5. The eviction path does not release the app’s JS context, and the shared heap is exhausted inside a single four-minute exercise. Method: fresh reboot, one exercise, three apps enabled, triggering the eviction repeatedly by switching screens and opening/closing the map. After each eviction I re-enabled my app from the SuuntoPlus menu without ending the exercise. Four evictions in four minutes # time how long my app survived after being enabled 1 14:48:40 118 s 2 14:49:07 14 s 3 14:49:57 33 s 4 14:50:27 15 s 118 s the first time, 21 s on average afterwards — an 87% collapse. The heap is at 99.5% Two lines from the firmware itself, 16 seconds before the first eviction: 14:48:24 : WRN UI_FRAMEWORK : JsTotMem 129980/133120 (97.6%) 14:48:29 : WRN UI_FRAMEWORK : JsTotMem 132412/133120 (99.5%) This is the only figure the system has ever given me about its own limits, and it is not documented anywhere. An earlier report on this forum (topic 15490) describes the watch freezing at essentially this same level. Nothing is ever released None of the four evictions is followed by JS discard. The first and only one in the whole session appears at 14:50:35, when I stop the exercise. So every Disable → Load script → Enable cycle instantiates the module scope again while the previous one is still held. That also reframes the “three apps” case. It is not that a third app is too big — my own footprint is 12.4 KB, resident main.js plus the single mounted template. It is that three apps cycling through evictions exhaust a shared pool that nothing empties until the exercise ends. One caveat on reading this The intervals between evictions look almost constant (27, 50, 30 s). That number measures how fast I re-enabled the app by hand, not the watch. Survival time is the honest metric. And the last three survival times being similar does not mean it stabilised — it means the pool was already full before I started measuring. At 99.5%, any re-enable trips the release callback almost immediately. So, concretely Is Zapp X:Disable without a following JS discard expected to leak the module scope? If yes, a firmware eviction is not a recoverable event — it permanently consumes shared heap, and the watch degrades within a single session. Is there a supported way to make an app release its context on eviction, or to be re-enabled cleanly within the same exercise? What is the intended budget per app against the 133 120 B shared heap when three apps are enabled, which is the configuration FW 2.50.26 added? I have the full logs and the built blob available if that helps, and I am happy to run any test you would like measured.