Hollis DG03 data import error

Wed May 21 23:12:52 PDT 2014

Hello Folks

This issue is still pending resolution. I left on a dive vacation and
forgot about sync'ing my DC after that. So far I've just been using my DC
for dives without logging.

Now I am trying again on a fresh install of Ubuntu 14.0.4LTE.

Here are the things I tried:

$ ls -l /dev/ttyU*
crw-rw---- 1 root dialout 188, 0 May 22 11:24 /dev/ttyUSB0

$ sudo chmod 0666 /dev/ttyUSB0
$ ls -l /dev/ttyU*
crw-rw-rw- 1 root dialout 188, 0 May 22 11:25 /dev/ttyUSB0

I tried making the above permanent on reboot with a
/etc/udev/rules.d/50-usbtty-rules file that read:
KERNEL=="ttyUSB*", MODE="0666"
but this resulted in my usb mouse and keyboard becoming unresponsive on
reboot, so I removed it.

Then I tried the instructions by Jef given earlier when this thread was
active:
>>>
it seems modem-manager thinks you just connected a modem and takes the
device. you could create an udev rule to blacklist some usb serial
devices. look at (something like, probably /usr/lib)
/lib/udev/rules.d/77-mm-usb-de
vice-blacklist.rules
then create a similar file in /etc/udev/rules.d containing the pid/vid
of your divecomputer
<<<
$ lsusb
Bus 001 Device 014: ID 0403:f460 Future Technology Devices International,
Ltd

with  /etc/udev/rules.d$ cat 50-divecomputer-blacklist.rules
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="f460",
ENV{ID_MM_DEVICE_IGNORE}="1"

and
$ sudo stop modemmanager

No luck.

So to summarize:
1. Adding my user to dialout group did not work
2. stopping  modemmanager did not work
3. Adding a blacklist rule for my device did not work.

Any other ideas to fix this? I tested with windows using the hollis
software and it works.

Thanks
G0bble

On Tue, Jun 18, 2013 at 5:21 PM, Martin Gysel <me at bearsh.org> wrote:

> Am 18.06.2013 13:30, schrieb Jef Driesen:
> > On 2013-06-17 20:22, Dirk Hohndel wrote:
> >> On Mon, 2013-06-17 at 16:24 +0200, Jef Driesen wrote:
> >> On 2013-06-17 15:43, Martin Gysel wrote:
> >> > Am 17.06.2013 14:53, schrieb Gobbledegeek:
> >> > Jun 17 12:44:20 --- modem-manager[891]: <info>  (ttyUSB0) opening
> >> > serial
> >> > port...
> >> > Jun 17 12:44:33 --- modem-manager[891]: <info>  (ttyUSB0) closing
> >> > serial
> >> > port...
> >> > Jun 17 12:44:33 --- modem-manager[891]: <info>  (ttyUSB0) serial port
> >> > closed
> >> > Jun 17 12:44:33 --- modem-manager[891]: <info>  (ttyUSB0) opening
> >> > serial
> >> > port...
> >> > Jun 17 12:44:39 --- modem-manager[891]: <info>  (ttyUSB0) closing
> >> > serial
> >> > port...
> >> > logs
> >> >
> >> > it seems modem-manager thinks you just connected a modem and takes the
> >> > device. you could create an udev rule to blacklist some usb serial
> >> > devices. look at (something like, probably /usr/lib)
> >> > /lib/udev/rules.d/77-mm-usb-device-blacklist.rules
> >> > then create a similar file in /etc/udev/rules.d containing the pid/vid
> >> > of your divecomputer
> >>
> >> I doubt that is the problem. The modem-manager lines are stating opening
> >> AND closing. I guess it's probing for a modem, discovering it's not a
> >> modem, and then closing it again. That's actually the reason why
> >> libdivecomputer opens serial ports with exclusive access. That should
> >> prevent another process (except for those with root permissions) from
> >> messing with the serial port while we're using it. Try accessing the
> >> serial port (e.g. cat /dev/ttyUSB0) while a download is in progress. It
> >> should fail, unless you compiled libdivecomputer with --enable-pty,
> >> which also disables the exclusive access.
> >>
> >> But just in case I'm wrong, you could try to disable modem-manager
> >> somehow. (I have no idea how to do that.)
> >>
> >> I got a debug log from Gobbledegeek, and it contains a huge amount of
> >> packet errors. The device does reply with a NAK response to almost every
> >> single packet. In that case we automatically retry, and that usually
> >> works, until we run out of luck and encounter a fatal error.
> >>
> >> Linus and I have both had loads of problems with modem-manager confusing
> >> the serial communication with dive computers. We both disable / remove
> >> modem-manager on our systems because it certainly causes issues with
> >> Suunto dive computers.
> >>
> >> So that's the first thing I would try.
> >
> > This is the first time I hear about modem-manager related problems. But
> > there is a first time for everything :-)
> >
> > Do you know what the actual problem is with modem-manager?
>
> for me, on one system, modem-manager opened my fdti usb-serial adapter
> exclusively (like you described above). so I could only use it as root
> although I was it the appropriate group to have 'full' access to it.
> modem-manger didn't release the device by its own although it's quite
> obvious it was not a modem (don't know how it try to detect if it's a
> modem or not). the mentioned udev rule worked. I also think
> modem-manager's upstream should add the standard ftdi vid/pid
> combination to its blacklist rule. if there is any modem manufacturer
> using standard vid/pid it should be sledged...
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>

-- 
--G0bbleDeGeek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140522/9245ab10/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface.log.gz
Type: application/x-gzip
Size: 982 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140522/9245ab10/attachment.bin>