deco code rewrite

[Dirk Hohndel]

Jef Driesen <jefdriesen at telenet.be> writes:
>>> So maybe this is something we could still add for libdivecomputer 0.3? I think the easiest way to extend the current libdivecomputer design to deal with this is to model these as events:
>>>
>>> if the diver is in CC mode (or enters CC mode), then send a DC_EVENT_SETPOINT on the first sample that gives us the current setpoint.
>>> if the dive computer reports a change in setpoint, then send another DC_EVENT_SETPOINT event.
>>> value should simply be the pO2 (since the current design uses floating point we can simply use a double with the correct value)
>>>
>>> Does that work?
>
> In the current design, events can only carry an integer, not a floating point value.

Oops. Forgot.

> 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!

>> 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.

>> - 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.

>> - 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...

>> - Firmware (nice to have)
>
> This is already supported in libdivecomputer. You get the current firmware 
> version during the DC_EVENT_DEVINFO.
>
>> Check this profile for what the Shearwater software is reporting:
>> http://trac.hohndel.org/attachment/ticket/5/tg.png
>> This also shows the not constant pO2. What would be interessting is what the
>> reports when one changes the GF settings while diving which is possible for the
>> Predator and with newest OSTC firmwares. If there is a need, I would offer to do
>> some test dives for this :-).
>
> Let's start with the normal features first, and then look at the corner cases :-)

no kidding :-)

/D