Mandatory Gas Time Alarm at beginning of the dive

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

[hhouter]

@Mikenizm I was comparing some of the four Mandatory Gas Time Alarms from my dives and found a dive where indeed things are a bit more complex and result in strange readings like the dive below. This dive intreged me as I was actually reading TANK PRESSURE: - - (0) during this dive at 33 meters. I can share the json if needed.

Claude: There are two gaps in collecting data of this dive. The alarm fired 9:30 minutes in the dive at 33.27m. something structurally different then the other ones which were more in the 1 to 2 minutes alarm range at shallower depths.

Dive context: deeper dive (max 34.36 m), and this time the first alarm hits at 9:30 into the dive. No elevated consumption beforehand — this wasn’t a noisy-estimate problem like the other files.

Time	Depth	Ventilation	GasTime
400–470s	21.6→28 m	steady 0.0003–0.0004	steady 1280–1630s

Then a real, extended data gap:

Time	Depth	Pressure	Ventilation	GasTime
480.62–490.62s	28.7→29.6 m	None	0	0
500.62–560.62s	30.6→33.0 m	present, declining normally	None	None
570.13s	33.27 m	present	None	None	← Alarm fires here
570.62–590.62s	33.3→33.9 m	None	0	0
594.13s	34.1 m	present	0.000188	37s ← alarm clears
600.62s	34.1 m	present	0.000186	1729s

What this shows:
There were actually two separate dropouts stitched together: a short one at 480–490s, then a long ~70-second stretch (500–570s) where the pressure signal was fine but the computer simply wasn’t producing a ventilation/gas-time estimate at all (None, not 0) — then another ~20-second full pressure dropout right as the alarm was active.

The alarm fired at the very moment the ventilation calculation had been dark for over a minute — likely the computer’s watchdog flagging “I can’t tell you your gas time” rather than a genuine low-air event.

When data finally resumed at 594.13s, it briefly computed a startling 37 seconds of gas time — before jumping to a much healthier 1729s just 6 seconds later.

That 37s figure is a transient artifact of restarting the estimate on stale/limited data, the same pattern as the first file’s dip, just far more dramatic because the gap was longer and happened at depth…