Galileo Sol dive log decoding for sidemount dives.

[Jef Driesen]

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