Dive data import error with Hollis DG03

[Jef Driesen]

On 2014-03-24 22:15, Rick Walsh wrote:
> On 25 March 2014 01:00, Rick Walsh <rickmwalsh at gmail.com> wrote:
>> On 25 March 2014 00:29, Jef Driesen <jef at libdivecomputer.org> wrote:
>>> At the moment my preference is towards this adaptive delay solution,
>>> assuming it works of course. Could you give the attached patch a try?
>>> Preferable on multiple systems (Linux, Windows) and both with and 
>>> without
>>> the 16ms low latency timer. The patch starts with a delay of 0ms, and
>>> increases it with 4ms on every failure. That's just a proof of 
>>> concept of
>>> course. We can easily change the logic depending on what works best.
>> 
>> The patch works for me on Linux. I rebuilt libdivecomputer, then
>> subsurface. Building on/for Windows is beyond me.
>> 
>> latency_timer is left at 1 (not using setserial or udev rules).
>> 
>> There is one error in the log file from subsurface (Unexpected answer
>> start byte(s)), then it sleeps. I'm guessing that's exactly what you
>> want it to do.
> 
> As the delay was only increased once, to 4ms, I tried reducing the
> delay increment to 1ms by editing oceanic_atom2.c (after applying your
> patch)
> 
> --- oceanic_atom2.c~    2014-03-25 07:59:35.608749961 +1100
> +++ oceanic_atom2.c    2014-03-25 07:33:23.549403357 +1100
> @@ -369,7 +369,7 @@
>          if (nretries++ >= MAXRETRIES)
>              return rc;
> 
> -        device->delay += 4;
> +        device->delay += 1;
> 
>          // Delay the next attempt.
>          serial_sleep (device->port, 100);
> 
> 
> For me this worked just as well as the delay increment of 4ms.
> Downloading from my DC in subsurface, I get one error line (line 34)
> in the log, and every subsequent Write is preceded by Sleep: value=1.
> The sleep value never increases beyond 1ms.

I think we have to be careful, to not make the delay too small. Because 
then we may need too many attempts before we reach a good value. 
Currently the code will retry at most 2 times before giving up. So if we 
don't reach a good value before the third attempt the download will 
still fail. Yes, we can easily increase the number of tries, but it's 
always a trade-off. If we try too many tries, then the download will 
appear to get stuck (e.g. each timeout will block for 3 seconds), which 
is a bit annoying for the user.

> (line 34)
> ERROR: Failed to receive the answer. [in oceanic_atom2.c:337
> (oceanic_atom2_send)]
> INFO: Sleep: value=100
> INFO: Flush: queue=1, input=0, output=0
> INFO: Sleep: value=1
> ...
> INFO: Write: size=4, data=B10F0900
> INFO: Read: size=1, data=5A
> INFO: Read: size=17, data=40060003048C8C8C99070501020200029D
> INFO: Sleep: value=1
> INFO: Write: size=4, data=6A05A500
> INFO: Read: size=1, data=A5
> (EOF)
> 
> I also tried downloading from my DC with
> /sys/bus/usb-serial/devices/ttyUSB0/latency_timer set to 16.
> Essentially, it does the same as above, but the error line doesn't
> occur until line 6649, so it gets nearly halfway through downloading
> before it needs to introduce the 1ms delay.

The difference is hard to see without the timestamps. Next time, attach 
the full logfile, rather posting a snippet from the terminal output. You 
can of course still include small snippets inline in your email, but if 
necessary I can still have a look at the full picture :-)

> This looks promising - the patch works as it should, and there's no
> need to get root privilege or play with /sys/ files. Note, I haven't
> tested on other hardware or OSs.

I have uploaded builds for all three OS'es. See my previous email. Can 
you (or anyone else) give these builds a try?

Jef