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

Anton Lundin glance at acc.umu.se
Fri Mar 3 00:53:28 PST 2017

On 03 March, 2017 - Jef Driesen wrote:

> On 2017-03-02 21:57, Salvador Cuñat wrote:
> >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.
> Send me a memory dump of those dive computers, and I'll have a look.
> If you don't have a full memory dump anymore, I can work with the
> raw data of the individual dives too.

I guess its easiest just to modify the libdivecomputer call to dump the
profile data to a file. That way smtk2ssrf can generate the raw dive
dumps that Jef is looking for.

It might even be easiest if you Jef did that yourself, then you can
generate all the testdata you would like and compare your parsed results
with what the vendor application spits out.


Anton Lundin	+46702-161604

More information about the subsurface mailing list