Re: Patches to add basic support for the Suunto EON Steel
Ok, this reply didn't go to the mailing list, because the dive log attachments made it too big. So I'm just quoting the text here for mailing list posterity, I'm assuming Jef got the actual attachments and hopefully nobody else cares (and maybe I shouldn't make my dive data that public anyway). Linus On Tue, Oct 28, 2014 at 9:51 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
On Tue, Oct 28, 2014 at 8:43 AM, Jef Driesen <jef@libdivecomputer.org> wrote:
There are also some header files like unistd.h which don't exist on windows.
Hmm. I wonder why I included them.
Part of it is probably that the whole back-end started out as this "suunto hacking tool" that did a lot of "print hex information of the packets". That's also why there was no libdivecomputer infrastructure, this thing was entirely stand-alone for just trying to gather traces and recreate them, and figure out what the things did.
I got no actual information from Suunto, but the fact that many things are just text helped. Seeing filenames etc in the dumps etc.. And the actual dive dumps have this interesting "each data has its type associated with it, and each type has a human-readable type descriptor". Which meant that I never needed to guess what the actual data means - the problem was figuring out the odd marshaling of the data, and the odd packet protocol.
(For example, in the attached dive files, you don't see the crazy packet protocol artifacts, because "read_file()" has cleaned it all up. Just looking at the textual parts of the packets confused me initially, because it turns out that the dive computer re-uses the buffer it uses for sending the USB packets, and only fills in the parts it needs for a possible partial packet. So the HID packets will contain random garbage from the *previous* packet at the end etc etc. And while the packets are 64 bytes, the two first bytes of the packet is "packet information", so each packet contains just 62 bytes of actual payload, yadda yadda).
Libdivecomputer doesn't log anything on its own. The actual logging is done by the application. That's on purpose. That's for example how subsurface is able to generate a libdivecomputer log directly from the GUI. I believe that's a very useful feature, which certainly doesn't sucks :-)
So the logging I have is for protocol errors, or surprising things. Not useful to users. It's more of a protocol verification, I would *not* want it to show up in applications.
Why do you need void pointers here? You're parsing a byte array, which is by definition an unsigned char array. So where do you get void pointers from?
"void *" is the "random byte area" type. It's one of the things C++ completely screwed up. It's very useful when you use the helper function on random data (that may be embedded in structures etc, or give pointers to "uint32_t" etc when you convert from little-endian to big-endian etc.
But if there are no cases of that left over, maybe you can convert them all to "unsigned char *" ..
I know it doesn't support a standard memory dump. But a dump of one dive is fine too. I can use the parser standalone.
I hacked up subsurface to just dump the per-dive data to a "dive-%08x.log" file. That's *fairly* close to what the computer does internally, although this dumped data contains the date in the first 32-bit word, which is what the parser expects. On the dive computer, the date is encoded in the filename - see the
dc_buffer_append(file, buf, 4);
in eon_steel_device_foreach() where I append it to the data buffer instead, since the parser doesn't have access to the filename.
(The dive date is *also* encoded in the dive data, but in a very inconvenient format with a dynamic type, so I wanted the data from the filename for simplicity).
So here are the dumps of the dives I have on that dive computer so far, in that "parser format".
That first dive is just me lowering the dive computer into the neighbors pool. The other 21 dives are the ones we did in Bonaire.
Dirk has one of the Intel engineers create a contraption to lower the thing into the pool multiple times, so that I can see what happens to the directory listing when it no longer fits in one "readdir" reply (the packets may be 64 bytes each, but they are chained up to be replies that can apparently be up to 1kB in size - at least I haven't seen anything bigger than that yet. And I don't know what happens when the directory listing is bigger than that, because the 22 dives I have so far create only about 460 bytes of "readdir reply").
Linus
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. There are tons of other interesting fields (battery charge and voltage before/after dive etc), and various events. 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. 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". Linus
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
On Tue, Oct 28, 2014 at 10:39 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
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...
I'd much rather just these things as some "string event" back, and *not* make them special to the EON steel. For the EON Steel, the battery data is literally strings: "Charge: 98%, Voltage: 4.157V" .. "Charge: 49%, Voltage: 3.802V" and I'd argue that even if you have a dive computer that natively uses milli-volts and returns it as an integer internally, returning it in that form to any application would be prettyu much by definition broken and useless. The application cannot *do* anything with such data, since it doesn't really have meaning for the application - the best we can ever really do in subsurface is to just display it as a string, and let the human in front of the computer then decide that it means. Without exact information about how precise the voltage is, what the battery type is, etc etc, it's simply impossible to make any sane automated judgement, but a human can at least try to figure out the pattern. The charge percentage is arguably the more important field for a human, but other dive computers may just give voltage. This is stuff that strings are good for. So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields. This would allow returning things like "Conservatism" and "Dive mode" too. Again, these things don't have any meaning *across* dive computers, and not all dive computers necessarily even agree about the meaning, so there is no sense in some kind of organized model for the data, but it can be interesting for a human who knows the dive computer to see. Linus
On Tue, Oct 28, 2014 at 11:01:10AM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 10:39 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
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...
I'd much rather just these things as some "string event" back, and *not* make them special to the EON steel.
That is EXACTLY what I want. I need to understand what you pass to the callback: if (!callback(dc_buffer_get_data(file), dc_buffer_get_size(file), NULL, 0, userdata)) What's in that buffer?
So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields.
This would allow returning things like "Conservatism" and "Dive mode" too. Again, these things don't have any meaning *across* dive computers, and not all dive computers necessarily even agree about the meaning, so there is no sense in some kind of organized model for the data, but it can be interesting for a human who knows the dive computer to see.
You can do this already. You just need to cheat. DC_SAMPLE_VENDOR allows you to pass data of a given length. Simply have two strings in there, both \0 terminated. /me runs and hides... /D
On Tue, Oct 28, 2014 at 11:36:51AM -0700, Dirk Hohndel wrote:
On Tue, Oct 28, 2014 at 11:01:10AM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 10:39 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
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...
I'd much rather just these things as some "string event" back, and *not* make them special to the EON steel.
That is EXACTLY what I want. I need to understand what you pass to the callback:
if (!callback(dc_buffer_get_data(file), dc_buffer_get_size(file), NULL, 0, userdata))
What's in that buffer?
So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields.
This would allow returning things like "Conservatism" and "Dive mode" too. Again, these things don't have any meaning *across* dive computers, and not all dive computers necessarily even agree about the meaning, so there is no sense in some kind of organized model for the data, but it can be interesting for a human who knows the dive computer to see.
You can do this already. You just need to cheat. DC_SAMPLE_VENDOR allows you to pass data of a given length. Simply have two strings in there, both \0 terminated.
Actually, dive mode and conservatism and battery voltage are all per dive, not per sample. So we don't even need DC_SAMPLE_VENDOR. This should all be contained in the dc_buffer_get_data(file) - so the question remains, what's in that buffer? /D
On Tue, Oct 28, 2014 at 11:42 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
Actually, dive mode and conservatism and battery voltage are all per dive, not per sample. So we don't even need DC_SAMPLE_VENDOR. This should all be contained in the dc_buffer_get_data(file) - so the question remains, what's in that buffer?
That's the raw data. It's not *useful* to subsurface, Dirk. That would mean that we would have to just parse it all again, using EON Steel-specific parser. That's pure and utter crap. At that point, why the hell should we have anything to do with libdivecomputer in the first place? Why am I wasting time trying to get Jef to take my patches at all? I can happily just say "screw libdivecomputer", and do a EON Steel importer inside subsurface, the way the Uemis one does. If that's what you want, I'll do it. It will probably make it much easier to get the patches accepted. But I think that kind of approach is silly. I would much rather improve the actual libdivecomputer interfaces, and report back strings. NOT some kind of "raw divecomputer data". Because if you want raw divecomputer data, and then intend to parse that again in subsurface, then seriously, all the effort I put into making the code more acceptable to Jef was just totally wasted effort. What I do *not* want to do is have the pain *twice*. Either we parse it in libdivecomputer, *or* we parse it in subsurface. Not both. Not some unholy mixture where libdivecomputer parses the basic samples, and then subsurface parses the rest. Just tell me. Do we do the parsing in subsurface and I throw away the libdivecomputer patches, or do you want sane libdivecomputer interfaces? I'm ok with either, really. Avoiding libdivecomputer makes my life easier. I think it would be a shame, but .. Linus
On Tue, Oct 28, 2014 at 11:58 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
I can happily just say "screw libdivecomputer", and do a EON Steel importer inside subsurface, the way the Uemis one does. If that's what you want, I'll do it. It will probably make it much easier to get the patches accepted.
.. btw, not just that, but it will make some of the interfaces simpler too if I can just fill in the data directly into our divecomputer structure. So I certainly don't object to changing my importer to be more Uemis-like. No callbacks, no impedance matching, no need to try to make things compile in an odd environment etc. I still think it would be *much* better if we fed the thing back to libdivecomputer. Not because I particularly care about the other projects that use it, but just because it's the right thing to do. But I really think it's wrong to parse the data twice. So if we want battery information, I'm not going to be part of anything that says "here's the raw vendor information, you parse it again yourself". That just makes me throw up in my mouth a little. I'd make it return the data as a string. And NOT using DC_SAMPLE_VENDOR, but as something that is *defined* to pass up a string, so that it isn't some one-off random hack. Linus
On Tue, Oct 28, 2014 at 11:58:10AM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 11:42 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
Actually, dive mode and conservatism and battery voltage are all per dive, not per sample. So we don't even need DC_SAMPLE_VENDOR. This should all be contained in the dc_buffer_get_data(file) - so the question remains, what's in that buffer?
That's the raw data. It's not *useful* to subsurface, Dirk.
We already parse the raw data from other backends in a couple of cases, just for the record.
I can happily just say "screw libdivecomputer", and do a EON Steel importer inside subsurface, the way the Uemis one does.
For the record, the reason that the Uemis downloader isn't in libdivecomputer is that Jef and I couldn't figure out a way to make that work. The way the communication is done there is just way the hell to broken :-(
But I think that kind of approach is silly. I would much rather improve the actual libdivecomputer interfaces, and report back strings. NOT some kind of "raw divecomputer data".
I was asking you what the format of that data was. You can relax, take a deep breath and stop yelling for a moment. I know that's hard, but sometimes it actually helps the conversation. So yes, let's figure out a sane way to hand data like that back to the application. /D
On Tue, Oct 28, 2014 at 12:25 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
So yes, let's figure out a sane way to hand data like that back to the application.
.. the email you wrote was an answer to teh email where I already told you what my suggestion was. But you answered with the completely unacceptable "DC_SAMPLE_VENDOR", which completely misses the point, exactly because it is *not* defined to be strings. Let me quote it: "So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields" So I literally suggest just "DC_SAMPLE_STRING", which comes with a structure that has two constant strings: the "descriptor" and the "value". Nothing else. No structure, no rules except for "strings for human consumption". For the battery thing, it could be { "Battery at start of dive", "Charge: 98%, Voltage: 4.157V" } but it could also be things like { "Dive algorithm", "Suunto RGBM" } or for things like the Uemis (if it were ever converted to libdivecomputer): { "Suit", "3-5mm wetsuit" } just to give a non-EON-Steel example. The point being that most modern dive computers have these kinds of random fields that it definitely isn't worth trying to organize a data structure for. And then, subsurface could certainly try to match some strings (ie maybe we could catch that "suit" thing), but others it would just show in a popup when you hover over the dive computer name. Or add to the "Notes" window by default (although that would probably be annoying). Or something like that. Linus
On Tue, Oct 28, 2014 at 12:38:08PM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 12:25 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
So yes, let's figure out a sane way to hand data like that back to the application.
"So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields"
So I literally suggest just "DC_SAMPLE_STRING", which comes with a structure that has two constant strings: the "descriptor" and the "value". Nothing else. No structure, no rules except for "strings for human consumption".
Is this per sample data or per dive date? So I think this is a DC_FIELD_STRING in libdivecomputer nomenclature.
For the battery thing, it could be
{ "Battery at start of dive", "Charge: 98%, Voltage: 4.157V" }
but it could also be things like
{ "Dive algorithm", "Suunto RGBM" }
or for things like the Uemis (if it were ever converted to libdivecomputer):
{ "Suit", "3-5mm wetsuit" }
Yes, this would be extremely useful and I have a number of backends that could take advantage of that - and I already have an idea how to present this in Subsurface. I coded this for the Uemis way back when in the Gtk days, so this will need to be redone, but getting description / value pairs and showing them in Subsurface would be very easy and very powerful. And yes, this is MUCH better than the complicated deco types we have been discussing.
just to give a non-EON-Steel example. The point being that most modern dive computers have these kinds of random fields that it definitely isn't worth trying to organize a data structure for.
Yes. Agreed.
And then, subsurface could certainly try to match some strings (ie maybe we could catch that "suit" thing), but others it would just show in a popup when you hover over the dive computer name. Or add to the "Notes" window by default (although that would probably be annoying). Or something like that.
I wouldn't add them to notes. I'd create a separate UI area where such "structured data" can be shown as "additional info" or something like that. /D
On Tue, Oct 28, 2014 at 12:44 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
Is this per sample data or per dive date? So I think this is a DC_FIELD_STRING in libdivecomputer nomenclature.
DC_FIELD_STRING would work, yes. I think it would likely be but be slightly annoying as the DC_FIELD_xyz model is driven by the application, so now the application has to query these strings, which in turn means that you have to either count them up-front, or use the index model (and perhaps iterate until you get NULL's back or an error code?). The DC_SAMPLE_xys model is nice for the kinds of things where the divecomputer just gives a random number of entries, because that's obviously how the samples work too. But no, this is not a big fundamental issue, it's just a detail in the interface. DC_FIELD_STRING is fine too. I guess I could even convert the serial number etc to be those kinds of things, and use this instead of the DC_FIELD_DEVINFO thing I wrote. Linus
On Tue, Oct 28, 2014 at 01:02:07PM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 12:44 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
Is this per sample data or per dive date? So I think this is a DC_FIELD_STRING in libdivecomputer nomenclature.
DC_FIELD_STRING would work, yes.
I think it would likely be but be slightly annoying as the DC_FIELD_xyz model is driven by the application, so now the application has to query these strings, which in turn means that you have to either count them up-front, or use the index model (and perhaps iterate until you get NULL's back or an error code?).
Ah. Hadn't thought of that. Having DC_FIELD_STRING return an array of pairs of strings sounds challenging. Maybe "keep calling it until it returns two empty strings" is a reasonable way of doing this. I like this better than having to first get a number of strings.
The DC_SAMPLE_xys model is nice for the kinds of things where the divecomputer just gives a random number of entries, because that's obviously how the samples work too.
Yes. Maybe it's just my mindset that's too inflexible here. I think of DC_SAMPLE things as stuff that happens "during the dive". And I think of DC_FIELD things as stuff about the whole dive. Maybe I need to drop that categorization. Jef - would either of these work for you?
I guess I could even convert the serial number etc to be those kinds of things, and use this instead of the DC_FIELD_DEVINFO thing I wrote.
It would certainly make things nicely consistent. Let's see what Jef thinks of this direction. /D
On Tue, Oct 28, 2014 at 11:36 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
I need to understand what you pass to the callback:
if (!callback(dc_buffer_get_data(file), dc_buffer_get_size(file), NULL, 0, userdata))
What's in that buffer?
That's just the whole dive file.
You can do this already. You just need to cheat. DC_SAMPLE_VENDOR allows you to pass data of a given length. Simply have two strings in there, both \0 terminated.
Yeah,. and I refuse to use shit like that. Sorry, Jeff, but if it's a string, it had better be *defined* as a string. Not "random memory data that you aren't guaranteed to be able to show". The DC_SAMPLE_VENDOR callback could be any garbage, certainly *not* something that subsurface could then show as divecomputer information. There are multuiple DC backends that use it, and they all just use it for random binary data. And that's just useless shit, pardon my French. Linus
On Tue, Oct 28, 2014 at 5:10 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: [...]
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.
The 15 tissue compartments half-times are documented in the Suunto manual. I am almost certain they are tracked like every other haldanean tissue compartments, i.e. can be calculated with Buhlmann equation. IMHO, there is much more value in such information than in Subsurface's recalculation of inert gas pressure in tissue compartment recalculation with Buhlmann. [...] Regards, w ------------------------------------------------------------------------------ _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
On Wed, Oct 29, 2014 at 5:00 PM, Artur Wroblewski <wrobell@pld-linux.org> wrote:
The 15 tissue compartments half-times are documented in the Suunto manual.
Hmm. Interesting. I hadn't actually noticed that, but right you are. Not that they are exhaustively documented, but the Nitrogen half-times for the compartments are indeed there (with "halftimes are divided by a constant factor to obtain helium halftimes")
IMHO, there is much more value in such information than in Subsurface's recalculation of inert gas pressure in tissue compartment recalculation with Buhlmann.
I'm not sure that follows, though.. The ones we calculate are much better documented, and at least as well-tested as the one Suunto does, and you can actually see how changing the values and settings changes things, and how it affects the loading during the dive - while I can only download the saturation before/after the dive, with no logging of it during.. That said, it would perhaps be interesting to see if we can match the before/after values some way. But there's that magic M-value and probably other hidden variables that depend on dynamic issues like ascent speed, so it likely isn't nearly as simple as looking at the profile and the beginning/ending compartment values and trying to figure out the hidden constants. There's some more docs from Suunto at http://ns.suunto.com/pdf/Suunto_RGBM.pdf if some mathematically inclined person cares and is interested. And I can give people profiles and tissue loading data from my 21 dives if somebody really wants to see if they can match the data at least superficially. Linus ------------------------------------------------------------------------------ _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel
Hi, Le 30/10/2014 18:17, Linus Torvalds a écrit :
There's some more docs from Suunto at
http://ns.suunto.com/pdf/Suunto_RGBM.pdf
if some mathematically inclined person cares and is interested. And I can give people profiles and tissue loading data from my 21 dives if somebody really wants to see if they can match the data at least superficially.
The RGBM algorithm is documented in details here: http://www.scuba-doc.com/rgbm.pdf. Unfortunately, the article (and Wienke's books) is quite difficult to follow. I'm not a native English speaker, but the style feels awkward. And while I'm a researcher in statistics I don't understand everything. I've access to research papers published by Wienke (not all but a good selection of it through my university's subscription) but that does not help much... I can share some docs if someone's interested. Gap has also a technical primer on how they implemented RGBM: http://www.gap-software.com/staticfiles/RGBMmath.pdf. Not super clear.
From what I've gathered, the RGBM works as the VPM by tracking bubble growth, more precisely the effect of pressure change on the distribution of the radius of the bubbles in the tissues. The idea is that small bubbles will vanish naturally whereas big ones will grow, leading to a notion of critical phase volume: basically, you don't want too much bubbles with a radius above some critical excitation radius. VPM and RGBM use similar approach, but the bubble growth model of RGBM is more complicated.
The main difference with Bühlmann approach and VPM/RGBM is the way the allowed gradient is calculated, not the way the gas pressure in compartment is tracked (which is pretty basic stuff). The original RGBM implementation uses a lot of compartment while Suunto's version is down to 9 (or 15? Suunto's doc says 9). If I understand correctly, this means that the tissue saturations tracked by the EON steel should be comparable to the ones tracked by any other computer, provided the half lifes match. I've not followed subsurface discussions lately, so I'm not sure if a VPM implementation is still under consideration (it was discussed at some time). My impression is that VPM is already a bit convolved mathematically so it would be probably better to start with it before RGBM which is a step further away from the simple Bühlmann approach. Hope that helps. Fabrice
On Thu, Oct 30, 2014 at 5:17 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
On Wed, Oct 29, 2014 at 5:00 PM, Artur Wroblewski <wrobell@pld-linux.org> wrote:
The 15 tissue compartments half-times are documented in the Suunto manual.
Hmm. Interesting. I hadn't actually noticed that, but right you are. Not that they are exhaustively documented, but the Nitrogen half-times for the compartments are indeed there (with "halftimes are divided by a constant factor to obtain helium halftimes")
It seems, I have exaggerated the documentation part. The constant is probably around 2.65 (helium diffuses 2.65 faster than nitrogen). In [1] Wienke says "around 2.7" (pages 82-83) or "around 2.65" (i.e. page 143). Also, divide the Buhlmann nitrogen half-times by helium ones (5 / 1.88 == 2.66).
IMHO, there is much more value in such information than in Subsurface's recalculation of inert gas pressure in tissue compartment recalculation with Buhlmann.
I'm not sure that follows, though.. The ones we calculate are much better documented, and at least as well-tested as the one Suunto does, and you can actually see how changing the values and settings changes things, and how it affects the loading during the dive - while I can only download the saturation before/after the dive, with no logging of it during..
OK. I misread your e-mail thinking you get the data during the dive as well. [...] Anyway, you have pressure of inert gas in tissue compartments. An application using libdivecomputer could fetch the data to calculate surface intervals, no fly time and for multi-day dive planning or apply it to some other use cases we cannot predict here. A calculation does not have to use the same decompression model principles as the one implemented in a dive computer. Inert gas pressure in tissue compartments data is quite common in many decompression models (ZH-L16, VVAL 18, VPM, RGBM) and, if I understand well, the Cochran backend could provide such data, too. We could ask HeinrichsWeikamp to have it in OSTC dive computers. Therefore, IMHO, it would be good to model this data as, for example, a list of pressure values (in unit used by libdivecomputer for pressure) for each inert gas (but not strings). Regards, w [1] http://www.sergiodestro.com/decodoc/RGBM_Update8402.pdf
On 31 October, 2014 - Artur Wroblewski wrote:
Inert gas pressure in tissue compartments data is quite common in many decompression models (ZH-L16, VVAL 18, VPM, RGBM) and, if I understand well, the Cochran backend could provide such data, too. We could ask HeinrichsWeikamp to have it in OSTC dive computers.
The OSTC3 already stores the following according to the manual: N2 compartment desaturation time in min. 16Bytes N2 compartments at end of dive in mbar 64Bytes 16*4Byte (Float), See Note 9 He compartment desaturation time in min. 16Bytes He compartments at end of dive in mbar 64Bytes 16*4Byte (Float), See Note 9 Note 9: Compartment assignment according to Bühlmann, Albert: Tauchmedizin; 4. Auflage [2002], values after dive Libdivecomputer currently doesn't read those values, but it would be quite simple to add that. //Anton -- Anton Lundin +46702-161604
participants (5)
-
Anton Lundin -
Artur Wroblewski -
Dirk Hohndel -
Fabrice Rossi -
Linus Torvalds