@GiPFELKiND said: @johann.fuehrer thank you! I will try this ️ I always clean my Suunto watches like every week with normal soap, old hand brush. Daily just with water only after training. Looks like new

@isazi LOL! Damn you Jay!

@Zesty said: @elbee ok thanks. I sent the watch back a second time and hopefully they will exchange it. I appreciate the feedback everyone has shared. You know you can disable bloodoxygen measuring yourself?

@jussim It’s been like this for months. I downgraded the firmware to the previous version. The heart rate measurement only stops every two weeks. Suunto doesn’t deal with it. They probably know about the bug. I’d like you to buy a new Suunto with a new bug.

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

@Łukasz-Szmigiel ok @isazi for the follow up just in case

@Elipsus no worries at all about the language — I saw a few posts in French on other threads so I didn’t immediately realize this particular forum/section is English-only. Sorry about that, happy to continue in English from here. Regarding the full discharge/recharge cycle: I actually already tried this exact process a week ago, based on advice I found in another forum thread. Unfortunately it didn’t change anything for me, the drain rate went right back to the same level afterward. I have been considering sending the watch in for service, but it’s no longer under warranty — which is honestly what frustrates me most about this. The watch is barely two years old, and this issue only appeared after a software update, not from any wear or misuse on my end. Has anyone had luck getting Suunto to acknowledge this as a software-side issue rather than treating it as a standard out-of-warranty repair?

@VoiGAS thanks!! I’ll look into it. My hope is to get him thinking about training sessions using RPE first, and HR as secondary feedback. So this might be the way I go.

@MarTej_cz thanks, I will try

@Art-C hi when you clear the alarm you should see the bar’s in the tank pressure window again!!

@Art-C I’m not sure for the full 100% but it seems Suunto is wotking on an update that makes the screen views more flexible. It was written in the forum somewhere but Suunto has never been confirmed. So let us hope by putting post to the forum thry pickup and do what the Nautic users want. Indeed the screen is awesome, just like the compass and Battery usage !!!

To add to this one, I have the lovely death of HR experience today. See below: [image: 1786859596217-screenshot_20260816-074727.png] [image: 1786859596253-screenshot_20260816-074744.png] I sent logs of course, latest firmware. But somewhat perturbed that this is the end firmware for the watch and this happens. Resources is also stuck at 70%, despite being at 10% before the night. So I suspect a reboot or something is involved?

@David-Jakobsson well, advanced running zones are only for running based sports, not paragliding I will report the original issue for you.

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

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

@SergioB This has already been suggested and seemingly ignored. Also, the font size for the remaining distance in the zoomed in mode should be increased - it is difficult to see. And yes, because of the blue labels rendered on top of the screen it is now impossible to see remaining ascent/descent in the zoomed in mode.

@2b2bff it happens the same to me, but I haven’t understand the pattern yet. Sometimes I see only one activity type, sometimes more than one. The only thing I have discovered is that the summary discards always at least one activity, it is never complete.

@colakovitz You just need it for the pairing (initial connection), afterwards not. Eats a lot of battery…