testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

Salvador Cuñat salvador.cunat at gmail.com
Thu Mar 2 12:57:44 PST 2017

Good evening Alessandro.

Thank you very much for your exhaustive testing.

2017-03-01 0:20 GMT+01:00 Alessandro Volpi <volpial at gmail.com>:

> After my latest test run I am able to send you this message with my
> remarks about the observed behavior of smtk2ssrf :
>    Some "data format errors" are detected in a number of dives carried
>    out with the old Aladin Air Z O2 ; nevertheless the profiles of said dives
>    ( Dive #241 and older) seem to be error free. I guess that some samples are
>    missing, but the general trend of the time/depth plot is practically
>    unaffected.
Yes, the the profiles are good. I think, the data format error only
affects the Nitrox & O2 series.  I never got one of this with my own
smarttrak file (aladin X & Z  imported from datatrak), but I've noticed
them with some sample dives from old aladin series.  I'll need to look into
libdivecomputer. May be it can be fixed and put into libdc upstream.

>   The special events flags produced by the SmartTec device are simply
This, again, will look into libdc.

>    The events produced by Galileo Sol and Galileo trimix are
>    accurately recorded but their type is ignored. Moving the cursor on the red
>    flags with diagonal white stripe results in a pop-up label with the
>    "Bookmark" caption. Ascent and  workload warnings are thus labeled as
>    "Bookmark" ; surprisingly the manually added Bookmarks are totally IGNORED.
This was the reason I told you to keep your .slg log file.  Most (all)
alarms in Galileo are marked as bookmarks as they are not correctly known.
BTW, when you say "manually added bookmarks", are you talking about
bookmarks set in Galileo or bookmarks set in smarttrak? If they are set in
the device, they should be imported by libdc, if we are talking about that
bookmarks set in smartrak, I don't think they can ever be imported as they
are not stored as a time function, but (x,y) coordinates related to a
(possibly) fixed space or (probably not) screen position.

>    In my past test runs I have observed that the tank "description"
>    field, although correct in most cases, is sometimes classified as "unknown"
>    in spite of the presence of a reasonable tank description in the SmartTrak
>    dive log. I was thinking that these glitches were somehow related to the
>    type of dive computer and to the presence and the health of the pressure
>    transmitter. This was DEFINITELY WRONG. The tank description is IGNORED
>    when, and ONLY WHEN the Start and End pressure fields ARE LEFT EMPTY. This
This was an intentional assumption in my side. The actual workflow of
smtk2ssrf with tanks is:

1- libdc has parsed the raw dive data and may or may not have got tank data
   (whichever is the reason). If libdc got tank data, we have an
   initial pressure for sure.
2- If there is no initial pressure read the smarttrak data (the user
   may have set it manually), including start and end pressure and
3- If we still don't have an initial pressure, discard the tank
   (assuming it hasn't been used). If we have an initial pressure
   complete the tank data (type and working pressure).

The flaw in this marvelous workflow is in point 2. Let's see your
#449 dive. Second and third tanks have not been used (there are no
initial press) *BUT* they had set the O2% (the second, not shown, is
set to 21%). So we end up with three tanks, two of them unnamed.
Subsurface doesn't support unnamed tanks so it changes the description
to "unknown".
I still think that is better not to show tanks which  haven't been
used, but fixing this issue seems easy: get the mix only if we have an
initial pressure.  I will send a fix for this ASAP.

> BTW I have seen that somehow smtk2ssrf and subsurface are able to DETECT A
> FLAWED PRESSURE probe. The Start and End pressure fields in the "Equipment"
>  tab are filled with a pink background, when a transmitter is not working
> properly: see dives  # 457,  458, 459, 464, 465, 466, 468, 469, 470, 472,
> 473, 478, 480, 481, 484 and 486.
> It IS SPECIALLY REMARKABLE that subsurface IS DETECTING the malfunctioning
> probes, whilst SmartTrak IS NOT !
Unsure about this. Whichever is the reason the credit must go to
libdivecomputer and subsurface developers, smtk2ssrf has little to say
here, just tries to translate the data.

Best regards.


More information about the subsurface mailing list