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…

@v.sacre interesting idea. However: There’s safe already. Too much in case of S+ is no good You can unload S+ and load different one during the workout so there’s no need to have a one-app-fits-all

@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.

@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”

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.

@pavel.samokha said: @André-Faria Hey, you’re doing a nice effort, but it’s unlikely me or anyone else from current Suunto employees would help with that. I understand that it’s fun for you, but for wider audience of Suunto users I have more important issues to solve than providing you materials. It’s also questionable if I can provide them at all without legal checks. For sure, and I totally understand that. If I didn’t ask I would never know. And thanks for taking the time to answer me, it is already nice from you!

@metrodraft Some random thoughts on your comments. First, “steps” isn’t a great metric to track, and Run being lower than 165 doesn’t mean Run is “wrong,” as 165 could easily have been overcounting. If you want accurate steps you need either a footpod or a pedometer like on your belt, not a device on one of your arms. Personally, I ignore steps altogether; if you wish to track it then accept no one device is likely to be fully accurate and instead you’re looking for trends within the device itself. So you need to “start over” with the Run compared to 165 it seems. I have no idea why people wear devices in the shower. I always take off devices so I can wash the skin which is in contact with the device all day. So locking a screen for shower makes no sense to me as well. Interesting comment about the metrics of the 165. Curiously, are you tracking CTL-ATL-TSB with the Suunto? Some people find this system a bit difficult to get into, but it’s far better than tracking steps, and I hope this gives you actionable metrics where perhaps the 165 didn’t.

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]

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)

let’s wait for the end of the hiking season and maybe the diving computers will move forward

Hi Same for me … I dive in salt water but I rinse the Nautic in fresh water after each dive

I cannot fix the root cause in the watch, but export to FIT files (and Strava) should gracefully handle the corrupted records. At least to the level when no intervals have abnormal duration. To fix broken workouts in Strava you need to delete it, export FIT file from Suunto App for the workout and upload it to Strava

Also seems that the Paragliding activity (I use it for Hike n fly) does not use the advanced running zones. There seems to be little response here on the forum, does anybody know where to report bugs?