On 2015-04-15 11:23, Willem Ferguson wrote:
Attached is my modification of Simon's code for decoding Uwatec dive
logs. For your convenience I also attach a dive log. If you look
around line 388, there is decoding of bookmarks. If you look at lines
390-440 there is decoding of cylinder changes. The Uwatec Sol
registers cylinder changes even if the gases are identical. I use the
hex value f9x value to detect a cylinder change. I also managed to
decode a number of alarm conditions such as max depth exceeded, rapid
ascent, heavy workload, etc but I did not spend a lot of time on that,
though these are reflected in my modifications to the code.
I must admit that I am focused on my own need which is to record
sidemount dives accurately, preferably using cylinder change events,
otherwise using bookmarks. Is any of this reasonably easily
implementable within the context of libdivecomputer-subsurface dive
upload? What does libdivecomputer do if there are two successive
gas-change events to the same gas? I get identical information if I
write the data on a slate during the dive and decode the hex dump
afterwards. At the moment I download each dive twice, once into the
Subsurface dive list and then into a hex dump (also using Subsurface).
Then I run the above software on the hex dump which gives me the times
at which I performed cylinder changes. A roundabout way and not
efficient at all, but it works if one is prepared to take the trouble.
What would you suggest I do in order to make a positive contribution?
I would be glad to help in any way.
Bookmark events should be fairly easy to implement. This is just a
matter of checking the right bit, and then emit a DC_SAMPLE_EVENT sample
with type set to SAMPLE_EVENT_BOOKMARK.
Gas/tank changes are already parsed. But as you probably know,
libdivecomputer reports the oxygen and helium percentages rather than
the gasmix index. Thus when switching to another tank with the same mix,
libdivecomputer will emit a gaschange event (because internally it
tracks the mix index). But at the application level you'll see a switch
to the same mix as before, and the application might drop it.
I've already done some work on replacing the gas change events with a
proper DC_SAMPLE_GASMIX sample, carrying the gas mix index instead of
the oxygen and helium percentages, but isn't completely finished yet.
Technically, removing the events will break backwards compatibility. One
option to fix this without having to wait until v0.5 is out, would be to
introduce the new DC_SAMPLE_GASMIX now, but keep the old gas change
events too. The advantage would be that applications can migrate to the
new api immediately, while old applications keep working as before. Once
v0.5 is out the old events can be removed permanently.
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
