Galileo TriMix / IrDA

[William Perry]

Installed fresh copies of Ubuntu 13.04 and Debian 6.x in Parallels 8 and
the latest VirtualBox on MacOS, and no joy.  Very strange.  I think I have
a VMware Fusion license floating around somewhere, will have to see if I
can test there as well.  I can live with using a physical machine for now.
 I don't foresee really logging my dives as anally as I used to once I hit
1000 dives later this summer.


On Wed, May 1, 2013 at 10:53 AM, William Perry <wmperry at gmail.com> wrote:

> I installed Ubuntu on a physical machine last night and it had absolutely
> no problems reading the dives off of the computer using 'universal -b
> smart' -- had to have irattach running to fully plumb everything, but
> everything seems to download.  I will try throwing ubuntu on VirtualBox and
> see if it has the same issues talking to the adapter.
>
> Tried 3 different adapters down at the SCUBA shop yesterday to no avail -
> they all used the mcs7780 chipset and none worked in the linux VM but all
> worked in a Windows 7 VM.  Strange.
>
> -bill
>
> On Tue, Apr 30, 2013 at 2:40 PM, Jef Driesen <jefdriesen at telenet.be>wrote:
>
>> On 30-04-13 14:39, William Perry wrote:
>>
>>> I am looking at switching to Subsurface so that I can just keep a linux
>>> VM
>>> floating around to download dives from my Galileo (Trimix) instead of a
>>> Windows VM and the 'fabulous' SmarTrak software from ScubaPro.  I am
>>> running
>>> this Ubuntu 13.04 VM in Parallels 8 at the moment and am having issues
>>> getting this to download anything at all with a generic mcs7780 USB
>>> adapter.
>>> I expect it is an issue with the low-level IR stack, but the IRDA
>>> documentation leaves a bit to be desired.
>>>
>>
>> You are running Linux in a VM? Maybe that's part of the problem. Usually
>> running in a VM works fine, but in some cases it doesn't. Have you tried on
>> a real machine?
>>
>> Can you send the output of libdivecomputer's smart test app? That might
>> give us a clue where it fails. Does it fail opening the irda socket, during
>> device discovery, or during the actual communication?
>>
>>
>>  The irda0 driver gets loaded successfully and I have modified
>>> /etc/default/irda-utils to set
>>> DEVICE=irda0
>>> AUTOMATIC=true
>>> DISCOVERY=true
>>>
>>> And irattach gets launched successfully when I plug in the USB device,
>>> but it
>>> just spits out this:
>>>
>>> Apr 30 08:20:36 bplinux irattach: Starting device irda0
>>> Apr 30 08:20:36 bplinux irattach: ioctl(SIOCSIFFLAGS): Broken pipe
>>> Apr 30 08:20:36 bplinux irattach: Stopping device irda0
>>> Apr 30 08:20:36 bplinux irattach: exiting …
>>>
>>> And then dies.  'ifconfig -a' shows the irda0 adapter still, and lsusb is
>>> showing the correct chip manufacturer / identifying information: Bus 002
>>> Device 005: ID 9710:7780 MosChip Semiconductor MCS7780 4Mbps Fast IrDA
>>> Adapter
>>>
>>
>> I'm not sure if ifconfig is supposed to show the irda adapter. Maybe your
>> system tries to use the irda adapter as a network interface, and that's why
>> libdivecomputer fails to talk to it?
>>
>> There was a similar report recently (although with another chipset),
>> where the irda interface was used by the usbserial (or ir_usb?) module, and
>> I believe unloading that made it work. As was already pointed out in one of
>> the other replies, you don't need a /dev/ttyUSB0 entry at all.
>>
>>
>>  But I get no joy trying to import from Subsurface, or from a quick test
>>> program I wrote to talk directly to libdivecomputer.  This is actually
>>> the
>>> first time in 20 years of using and developing software on Linux that I
>>> have
>>> tried to get IrDA working.  Am I missing something very basic here?  I
>>> was
>>> able to download the dives into SmarTrak in windows so I don't think I
>>> have a
>>> hardware issue, but the adapter is ~6 years old and has had a few
>>> accidents,
>>> perhaps the windows drivers are a bit more forgiving?
>>>
>>
>> When you say downloading works in Windows, was that recently, or long
>> time ago? On a real machine, or also in a VM?
>>
>> Jef
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130501/00af65d6/attachment.html>