Android FTDI support not working with fresh app build

[Bill Perry]

On 09/16/2018 11:35 AM, Dirk Hohndel wrote:
> Yep, I pulled Anton's fix this morning, that will also be fixed in the upcoming version 2.1.2
> of Subsurface-mobile
>
> /D

Cool.

I'm discussing and finalizing a libdivecomputer update to make the Pelagic data cable initialization more reliable with Jef.
Here is a link to the issue with details in the libdivecomputer repo: https://github.com/libdivecomputer/libdivecomputer/issues/4
It is a tweak to how RTS is handled when the port is opened.
I'm assuming that this will trickle down into the subsurface mobile version once it gets into the top level libdivecomputer repo.

Another Pelagic data cable related issue with subsurface mobile that I'm still tracking down is recovering from failed downloads
when using the pelagic data cable.

If you attempt to download dives and the data cable is not properly plugged into the divecomputer but the dive computer (Atmos AI in this case) is in PC countdown mode,
the download attempt obviously fails but then as soon as the data cable is properly plugged in (while dive computer still in countdown mode),
the divecomputer switches to download mode.
I'm assuming that this is because the PIC inside the data cable had queued up the Goto Download mode command and sent it to the divecomputer once the
cable was actually properly connected.
At this point the divecomputer gets the enter download mode command, goes into download mode with all segments lit and becomes stuck in download mode.
Attempting to use [Retry] doesn't work as there is some kind of issue.

Once a patch to prevent dc_serial_open() from being called when ftdi_open() fails is put into libdivecomputer,

libdivecomputer reports:
============================
Subsurface: v4.8.1, built with libdivecomputer v0.7.0-devel-Subsurface-NG (8f4945dc1e83c53ed9d2cdbaaa16e7b117df1f32)
============================
nothing else.

subsurface reports:
============================
"49.193: DCDownloadThread started for Aeris Atmos AI on FTDI"
Starting download from  ftdi
Starting the thread 0
Finishing download thread: "Error opening the device ftdi Aeris (Atmos AI).\nIn most cases, in order to debug this issue, it is useful to send the developers the log files. You can copy them to the clipboard in the About dialog."
no new dives downloaded
"55.734: DCDownloadThread finished"
"64.170: DCDownloadThread started for Aeris Atmos AI on ftdi"
Starting download from  ftdi
Starting the thread 0
Finishing download thread: "Unable to open ftdi Aeris (Atmos AI)"
"64.192: Input/output error"
no new dives downloaded
"64.198: DCDownloadThread finished"
"66.297: exit DCDownload screen"
qrc:/qml/main.qml:548: TypeError: Cannot read property 'objectName' of null
"77.830: DCDownloadThread started for Aeris Atmos AI on FTDI"
Starting download from  ftdi
Starting the thread 0
Finishing download thread: "Unable to open ftdi Aeris (Atmos AI)"
"77.873: Input/output error"
no new dives downloaded
"77.875: DCDownloadThread finished"
============================

Using [Quit] and retrying the download does not work either.

If 2 minutes go by, from the time when the Atmos AI divecomputer entered download mode, the dive computer will watchdog reset and exit download mode.
Yanking the data cable and reinserting it - with subsurface still running, doesn't help.

I have noticed that if Subsurface mobile is exited and the data cable is yanked, and subsurface mobile started again by the OS dialog that comes up when the data cable is reinserted,
that the next download attempt will re-connect to the dive computer - that is already in download mode, and will clear things up.

I need to dig deeper to figure out what is really happening to see if this can work better.


--- bill