Trying out a brand new Oceanic Geo 2.0 -- can't sync

[Jef Driesen]

On 28-06-13 21:27, Benjamin Kahn wrote:
> I just received a brand new Oceanic Geo 2.0 for a dive trip next month.
> I won't have much network access, so I'd like to make sure I can connect
> my new dive computer to my Fedora 18 laptop before going.

In some cases downloading a dive computer without any dives can fail, because 
this is a rather rare condition, and not all code has ever been tested in such 
condition. Data from a brand new device is hard to get, because it usually 
doesn't last long in that condition. Nobody buys a dive computer to stay dry  :-)

> I've seen two types of errors. Sometimes I immediately get a permission
> error:
>
>          [0.000] ERROR: Device or resource busy (16) [in serial_posix.c:107 (serial_open)]
>          [0.000] ERROR: Failed to open the serial port. [in oceanic_atom2.c:377 (oceanic_atom2_device_open)]

Looks like some other applications already has opened the serial port in 
exclusive mode. That might be modemmanager, as Linus explained in his reply. 
Trying to shutdown that process is probably a good idea.

There is a command to see which process has a certain file open, but I can't 
remember its name right now.

> And sometimes, I get further. When this happens the DC appears to crash.
> Every element on the LCD turns black until I press one of the keys on
> the DC.  When this happens, I see this output to the console:
>
>          [0.112] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:287 (oceanic_atom2_send)]
>          [3.226] ERROR: Failed to receive the answer. [in oceanic_atom2.c:281 (oceanic_atom2_send)]
>          [3.339] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:287 (oceanic_atom2_send)]
>          [3.449] WARNING: Uninitialized logbook entries detected! [in oceanic_common.c:404 (oceanic_common_device_foreach)]
>          [6.453] ERROR: Failed to receive the answer. [in oceanic_atom2.c:281 (oceanic_atom2_send)]

The warning you can just ignore. For the errors, I'll need a full debug log. The 
easiest way to get that is to run the libdivecomputer "universal" test app. You 
can build it from source, or download a pre-compiled binary here:

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

Then run it with these options:

./universal -l output.log -d output.xml -n "Oceanic Geo 2.0" -v /dev/ttyUSB0

and send the output.log file.

> Here's what I've tried so far:
>
> I located a Windows computer and was able to connect to the DC (reading
> and writing) using the USB cable.

That confirms the cable and dive computer are all fine.

> /var/log/messages shows that the cable is detected:
>
>          Jun 28 00:42:24 localhost kernel: [894764.927592] usb 1-1.2: new full-speed USB device number 27 using ehci-pci
>          Jun 28 00:42:24 localhost kernel: [894765.009894] usb 1-1.2: New USB device found, idVendor=0403, idProduct=f460
>          Jun 28 00:42:24 localhost kernel: [894765.009905] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>          Jun 28 00:42:24 localhost kernel: [894765.009917] usb 1-1.2: Product: 2002 Design,Inc. USB
>          Jun 28 00:42:24 localhost kernel: [894765.009922] usb 1-1.2: Manufacturer: 2002 Design,Inc
>          Jun 28 00:42:24 localhost kernel: [894765.009926] usb 1-1.2: SerialNumber: 20030001
>          Jun 28 00:42:24 localhost kernel: [894765.014762] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
>          Jun 28 00:42:24 localhost kernel: [894765.014871] usb 1-1.2: Detected FT232BM
>          Jun 28 00:42:24 localhost kernel: [894765.014880] usb 1-1.2: Number of endpoints 2
>          Jun 28 00:42:24 localhost kernel: [894765.014888] usb 1-1.2: Endpoint 1 MaxPacketSize 64
>          Jun 28 00:42:24 localhost kernel: [894765.014895] usb 1-1.2: Endpoint 2 MaxPacketSize 64
>          Jun 28 00:42:24 localhost kernel: [894765.014902] usb 1-1.2: Setting MaxPacketSize 64
>          Jun 28 00:42:24 localhost kernel: [894765.016122] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

Looks fine too.

>          Jun 28 00:42:24 localhost mtp-probe: checking bus 1, device 27: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2"
>          Jun 28 00:42:24 localhost mtp-probe: bus: 1, device: 27 was not an MTP device

If mtp-probe is probing the device, as it's name indicates, then that might be 
another candidate interfering with the download. If the probing involves sending 
data to the device, than that may also explain your dive computer acting weird 
because it's receiving data it doesn't understand.

Jef