Dive data import error with Hollis DG03

Jef Driesen jef at libdivecomputer.org
Wed Mar 26 01:17:00 PDT 2014


On 2014-03-26 07:17, Hamish Moffatt wrote:
> On 25/03/14 23:27, Jef Driesen wrote:
>> I have uploaded "universal-atom2-delay" builds with the 100ms delay 
>> (and the flush) removed. Can you give them a try?
>> 
>> http://www.libdivecomputer.org/builds/experimental/
>> 
>> Please include the full logfile, because the timestamps are written to 
>> the logfile, but not the terminal output. So if you copy-and-paste 
>> from the terminal output, these timestamps are lost.
>> 
> 
> It works for me, although the first read times out (3 seconds) with no
> reply at all. I don't remember it before but I just tried your regular
> "universal" build and it does it too. Hmm. It could be the dive
> computer though, which I would have to say is pretty dumb.

I've noticed in the past that many dive computers require some delay 
between open the serial port and sending the first request. That's why 
in most libdivecomputer backends, you'll find a 100ms delay, followed by 
a flush of the input buffer (that's another oddity, because I have no 
idea how there can already be any data in the buffer immediately after 
opening the serial port). Anyway, without that 100ms delay the 
communication just fails. Maybe the dive computer needs some time to 
notice the usb connection? I really don't know.

If you compare the time it takes to setup serial port, you'll notice 
there is quite some difference between Linux (1.113ms) and Windows 
(24.126ms). Maybe that has something to do with it? But on the other 
hand, if that was indeed the problem, I would expect to see a failure 
when sending the very first request, but that's not where it fails for 
you.

(Note that something we noticed with the older Oceanic interfaces (vtpro 
and veo250) is that their pc interface, is not just some dumb cable with 
a usb-serial chip inside, but has a microchip inside. I suspect that 
this is some debug interface that was simply re-used for implementing 
the download protocol. We discovered that some of the initialization 
request are answered by the cable itself and not the dive computer. So 
there might be some overhead there. First we're talking to the 
microchip, then I assume the microchip will do whatever it needs to do 
to initialize the connection to the dive computer, and only then we can 
pass request to the dive computer. But I don't know if this still 
applies to the newer atom2 based models.)

BTW, I think there should be no problem to lower the timeout from 3 
seconds to just 1 second. A packet usually takes only a few 
milliseconds, so that's still plenty of margin.

> Anyway the sleep value stays at 8 for the duration, there's no more
> errors. Low latency flag is still set on the port. Bit of a shame it
> got to 8ms, as 4ms would have been plenty I think.

I think we are moving in the right direction. This is already a very 
nice improvement, compared to the failing downloads we had before.

I wonder if we can get rid of the initial failure by introducing a small 
delay (for example 50ms or something like that) before sending the first 
read request? Can you try that? Just add a serial_sleep call near the 
end of the oceanic_atom2_device_open function

Another thing that's probably worth considering is to set an upper limit 
for the dynamic delay. Otherwise, if someone still suffers from errors 
on every single packet, the delay will grow out of control.

> [0.000032] DATETIME 2014-03-26T05:57:14Z (1395813434)
> [0.000059] VERSION 0.5.0-devel 
> (fa90009c293a9ca1a4eaf49a478b381477695c0a)
> [0.000078] Opening the device (Oceanic VT3, /dev/ttyUSB0).
> [0.000088] INFO: Open: name=/dev/ttyUSB0
> [0.000862] INFO: Configure: baudrate=38400, databits=8, parity=0,
> stopbits=1, flowcontrol=0
> [0.001099] INFO: Timeout: value=3000
> [0.001113] INFO: Sleep: value=100
> [0.101191] INFO: Flush: queue=3, input=0, output=0
> [0.101599] INFO: Write: size=2, data=8400
> [0.103020] INFO: Read: size=1, data=5A
> [0.106891] INFO: Read: size=17, data=4F43452056543320523244203531324BBF
> [0.106910] Registering the event handler.
> [0.106916] Registering the cancellation handler.
> [0.106922] Downloading the memory dump.
> [0.106947] Event: vendor=4F43452056543320523244203531324B
> [0.106985] Event: progress 0.00% (0/65536)
> [0.111117] INFO: Write: size=4, data=B1000000
> [0.111133] INFO: Read: size=1, data=A5
> [0.111139] ERROR: Unexpected answer start byte(s). [in
> ../../source/src/oceanic_atom2.c:343 (oceanic_atom2_send)]
> [0.111147] INFO: Sleep: value=4
> [0.119110] INFO: Write: size=4, data=B1000000
> [3.122144] INFO: Read: size=0, data=
> [3.122156] ERROR: Failed to receive the answer. [in
> ../../source/src/oceanic_atom2.c:337 (oceanic_atom2_send)]
> [3.122161] INFO: Sleep: value=8
> [3.131108] INFO: Write: size=4, data=B1000000
> [3.131993] INFO: Read: size=1, data=5A
> [3.142992] INFO: Read: size=17, data=0416041120081001425800730000000075
> [3.143001] Event: progress 0.02% (16/65536)
> [3.143023] INFO: Sleep: value=8
> [3.155146] INFO: Write: size=4, data=B1000100
> [3.155165] INFO: Read: size=1, data=5A
> [3.163873] INFO: Read: size=17, data=6701DA064204E506E206DC06FF0FAAFBF6
> [3.163885] Event: progress 0.05% (32/65536)
> [3.163894] INFO: Sleep: value=8
> [3.175139] INFO: Write: size=4, data=B1000200
> [3.175153] INFO: Read: size=1, data=5A
> [3.184705] INFO: Read: size=17, data=0000DC06FF0FDC06FF0F00000000AA8A14
> [3.184717] Event: progress 0.07% (48/65536)
> [3.184725] INFO: Sleep: value=8
> [3.195163] INFO: Write: size=4, data=B1000300
> [3.195180] INFO: Read: size=1, data=5A
> [3.205734] INFO: Read: size=17, data=890E370D00011B0B670542053250AAE1C2
> [3.205741] Event: progress 0.10% (64/65536)
> [3.205748] INFO: Sleep: value=8
> [3.215108] INFO: Write: size=4, data=B1000400
> [3.215618] INFO: Read: size=1, data=5A
> [3.226616] INFO: Read: size=17, data=300220028003500530BEB0BB0000000085
> 
> And Windows (default latency timer), no initial timeout, no errors at 
> all:
> 
> [0.000011] DATETIME 2014-03-26T06:10:30Z (1395814230)
> [0.000220] VERSION 0.5.0-devel 
> (fa90009c293a9ca1a4eaf49a478b381477695c0a)
> [0.000534] Opening the device (Oceanic VT3, COM3).
> [0.002059] INFO: Open: name=COM3
> [0.019211] INFO: Configure: baudrate=38400, databits=8, parity=0,
> stopbits=1, flowcontrol=0
> [0.024126] INFO: Timeout: value=3000
> [0.024262] INFO: Sleep: value=100
> [0.118962] INFO: Flush: queue=3, input=0, output=0
> [0.121072] INFO: Write: size=2, data=8400
> [0.124054] INFO: Read: size=1, data=5A
> [0.128054] INFO: Read: size=17, data=4F43452056543320523244203531324BBF
> [0.128799] Registering the event handler.
> [0.129153] Registering the cancellation handler.
> [0.130000] Downloading the memory dump.
> [0.130752] Event: vendor=4F43452056543320523244203531324B
> [0.133997] Event: progress 0.00% (0/65536)
> [0.135079] INFO: Write: size=4, data=B1000000
> [0.139079] INFO: Read: size=1, data=5A
> [0.150094] INFO: Read: size=17, data=0416041120081001425800730000000075
> [0.150375] Event: progress 0.02% (16/65536)
> [0.152103] INFO: Write: size=4, data=B1000100
> [0.155092] INFO: Read: size=1, data=5A
> [0.166106] INFO: Read: size=17, data=6701DA064204E506E206DC06FF0FAAFBF6
> [0.166388] Event: progress 0.05% (32/65536)
> [0.168117] INFO: Write: size=4, data=B1000200
> [0.171114] INFO: Read: size=1, data=5A
> [0.182134] INFO: Read: size=17, data=0000DC06FF0FDC06FF0F00000000AA8A14
> [0.182453] Event: progress 0.07% (48/65536)
> [0.184141] INFO: Write: size=4, data=B1000300
> [0.187144] INFO: Read: size=1, data=5A
> [0.198144] INFO: Read: size=17, data=890E370D00011B0B670542053250AAE1C2
> [0.198475] Event: progress 0.10% (64/65536)
> [0.200158] INFO: Write: size=4, data=B1000400
> [0.204144] INFO: Read: size=1, data=5A
> [0.215161] INFO: Read: size=17, data=300220028003500530BEB0BB0000000085
> [0.215448] Event: progress 0.12% (80/65536)
> [0.217170] INFO: Write: size=4, data=B1000500
> [0.220170] INFO: Read: size=1, data=5A
> [0.231182] INFO: Read: size=17, data=A014000300002C01980805A0022100024E
> [0.231470] Event: progress 0.15% (96/65536)
> [0.233196] INFO: Write: size=4, data=B1000600
> [0.237185] INFO: Read: size=1, data=5A
> [0.248197] INFO: Read: size=17, data=3899000099003102E9050400000000008F
> [0.248467] Event: progress 0.17% (112/65536)
> [0.250224] INFO: Write: size=4, data=B1000700
> [0.254203] INFO: Read: size=1, data=5A
> [0.265218] INFO: Read: size=17, data=0906290000000000003C00000100000277
> 
> I can try the Mac later too.

That would be great.

> Total runtime on Linux was 170 seconds, 129 on Windows.

With an 8ms delay on all 4096 packets, that gives a total delay of 32s. 
That explains already most of the difference.

Jef


More information about the subsurface mailing list