Ok, So I'm reviving this thread as I'm back to trying to investigate what is going on as I really want to use Subsurface with my Atmos AI.
Here is a brief summary for those not following along.
Subsurface mobile cannot download an Aeris Atmos AI using a Pelagic download
cable.
(Subsurface desktop on linux has no issues)
A year ago, I found some coding issues in libdivecomputer that were causing
some of the issues
and managed to get it working but not all the time.
There were (and still are) some issues with the low level data cable
initialization for this type of data cable
The RTS line is not being handle correctly - it is easily fixed and resolves
part of the issue to allow retries of the
initialization to properly work.
The other issue back then was that the serial_ftdi_read() function
serial_ftdi.c was broken with respect to timeouts
which meant timeouts could be much MUCH longer than expected - so long that the
divecomputer could timeout and turn off.
Fastforward to today and lots has changed, including a change to using
"iostream" stuff rather than directly calling the serial code.
I tested the latest Subsurface Mobile code on a Galaxy 4 and a Galaxy S 7.
Downloads work on the S4 - but only once (this is due to the RTS handling
issue) until the app is restarted and the cable is pulled.
Downloads fail on the S7.
I created a h/w test jig that I can use to get better visibility what the USB
host is doing with the FTDI cable.
First a bit of background reminder.
The Pelagic data cable is not just a FTDI chip with its output signals hooked
up to the pins on the dive computer.
There is a PIC processor that sits between the FTDI chip and the dive computer
and processes messages from the host
and talks to the dive computer. The host does not directly talk to the dive
computer.
There are different versions of this data cable that have different physical
pin interfaces to the dive computers
and the PIC internally can have different f/w in it. Some cables run at
different baud rates between the FTDI chip and
and the PIC.
The data cable I'm using is an Oceanic part #4.9600 that runs at 9600 baud.
The RTS signal is used to reset the PIC. The libdivecomputer is not handling
the RTS signal in a robust way
that allows recovery and restarting from all conditions. This does create some
issues - it is easily fixed.
My h/w test jig consists of standard FTDI cable along with an Arduino and a
logic analyzer to measure things in real time.
The cable is the "official" FTDI cable directly from FTDI that uses the 6 pin
header with RTS & CTS pins.
The cable is hooked up to an Arduino that has been programmed to mimick the PIC
microcontroller that is inside the data cable.
This allows seeing the low level signal control and timing.
A bit more background. When talking to the Pelagic data cable, you must first
initialized the PIC then you can talk to the PIC
which can query the dive computer. There are some specific timings that need to
be honored in order for the
PIC initialization to work properly / reliably. If they are not followed, the
data cable will appear to be "deaf".
Here is what I noticed today. When using the real data cable and the Atmos AI
dive computer,
the dive computer never enters download mode on the Galaxy S7 but works
correctly on the S4.
I hooked up my test jig and one issue became obvious.
After you un-reset the PIC by lowering RTS, you should wait 100ms (that is what
the original Aeris s/w did). (libedivecomputer has a 100ms delay in the code)
if you don't wait long enough the PIC will mis the initial command and you can
never talk further with it.
It will appear to be deaf and will not answer - not even NAK any messages.
For the Atmos AI this delay can be seen in oceanic_vtpro_device_open() in the
file oceanic_vtpro.c
> // Set the RTS line.
> status = dc_iostream_set_rts (device->iostream, 1);
> if (status != DC_STATUS_SUCCESS) {
> ERROR (context, "Failed to set the RTS line.");
> goto error_free;
> }
>
> // Give the interface 100 ms to settle and draw power up.
> dc_iostream_sleep (device->iostream, device->protocol == MOD ? 100 :
> 1000);
>
> // Make sure everything is in a sane state.
> dc_iostream_purge (device->iostream, DC_DIRECTION_ALL);
>
> // Initialize the data cable (MOD mode).
> status = oceanic_vtpro_init (device);
In looking at analyzer shots here is the timing for desktop, S4, and S7
From the time RTS changes state to the first bit of the first byte of the
initialization message.
Desktop linux: 101ms (which is correct)
Galaxy S4: 2.5ms (which is not nearly long enough)
Galaxy S7: 650us (which is way too short and explains why it does not work on
the S7 as the PIC never sees the initial command)
It appears that delays used by libdivecomputer on Android - at least on the
Samsung devices not working based
on the analyzer shots are likely not doing any delay.
So depending the data cable (some cables for other computers run at 38400 vs
9600 and have faster PICs in them) and the speed
of the phone and what is going on inside the phone, the connection may not ever
work.
Surprisingly the short 2.5ms delay that is happening on the S4 seems to work,
instead of the intended 100ms delay.
My guess is that this issue affects more than just this dive computer and this
data cable which may explain some of the
"hit and miss" issues with FTDI cables and Subsurface mobile.
I haven't fully traced down the iostream to see where the dc_iostream_sleep()
function eventually goes,
but I think calls down into posix_serial.c dc_serial_sleep()
> static dc_status_t
> dc_serial_sleep (dc_iostream_t *abstract, unsigned int timeout)
> {
> struct timespec ts;
> ts.tv_sec = (timeout / 1000);
> ts.tv_nsec = (timeout % 1000) * 1000000;
>
> while (nanosleep (&ts, &ts) != 0) {
> int errcode = errno;
> if (errcode != EINTR ) {
> SYSERROR (abstract->context, errcode);
> return syserror (errcode);
> }
> }
>
> return DC_STATUS_SUCCESS;
> }
There are better ways to handle the while loop to ensure that the proper delay
is always met.
Whatever the case, dc_serial_sleep() as called by libdivecomputer is not
working on Android at least on the Samsung galaxy S4 running 4.4.4 and Galaxy
S7 running 8.0.0
which not allowing the PIC to be initialized which means that the Atmos AI
can't be downloaded.
I will need some help again getting a working build environment to be able to
build the app and test the fixes.
--- bill
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
