Mandatory Gas Time Alarm at beginning of the dive

[MartinPadiPro]

@hhouter made two dives today.
No gas alarms this time.
Everything went well.

[hhouter]

@MartinPadiPro Yes, but let me guarantee you that you will encounter the same issue soon (if Suunto doesn’t fix the issue in an update). Between my first and second time I had 5 months diving without issues, between second and third, 1 month.

[MartinPadiPro]

@hhouter I hope they will fix it soon. Tomorrow i will go diving again. Fingers crossed

[hhouter]

A friend diving with the Nautic received a mandatory gas time alarm in the beginning of a dive today 29/07/2026.

Suunto please do something about this. This is not an isolated issue or a faulty Nautic that needs to be sent-in for service, it is a issue in the current firmware…!!

See below the response from support, this cannot be true. Triggering an alarm is a serious situation and cannot be left up to the divers interpretation to wait for the stabilization of the calculation.

Initial SAC Calculation Phase
During the first 5–10 minutes of a dive, the algorithm calculates your breathing rate. A higher breathing rate or sudden depth changes during descent may temporarily reduce the estimated gas time, which can trigger an alarm before the calculation stabilizes.

Screenshot_20260729_105855_Suunto.jpg

[l.sillsuunto]

For me, the real concern is not simply that the gas-time value is briefly wrong.

As the screenshots show, divers started ascending after the mandatory red alarm because they understandably believed they might have a serious gas problem. An experienced diver may be able to verify the actual gas situation underwater, but a less experienced diver could panic and make a dangerous decision.

If Suunto knows that the gas-time calculation may not yet be reliable during the first minutes of a dive, then it should not be able to trigger a mandatory critical alarm at that stage.

There is also the risk of people losing trust in the warning after several false alarms and then hesitating when a real one occurs.

I will report this through ICSMS for the European market tomorrow so that it can be assessed independently. Divers in the United States may also want to report the issue through SaferProducts.gov, the reporting system of the US Consumer Product Safety Commission.

[hhouter]

See also the facebook Suunto Nautic group. More people are impacted.

[Mikenizm]

Had the same thing happening a month back. Also when checking the graphic, it shows a very high gas consumption during the same time.

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.

[hhouter]

@Mikenizm Wow… good work.

This is what I just received:

[MartinPadiPro]

@Mikenizm thanks that is very helpfull

[Mikenizm]

I want to raise one thing while the fix is still being scoped, though. The mail talks about the unexpected Mandatory Gas Time alarm specifically, and I think the alarm is only the noisy half of this.

I went back and ran the same check over all seven dives I have on the Nautic. Three of them show the estimator dropping out during the descent and coming back with a nonsense number: 69 l/min on 7 May, 40.6 on 21 May, 100 on 28 June. Only the last one produced an alarm, and the only reason is that the resulting gas time happened to land below the threshold that time. The other two failed in exactly the same way and I never noticed.

Also after digging in the logs a bit more I found out the alarm is a proper event in the log:

127.6s  {"DiveEvents": {"Alarm": {"Active": true,  "Type": "Gas Time"}}}
137.7s  {"DiveEvents": {"Alarm": {"Active": false, "Type": "Gas Time"}}}

At 127.6 s both Ventilation and GasTime are null, not zero. The 100 l/min turns up 2.3 seconds afterwards. So the alarm doesn’t fire because the estimate went bad, it fires because there is no estimate at all, and the bad number is what comes back after.

On my 16 July dive the estimator barely produced anything at all: of 371 samples, 355 had a valid tank pressure but only 17 had a Ventilation value, all reading 0.0 with GasTime: 0. In practice that meant no gas consumption or gas time on my display for that dive, with the POD transmitting normally throughout. No alarm on that one, incidentally, even with GasTime at zero at nearly 12 m.

So there is definitely something wrong happening in the Nautic. Let’s hope they will release an update soon.