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