This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Discontinuous errors in O2 CNS% calculation

I did a dive with my Descent Mk2 (firmware version 8.10) in Multi-Gas mode yesterday and during decompression I suddenly got an alert like this: "CNS toxicity at 150%. End your dive now." That can't be right, there's no way I was over the CNS toxicity limit at that time. We had done about 42 minutes bottom time at an average depth of 145 ft (44 m) on 18/45 trimix, switched to 50% nitrox at 70 ft (21 m) for 4 minute stops every 10 ft (3 m), and then switched to 100% oxygen at 20 ft (6 m) for the final stop. The alert popped up after a few minutes on oxygen.

The FIT File Viewer shows that at timestamp 4/24/2021 11:39:06 AM the "cns_load(percent)" field jumped from 66 up to 150. It had been counting up smoothly until that point but then suddenly jumped. It kept increasing from there until at 11:53:35 AM it reached 226, and then suddenly dropped back down to 23! I'll open a support ticket with Garmin since this seems like a defect. Has anyone else seen similar problems?

Here's a link to the dive activity. I made it public if anyone wants to take a look.

connect.garmin.com/.../6665617152

  • I just did 2 cave dives and have the same issue. Mine jumped to 150% while deco on O2. 

  • Could you guys test it using metric units and proper ISO date and time format setting in the watch and Garmin connect?? (like 2021-09-27 13:05)

    I have the weird feeling since the past couple of months seeing different issues that some problems can be related to the internal calculations messed up using mixed units.

    Like NASA did with the MARS probe.

    I really really hope that developers in Garmin are smart enough to use ISO standards and metric units everywhere and the imperial stuff is only transformed during view.

  • This is obviously not a units issue. The internal calculations and FIT file recording is done using fixed units, and then they are converted for display.

  • I took a more detailed look at a FIT file from a recent tech dive. The chart below shows how the calculated CNS % value changes over time along with the PPO2. During the first part of the dive it looks reasonable. But then after switching to 100% oxygen at 12:05 PM it goes totally haywire and appears to jump up and down at random. Maybe there's some kind of overflow defect in the firmware?

    connect.garmin.com/.../7799503081

  • How did you view that fit file?

  • http://fitfileviewer.com/

    I downloaded the CNS % data as a CSV file and then created a chart in Excel.

  • Thats excellent, any chance you can do a youtube vid or similar showing that step ny step?

  • Here are the steps in Windows.

    1. Open a web browser and to go the dive in Garmin Connect web.
    2. Go to the More menu and select Export Original.
    3. Save the file to any folder.
    4. Go to the folder, right click on the file, and select Extract All.
    5. Select a destination folder and click on Extract.
    6. Open a web browser and go to https://www.fitfileviewer.com/ .
    7. Click on Open Fit file.
    8. Select the extracted FIT file and click on Open.
    9. Scroll down to the record section and click on Download as CSV.
    10. Open Excel and load the CSV file.

    Now you can chart the data however you like.

  • I am continuing to work with Garmin support on this issue. The defect is still present in firmware version 8.40. If you are having a similar problem with inaccurate CNS% calculations then please also contact Garmin support, ask for Cody, and mention "<< Ref:21314361K1 >>". If we can give them sample FIT files from more divers then it should help them fix the bug faster.

    While the cause the of the sudden discontinuous jumps up remain a mystery, I am pretty sure that the drops down are the result of overflows. The FIT file cns_load field is a uint8 type (unsigned 8 bit integer) so when it hits a maximum value of 255 it wraps around back to 0 and starts counting up again from there. If Garmin can just fix the defect that causes those spurious jumps up then that should prevent overflows from occurring.

  • This is fixed in software version 14.10. I did a tech dive yesterday and there were no discontinuities in the CNS% (cns_load) field.

    connect.garmin.com/.../9260191667