On 08 December, 2014 - Miika Turkia wrote: > On Sun, Dec 7, 2014 at 11:25 PM, Anton Lundin <gla...@acc.umu.se> wrote: > > > On 07 December, 2014 - Miika Turkia wrote: > > > > > On Sun, Dec 7, 2014 at 10:35 PM, Anton Lundin <gla...@acc.umu.se> wrote: > > > > > > > On 07 December, 2014 - Miika Turkia wrote: > > > > > > > > > On Sun, Dec 7, 2014 at 5:09 PM, Anton Lundin <gla...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface