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.