Mandatory Gas Time Alarm at beginning of the dive

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

[hhouter]

Asked Claude AI to do a check on anomalies for GasTime and Ventilation of this dive:

That chart makes the pattern obvious — GasTime should trend smoothly downward (or oscillate gently as you work harder/easier), but instead it repeatedly stabs down to zero and snaps back. Every one of those spikes lines up with a missing Pressure reading

Pattern summary:
Dropouts are spread across the entire 55-minute dive, not clustered at a specific depth or phase.
Most are brief (1 sample, ~0–10s), but two stand out — 17.8 min (10 samples, ~60s) and 16.0 min (6 samples, ~50s) — nearly a full minute each with no valid gas data. 26.3% of all gas-0 readings are affected.

Is Suunto able to comment on the findings and conclusions from @mikenizm ?

[hhouter]

Did the same for the JSON file from my Buddy who uses the Suunto Ocean and was making the same dive with me that day… These are the reults.

Claude.io: This dive’s data is much cleaner than the previous one.

Here’s what I found:
Dropout rate: 3.6% (much lower)
Only 13 of 360 gas-0 readings have missing Pressure/GasTime, spread across 9 short episodes — 7 are single-sample blips (0-1s), the longest are just 2 samples.

Compare to the earlier dive’s 26.3% dropout with 43 episodes — this transmitter connection was far more stable.

Startup ramp-up (expected, not really an anomaly):
The first ~5 samples show GasTime/Ventilation as None (not 0) while Pressure is already valid — the computer hadn’t accumulated enough breathing data yet to compute a rate. This is normal startup behavior, distinct from the mid-dive zero-dropouts.
Right after that, GasTime hits a flat 6000-minute ceiling for 3 consecutive samples (08:54:19–08:54:39) — an unrealistic 100-hour “time remaining,” clearly a display cap/sentinel value used while the consumption estimate is still very low/unstable, not a real prediction.

A genuine (non-error) exertion spike: Around 08:54:59–08:55:39, Ventilation jumps to ~0.0004–0.00044 (roughly 4 std devs above the dive’s mean of 0.000176) for 5 consecutive samples, and GasTime correspondingly drops sharply (5166 → 4085 min).

This lines up physiologically — harder breathing → faster projected gas depletion — so it looks like a real brief exertion event (current, effort, etc.), not a sensor glitch.

Minor sensor noise:
Pressure “increases” slightly (rather than only decreasing) at 36 points in the dive, but these are tiny — averaging ~13,000 out of readings in the ~7-20 million range (~0.06-0.1%), consistent with normal transmitter/quantization jitter rather than any real gas refill.

No negative values, no NaNs, Ventilation and GasTime otherwise stay in sane ranges (1278–6000 min, 0.000096–0.000442) for the full 57-minute dive.

Bottom line: this dive’s transmitter link was solid — the only real data-quality flags are the brief startup-ramp None/6000-cap period and a handful of tiny pressure-noise blips, nothing like the recurring false zero-outs from the other dive.

[Nandodiver]

Ive being “lucky” so far

Never had any random gas time alarm beginning at the dive , except today when i had 50 bars at the end of the dive… but that is mandatory gas alert at 50 bars

Nautic & Nautic S
6 dives with 2 transmitters and counting

[Nandodiver]

I hope all of you with this bug dive with the analog pressure gauge + transmitter

While i like to use transmitters the SPG is always theres, sidemount or backmount.

[hhouter]

@Nandodiver … just like the SPG we would expect that a device like the Nautic will simply work. You probably don’t question the gauge to be correct, that is what the Nautic should provide also.

[Nandodiver]

@hhouter Just taking a guess… but it possible that the first order/serial of transmitters might be faulty…
My transmitters arrive in 15 july 2026

You should gather an excel with owner data to try to find a common pattern between the transmitters.

[Nandodiver]

date of arrival 15 july 2026

First 2 digits (YY): Year of manufacture
Next 2 digits (WW): Week of the year the device was made.
Remaining digits: Unique factory production numbers

Transmitter Model DP142
Serial 2625xxxxxxx
Serial 2625xxxxxxx

Nautic DW251
software 2.49.32
bluetooth 3.0.50
serial 2553xxxxxxxx

Nautic S DW253
software 2.54.12
bluetooth 3.0.54
Serial 2604xxxxxxxx

[hhouter]

@Nandodiver that might be an option but why is my EON Core on the same POD and same dive where the Nautic logs the alarm not giving any comparable errorss? My expectation is that the errors are in the Nautic.

[Nandodiver]

@hhouter do you have the problem in :

Sunnto Tank POD (new version)

Or the

Suunto wireless tank pressure transmitter (old version)

[hhouter]

@Nandodiver I have the tank POD, i believe the transmitter only works with the older computers like Vyper and the D Range of dive watches.
I bought the POD in the beginning of this year and i’m not aware that there is a new version available.