On 2014-03-07 03:20, Hamish Moffatt wrote:
I'm trying to download from my VT3. I've built libdivecomputer 0.4.2 on Linux (64-bit) but downloading is very slow and eventually fails. I've tested with both Subsurface and using the "universal" example. It does retrieve some dive data ok though.
Downloading my VT3 does work on Windows though, using Diving Log 5.0 (includes libdivecomputer 0.4.2, 32-bit) or the "universal" app binary which I downloaded directly from the libdivecomputer.org site.
I'm a bit surprised it works on Windows, but not on Linux. Because the code is the same, except for the low-level serial code, that might indicate a problem with the driver rather than the dive computer.
I've included a bit of the output log from "universal" on linux below. I checked that nothing else has the port open with lsof - earlier modem-manager was running but I've killed and removed that now.
Normally, if modem-manager has the port open, you wouldn't even be able to open the serial port, because we try to get exclusive access. So I assume you fixed that problem correctly. To applications talking to the same serial port results in all kinds of weird problems.
[0.209269] INFO: Write: size=4, data=B1000000 [3.212314] INFO: Read: size=0, data= [3.212333] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [3.212341] INFO: Sleep: value=100 [3.312423] INFO: Flush: queue=1, input=0, output=0 [3.312656] INFO: Write: size=4, data=B1000000 [3.314042] INFO: Read: size=1, data=5A [3.324885] INFO: Read: size=17, data=0416041120081001425800730000000075
[6.441357] INFO: Write: size=4, data=B1005400 [6.443109] INFO: Read: size=1, data=A5 [6.443125] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [6.443133] INFO: Sleep: value=100 [6.543215] INFO: Flush: queue=1, input=0, output=0 [6.543519] INFO: Write: size=4, data=B1005400 [6.544642] INFO: Read: size=1, data=5A [6.555511] INFO: Read: size=17, data=39111F172E0CABB4258302172E4B7BB785
What happens here is that the first time we send a command to the dive computer, we either don't get a reply back (first case above), or the dive computer replies with a negative answer (second case above). In such case, libdivecomputer will automatically retry sending the command, and that appears to work.
Usually such errors are rare, and you shouldn't even notice them. But you seem to get an error on every single packet. That also explains why the download is terribly slow. If there is no response from the dive computer, the timeout (3 seconds) will expire. Thus every packet will take 3 seconds instead of a few milleseconds. You can easily see this from the timings in the first case above.
If you've bad luck and the retrying fails too, then eventually libdivecomputer will give up and fail with an error.
Any suggestions?
Does your dive computer have a low battery? It's pretty common reason for failing downloads. Typically the PC interface requires more power than during diving. Another thing is to avoid using USB hubs and connect directly to a USB port on the PC.
Jef