Fwd: Re: Fwd: Re: Subsurface-mobile downloadfrom divecomputer

[Anton Lundin]

On 15 February, 2016 - Willem Ferguson wrote:

> 
> 
> On 14/02/2016 23:13, Anton Lundin wrote:
> >On 14 February, 2016 - Willem Ferguson wrote:
> >
> >>Is there a way in android to check for a PID? You can imagine that
> >>the initial step of devising communication will be immensely
> >>complex.
> >A PID is useless without the corresponding VID. We already have code
> >that checks for supported PID/VID's in get_usb_fd(). We would get
> >intents from the system if a PID/VID that we had listed in the manifest
> >would be connected to the device too.
> >
> >I failed to parse the sentence, so please rephrase if you can.
> >
> >
> >//Anton
> >
> >
> I guess I meant: If one connects a dive computer for the first time to
> an Android device, which mechanisms are there within Subsurface to check
> the integrity of the communication between Android and the dive
> computer?

If the app registered interest for a specific PID/VID, the app will get
started via a intent when that device is connected. If you pick that app
to get opened, that app automatically gets permission to talk to that
device.

> I assume this has to be at the OS level, even before one
> contemplates communication between Subsurface and the dive computer. In
> Linux one has at least some facilities e.g dmesg that, amongst others,
> reports valid devices. It is fairly certain that initially the dive
> computer that I will test will NOT communicate with Subsurface. Without
> a more basic way of monitoring the status of the I/O port and the device
> seen on the other side of the port, debugging could be extremely
> difficult. Hope this makes sense?

dmesg is just debug messages. A better way to check connected usb
devices is to use lsusb. You can call android api's to get the same
information as lsusb will tell you.


The only real way to test communication with a device is to actually
talk to that device. Current quite ugly ftdi implementation just checks
if the device string is "ftdi" and then calls into the serial-ftdi code
which looks for ftdi devices, and if it finds one, opens and uses that
one. Current code doesn't give you the opportunity to "pick" device, but
that doesn't really matter, because, how many ftdi devices will you have
connected to your android device when you're trying to download from
your dive computer?


Btw. ftdi isn't the only communication which works on android. Bluetooth
works just fine, becase Qt does all the heavy lifting for us, mapping Qt
Bluetooth api to Android Bluetooth api.


My tip is to play around with the desktop app on your Android device.


//Anton


-- 
Anton Lundin	+46702-161604