Android beta...

[Dirk Hohndel]

On Thu, Jul 13, 2017 at 12:13:33AM +0200, Salvador Cuñat wrote:
> Good night Anton.
> 
> On Wed, Jul 12, 2017 at 10:32:59PM +0200, Anton Lundin wrote:
> > On 12 July, 2017 - Dirk Hohndel wrote:
> > 
> > > On Wed, Jul 12, 2017 at 01:28:50PM +0200, Anton Lundin wrote:
> > > You're looking at old code. The new code no longer shows the hex to the
> > > user (but still writes it to a libdivecomputer log). So if you are looking
> > > at the subsurface.log, then no hex. Looking at libdivecomputer.log you'll
> > > get the hex
> > 
> > Good that it was just my fault. That simplifies alot.
> > 
> > 
> > Btw. I figured out that a libdivecomputer log will give me all the data
> > that the dc responded with, and that will let me see if its just
> > firmware which is zero or if its other random bits.
> > 
> How can I get the libdivecomputer log? I only know of subsurface.log
> and subsurface.bin while downloading.

Since this says Android in the Subject I'm assuming Subsurface-mobile.
The last couple of binaries that I made (I think 381 and newer) allow you
to select a checkbox in the Settings->Preferences to enable the libdc
dump. And that libdivecomputer.log is then found in the same place as the
subsurface.log

> In fact I can't get them when using ftdi device, although selected in
> the dialog. No problem when using ttyUSB0.

Hmm, but then this sentence makes me think that maybe you are on the
desktop, using Subsurface? There it's just one of the questions in the
download dialog (and it makes you select a filename / location).

> > If its just the firmware field, I would guess its due to some memory
> > corruption on your OSTC 2N, and I'd suggest just reflashing the
> > firmware. It might fix it or it might not. The fact that it works on
> > desktop doesn't point to this.
> > 
> What is confirmed is that using ftdi device on desktop build downloads
> just 9 dives/32k data. So it's not an Android problem.
> 
> So ... using ttyUSB0 downloads 64k data, using ftdi downloads just 32k
> data, both on desktop.

But that could be explained by a mixup in firmware versions.

> > If there are random corruptions all over the transferee, its a bug in
> > serial_ftdi.c / libftdi / libusb / android / your hw. I would be really
> > supprised if the only bits that bug broke where the firmware version, so
> > it might be clear from the libdivecomputer.log file.
> > 
> I don't think it's data corruption. Look at the lines just after the
> last INFO:  in the attached log (just verbose output of subsurface).
> The firmware version is readed (3.13 and 3.14 these are correct).
> 
> Please tell me how to get the libdivecomputer log, an I'll send it
> tomorrow.

Hope the instructions above help

/D