OSTC3 import failure

[Jef Driesen]

On 2014-10-10 03:38, Dirk Hohndel wrote:
> On Thu, Oct 09, 2014 at 02:24:41PM -1000, Gaetan Bisson wrote:
>> If I also try to enable a dumpfile, then a popup says "Dive data 
>> import
>> error" and nothing is imported and no dumpfile is created.
> 
> The OSTC3 doesn't support memory dumps, IIRC.

The ostc3 protocol doesn't support memory dumps. As an alternative, you 
can run the pre-built universal app from the libdivecomputer. This has 
been patched to dump the raw dives to files named "dive_xxx.bin" if you 
run it with the -d option.

But I already extracted the raw dive from the logfile and attached it.

>> INFO: Read: size=538, 
>>
data=00000000001C00003A000900000000000000000035000037000900000000000000000016000020001F0D0100F043000000000000000000000000000000000000000000000000300019000019000900000000000000000017000010000900000000000000000009000009000D0D0100F00000000000000000000B00000A00090000000000000000000700000A00090000000000000000000A00000B001F0D0100F04500000000000000000000000000000000000000000000000030000900000B00090000000000000000000900000900090000000000000000000B00000B000D0D0100F00000000000000000000A00000B00090000000000000000000A00000A00090000000000000000000A00000A001F0D0100F04400000000000000000000000000000000000000000000000030000B00000A00090000000000000000000900000900090000000000000000000900000A000D0D0100F00000000000000000000C00000B00090000000000000000000700000B000900000000000000000009000008001F0D0100F04300000000000000000000000000000000000000000000000030000900000900090000000000000000000A00000900090000000000000000000B000009000D0D0100F00000000000000000000900000900090000000000000000000B00000C00090000000000000
000000B000009001F0D0100F0420000000000000000000000000000000000000000000000003000FDFD
>> INFO: Read: size=1, data=4D
>> ERROR: Buffer overflow detected! [in hw_ostc_parser.c:598 
>> (hw_ostc_parser_samples_foreach)]
> 
> Now I may be overly suspicious, but I think this pretty much points us 
> at
> the culprit...

Indeed.

> This is the code that triggers this (at least in my version of
> libdivecomputer which is pretty close to git master plus a few of my 
> own
> patches that haven't made it into libdivecomputer, yet, but those are
> unrelated to the OSTC)
> 
>                // Extended sample info.
>                 for (unsigned int i = 0; i < nconfig; ++i) {
>                         if (info[i].divisor && (nsamples %
> info[i].divisor) == 0) {
>                                 if (length < info[i].size) {
>                                         ERROR (abstract->context,
> "Buffer overflow detected!");
>                                         return DC_STATUS_DATAFORMAT;
>                                 }
> 
> So it looks like the last read (which returned 1 byte) was expected to
> deliver a lot more data. I haven't gone through the data stream to 
> analyze
> what exactly the OSTC3 was sending that confused libdivecomputer, but 
> it's
> pretty clear this is where the problem is.

It seems the data was downloaded correctly. I don't think it's 
truncated, because the end marker 0xFDFD is there. That 1 byte read 
which returns 0x4D is the ready byte. That's perfectly normal.

What happens during the parsing is that you have extended sample info 3 
set as follows:

info[3].type = 3
info[3].divisor = 2
info[3].size = 9

This corresponds to ppO2 sensor data. At the point where the parsing 
fails (10th sample at offset 0x160), the remaining length is only 8 
bytes. So that's not enough for the 9 byte large ppO2 sensor data. Now 
we only need to figure out the root of the problem :-)

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ostc3.bin
Type: application/octet-stream
Size: 31258 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141010/d931ffd3/attachment-0001.bin>