Patches to add basic support for the Suunto EON Steel

Dirk Hohndel dirk at hohndel.org
Tue Oct 28 10:39:45 PDT 2014


On Tue, Oct 28, 2014 at 10:10:08AM -0700, Linus Torvalds wrote:
> Btw, here's a patch to add the actual deco information (NDL and
> ceiling) to libdivecomputer.
> 
> The "ceiling time" thing is actually the TTS. There doesn't seem to be
> any actual "time at deco stop" in the dive data.

Yeah, that appears to be the way Suunto does this. Odd, but also oddly
useful, as you and I discussed before.

> There are tons of other interesting fields (battery charge and voltage
> before/after dive etc), and various events.

By the way: this is something we can get from several of the tech focused
computers and something that tech divers have been asking for repeatedly.

When discussing this with Jef he usually is not in favor of adding all
these speacial things so I'm thinking of doing the parsing in Subsurface
instead. You should implement a SAMPLE_VENDOR_EONSTEEL and pass the raw
sample data back to subsurface... IIRC, the dive_cb already gets the raw
header data. I need to look again to understand if this is filled with
everything we might want on your implementation of the EON Steel backend.

> It's all self-documented
> by the type subsystem, although some of it isn't very clear. For
> example, Suunto clearly has 15 compartments for nitrogen/helium
> loading, and it gives the pressures (32-bit integer values: Pascal),
> but do people care? The *meaning* of those fields are a bit unclear,
> since the deco algorithm is a mixture of that and the
> RgbmNitrogen/RgbmHelium values, and we don't really know how the RGBM
> algorithm works.

I'm not sure people care about these undefined values. It's battery
voltages and things like that we get requests for.

> So while there is some type description, that type description doesn't
> necessarily make the values "meaningful", even if you know what they
> are.. They are "data", not "information".

Which, btw, tends to be one of the areas where I agree with Jef.
When we have data ("ascend rate 3 LEDs") I see little justification for
passing this on to the application. But if we have information ("battery
voltage before / after dive in volts") then I'd like to be able to get
that and display it.

/D


More information about the devel mailing list