Hollis DG03 data import error

Martin Gysel me at bearsh.org
Tue Jun 18 04:51:07 PDT 2013

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...

More information about the subsurface mailing list