help needed: Android devices and FTDI dive computers

[Dirk Hohndel]

I need help from people who have both an Android device, an FTDI dive
computer / download cable, and a way to connect the two (OTG cable for
older phones - for USB C phones this tends to be simply a USB C/A adapter)

Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?

I have access to a single such device, a Heinrichs Weikamp OSTC 3 - and
that presents me with a Product Name of "HeinrichsWeikamp OSTC 3". How
useful, I have code ready that will show the download page with the
correct dive computer selected when you plug in that dive computer. I'd
love to see what other cables / devices give us in information. For
example, I assume that the cables will at best give us a vendor - and
maybe not even that, but since they work for multiple dive computer
models, I doubt that they'll tell us which dive computer is attached.

But without actual test data I'm not sure how far we can push this.

Thanks

/D

[Dietrich Meyer]

Hi Dirk,

not sure if this really helps.
I got a Suunto Vyper2, a noname FTDI cable (not original Suunto, but sourced
from some ebay seller) and a Samsung Galaxy S7 edge with LineageOS 14.1.

Installed "USB Device Info" from F-Droid. Screenshot with device info
attached....

Best,

Dietrich

Post by Dirk Hohndel
I need help from people who have both an Android device, an FTDI dive
computer / download cable, and a way to connect the two (OTG cable for
older phones - for USB C phones this tends to be simply a USB C/A adapter)
Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?
I have access to a single such device, a Heinrichs Weikamp OSTC 3 - and
that presents me with a Product Name of "HeinrichsWeikamp OSTC 3". How
useful, I have code ready that will show the download page with the
correct dive computer selected when you plug in that dive computer. I'd
love to see what other cables / devices give us in information. For
example, I assume that the cables will at best give us a vendor - and
maybe not even that, but since they work for multiple dive computer
models, I doubt that they'll tell us which dive computer is attached.
But without actual test data I'm not sure how far we can push this.
Thanks
/D

[Dirk Hohndel]

Post by Dietrich Meyer
Hi Dirk,
not sure if this really helps.
I got a Suunto Vyper2, a noname FTDI cable (not original Suunto, but sourced
from some ebay seller) and a Samsung Galaxy S7 edge with LineageOS 14.1.
Installed "USB Device Info" from F-Droid. Screenshot with device info
attached....

Thanks - so this is different from the Tusa cable... that one had

Vendor ID: 0403
Vendor Name: FTDI
Product ID: f460
Product Name (reported): TTL232R-3V3

yours shows

Vendor ID: 0403
Vendor Name: Smartinterface
Product ID: 6001
Product Name (reported): USB <-> Serial Cable

It's interesting that they report the official FTDI Vendor ID, but a
different Vendor Name :-)
Which means that I need to make sure that I pick the Vendor ID, not just
the Vendor Name when setting FTDI as connection.

/D

[Linus Torvalds]

Post by Dirk Hohndel
Vendor ID: 0403
Vendor Name: FTDI
Product ID: f460
Product Name (reported): TTL232R-3V3

I have no idea where it got the TTL232R-3V3 from. As mentioned, the
names just come from some user space ID database.

The kernel calls this

#define FTDI_OCEANIC_PID 0xF460 /* Oceanic dive instrument */

Post by Dirk Hohndel
Vendor ID: 0403
Vendor Name: Smartinterface
Product ID: 6001
Product Name (reported): USB <-> Serial Cable

The 0403:6001 vendor:device ID is the "original" FTDI ID. Which is not
surprising, since Dietrich reported it's an ebay seller one. So it
just uses the default FTDI ID.

Post by Dirk Hohndel
It's interesting that they report the official FTDI Vendor ID, but a
different Vendor Name :-)

Again, it's just the database. The reason for that is that not all
vendors have their own "real" USB vendor ID, so they use the chip
vendor ID for the chip, and then asked for an ID for their own use
from the vendor (rather than from the USB SIG).

So the databases of USB ID's will often have a <vendorid,devid>
mapping to a device name, rather than translate the two independently.

The FTDI chips allow both the vendor ID and the device ID to be
reprogrammed using a serial ROM (along with some other default
settings, iirc), so you will *also* find FTDI chips that do *not* have
the FTDI vendor ID. There are atmel devices that used the FTDI chips,
but used their own USB vendor ID etc etc.

The kernel FTDI driver literally has a list of over eight *hundred*
combinations of vendor ID and device ID's for the FTDI driver.

Post by Dirk Hohndel
Which means that I need to make sure that I pick the Vendor ID, not just
the Vendor Name when setting FTDI as connection.

.. again, the strings you see really are entirely meaningless and not
reliable at all.

Even the vendor ID isn't reliable, although in the case of dive
computers, it's possible that they all use the FTDI vendor ID. I find
57 different vendor IDs in the kernel ftdi driver, but none of them
look like dive computers.

Linus

[Chirana Gheorghita Eugeniu Theodor]

I don't think it will help bet here goes
Tusa zen iq900
Usb cable connected to galaxy s9+
Official android 8.0.0
Cable not original is a ttl232r3v3we

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

Additional Info
Interface #0
Class: Vendor Specific (0xff)
Endpoint: #0
Address : 0x81 (10000001 <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

On Aug 8, 2018 19:32, "Dirk Hohndel" <***@hohndel.org> wrote:

I need help from people who have both an Android device, an FTDI dive
computer / download cable, and a way to connect the two (OTG cable for
older phones - for USB C phones this tends to be simply a USB C/A adapter)

Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?

I have access to a single such device, a Heinrichs Weikamp OSTC 3 - and
that presents me with a Product Name of "HeinrichsWeikamp OSTC 3". How
useful, I have code ready that will show the download page with the
correct dive computer selected when you plug in that dive computer. I'd
love to see what other cables / devices give us in information. For
example, I assume that the cables will at best give us a vendor - and
maybe not even that, but since they work for multiple dive computer
models, I doubt that they'll tell us which dive computer is attached.

But without actual test data I'm not sure how far we can push this.

Thanks

/D

[Dirk Hohndel]

Post by Chirana Gheorghita Eugeniu Theodor
I don't think it will help bet here goes

Actually, this does help a lot. It tells me that Tusa didn't modify the
default information for the FTDI TTL232R-3V3 chip that they use.
That's a great data point to have.

Post by Chirana Gheorghita Eugeniu Theodor
Tusa zen iq900
Usb cable connected to galaxy s9+
Official android 8.0.0
Cable not original is a ttl232r3v3we
USB Device Info
Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): FTDI
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: f460
Product Name (reported): TTL232R-3V3
Product Name (from DB): not found

Yep, straight FTDI info. And that's what we may get from most of these
cables. I'm mostly hoping that there are at least a few where we get more.

/D

[Linus Torvalds]

Post by Dirk Hohndel
Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?

Sadly, at least for the Suunto FTDI cases, I don't think you can tell
which dive computer it is.

You can tell it's an official Suunto cable, because it will have a
product ID of 0xf680 (the vendor ID will be 0403 - FTDI). But all the
Suunto cables use the same device ID, afaik - even when they have
different connectors.

And obviously, some people made their own cables instead of paying
Suunto $90 for the silly TFDI chip, so then they'd not going to
necessarily even have that product ID.

End result: I suspect you need to create the mapping based on user
input. Possibly by just going by "last time this device was plugged
in, they picked dive computer XYZ".

Linus

[Dirk Hohndel]

Post by Linus Torvalds

Post by Dirk Hohndel
Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?

Sadly, at least for the Suunto FTDI cases, I don't think you can tell
which dive computer it is.
You can tell it's an official Suunto cable, because it will have a
product ID of 0xf680 (the vendor ID will be 0403 - FTDI). But all the
Suunto cables use the same device ID, afaik - even when they have
different connectors.
And obviously, some people made their own cables instead of paying
Suunto $90 for the silly TFDI chip, so then they'd not going to
necessarily even have that product ID.

Since you have at least one of those cables, would you mind installing the
app and sending me the output? Just so I know which information I can get
from an official Suunto cable?

Post by Linus Torvalds
End result: I suspect you need to create the mapping based on user
input. Possibly by just going by "last time this device was plugged
in, they picked dive computer XYZ".

That is a good point and something I need to add. But I'd also want to at
least pre-select Suunto the first time someone plugs in a Suunto cable.

/D

[Linus Torvalds]

Post by Dirk Hohndel
Since you have at least one of those cables, would you mind installing the
app and sending me the output? Just so I know which information I can get
from an official Suunto cable?

I tried to, but I have once more completely mis-placed my USB-C to A cable.

I have at least four of those things lying around, since we have three
Pixel's in the household and I'm pretty sure they all came with one.
And _last_ time I couldn't find it I ordered one off Amazon.

They are small and I never use them.

I'll try to look around some more.

NOTE! You can *not* rely on whatever product name strings that you get
from various apps. They do not come from the device itself, they come
from a database lookup of the vendor/device ID numbers. And even if
that database is in some system library, it doesn't mean that every
Android device will have the _same_ database.

So for all I know, you might literally get two different names for the
same device on two different phones, just because they have different
Android versions on them.

So you really should only trust the numerical vendor/device ID. That's
what the actual USB device will report.

(Sure, you can also look at other "actual report" details like serial
numbers etc, but USB serial numbers do not tend to be reliable. And
device classes etc will be the same for the same device ID (unless
there's some seriously screwed up devices out there).

Linus

[Dirk Hohndel]

Post by Linus Torvalds

Post by Dirk Hohndel
Since you have at least one of those cables, would you mind installing the
app and sending me the output? Just so I know which information I can get
from an official Suunto cable?

I tried to, but I have once more completely mis-placed my USB-C to A cable.
I have at least four of those things lying around, since we have three
Pixel's in the household and I'm pretty sure they all came with one.
And _last_ time I couldn't find it I ordered one off Amazon.
They are small and I never use them.
I'll try to look around some more.
NOTE! You can *not* rely on whatever product name strings that you get
from various apps. They do not come from the device itself, they come
from a database lookup of the vendor/device ID numbers. And even if
that database is in some system library, it doesn't mean that every
Android device will have the _same_ database.

I believe that to be wrong. As you see in the screenshot posted here,
there's a name from a database, and a name as reported from the device.
Clearly the name "Smartinterface" is not what came from some database for
Vendor ID 0403 - as that is FTDI.

Post by Linus Torvalds
So for all I know, you might literally get two different names for the
same device on two different phones, just because they have different
Android versions on them.

You might be right. I need to spend more time reading the specs to
understand how much of this comes from the USB spec vs interpretation in
Android.

Post by Linus Torvalds
So you really should only trust the numerical vendor/device ID. That's
what the actual USB device will report.

See above. Wouldn't be the first time I'm wrong, won't be the last.

/D

[Linus Torvalds]

Post by Dirk Hohndel
I believe that to be wrong. As you see in the screenshot posted here,
there's a name from a database, and a name as reported from the device.
Clearly the name "Smartinterface" is not what came from some database for
Vendor ID 0403 - as that is FTDI.

So the USB spec does have the _possibility_ of USB devices returning
strings. But you generally shouldn't rely on them either, because many
don't, or they are "fake".

See

https://www.beyondlogic.org/usbnutshell/usb5.shtml#StringDescriptors

for some commentary about the string descriptors. Note the "human
readable information and are optional".

But if you care, the strings the Suunto returns are

Suunto
Suunto Sports Instrument

for the Product and Manufacturer strings respectively.

But again, the vendor ID/device ID is the actually _identifying_ data.
And not all devices will even have the string data at all.

(Although it's possible that in practice, the dive computer interfaces
end up having them, although they might be fairly random).

Linus

[Dirk Hohndel]

Post by Linus Torvalds

Post by Dirk Hohndel
I believe that to be wrong. As you see in the screenshot posted here,
there's a name from a database, and a name as reported from the device.
Clearly the name "Smartinterface" is not what came from some database for
Vendor ID 0403 - as that is FTDI.

So the USB spec does have the _possibility_ of USB devices returning
strings. But you generally shouldn't rely on them either, because many
don't, or they are "fake".
See
https://www.beyondlogic.org/usbnutshell/usb5.shtml#StringDescriptors

Yes, that matches my recollection.

Post by Linus Torvalds
for some commentary about the string descriptors. Note the "human
readable information and are optional".

To recap my point... my goal is to build a mapping that says "if we see
this string for the first time, we happen to know that it's a good guess
that this is the following device or at least following vendor" and to
populate the combo boxes accordingly.

And your idea that you suggested to then remember what the user actually
used will make this even better.

Nothing I am proposing implies that we /rely/ on this information or that
the user can'r override it in case it's wrong. I'm simply saying "hey, if
someone plugs in an OSTC 3 and if we see "HeinrichsWeikamp OSTC 3" as name
then we really can make this easier for the user by automatically picking
the right settings.

Post by Linus Torvalds
But if you care, the strings the Suunto returns are
Suunto
Suunto Sports Instrument

Thanks. So if we see this the first time, it seems reasonable to populate
the Vendor combobox with Suunto and leave the product empty. And if you
then select "Vyper Air" and download from it, we could remember that and
offer this by default the next time we see this cable (or a cable that
identifies itself like this). This means for the user with two different
Suunto computers we will potentially pre-populate the wrong product. But
they can always simply correct that.

Post by Linus Torvalds
But again, the vendor ID/device ID is the actually _identifying_ data.
And not all devices will even have the string data at all.

Correct. I'm ok with that. What I'm wondering is if some dive computers
might report the FTDI vendor ID but have a custom string that helps us to
a more educated guess. And maybe this will all turn out to be wrong or
useless in most cases. But I think it's worth collecting data and trying
to figure out if there is value there...

Post by Linus Torvalds
(Although it's possible that in practice, the dive computer interfaces
end up having them, although they might be fairly random).

That's what I'm trying to find out :-)

/D

[Matt Thompson]

Post by Dirk Hohndel
I need help from people who have both an Android device, an FTDI dive
computer / download cable, and a way to connect the two (OTG cable for
older phones - for USB C phones this tends to be simply a USB C/A adapter)
Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?
This is a Suunto D4i with the official Suunto cable.

Device Info
Device Path: /dev/bus/usb/001/009
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): Suunto
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: f680
Product Name (reported): Suunto Sports Instrument
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

[Matt Thompson]

Device Info
Device Path: /dev/bus/usb/001/003
Device Class: Diagnostics Device (0xdc)
Vendor ID: 0471
Vendor Name (reported): ATOMIC AQUATICS
Vendor Name (from DB): Philips (or NXP)
Product ID: 0888
Product Name (reported): COBALT
Product Name (from DB): not found

Additional Info
Interface #0
Class: Diagnostics Device (0xdc)
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
Endpoint: #2
Address : 0x82 (10000010)
Number : 2
Direction : Inbound (0x80)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 000000010

[Dirk Hohndel]

Once again, this was written without being able to test the code as I
didn't take any dive computers (or the old phone that allows access to
/sys) with me on this business trip... based on Matt's test of an earlier
version I am, however, hopeful that this might be going in the right
direction.

Here's what I'd like people to try - even if you only have an Android
device that currently doesn't allow us to download via USB OTG! We won't
try to download, we just want to see if the automation for picking the
right vendor / product / connection is working as intended...

Download the latest test build
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.156-arm.apk

Start Subsurface-mobile (I need to poke at this a little more in order for
it to work correctly when Subsurface-mobile gets started because you
plugged in a dive computer)

Once Subsurface-mobile is running, plug in your dive computer. Android
should ask you if you want to connect the device with Subsurface-mobile.
If it doesn't ask, I want to know more about your dive computer and cable
in order to be able to fix this. Right now I think it should ask for all
the dive computers referenced in the Subject line of this email.

Once you accept the request, Subsurface-mobile should switch to the
Download page, and depending on your specific situation, some / most / all
of the information for the three comboboxes should be filled in.

Please note which options were selected for vendor / product / connection

Now go to the About page, copy the logs and send all the information
(which dive computer, which cable, did this all work, which v/p/c was
selected when the download page opened) plus of course the logs to the
mailing list.

I'd love to see the information we can get from the various USB based OSTC
dive computers (maybe Matthias can help there?). And also for any other
dive computer that you happen to have a cable for.


Thanks, I really appreciate the help :-)

/D

PS: and now, of course, I hope I didn't mess up something stupid, everyong
tries and nothing works at all...

[Matt Thompson]

Post by Dirk Hohndel
Here's what I'd like people to try - even if you only have an Android
device that currently doesn't allow us to download via USB OTG! We won't
try to download, we just want to see if the automation for picking the
right vendor / product / connection is working as intended...
Auto launched Subsurface mobile with both the Cobalt 2 and Suunto D4i. If

Subsurface was not already running it did not switch to the download page
automatically. If Subsurface was open or running in the background it did
automatically pull up the download page and fill in details. Cobalt 2 was
completely ready to go. Suunto only had the manufacturer selected
(probably all we can hope for based on the cable implementation.)

Very cool!

i750TC did not ask about which app to use when I plugged it in. Info sent
on the other thread.

Post by Dirk Hohndel
PS: and now, of course, I hope I didn't mess up something stupid, everyong
tries and nothing works at all...

Looks at least basically sane.

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Dirk Hohndel
Here's what I'd like people to try - even if you only have an Android
device that currently doesn't allow us to download via USB OTG! We won't
try to download, we just want to see if the automation for picking the
right vendor / product / connection is working as intended...

Auto launched Subsurface mobile with both the Cobalt 2 and Suunto D4i. If
Subsurface was not already running it did not switch to the download page
automatically.

Correct. There is some code missing that I still need to write. When
Subsurface-mobile is launched by the Intent (i.e., by Android detecting a
USB devie we have registered our interest in) we need to wait until the
app is fully launched and ready before we try to open the download page.

So this is a known issue and will be addressed. Once I find the time to
work on it :-)

Post by Dirk Hohndel
If Subsurface was open or running in the background it did
automatically pull up the download page and fill in details. Cobalt 2 was
completely ready to go. Suunto only had the manufacturer selected
(probably all we can hope for based on the cable implementation.)

Thanks for the confirmation that this works as I had hoped.

Post by Dirk Hohndel
i750TC did not ask about which app to use when I plugged it in. Info sent
on the other thread.

Yes, that will be fixed in the next build.

/D

[Anton Lundin]

Nice work Dirk.

I'll dump some data from my devices when I get back home.

I'd love to see parts of this feature ported to the desktop ui to. On Linux we can dig out info about ftdi devices from sysfs, and we might be able to do something equivalent on windows and Mac.

//Anton - sorry for the top post, on my cell

Post by Dirk Hohndel
Once again, this was written without being able to test the code as I
didn't take any dive computers (or the old phone that allows access to
/sys) with me on this business trip... based on Matt's test of an earlier
version I am, however, hopeful that this might be going in the right
direction.
Here's what I'd like people to try - even if you only have an Android
device that currently doesn't allow us to download via USB OTG! We won't
try to download, we just want to see if the automation for picking the
right vendor / product / connection is working as intended...
Download the latest test build
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.156-arm.apk
Start Subsurface-mobile (I need to poke at this a little more in order for
it to work correctly when Subsurface-mobile gets started because you
plugged in a dive computer)
Once Subsurface-mobile is running, plug in your dive computer. Android
should ask you if you want to connect the device with
Subsurface-mobile.
If it doesn't ask, I want to know more about your dive computer and cable
in order to be able to fix this. Right now I think it should ask for all
the dive computers referenced in the Subject line of this email.
Once you accept the request, Subsurface-mobile should switch to the
Download page, and depending on your specific situation, some / most / all
of the information for the three comboboxes should be filled in.
Please note which options were selected for vendor / product /
connection
Now go to the About page, copy the logs and send all the information
(which dive computer, which cable, did this all work, which v/p/c was
selected when the download page opened) plus of course the logs to the
mailing list.
I'd love to see the information we can get from the various USB based OSTC
dive computers (maybe Matthias can help there?). And also for any other
dive computer that you happen to have a cable for.
Thanks, I really appreciate the help :-)
/D
PS: and now, of course, I hope I didn't mess up something stupid, everyong
tries and nothing works at all...
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[Matt Thompson]

Don't know why I didn't think to send this earlier with the other two but
here is the USB info for the Aqualung i750TC using the standard Aqualung
connector.

Device Info
Device Path: /dev/bus/usb/001/005
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): FTDI
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6015
Product Name (reported): FT231X USB UART
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

Looks like we don't have this one working for download at all just yet in
mobile. I was able to select everything but downloads fail. Logs follow.

---------- subsurface.log ----------
Empty filename passed to function
"0.003: Failed to open logfile /storage/emulated/0/subsurface.log at Wed
Aug 8 23:39:31 2018 error: Permission denied"
"0.003: Failed to open logfile /storage/emulated/0/Documents/subsurface.log
at Wed Aug 8 23:39:31 2018 error: Permission denied"
"0.003: Successfully opened logfile
/storage/emulated/0/Android/data/org.subsurfacedivelog.mobile/files/Documents/subsurface.log
at Wed Aug 8 23:39:31 2018"
"0.004: Starting Subsurface-mobile:[phone]):Android
(8.1):arm:en-US"
"0.004: built with libdivecomputer v0.7.0-devel-Subsurface-NG
(bb985eedbb3e686e5a71bf2aa234fb49f8cab653)"
"0.004: built with Qt Version 5.11.1, runtime from Qt Version 5.11.1"
"0.004: built with libgit2 0.26.0"
localBtDevice isn't valid or not connectable
"Created position source android"
"0.011: Created position source android"
"Set GPS service update interval to 300 s"
"0.011: Set GPS service update interval to 300 s"
"0.016: location service is available"
"0.370: Synchronising data file"
"0.372: Load dives from local cache"
"0.481: Successfully opened dive data"
"0.502: AppState changed to active with save ongoing and no unsaved changes"
"0.504: 321 dives loaded from cache"
"0.505: have cloud credentials, trying to connect"
"0.505: Have credentials, let's see if they are valid"
Completed connection with cloud storage backend, response "[OK]"
"Set GPS service update interval to 300 s"
"1.134: Set GPS service update interval to 300 s"
Using the following font: Roboto
qqwindow devicePixelRatio 2.62613 2.62613
Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL, BT)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Cressi: Drake (SERIAL), Giotto (SERIAL), Leonardo (SERIAL), Newton
(SERIAL)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL, BLE), Quad (SERIAL, BLE), Quad Air (SERIAL, BLE),
Smart (SERIAL, BLE)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tecdiving: DiveComputer.eu (SERIAL, BT)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 71.9691 153.059
"2.596: Synchronising data file"
"2.607: Sync with cloud storage"
"2.977: Successful cloud connection, fetch remote"
"3.375: Done syncing with cloud storage"
"3.391: Cloud sync shows local cache was current"
"19.780: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"19.795: Unsupported operation"
no new dives downloaded
"19.821: DCDownloadThread finished"
"32.229: AppState changed to inactive with no save ongoing and no unsaved
changes"
"32.245: AppState changed to suspended with no save ongoing and no unsaved
changes"
"43.814: AppState changed to active with no save ongoing and no unsaved
changes"
The item DownloadFromDiveComputer_QMLTYPE_111(0xc9391ee0) is already in the
PageRow
"52.849: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"52.866: Unsupported operation"
no new dives downloaded
"52.869: DCDownloadThread finished"
"56.167: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"56.178: Unsupported operation"
no new dives downloaded
"56.179: DCDownloadThread finished"
"56.768: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"56.777: Unsupported operation"
no new dives downloaded
"56.779: DCDownloadThread finished"
"57.288: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"57.303: Unsupported operation"
no new dives downloaded
"57.305: DCDownloadThread finished"
localBtDevice isn't valid or not connectable
"59.812: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"59.828: Unsupported operation"
no new dives downloaded
"59.833: DCDownloadThread finished"
"63.695: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"63.710: Unsupported operation"
no new dives downloaded
"63.713: DCDownloadThread finished"
"64.830: AppState changed to inactive with no save ongoing and no unsaved
changes"
"64.848: AppState changed to suspended with no save ongoing and no unsaved
changes"
"304.109: AppState changed to active with no save ongoing and no unsaved
changes"
"307.815: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"307.833: Unsupported operation"
no new dives downloaded
"307.835: DCDownloadThread finished"
"310.524: DCDownloadThread started for Aqualung i750TC on ftdi"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"310.541: Unsupported operation"
no new dives downloaded
"310.543: DCDownloadThread finished"



---------- libdivecomputer.log ----------
Subsurface: v4.8.1-156-g23b7970459b6, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (bb985eedbb3e686e5a71bf2aa234fb49f8cab653)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

[Dirk Hohndel]

Post by Matt Thompson
Don't know why I didn't think to send this earlier with the other two but
here is the USB info for the Aqualung i750TC using the standard Aqualung
connector.

Nice

Post by Matt Thompson
Device Info
Device Path: /dev/bus/usb/001/005
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): FTDI
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6015
Product Name (reported): FT231X USB UART
Product Name (from DB): not found

So this appears to be a Product ID for FTDI that we hadn't seen before.
It's unclear, of course, if this is Aqualung specific or just another
generic one.

I'll add this to the ones we recognize, but for now without making it
pre-select Aqualung.

Post by Matt Thompson
Looks like we don't have this one working for download at all just yet in
mobile. I was able to select everything but downloads fail. Logs follow.

I'm adding this to my branch right now.

Post by Matt Thompson
---------- subsurface.log ----------
"19.780: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"19.795: Unsupported operation"
no new dives downloaded
"19.821: DCDownloadThread finished"
---------- libdivecomputer.log ----------
Subsurface: v4.8.1-156-g23b7970459b6, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (bb985eedbb3e686e5a71bf2aa234fb49f8cab653)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

This might be a sign that your phone doesn't allow access to '/sys' as a
"security precaution" and that currently breaks our ability to download
via FTDI.

/D

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Matt Thompson
---------- subsurface.log ----------
"19.780: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"19.795: Unsupported operation"
no new dives downloaded
"19.821: DCDownloadThread finished"
---------- libdivecomputer.log ----------
Subsurface: v4.8.1-156-g23b7970459b6, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (bb985eedbb3e686e5a71bf2aa234fb49f8cab653)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

This might be a sign that your phone doesn't allow access to '/sys' as a
"security precaution" and that currently breaks our ability to download
via FTDI.

Actually, since you are able to do Cobalt downloads on that phone... I'm
not sure this is true. That should run into the same libusb problems, I
think...

/D

[Matt Thompson]

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Matt Thompson
---------- subsurface.log ----------
"19.780: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"19.795: Unsupported operation"
no new dives downloaded
"19.821: DCDownloadThread finished"
---------- libdivecomputer.log ----------
Subsurface: v4.8.1-156-g23b7970459b6, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (bb985eedbb3e686e5a71bf2aa234fb49f8cab653)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

This might be a sign that your phone doesn't allow access to '/sys' as a
"security precaution" and that currently breaks our ability to download
via FTDI.

Actually, since you are able to do Cobalt downloads on that phone... I'm
not sure this is true. That should run into the same libusb problems, I
think...

I was able to download from my D4i as well so I'm not sure what's going on
with the 750.

[Dirk Hohndel]

Post by Matt Thompson
I was able to download from my D4i as well so I'm not sure what's going on
with the 750.

Well, since I am on a run having you test completely untested code...
here's one that's even more untested...

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.161-arm.apk

This tries to
a) get your i750TC recognized (not sure if that will help with download)
b) switch to the Download page even if Subsurface-mobile wasn't running
when you plugged in your device

So far I can tell you "it compiles". I might have completely broken things
and nothing might work anymore... but if you happen to have a moment, I'd
appreciate more testing :-)

/D

[Matt Thompson]

Post by Dirk Hohndel

Post by Matt Thompson
I was able to download from my D4i as well so I'm not sure what's going

on

Post by Matt Thompson
with the 750.

Well, since I am on a run having you test completely untested code...
here's one that's even more untested...

You caught me working from home for a few days so I have ready access to my
dive computers. :D

Post by Dirk Hohndel
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.161-arm.apk
This tries to
a) get your i750TC recognized (not sure if that will help with download)
b) switch to the Download page even if Subsurface-mobile wasn't running
when you plugged in your device
So far I can tell you "it compiles". I might have completely broken things
and nothing might work anymore... but if you happen to have a moment, I'd
appreciate more testing :-)
/D

It was a good run but not much success this time.

For some reason Subsurface still does not pop up as an option when I plug
in the i750. Also, Subsurface does not switch to the download page
automatically with either of my other two computers even if the app is
currently running so a bit of a regression. Downloading does still work
from the Cobalt and the D4i but does not work for the i750. Logs from the
failed i750 attempt are below.

---------- subsurface.log ----------
Empty filename passed to function
"0.003: Failed to open logfile /storage/emulated/0/subsurface.log at Thu
Aug 9 10:35:15 2018 error: Permission denied"
"0.003: Failed to open logfile /storage/emulated/0/Documents/subsurface.log
at Thu Aug 9 10:35:15 2018 error: Permission denied"
"0.003: Successfully opened logfile
/storage/emulated/0/Android/data/org.subsurfacedivelog.mobile/files/Documents/subsurface.log
at Thu Aug 9 10:35:15 2018"
"0.004: Starting Subsurface-mobile:[phone]):Android
(8.1):arm:en-US"
"0.004: built with libdivecomputer v0.7.0-devel-Subsurface-NG
(bb985eedbb3e686e5a71bf2aa234fb49f8cab653)"
"0.004: built with Qt Version 5.11.1, runtime from Qt Version 5.11.1"
"0.004: built with libgit2 0.26.0"
localBtDevice isn't valid or not connectable
"Created position source android"
"0.010: Created position source android"
"Set GPS service update interval to 300 s"
"0.011: Set GPS service update interval to 300 s"
"0.015: location service is available"
"0.374: Synchronising data file"
"0.376: Load dives from local cache"
"0.484: Successfully opened dive data"
"0.506: AppState changed to active with save ongoing and no unsaved changes"
"0.508: 321 dives loaded from cache"
"0.509: have cloud credentials, trying to connect"
"0.509: Have credentials, let's see if they are valid"
Completed connection with cloud storage backend, response "[OK]"
"Set GPS service update interval to 300 s"
"0.994: Set GPS service update interval to 300 s"
checkPendingIntents
Using the following font: Roboto
qqwindow devicePixelRatio 2.62613 2.62613
Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL, BT)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Cressi: Drake (SERIAL), Giotto (SERIAL), Leonardo (SERIAL), Newton
(SERIAL)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL, BLE), Quad (SERIAL, BLE), Quad Air (SERIAL, BLE),
Smart (SERIAL, BLE)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tecdiving: DiveComputer.eu (SERIAL, BT)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 71.9691 153.059
"2.230: Synchronising data file"
"2.240: Sync with cloud storage"
"2.642: Successful cloud connection, fetch remote"
"3.050: Done syncing with cloud storage"
"3.064: Cloud sync shows local cache was current"
"13.754: DCDownloadThread started for Aqualung i750TC on "
Starting download from BT
connecting to Uuid "{00001101-0000-1000-8000-00805f9b34fb}"
connectToService() "00:00:00:00:00:00"
"{00001101-0000-1000-8000-00805f9b34fb}"
Connnecting via insecure rfcomm
Connecting socket
The connection step took more than expected. Wait another 20 seconds
Falling back to reverse uuid workaround.
Workaround failed
Failed to connect to device . Device state
QBluetoothSocket::UnconnectedState . Error:
QBluetoothSocket::ServiceNotFoundError
"18.914: Unsupported operation"
Finishing download thread: "Unable to open Aqualung (i750TC)"
no new dives downloaded
"18.952: DCDownloadThread finished"
"22.782: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
"22.786: Unsupported operation"
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
no new dives downloaded
"22.815: DCDownloadThread finished"



---------- libdivecomputer.log ----------
Subsurface: v4.8.1-161-ga73d7352e680, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (bb985eedbb3e686e5a71bf2aa234fb49f8cab653)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

[Dirk Hohndel]

Post by Matt Thompson

Post by Dirk Hohndel
Well, since I am on a run having you test completely untested code...
here's one that's even more untested...

You caught me working from home for a few days so I have ready access to my
dive computers. :D

He. I work from home a lot. But not this week (well, back home tonight).

Post by Matt Thompson
It was a good run but not much success this time.

Drat.

Post by Matt Thompson
For some reason Subsurface still does not pop up as an option when I plug
in the i750. Also, Subsurface does not switch to the download page
automatically with either of my other two computers even if the app is
currently running so a bit of a regression. Downloading does still work
from the Cobalt and the D4i but does not work for the i750. Logs from the
failed i750 attempt are below.

I was afraid that we'd regress on the switching to download page...
changing Java code always has me extra nervous.

Post by Matt Thompson
"0.508: 321 dives loaded from cache"
"0.509: have cloud credentials, trying to connect"
"0.509: Have credentials, let's see if they are valid"
Completed connection with cloud storage backend, response "[OK]"
"Set GPS service update interval to 300 s"
"0.994: Set GPS service update interval to 300 s"
checkPendingIntents

THIS should be when we process the intent that caused us to open the app.
So the code is run, it's just not doing what I thought it would do :-/

Post by Matt Thompson
"3.064: Cloud sync shows local cache was current"
"13.754: DCDownloadThread started for Aqualung i750TC on "
Starting download from BT
connecting to Uuid "{00001101-0000-1000-8000-00805f9b34fb}"
connectToService() "00:00:00:00:00:00"
"{00001101-0000-1000-8000-00805f9b34fb}"

It's using BT. What happens if you pick FTDI for download?

Oh, and I don't understand why you weren't asked to open Subsurface-mobile
when you plugged it in. Is there a typo in my code? Can you again send me
the data from USB Device Info for that cable?

Thanks

/D

[Matt Thompson]

Post by Dirk Hohndel
I was afraid that we'd regress on the switching to download page...
changing Java code always has me extra nervous.

Post by Matt Thompson
"0.508: 321 dives loaded from cache"
"0.509: have cloud credentials, trying to connect"
"0.509: Have credentials, let's see if they are valid"
Completed connection with cloud storage backend, response "[OK]"
"Set GPS service update interval to 300 s"
"0.994: Set GPS service update interval to 300 s"
checkPendingIntents

THIS should be when we process the intent that caused us to open the app.
So the code is run, it's just not doing what I thought it would do :-/
It's using BT. What happens if you pick FTDI for download?

"22.782: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
"22.786: Unsupported operation"
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
no new dives downloaded
"22.815: DCDownloadThread finished"

The Unsupported operation seems relevant...

Oh, and I don't understand why you weren't asked to open Subsurface-mobile

Post by Dirk Hohndel
when you plugged it in. Is there a typo in my code? Can you again send me
the data from USB Device Info for that cable?

Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): FTDI
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6015
Product Name (reported): FT231X USB UART
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

[Dirk Hohndel]

Post by Matt Thompson
"22.782: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
"22.786: Unsupported operation"
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
no new dives downloaded
"22.815: DCDownloadThread finished"
The Unsupported operation seems relevant...

We need better debug messages from this code :-(

Post by Matt Thompson

Post by Dirk Hohndel
Oh, and I don't understand why you weren't asked to open Subsurface-mobile
when you plugged it in. Is there a typo in my code? Can you again send me
the data from USB Device Info for that cable?

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

So that's 1027/24597

+ <usb-device vendor-id="1027" product-id="24597"/>

Which is why I don't understand why the page didn't open...

/D

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Dirk Hohndel
Oh, and I don't understand why you weren't asked to open Subsurface-mobile
when you plugged it in. Is there a typo in my code? Can you again send me
the data from USB Device Info for that cable?

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

So that's 1027/24597
+ <usb-device vendor-id="1027" product-id="24597"/>
Which is why I don't understand why the page didn't open...

I looked through your log again. You were running .161 which should have
exactly that line in it's device-filter.xml in the sources.
But then I unpack the .apk and see that the device-filter.xml in there is
the old one.

ARG. android/res vs. android-mobile/res

Fixed. I hope. New binary is up:

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.162-arm.apk

/D

[Matt Thompson]

Post by Dirk Hohndel
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.162-arm.apk
/D

That's got the intents working.

[Dirk Hohndel]

Post by Matt Thompson
That's got the intents working.

Matt, I have to say this. Thank you so much for your help this week.
It is so much fun to poke at things like this if there's someone out there
to work with, who tests, reports, responds.

People constantly underestimate how much the community of testers matters
in projects like Subsurface.

Thank you. Your help means a lot to me.

/D

[Matt Thompson]

Post by Dirk Hohndel
Thank you. Your help means a lot to me.
Sure thing. I'm glad I have finally found a way and time to contribute a

bit. I never have quite managed to get a development environment set up.
I usually run out of time fiddling with Qt versions and such. But I'm
happy to help test.

I'll be on the road this weekend so I won't be testing but I'll be sure to
check in next week.

[Thomas Fänge]

Hi Dirk,

Connected my Mares Dive Link cable to my Sony Xperia XZ2 Compact (using a
USB-C OTG cable), and the USB Device Info app said the following:

Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 10c4
Vendor Name (reported): Silicon Labs
Vendor Name (from DB): Cygnal Integrated Products, Inc.
Product ID: ea60
Product Name (reported): CP2109 USB to UART Bridge Controller

Product Name (from DB): not found

Additional Info
Interface #0
Class: Vendor Specific (0xff)
Endpoint: #0

Address : 0x01 (00000001)
Number : 1


Direction : Outbound (0x0)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 000000010

Endpoint: #1


Address : 0x82 (10000010)
Number : 2
Direction : Inbound (0x80)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 000000010


Note that the Subsurface App didn't automatically start when cable was
connected (but eg. the DiveMate app does if it is installed).

Best regards,
Thomas

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Dirk Hohndel
Oh, and I don't understand why you weren't asked to open

Subsurface-mobile

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Dirk Hohndel
when you plugged it in. Is there a typo in my code? Can you again

send me

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Dirk Hohndel
the data from USB Device Info for that cable?

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

So that's 1027/24597
+ <usb-device vendor-id="1027" product-id="24597"/>
Which is why I don't understand why the page didn't open...

I looked through your log again. You were running .161 which should have
exactly that line in it's device-filter.xml in the sources.
But then I unpack the .apk and see that the device-filter.xml in there is
the old one.
ARG. android/res vs. android-mobile/res
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.162-arm.apk
/D
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[Dirk Hohndel]

Thanks Thomas.

The Mares family of dive computers use a Silicon Labs cable, and sadly I haven't found a user space driver for that.
So with our current approach, we cannot download from those on Android.

The data, however, are useful and great to have for future reference. So much appreciated.

/D

Post by Dietrich Meyer
Hi Dirk,
Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 10c4
Vendor Name (reported): Silicon Labs
Vendor Name (from DB): Cygnal Integrated Products, Inc.
Product ID: ea60
Product Name (reported): CP2109 USB to UART Bridge Controller
Product Name (from DB): not found

[Dirk Hohndel]

The one group that I hoped we'd get a few more entries for are the serial OSTC dive computers.
In the past we had quite a few users of those on this mailing list - if you have one, and an Android
phone, I'd love to get the information that Subsurface sees when you connect it.

With the latest versions this has become easier - just plug in your dive computer (with the USB C/A
adapter that came with your phone if you have a new USB C based phone, or with an OTG adapter
if you have an older, micro-USB based phone), it should start Subsurface, and then go to About, copy
the logs and send them to us.

The same applies for all the Aeris, Oceanic, Scubapro, Cressi, and Suunto dive computers, btw.

The whole thing shouldn't take more than a couple of minutes (not including the time to find the
adapter, of course) :-)

Thanks, your help is really appreciated.

/D

[Salvador Cuñat]

Hi Dirk.

Post by Dirk Hohndel
The same applies for all the Aeris, Oceanic, Scubapro, Cressi, and Suunto
dive computers, btw.
Attached files come from an Oceanic VTX device on an Android 8.1.0 phone.

I have an OSTC 2N but Anton has posted the data in the other thread.

Best regards.

Salva.

[Dirk Hohndel]

Hi Salvador.

This is strange. So it shows that you were using .166 which is the one
that should have recognized the productID that is shown in the screen
shot. Yet the log shows no sign that it ever saw the Android Intent when
you plugged it in.

Does it start a different application when you plug it in? What does your
phone do when you plug the VTX into it?

Because I thought that this would work now and your logs confuse me :-(

/D

[Salvador Cuñat]

Hi Dirk

Post by Dirk Hohndel
Does it start a different application when you plug it in? What does your
phone do when you plug the VTX into it?

No, it doesn't.
OSTC 2N does although can't download on my phone. But VTX does nothing.
The cable I'm using is the same which works fine on desktop Subsurface.

I'll try to get a logcat tomorrow if you think it can help.

Best regards.
Salva.

[Dirk Hohndel]

Post by Dietrich Meyer
Hi Dirk

Post by Dirk Hohndel
Does it start a different application when you plug it in? What does your
phone do when you plug the VTX into it?

No, it doesn't.

What does the phone do when you plug the VTX into it? Nothing at all?
Does it show any dialog?

Post by Dietrich Meyer
OSTC 2N does although can't download on my phone. But VTX does nothing.
The cable I'm using is the same which works fine on desktop Subsurface.

Do you have to switch the VTX into some special download mode maybe?

Post by Dietrich Meyer
I'll try to get a logcat tomorrow if you think it can help.

Yes, I think it would

Thanks

/D

[Salvador Cuñat]

Post by Dirk Hohndel

Post by Dietrich Meyer
Hi Dirk

Post by Dirk Hohndel
Does it start a different application when you plug it in? What does

your

Post by Dietrich Meyer

Post by Dirk Hohndel
phone do when you plug the VTX into it?

No, it doesn't.

What does the phone do when you plug the VTX into it? Nothing at all?
Does it show any dialog?

Ok. I was wrong , the phone shows the classic dialog offering to open
Subsurface as default app. It showed after uninstalling the appstore
version and reinstalling -166. May be I said "no" in the past and Android
remembered it.

Post by Dirk Hohndel
Do you have to switch the VTX into some special download mode maybe?

Not needed in this divecomputer. The connection is detected and it enters
the mode.

Post by Dirk Hohndel
I'll try to get a logcat tomorrow if you think it can help.

Attached logcat files for VTX and OSTC2N, plus subsurface and
libdivecomputer logs.

Best regards.

Salva.

[Linus Torvalds]

Post by Dirk Hohndel

Post by Chirana Gheorghita Eugeniu Theodor
Vendor ID: 0403
Product ID: 6015

So this appears to be a Product ID for FTDI that we hadn't seen before.
It's unclear, of course, if this is Aqualung specific or just another
generic one.

It's just a generic one, nothing Aqualung-specific, I'm afraid.\

Linus

[Matt Thompson]

On Thu, Aug 9, 2018 at 11:54 AM Linus Torvalds <

Post by Linus Torvalds

Post by Dirk Hohndel

Post by Chirana Gheorghita Eugeniu Theodor
Vendor ID: 0403
Product ID: 6015

So this appears to be a Product ID for FTDI that we hadn't seen before.
It's unclear, of course, if this is Aqualung specific or just another
generic one.

It's just a generic one, nothing Aqualung-specific, I'm afraid.\

I suspect the Oceanic VTX and Aeris A300 probably use exactly the same
connector/cable as they are all cousins.

[Anton Lundin]

Post by Matt Thompson

Post by Matt Thompson
Don't know why I didn't think to send this earlier with the other two

but

Post by Matt Thompson
here is the USB info for the Aqualung i750TC using the standard

Aqualung

Post by Matt Thompson
connector.

Nice

Post by Matt Thompson
Device Info
Device Path: /dev/bus/usb/001/005
Device Class: Use class information in the Interface Descriptors

(0x0)

Post by Matt Thompson
Vendor ID: 0403
Vendor Name (reported): FTDI
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6015
Product Name (reported): FT231X USB UART
Product Name (from DB): not found

So this appears to be a Product ID for FTDI that we hadn't seen before.
It's unclear, of course, if this is Aqualung specific or just another
generic one.
I'll add this to the ones we recognize, but for now without making it
pre-select Aqualung.

Post by Matt Thompson
Looks like we don't have this one working for download at all just

yet in

Post by Matt Thompson
mobile. I was able to select everything but downloads fail. Logs

follow.
I'm adding this to my branch right now.

Post by Matt Thompson
---------- subsurface.log ----------
"19.780: DCDownloadThread started for Aqualung i750TC on FTDI"
Starting download from ftdi
Finishing download thread: "Unable to open ftdi Aqualung (i750TC)"
"19.795: Unsupported operation"
no new dives downloaded
"19.821: DCDownloadThread finished"
---------- libdivecomputer.log ----------
Subsurface: v4.8.1-156-g23b7970459b6, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (bb985eedbb3e686e5a71bf2aa234fb49f8cab653)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

This might be a sign that your phone doesn't allow access to '/sys' as a
"security precaution" and that currently breaks our ability to download
via FTDI.

I'd rather say that we don't have this pid listed in serial_ftdi.c

//Anton

[Dirk Hohndel]

Post by Anton Lundin
I'd rather say that we don't have this pid listed in serial_ftdi.c

You are of course correct.

The fact that everywhere else we use the decimal value of VID/PID, but in
that file we use hex really doesn't make it easier to find what could be wrong
when you are searching for it.

I'll fix that and build a new test binary

/D

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Anton Lundin
I'd rather say that we don't have this pid listed in serial_ftdi.c

You are of course correct.
The fact that everywhere else we use the decimal value of VID/PID, but in
that file we use hex really doesn't make it easier to find what could be wrong
when you are searching for it.
I'll fix that and build a new test binary

And that is up. Matt, if you aren't tired of trying by now, this might support
the i750TC over FTDI

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.166-arm.apk

/D

[Matt Thompson]

Post by Dirk Hohndel

Post by Dirk Hohndel

Post by Anton Lundin
I'd rather say that we don't have this pid listed in serial_ftdi.c

You are of course correct.
The fact that everywhere else we use the decimal value of VID/PID, but

in

Post by Dirk Hohndel
that file we use hex really doesn't make it easier to find what could be

wrong

Post by Dirk Hohndel
when you are searching for it.
I'll fix that and build a new test binary

And that is up. Matt, if you aren't tired of trying by now, this might support
the i750TC over FTDI
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.166-arm.apk
/D

I'll give it a shot tomorrow when I am back home.

[Matt Thompson]

Post by Dirk Hohndel
And that is up. Matt, if you aren't tired of trying by now, this might support
the i750TC over FTDI
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.166-arm.apk
/D

That looks like it works! I was able to plug in the computer, Subsurface
automatically launched and switched to the download page. Once I filled in
the make and model (I understand that this can't be automatic because of
the generic FTDI cable id) it downloaded just fine. Nice work!

[Dirk Hohndel]

Post by Dirk Hohndel
And that is up. Matt, if you aren't tired of trying by now, this might support
the i750TC over FTDI
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.166-arm.apk <http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.1.166-arm.apk>
That looks like it works! I was able to plug in the computer, Subsurface automatically launched and switched to the download page. Once I filled in the make and model (I understand that this can't be automatic because of the generic FTDI cable id) it downloaded just fine. Nice work!

Thanks for the report back. I really appreciate it.

So glad this all works now :-)

/D

[Anton Lundin]

Post by Dirk Hohndel

Post by Anton Lundin
I'd rather say that we don't have this pid listed in serial_ftdi.c

You are of course correct.
The fact that everywhere else we use the decimal value of VID/PID, but in
that file we use hex really doesn't make it easier to find what could be wrong
when you are searching for it.
I'll fix that and build a new test binary

That's one if the stupid things with the current libftdi thingie that I
would like to see removed. If we pass something more inteligent to the
open function, like a device, bus/devnum, vid/pid or something, we can
remove that internal list and just access whatever the caller asked us
to open. That way we can remove the searching from there to.


//Anton

[Linus Torvalds]

Post by Dirk Hohndel
The fact that everywhere else we use the decimal value of VID/PID, but in
that file we use hex really doesn't make it easier to find what could be wrong
when you are searching for it.

Honestly, it's the "everywhere else we use decimal" that is just strange
and wrong.

USB IDs are pretty much always given in hex. Decimal values there are just
really odd. I was wondering why you used them earlier.

Every single tool that reports USB IDs that I've ever seen has used the hex
format.

Linus

[Dirk Hohndel]

Post by Dirk Hohndel
The fact that everywhere else we use the decimal value of VID/PID, but in
that file we use hex really doesn't make it easier to find what could be wrong
when you are searching for it.
Honestly, it's the "everywhere else we use decimal" that is just strange and wrong.
USB IDs are pretty much always given in hex. Decimal values there are just really odd. I was wondering why you used them earlier.
Every single tool that reports USB IDs that I've ever seen has used the hex format.

I need to check if device_filter.xml is smart enough to understand hex.
Frankly, I just followed what was used there.
Yes, hex would be better. But all decimal is better than some decimal and some hex

Just my $0.03

/D

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Dirk Hohndel
The fact that everywhere else we use the decimal value of VID/PID, but in
that file we use hex really doesn't make it easier to find what could be wrong
when you are searching for it.
Honestly, it's the "everywhere else we use decimal" that is just strange and wrong.
USB IDs are pretty much always given in hex. Decimal values there are just really odd. I was wondering why you used them earlier.
Every single tool that reports USB IDs that I've ever seen has used the hex format.

I need to check if device_filter.xml is smart enough to understand hex.
Frankly, I just followed what was used there.
Yes, hex would be better. But all decimal is better than some decimal and some hex

Yep, I remembered correctly:

https://stackoverflow.com/a/8328814

Thank you Google - that's ridiculous and arbitrary and stupid, and not
documented, you just are assumed to know this.

So while I agree with you, Linus, that hex would be so much smarter, I
still think that it makes more sense to use the same representation
everywhere.

/D

[Linus Torvalds]

Post by Dirk Hohndel
https://stackoverflow.com/a/8328814

Well, that one used hex numbers without a 0x prefix.

Does it perhaps work if you do

<usb-device vendor-id="0x0BDA" product-id="0x8187"/>

instead? Because if the number parsing is based on _anything_ normal,
then it should work.

But if it doesn't, oh well. And I'd blame xml. Because anybody who
ever uses xml gets everything wrong.

Linus

[Dirk Hohndel]

Post by Linus Torvalds

Post by Dirk Hohndel
https://stackoverflow.com/a/8328814

Well, that one used hex numbers without a 0x prefix.
Does it perhaps work if you do
<usb-device vendor-id="0x0BDA" product-id="0x8187"/>
instead? Because if the number parsing is based on _anything_ normal,
then it should work.

You're gonna make me try this instead of working on the several dozen
other things that I should work on. Well done.

Post by Linus Torvalds
But if it doesn't, oh well. And I'd blame xml. Because anybody who
ever uses xml gets everything wrong.

... says the guy who picked XML as the initial file format for Subsurface :-)

/D

[Dirk Hohndel]

Post by Linus Torvalds

Post by Dirk Hohndel
https://stackoverflow.com/a/8328814

Well, that one used hex numbers without a 0x prefix.
Does it perhaps work if you do
<usb-device vendor-id="0x0BDA" product-id="0x8187"/>
instead? Because if the number parsing is based on _anything_ normal,
then it should work.

Can I just say for the record that you are bleeping annoying?
I mean this whole "oh yeah, of course Linus is right" thing is getting
tiring...

In other words... yep, that seems to work. Should have tried that instead
of googling for bad advice :-(

/D

[Anton Lundin]

Post by Dirk Hohndel
I need help from people who have both an Android device, an FTDI dive
computer / download cable, and a way to connect the two (OTG cable for
older phones - for USB C phones this tends to be simply a USB C/A adapter)
Can you install the USB Device Info app from the app store, plug in the
FTDI cable, and send me the device info that is shown (plus any
descriptive information about the dive computer / download cable that you
used)?
I have access to a single such device, a Heinrichs Weikamp OSTC 3 - and
that presents me with a Product Name of "HeinrichsWeikamp OSTC 3". How
useful, I have code ready that will show the download page with the
correct dive computer selected when you plug in that dive computer. I'd
love to see what other cables / devices give us in information. For
example, I assume that the cables will at best give us a vendor - and
maybe not even that, but since they work for multiple dive computer
models, I doubt that they'll tell us which dive computer is attached.
But without actual test data I'm not sure how far we can push this.

Meanwhile I had a 3 year old "diver" in the bathtub next to me, I
managed to get some time to dump out some data from a bunch of dive
computers:

A suunto cable from smartinterface.de :

Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): Smartinterface
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6001
Product Name (reported): USB <-> Serial Cable
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


A Suunto Eon Steel connected over USB:

Device Info
Device Path: /dev/bus/usb/001/003
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 1493
Vendor Name (reported): Suunto
Vendor Name (from DB): Suunto
Product ID: 00030
Product Name (reported): GURU
Product Name (from DB): not found

Additional Info
Interface #0
Class: Human Interaction Device (0x3)
Endpoint: #0
Address : 0x02 (000000010)
Number : 2
Direction : Outbound (0x0)
Type : Intrrupt (0x3)
Poll Interval : 1
Max Packet Size: 64
Attributes : 000000011
Endpoint: #1
Address : 0x82 (10000010)
Number : 2
Direction : Inbound (0x80)
Type : Intrrupt (0x3)
Poll Interval : 1
Max Packet Size: 64
Attributes : 000000011
Endpoint: #2
Address : 0x83 (10000011)
Number : 3
Direction : Inbound (0x80)
Type : Intrrupt (0x3)
Poll Interval : 1
Max Packet Size: 64
Attributes : 000000011


A HW OSTC3:

Device Info
Device Path: /dev/bus/usb/001/008
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): HW
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6001
Product Name (reported): HeinrichsWeikamp OSTC3
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


A HW OSTC 2N:

Device Info
Device Path: /dev/bus/usb/001/011
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): HW
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6001
Product Name (reported): HeinrichsWeikamp OSTC 2N
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


//Anton

[Dirk Hohndel]

Post by Anton Lundin
Meanwhile I had a 3 year old "diver" in the bathtub next to me, I
managed to get some time to dump out some data from a bunch of dive

Thanks - that's super helpful.

Post by Anton Lundin
Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): Smartinterface
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6001
Product Name (reported): USB <-> Serial Cable
Product Name (from DB): not found

Generic IDs and an all too generic name, so all we can do is pre-select
FTDI. Which we should already be doing.

Post by Anton Lundin
Device Info
Device Path: /dev/bus/usb/001/003
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 1493
Vendor Name (reported): Suunto
Vendor Name (from DB): Suunto
Product ID: 00030
Product Name (reported): GURU
Product Name (from DB): not found

That one we should detect correctly based on VID/PID

Post by Anton Lundin
Device Info
Device Path: /dev/bus/usb/001/008
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): HW
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6001
Product Name (reported): HeinrichsWeikamp OSTC3
Product Name (from DB): not found

That one we already detect based on name

Post by Anton Lundin
Device Info
Device Path: /dev/bus/usb/001/011
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID: 0403
Vendor Name (reported): HW
Vendor Name (from DB): Future Technology Devices International, Ltd
Product ID: 6001
Product Name (reported): HeinrichsWeikamp OSTC 2N
Product Name (from DB): not found

Yay, that's one of the ones I was hoping someone would report. And note,
it's "OSTC 2N" versus before it was "OSTC3" - that's why I really am
looking for people to try this out and send us the output. Otherwise we'd
never guess these correctly.

I will add this in my next push.

Again, THANKS Anton.

/D

[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