Dive data import error with Hollis DG03

[Jef Driesen]

On 23-03-14 08:43, Rick Walsh wrote:
> Today I tried downloading my last few dives from my Hollis DG03 (uses
> the oceanic_atom2 'protocol'), and it failed with 'Dive data import
> error'. I updated subsurface to the latest git (from a version a
> couple of weeks old), and the same error occurred.
>
> Thinking maybe it might be getting confused with my old xml file with
>> 100 dives imported in previous versions of subsurface, I started a
> new file. I tried it a few times, and each time I received the same
> error someway through downloading data. Each time 2-4 dives were
> downloaded. Most of the downloaded dive data looks correct, but once
> max depth for two shallow (4.4m and 5.6m) pier dives were reported as
> 59.9m.
>
> Previously it had been working as expected.
>
> Can anyone make sense of this? I'm not sure if the bug is in
> subsurface, libdivecomputer, the kernel driver, or the DC.
>
> The last few lines of the libdivecomputer log are:
> INFO: Read: size=1, data=5A
> INFO: Read: size=9, data=7001EA1F842B00306E
> ERROR: Failed to receive the answer. [in oceanic_atom2.c:359
> (oceanic_atom2_transfer)]
> INFO: Write: size=4, data=6A05A500
> INFO: Read: size=1, data=A5
>
>
> There is also another error message that occurs several time
> throughout the logfile,
> ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:321
> (oceanic_atom2_send)]
>
>
> Version information:
> $ subsurface --version
> Subsurface v4.0.2-602-g9cfc585563ac, built with libdivecomputer v0.4.2-devel
>
> $ uname -a
> Linux elmo 3.13.5 #1 SMP Fri Feb 28 22:30:40 EST 2014 x86_64 x86_64
> x86_64 GNU/Linux
>
> Note: I don't know if this is related, but earlier, I had been having
> a problem connecting my DC. The DC screen is supposed to indicate that
> it is connected to a PC, but often it wouldn't, and subsurface
> couldn't detect it. I worked around this by removing the 'ftdi_sio'
> kernel module, and trying again. It would connect, but sometimes took
> a few tries. Before reporting a bug, I built the then latest stable
> kernel (I see it's now one minor revision old), which appeared to fix
> the problem.
>
> I'm using Linux Mint 15 (don't start - it "just" works, as opposed to
> "just works", and right now I cbf correcting that mistake), but with
> an updated kernel.
>
> I've attached my logbook, and the libdivecomputer logfile.

This sounds very similar to the ftdi latency problem that was reported recently 
on the libdivecomputer mailinglist [1]. Can you check the latency timer for the 
serial port (/dev/ttyUSB0), with this command:

cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If it contains the value 1, try increasing it to 16, with this command (as root):

echo 16 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

Can you also try to run libdivecomputer's universal test application. You can 
download it here:

http://www.libdivecomputer.org/builds/linux/universal

Run with these options:

./universal -v -l atom2.log -m atom2.bin -b atom2 /dev/ttyUSB0

[1] http://libdivecomputer.org/pipermail/devel/2014-March/000211.html

Jef