Android beta...

Anton Lundin glance at acc.umu.se
Wed Jul 12 13:32:59 PDT 2017


On 12 July, 2017 - Dirk Hohndel wrote:

> On Wed, Jul 12, 2017 at 01:28:50PM +0200, Anton Lundin wrote:
> > On 12 July, 2017 - Salvador Cuñat wrote:
> > 
> > > Good morning Anton.
> > > 
> > > Attached is another log done with the. 4.6.4-380 beta.
> > > 
> > > Interesting line is #144, where it says "firmware=0" (it should call
> > > 3.14).
> > > This and the fact that H&W fw versions under 1.90 used to download 32k
> > > logbooks instead of 64k logs, could easily explain why we are just
> > > downloading 32x1024 bytes blocks, and getting the oldest dives (about
> > > half of those stored)
> > > 
> > > Then the question would be, why Android misses the firmware version
> > > while Desktop doesn't?
> > > 
> > > Hope this blind shot can somehow help.
> > 
> > I looked at src/hw_ostc.c hw_ostc_device_foreach, where serial and
> > firmware are parsed and put into the devinfo data structure, and I can't
> > figure out how serial can get set but not firmware.
> > 
> > I took a tour in our android logging and ended up staring at
> > qt-models/messagehandlermodel.cpp. The wierd thing is that all our trace
> > prints of serial and firmware also contains the same numbers in hex, but
> > that trace print doesn't, so somethings fishy with the logging to.
> 
> 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.

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.


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.


Salvador: Could you send me such a file?


//Anton


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list