Dive data import error with Hollis DG03

[Jef Driesen]

On 2014-03-26 11:26, Rick Walsh wrote:
> It ran similarly for me, except that the timeout occurred on the second 
> read.
> 
> [0.128031] Event: progress 0.00% (0/65536)
> [0.130899] INFO: Write: size=4, data=B1000000
> [0.131928] INFO: Read: size=1, data=5A
> [0.141912] INFO: Read: size=17, data=0516110804110000444D000481006B01CB
> [0.141922] Event: progress 0.02% (16/65536)
> [0.143903] INFO: Write: size=4, data=B1000100
> [0.143923] INFO: Read: size=1, data=A5
> [0.143930] ERROR: Unexpected answer start byte(s). [in
> ../../source/src/oceanic_atom2.c:343 (oceanic_atom2_send)]
> [0.143939] INFO: Sleep: value=4
> [0.149918] INFO: Write: size=4, data=B1000100
> [3.153025] INFO: Read: size=0, data=
> [3.153060] ERROR: Failed to receive the answer. [in
> ../../source/src/oceanic_atom2.c:337 (oceanic_atom2_send)]
> [3.153079] INFO: Sleep: value=8
> [3.162912] INFO: Write: size=4, data=B1000100
> [3.163927] INFO: Read: size=1, data=5A
> [3.174952] INFO: Read: size=17, data=6B01B8061204AE066407A106FF0FAABE7C
> [3.174979] Event: progress 0.05% (32/65536)

After seeing this, I think we should leave the 100ms delay and the flush 
in place after all. If the packet fails with a NAK or timeout, then this 
indicates some problem and it's probably a good idea to give the device 
some more time to finish with whatever it was doing.

In the above scenario, if we had waited 100ms after the first NAK, then 
I suspect the second retry will probably have succeeded right away. Our 
4ms may be sufficient for the normal case, but not when the device tells 
us there was some problem processing the request.

That 100ms delay may also give us an opportunity to use smaller 
increments (e.g. 2ms or even 1ms instead of 4ms) for the dynamic delay. 
Because on a failure, that 100ms delay is what should make the retry 
work. If the dynamic delay is still too small, we'll just get a new 
error on the next packet. This is something that can easily be repeated 
multiple times, without having to worry about exceeding the maximum 
number of retries.

Can you try once more, with the 100ms and flush added again? And then a 
second try with 1ms increments for the dynamic delay.

On Linux:
> [92.509948] Result: Success
> 
> On Windows:
> [67.031023] Result: Success

This difference is already smaller than the 32 seconds overhead due to 
the dynamic delay.

Jef