Mandatory Gas Time Alarm at beginning of the dive

VoiGAS

@hhouter little bit offtopic, but I am really interested in your experience with the two algorithms. Maybe you like to share them here: https://forum.suunto.com/topic/15559/bühlmann-vs.-rgbm/10

hhouter

@VoiGAS Yes, will respond with my findings there.

ccrhenrik

A question to make things clear. You only get this alarm on the Nautic, not the other air integrated computers? The problem is with the Tank POD not the older transmitter?

hhouter

@ccrhenrik Correct. Two computers connected to same Tank POD. The EON Core does not give me the error, the Nautic does. See screenshots of same dive in post above. The tank pressure graph in both computers are equal and do not indicate any loss of pressure, see screenprints below.

So my conclusion is that it is not a tank pod error or inteference of a flashlight as the EON didn’t give me the error and functioned correctly. There should be a bug in the Nautic as it indicates the 5 Minutes Mandatory gas time alarm with full tank in certain situations in the beginning of the dive.

See both logs;

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: