help needed: Android devices and FTDI dive computers

[Bill Perry]

Perhaps a bit late but here is the information for ab
Oceanic data cable, Part # 04.9600 that I use with an Aeris Atmos AI.
It operates at 9600 baud.

Device Info
Device Path: /dev/bus/usb/002/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): Not provided
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: f460
Product Name (reported): Not provided
Product Name (from DB): not found

Additional Info
Interface #0
Class: Vendor Specific (0xff)
Endpoint: #0
Address : 0x81 (10000001)
Number : 1
Direction : Inbound (0x80)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 000000010
Endpoint: #1
Address : 0x02 (000000010)
Number : 2
Direction : Outbound (0x0)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 000000010

I use this data cable with an Aeris Atmos AI (first revision).
There is also an Aeris version of the cable - but I don't have that one. So I'm not sure if the VID/PID is the same.

When the cable is plugged into the phone the System will ask what app to run and Subsurface is one of the choices.
This is true for Galaxy 4 running Android 4.4.4 or Galaxy S7 running Android 8.0.0

Unfortunately, Subsurface mobile does not work with the Aeris Atmos AI. (The desktop version does)
I brought this up last summer.
I tried to submit some patches a year ago but they were delayed. Maybe we can get back to looking at this and getting it fixed?
There were a few issues in the low level data cable initialization but it also appears that their may be some interaction issues with the libusb interface.
These issues are likely to affect more than just the Aeris Atmos AI.

A bit about the early Pelagic data Cables and the potential for Auto device selection.
The Pelagic data cables are not just an FTDI chip with the serial signals running to the dive computer.
There is a PIC microntroller that sits between the FTDI chip and the pins that connect to the dive computer.
The host talks to the PIC through the FTDI chip and the PIC talks to the Dive computer.
The RTS signal resets the PIC.
There are multiple versions of the Pelagic data cables that have different form factors for the physical connection to the Dive computer
and different FW in the PIC. Some cables run at different baud rates between the FTDI chip and the PIC.

The Pelagic dive computers internally use large memory area to hold the configuration information and the dive data that is downloaded.
There is also a fixed area in that memory that holds information about the dive computer.
This includes a dive computer produtct ID that identifies the specific dive computer.
This dive computer product ID  is in a a fixed memory location on all the computers and could read and used to identify the dive computer.

libdivecomputer already knows about these Pelagic dive computer product IDs.
I wanted to use this ID for an auto detect mechanism back when libdivecomputer was very first starting 10 years ago, but Jeff didn't want to go that route.
(Note that It isn't a given that auto detect could always be done)

The tricky part is that different data cables can require using different baud rates to talk to the PIC and use a slightly different cable initialization sequence to initialize the PIC.
While it was a much simpler task back then since there were fewer data cables, I do think it is possible to auto identify at least some of the pelagic divecomputers.
It would require some amount of "guessing" to guess the proper initialization sequence, and do some iterative retries/guessing,
unless there are specific VID/PIDs that correspond to the different cable types.
(I've not looked to that level of detail)

But in the end I'm not sure if auto identifying the specific dive computer is worth it since it is very unlikely to ever be able to work 100% of the time.
I don't know how often users switch between dive computers. If it isn't that often, then as long as the app starts when the cable is plugged in
and simply remembers the last computer used, that might be good enough.

--- bill