Dive data import error with Hollis DG03

[Jef Driesen]

On 2014-03-24 14:01, Hamish Moffatt wrote:
> Right, I agree it wouldn't be good to add more delay on systems where
> we're already waiting 16ms. But if we know that commands should be
> separated by at least (let's say) 4ms, could we time the read() calls
> and only add whatever delay is necessary to ensure there's at least
> 4ms between commands?

I think timing the read calls will be tricky. We're doing two reads per 
packet. One for the ACK/NAK byte, and one for the actual packet payload. 
 From what I have seen so far in the logs is that only the first read 
suffers from the latency delay. Most likely because the dive computer 
submits both parts at once, such that they get transferred with a single 
USB packet, and thus they arrive at the host side at the same time. When 
we do that second read, the driver already has the data in its receive 
buffer, and doesn't have to wait another 16ms.

But in the end the delay we want is between the last read and the next 
write. So I'm not really sure what we should be timing.

> Otherwise you could look up the current latency by looking at the
> low_latency flag + sysfs on linux, the registry on Windows and the
> ioctl on Mac (if there's one to read the current setting), but that's
> pretty ugly and not portable to other kernels very readily.

This is indeed certainly not the easiest. As far as I know, Mac doesn't 
have an ioctl for reading the latency. And I suspect other unixes may 
not have such a thing either.

> Or maybe the adaptive delay would work.

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.

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delay.patch
Type: text/x-diff
Size: 1348 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140324/c1d33e6d/attachment.patch>