On Tue, Mar 11, 2014 at 5:20 PM, Hamish Moffatt hamish@cloud.net.au wrote:
Here's a log from Windows. There appears to be a whole lot less timing precision so it's a bit hard to compare, other than noting the absence of NAKs from the VT3.
Hmm. The windows log is for 0.5.0-devel, with the Linux one being 0.4.2. But I assume there are no big libdivecomputer changes.
[0.156] INFO: Write: size=2, data=8400 [0.156] INFO: Read: size=1, data=5A [0.156] INFO: Read: size=17, data=4F43452056543320523244203531324BBF [0.172] dc_device_dump [0.172] INFO: Write: size=4, data=B1000000 [0.187] INFO: Read: size=1, data=5A
So the Linux dump sometimes got A5 instead of 5A.
But the *timing* is very vert different. Here's Linux getting the right data:
[0.104540] INFO: Write: size=2, data=8400 [0.104551] INFO: Read: size=1, data=5A
and here's the same thing with the wrong data:
[0.109560] INFO: Sleep: value=1 [0.110624] INFO: Write: size=4, data=B1000000 [0.110634] INFO: Read: size=1, data=A5
Note how it did a two-byte write, and then immediately a read within 10 microseconds.
Which is a bit odd. Jef, shouldn't the sleep be *after* the write, and before the read? If there are any duplex issues, the "read -> write" turnaround isn't the problem (because by the time the read returns, we certainly know the data had been fully sent from the other side), but the "write -> read" turnaround might be problematic if the reader gets confused by DSR coming on while it's still receiving.
Linus