deco code rewrite

[Jef Driesen]

On 2012-12-06 23:35, Dirk Hohndel wrote:
> Jef Driesen <jefdriesen at telenet.be> writes:
>> We could consider adding a new DC_SAMPLE_SETPOINT sample type, and 
>> then add a
>> new field to the dc_sample_value_t union. As long as the size of the 
>> union
>> doesn't increase, it should remain backwards compatible. And since 
>> there is
>> already a double present, alignment rules wouldn't change either. So 
>> I don't
>> think such a change will cause trouble.
>>
>> It would definitely be a cleaner solution, compared to yet another 
>> abuse of the
>> events :-)
>
> I'm all for that!

I propose to add two new sample types then: DC_SAMPLE_SETPOINT and 
DC_SAMPLE_PPO2. For the corresponding data types, the dc_sample_value_t 
union is extended with two additional double's (named setpoint and 
ppo2), which will contain the O2 partial pressure in bar.

>>> Back to the Predator and downloading dive data: This unit reports 
>>> some more
>>> interesting stuff which I'd like to see in subsurface as well. So 
>>> Jef, this most
>>> likely addresses you in the first place:
>>> - GF Settings (would be really nice to know, have not seen this in 
>>> the OSTC logs
>>> so far!?)
>>
>> This is a more problematic one, because it's very device specific. 
>> Each device
>> has it own decompression model, with its specific parameters (if 
>> those are even
>> known). I don't see this as something that should be supported 
>> through the
>> generic interface.
>
> I think this would definitely be something for the vendor extension -
> not something we can easily do in the current design.

That's my opinion as well.

>>> - Battery voltages (nice to have)
>>
>> I've always wondered why anyone would need this? I mean as long as 
>> you have
>> enough, everything is fine, and if you don't then probably no dive 
>> will be recorded.
>
> It's nice to download your dives and get the nice warning that your
> battery is low in the dive log program. Believe it or not, that's
> something that I intended to implement for Uemis (especially for the
> tank sensor battery) as it's so easy to do and so helpful to have.

Of course it's important to know the battery status. However I see this 
as something that's important while operating the device, and not 
something that goes into your logbook. I mean it's very important that 
the device shows you the battery status, so you can decide whether to 
charge it or not. But what's the added value of having this info for 
each dive? My point is that I consider the battery status more a 
property of the device.

Showing some kind of low battery warning during (or after) the download 
is something different then what Jan meant with adding support for 
battery voltages. I think (and correct me if I'm wrong), that Jan 
referred to supporting the battery status in the header or even the full 
battery profile in the samples (the predator has this).

>>> - CNS % (quite nice, recorded by Computer??)
>>
>> This is already on our list.
>
> Yep. I hope to get to this for the Uemis in the next week or two and
> then create the CNS calculation in Subsurface. Not sure how hard this
> would be to sneak in as extension for libdivecomputer 0.3...

Add another DC_SAMPLE_CNS type, with a double containing a percentage?

Jef