Android FTDI support not working with fresh app build

Bill Perry bill at billandterrie.com
Thu Sep 13 23:35:30 PDT 2018


Ok, there is something very strange going on.
Here is what I've done.
I started over. I completely removed the subsurface directory and re-cloned the subsurface repo.
Followed the instructions in the INSTALL file and built an android .apk image from the head of the tree.
It was slightly larger than the previous .apk image I had previously built that wasn't able to open the ftdi port.
This newly built app did not show up when the ftdi cable was plugged in (neither did the first one)
When the app was started manually, the app would come up and the immediately crash.
I decided to start over again clean and checkout v4.8.1 and see if I could build that.
The .apk built from the v4.8.1 code was installed, the app would show up when the cable was plugged in.
This newly built v4.8.1 build could talk to the FTDI cable just like the 4.8.1 app downloaded from the playstore.

Now for the REALLY strange stuff!
The timing that is wrong in the app installed from the playstore is now correct with the app I just built.
With the 4.8.1 app I just built, downloads work on both the Galaxy S4 and the S7.

I have a logic analyzer hooked to a  h/w & s/w simulator test jig that simulates the Pelagic data cable and an Atmos AI
to be able to monitor data and signals on the FTDI chip to see what the host is doing.
There is a critical delay that must happen between RTS dropping and the first command sent to the PIC inside the Pelagic data cable.
The delay should be 100ms (that is what libdivecomputer code is asking for.)

With the 4.8.1 apk from the play store, this delay is
2.5ms on the Galaxy S4
600us on the Galaxy S7
Both are way too short and that is why downloads don't work. The PIC inside the Pelagic datacable misses the command because it isn't listening yet.

With the 4.8.1 code I checkout from the repository and built on my machine, the delays are:

103ms on the Galaxy S4
100ms on the Galaxy S7
These are the proper delays and downloads work as they should with this build.

I can post logic analyzer timing diagrams if people are interested in that level of detail.

There is something very odd going on.
I'm at a total loss as to what is happening and why my build has working delays whereas
the code from the playstore appears to not have working delays.

--- bill


On 09/14/2018 12:53 AM, Dirk Hohndel wrote:
> The Ubuntu package won't help, you need to build it for Android. I thought the scripts did that, but I'm not at my computer and trying to figure this out on the phone is now than I am ready for...
>
> On September 13, 2018 9:11:00 PM PDT, Bill Perry <bperrybap at opensource.billsworld.billandterrie.com> wrote:
>
>     I figured as much.
>     I hadn't installed libusb-1.0.0-dev
>     so I went back an installed all the Ubuntu packages listed in the INSTALL file, including libusb-1.0.0-dev
>     and re-ran the build script. But no difference.
>     I must still be missing something, probably really simple.
>
>     On 09/13/2018 10:20 PM, Dirk Hohndel wrote:
>
>              On Sep 13, 2018, at 6:05 PM, Bill Perry <bperrybap at opensource.billsworld.billandterrie.com> wrote:
>
>              The android app downloaded from the Playstore behaves differently than the one I just built from current sources.
>              I'm currently testing on a Samsung GS4 running kitkat 4.4.4
>
>              With the one from the play store: version 2.1.0(4.8.0)
>
>              - When the cable is plugged in OS asks to run subsurface.
>              NOTE: it will not do this if running the app in no cloud mode.
>              and it also won't talk over the ftdi cable either.
>              Once in cloud mode,
>              - It can open the port and push bytes out the data cable
>              However, the timing between the bytes & messages is wrong (which is what I'm trying to fix)
>
>              With the one I just built: version 2.1.2(4.8.1.413)
>              It appears to not be able to open the serial connection.
>              The libdivecomputer log shows: Subsurface: v4.8.1-413-g76c4fb397512, built with libdivecomputer v0.7.0-devel-Subsurface-NG (8f2ac8f61e8768d4774983de1f367f73c8c34ea2)
>              INFO: Open: name=ftdi
>              ERROR: No such file or directory (2) [in /home/bill/Documents/devel/Subsurface-devel/subsurface/libdivecomputer/src/serial_posix.c:295 (dc_serial_open)] Which seems to indicate it is trying open the device "ftdi" vs checking for the magic
"ftdi" name and calling the ftdi serial code instead of serial_posix code.
>              Have I not built the app properly, or is the code broken right now and I should go back to the tagged code from the last release?
>
>          You are building the app without libftdi
>
>          /D
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180914/907ddd71/attachment-0001.bin>


More information about the subsurface mailing list