Help needed: User manual - DM5 and Uemis/Vyper configuration

[Miika Turkia]

On Sun, Dec 7, 2014 at 11:25 PM, Anton Lundin <glance at acc.umu.se> wrote:

> On 07 December, 2014 - Miika Turkia wrote:
>
> > On Sun, Dec 7, 2014 at 10:35 PM, Anton Lundin <glance at acc.umu.se> wrote:
> >
> > > On 07 December, 2014 - Miika Turkia wrote:
> > >
> > > > On Sun, Dec 7, 2014 at 5:09 PM, Anton Lundin <glance at acc.umu.se>
> wrote:
> > > >
> > > > > On 07 December, 2014 - Miika Turkia wrote:
> > > > >
> > > > > > >
> > > > > > > I might be able to take a look at this as well.
> > > > > > >
> > > > > >
> > > > > > Maybe not. When I try to load the settings of my Stinger, I get a
> > > > > > segmentation fault.
> > > > > >
> > > > >
> > > > > Could you share a stack trace / or other fault report?
> > > > >
> > > > > The code _should_ work against the Stinger, but it's probably only
> me
> > > > > that have tested it and thats against my Vyper, where it works
> great.
> > > > >
> > > >
> > > > Sure, thing. The problem arises when there is communication trouble
> with
> > > > the device. The crash occurs in different attempts in dc_device_read.
> > > >
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > [Switching to Thread 0x7fff5effd700 (LWP 5738)]
> > > > 0x0000000000569528 in ReadSettingsThread::run (this=0x13eb950) at
> > > > ../configuredivecomputerthreads.cpp:198
> > > > 198                rc = dc_device_read(m_data->device,
> > > > SUUNTO_VYPER_NUMBEROFDIVES, data, 2);
> > > > (gdb) bt
> > > > #0  0x0000000000569528 in ReadSettingsThread::run (this=0x13eb950) at
> > > > ../configuredivecomputerthreads.cpp:198
> > > > #1  0x00007ffff2d3232f in ?? () from
> > > > /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> > > > #2  0x00007ffff2aa1182 in start_thread (arg=0x7fff5effd700) at
> > > > pthread_create.c:312
> > > > #3  0x00007ffff21c3efd in clone () at
> > > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> > > >
> > > > Steps to reproduce (note that there is no need to have the device
> > > attached,
> > > > this simulates dirty contacts that I apparently had):
> > > > - Hook a USB-serial adapter to laptop
> > > > - Try to retrieve details from Vyper class device
> > > > - After two-three attempts I get a crash
> > > >
> > >
> > > Did some poking around and the consecutive clicks have m_data
> > > overwritten with some bogus value. There is some need of protection
> > > against intensive clicking here...
> > >
> > > Don't really know how to solve this one.
> > >
> > > >
> > > >
> > > > Other notes after cleaning the contacts on my DC:
> > > > - I get a red text stating: This feature is not yet available... and
> at
> > > the
> > > > same time black text states: Dive computer details read succesfully.
> > > >
> > >
> > > Some buggy code there. Actually two bugs. Patches coming.
> > >
> > > > I'm not able to update dive count on Stinger (GUI issue? or not
> > > supported?)
> > > > Computer model should probably not be changeable on the GUI.
> > > > I have dive alarm at 80 minutes, but shown value on GUI is 999min.
> > > >
> > >
> > > According to the "documentation" on
> > > http://www.sarnau.info/papers:suunto_vyper
> > > for the alarm in minutes (max. 999 minutes, normal max. 4:59)
> > >
> > > Its stored as a two byte value, and in your case that the gui show's
> 999
> > > minutes is because the value it tried to set to the ui was larger than
> > > that.
> > >
> > >
> > > Could you add a debug line printing the raw value of the data read in
> > > the dc_device_read SUUNTO_VYPER_ALARM_TIME call?
> > >
> > >
> > > Might it be something weird with that device like it storing the alarm
> > > in seconds?
> >
> >
> > I get the following with fprintf(stderr, "DEBUG: %d %d\n", data[0],
> > data[1]);
> >
> > DEBUG: 128 29
> > libdc devinfo serial nr converted to 134807-8877
> > libdc devinfo firmware version converted to 00.21
> > DEBUG: 18 192
> >
>
> 18 192 -> 18*256 + 192 -> 4800
>
> 4800 / 60 is your 80 minutes.
>
>
> So the Stinger stores the depth alarm in seconds. Does the other values
> in the settings look sane so there are no other surprises?
>
> The other values seem to correct (I only have the bakcup to verify atm, so
not entirely sure).

When restoring the backup, nothing on top of the Custom text has the real
values (numeric fields are zero and text fields empty). Is this by design
or accidental?

I wonder how the other devices in the family look like...
>

Was your Vyper (or what do you use for testing) using minutes?

miika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141208/3ad6e939/attachment.html>