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

Alessandro Volpi volpial at gmail.com
Fri Mar 3 03:23:44 PST 2017


Dear Salva,

I do not think IT IS THE CASE FOR SPENDING MORE TIME about the issue of
unnamed tanks. The dive computer always assumes that the diver is actually
carrying the tanks whose O2 concentration has been defined or the tanks
equipped with a pressure transmitter having been paired with the computer.

This is not always the case, when the diver is lazy and does not erase the
O2 concentration data or the pairing data for the tanks not being actually
used.

But this has nothing to do with the smtk2ssrf operation.

As far as the problem of the missing tank description data for the dives
with undefined tank start pressure is concerned, my opinion is that this
small inconvenience is less important than the ADVANTAGE OF AVOIDING  to
show tanks which  haven't been used.

The simple solution is to open SmartTrak and to manually insert a 200 bar
start pressure for the first ( or unique ) tank in the few dives where such
piece of information is not available; doing that the tank description for
the first tank is expected to be included in the .xml file , even when the
diver does not remember the Start or End pressure for the concerned dive.

Best regards.

Alessandro


On Thu, Mar 2, 2017 at 8:57 PM, Salvador Cuñat <salvador.cunat at gmail.com>
wrote:

> 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
> >   IGNORED.
> >
> 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
>    mixes.
> 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.
>
> Salva.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170303/935656cf/attachment.html>


More information about the subsurface mailing list