@aiv4r is [image: 0UA9ixY] not a sign? Has been there since I dunno when. There are, from my understanding, already SuuntoPlus apps running natively on the Run, don’t ask me which as I’m not sure.

@Steven-Hambleton I would guess that the typical HW development time is 2 years. Then you would have different teams working on different products. I think this is what we see with Garmin and Suunto. If Apple releases new HW every year, they are likely still taking 2+ years for each watch, just running multiple model years in parallel. Suunto seems to follow the normal Agile development approach for software with 2-week sprints and quarterly releases. In my personal view that approach will emphasise regular releases of customer-visible features and give low priority to quality improvements and architectural changes. It does not have to be like that, but it is a common pattern.

Had the same thing happening a month back. Also when checking the graphic, it shows a very high gas consumption during the same time. [image: 1785453031862-img_1800.jpeg] [image: 1785453031973-img_1799.jpeg] I exported the raw JSON from the app and used AI (Claude) to help me dig through the samples. Here’s what it explained: Suunto Nautic on 2.49.32, Tank POD, 12 L, alarm at 02’07.6 at 5 m. The pressure data is clean — 10 s samples, ~0.01 bar resolution, completely smooth through the alarm (202.03 → 201.42 → 200.86 → 200.77 → 200.17 bar). No dropout, no reconnect step. Consistent with what @hhouter found running an EON Core on the same POD. But the consumption line in the app isn’t derived from that pressure. The Nautic logs a separate Ventilation field per cylinder, in m³/s, and calculates remaining GasTime from it. Here’s what it does around the alarm: 110.2 s Ventilation 0.000421 (25.3 l/min) GasTime 2956 s 119.9 s null null 127.6 s null null <- alarm 129.9 s 0.001667 (100.0 l/min) 0 s 137.7 s 0.001562 (93.7 l/min) 755 s 209.9 s 0.000059 (3.5 l/min) 6000 s (capped) Two null samples, then it re-initialises and its first output is 100 l/min. That puts remaining gas time at literally zero seconds, which fires the alarm. Eighty seconds later it’s back at the ceiling. The field is off outside the glitch too: it reports 3.2 l/min at the point where my pressure was dropping fastest of the whole dive, and integrated over the dive it’s 40% below the gas I actually used. So “the algorithm is still calculating your breathing rate” doesn’t hold up. A stabilising average converges — it doesn’t go null and restart at a physiologically impossible value. And an estimator in an invalid state shouldn’t be able to trigger a mandatory alarm at all. If you want to check your own log, export the JSON and look for Ventilation: null mid-dive immediately followed by a huge value and GasTime: 0. Happy to share the script I used.

@babychai No no, never used screen protector. Suunto saphire glass is very good, no need to protect it with a weaker layer IMO. But I think it’s a hardware issue, watch is not in warranty anymore, but I can live with it, until Suunto Vertical 3 release :). Cheers.

@MikeC30 this is well possible.

ah here https://www.suunto.com/en-gr/sports/News-Articles-container-page/suunto-core-2-vs-core-1-whats-new-and-why-it-matters/

Tiny fonts again - poor.

@VoiGAS for the EON, thats correct as they hold both tables. You can switch over or set Buhlmann as default where locks do not occur. But this does not downplay the fact that the ceiling was not followed and decompression was not finalized. This will have impact on further calculations as Buhllman uses its nitrogen buildup for further calculations. So better not to have these sitiations and allways follow the indicators on the computer to the letter. Suunto does make the difference between voluntary or mandatory decompression stops. The RGBM lock only applies to the latter. The screen showed in the link indicates a mandatory situation which is explained by Suunto… you get a warning to go to the ceiling of 6,5 meter. You need to do that within 3 minutes and sit out the deco as long as indicated by the EON, in this case 75 minutes which is far from beeing recreational… If you fail - after warnings like the red ceiling indication and audible signal - to comply within 3 minutes, the computer locks for 48 hours. So you might say it indeed locks during the end of the dive.

@VoiGAS said: The Run is the weight king (queen?) It should as it is one of its selling points…

@sartoric No, no protector, suunto has the best saphire glass And always clean. Maybe it’s a hardware fault as @tieutieu and @isazi mentioned. Well, glad to know that it still working as before on some watches because the timing it changes on mine, sure looks like it was being deprecated. Thank you all for the clarification.

@Egika @maszop I can only share my experiences. I sometimes get the notification when my speed is clearly under 5.4km/h and quite often I don’t get a notification when I walk faster than 5.4km/h. I live in the Netherlands, not a really challenging gnss surrounding. Current pase with gps isn’t the most accurate, but I sometimes continue to hike for over 500 meter and then gps should have a fairly accurate pace.

@elbee Thanks for your input but I wasn’t buying it so did some further testing. Fired up my old 9Peak & connected the HR sensor to that, exactly the same outcome with constant connect/disconnect so it’s the sensor that’s faulty rather than my Race. I’ve sent it back to Suunto via online service request & as it’s only 8 months old I’m hoping for a warranty exchange

Test run today with a Garmin. Race2 passed with flying colors. A huge thanks to the developers. Great job, guys. [image: IMG-20260718-123733.jpg]

@Egika yep, I stiil have it in one of my drawers loved it so much!

@bubuche I would use Runalyze or another external platform for that. Now I‘ve been using the latest updates for a bit, I think we‘re there. I thought about using predicted wind from the weather app, but you end up losing accuracy as soon as buildings are involved. I will look at using the accelerometer perhaps, but felt it was overkill when I started with this app. It might solve the grade latency issue though. I‘ll play around with it at some point.

@Squirrel don’t know. This is iOS beta 3.13

@Squirrel I can only tell what I observe. The gnss data is synced right when your watch is connected to the suunto app on the phone. At least, at some point the sync process is saying it is syncing gps data.

I don’t see this too much on trails but 100% on roads. I think they over corrected a bit with this last update. I constantly get “off route” notifications simply being on the other side of the street running in the correct direction.

@BakxM I had similar error on my old suunto 9 peak, it got stucked in a reboot restore state and couldn’t recover. After I left it drain the battery and it stayed like that for a few days it recovered with an errot 1403, 1405. It rebooted again but after some time it got stucked again and reported a different error. Contacted suunto support and they said iz is serious issue I had to send it back for service, but since it is old watch I negotiated coupon discount for a suunto race 2… 1403 is some memory error probably a part of memmory is bad.