Importing CCR data [was: CCR Testing]

[Paul Sargent]

On 1 Nov 2014, at 10:57, Miika Turkia <miika.turkia at gmail.com> wrote:

> Together they give enough information to know what the diver was breathing at any time.
> 
> Thanks, this gives me something to work on. The current Shearwater import is indeed quite limited in this regard. And of course the whole CCR concept was not there when I wrote the transformation. 

Indeed, and I think we’re going to find things rather fluid as we decide what’s useful information to have from a CCR dive. Willem’s building a road with the Poseidon work he’s doing, but it’s quite an esoteric rebreather, so I think we’ll find some concepts map well to others, and some won’t.

> The CSV import has no options for Gasses, Setpoints, OC/CC mode, ppO2 Sensors, all of which are in this file. I agree the dialog is a limiting factor here. I think there is also a problem with how these concepts map into the Subsurface XML.
> 
> Fields are named similarly to the XML.
> 
> I am thinking of 3 different options for this:
> 1) just keep it as it is and hope that CCR divers have better import option than the CSV
> 2) Implement the setpoints and other info under the hood with no configuration options for users
> 3) Make a new tab for CCR import
> 
> Personally I would of course prefer something that does not include GUI work, but overall I kinda like the third approach. At minimum, implement another tab for the CCR import and possibly cimplify the current CSV import for recreational divers. I just wonder if tech divers will need all the fields in current CSV import when diving OC.
> 
> Any comments on these? Anton, what is your opinion?

CSV is nice to have as a fall back. There’s always going to be a computer / rebreather that we don’t support, and having CSV available gives a user a fighting chance. Even if it’s a limited set of info. If you’ve got a better method for a particular device (e.g. XML, or a specific format of CSV) you’re going to do that.

My opinion is that for the configurable CSV import it has to be limited, otherwise you’ll be on a never ending quest to try to build in more flexibility.

	Time
	Depth
	Water Temp
	ppO2 (Single Value - CCR/SCR)
	CC/OC (CCR)
        Stop Depth

…and then it’s a manual process to enter gasses / switch depths.

(I’ve dropped off NDL, CNS, TTS, & pressure from the current list. CNS is calculable. NDL & TTS aren’t that important if you’ve got the ceiling IMHO. Pressure I assume is cylinder pressure - How many do you want? Possibly just 1, but no more)

Things like multiple sensor readings, or multiple gasses probably need to be limited to known vendors. There’s just too many ways they could be represented. 

    - Is an O2 sensor reading in bar or millivolts? 
    - Is a breathing gas a number into a gas table, an fO2/fHe, or a ppO2/ppHe? 
    - Is a set point column boolean Hi/Lo, or a value?

Any dialog box that deals with all of that is going to be huge. So I’d keep the options low (as present, maybe trimming a couple), and add a couple more for CCR/SCR. Then have predefined schemes which are able to do more under the hood (e.g. APD, Seabear, etc)

My 2p.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141101/1a47e9d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141101/1a47e9d1/attachment-0001.sig>