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

[Anton Lundin]

On 08 December, 2014 - Miika Turkia wrote:

> 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?
> 

Probably by lacking UX design. Those are not saved, because you can't
write them.

Maybe we should gray them out or something...

> I wonder how the other devices in the family look like...
> >
> 
> Was your Vyper (or what do you use for testing) using minutes?
> 

Yepp. The Vyper stores the times in minutes.


//Anton


-- 
Anton Lundin	+46702-161604