deco code rewrite

[Jef Driesen]

On 06-12-12 20:55, Jan Schubert wrote:
> On 12/06/12 16:15, Dirk Hohndel wrote:
>> On Dec 6, 2012, at 4:59 AM, Jef Driesen wrote:
>>
>>> On 2012-12-05 23:47, Dirk Hohndel wrote:
>>>> Fundamentally we are of course missing CC support (as that was a
>>>> rebreather dive, correct?). That is something that you and I should
>>>> discuss in more detail to understand how we should add this to
>>>> Subsurface.
>>> Keep me CC'ed on that discussion!
>> I think I'll do that here on the list so everyone gets to see it…
>>
>>  From my discussions with Jan so far I think the first thing that we will need is the setpoints from the dive computer. This is basically the setting that tells the us what the "constant pO2" is that the diver is diving with. Depending on the model of dive computer there are either a number of pre-defined setpoints (that's what the OSTC does) or they can be changed in increments during the dive (Shearwater).
>>
>> If we get those and the gas mix of the dilutant we can do correct partial pressure graphs (and can do deco calculations, once that code has been added).
>>
>> 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.

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 :-)

>> Jan, is there something else we need to add right now?
>
> OK, from a users point of view we just need to know if a dive (or parts of it)
> has been OC or CC. Using DC_EVENT_SETPOINT is just half way through as in real
> life the setpoint is not constant. Depending on the type of the (C)CR the real
> pO2 will fluctuate, drift and spike. Also the pO2 can vary in quite huge ways
> when the user decides to manually (over)steer the unit, flashes the loop, there
> is an accident, or some other issues. My hardwired Predator will record the real
> pO2 and report it when dowloading the log. There are other Computers which are
> not connected to the unit (including OSTC and unwired Predators, Pretels) but
> just use predefined set points for deco calculation. In case we get real pO2
> data we should use them of course. In this case there would even be no strong
> need to know the real set point but would be nice and will be reported anyway.
> In all other cases subsurface should just use a constant pO2, the same as the
> defined set point.
>
> Please note: All of the above is not valid anymore when it comes to pSCR, we
> only address [e|m|h|whatever]CCR with this. But as pSCR uses pSCR because they
> not trust any electronics and do not even use dive computers at all there is no
> need to cover this topic for a dive computer software (whoa, seeing some
> complains coming now :-).
>
> Personaly I use a hardwired Predator (meaning reading all my thre O2 cells,
> calculating the pO2 from this and steering the O2 injection), a OSTC (using
> fixed setpoint) and my good old Gekko on every dive. OffTopic: Would be nice to
> enrich the Gekko profile manually with CC mode, setpoint and gas actually used
> (set to air all the time in my case as there is no Trimix support but having
> time and depth might be helpful in case all my other electronics is failing).
> Might also be an issue when merging dives from different computers and
> recognizing different gas settings, different OC/CC mode, different deco...

So basically we'll need two new sample types: setpoint and ppO2. That shouldn't 
be too difficult.

For the dive mode, I'm not sure how we should take care of that. The simplest 
would be a per dive setting. Then we could also use this for other modes like 
freedive, gauge, etc. But as we already learned, the OC/CC mode can be switched 
during the dive. But turning it into another sample type seems a bit weird to 
me, especially because the only case were it will happen in practice is some 
emergency situation. So that means all applications will have to check all the 
samples to check whether a dive was OC or CC. I guess that even if you switch 
people will still consider it to be a CC dive, right?

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

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

> - CNS % (quite nice, recorded by Computer??)

This is already on our list.

> - 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 :-)

Jef