can't download Oceanic VT3 on linux
Hi, 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'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. Any suggestions? Thanks, Hamish [0.000037] DATETIME 2014-03-07T01:56:02Z (1394157362) [0.000068] VERSION 0.4.2 [0.000092] Opening the device (Oceanic VT3, /dev/ttyUSB0). [0.000865] INFO: Configure: baudrate=38400, databits=8, parity=0, stopbits=1, flowcontrol=0 [0.001106] INFO: Timeout: value=3000 [0.001115] INFO: Sleep: value=100 [0.101194] INFO: Flush: queue=3, input=263, output=0 [0.101437] INFO: Write: size=2, data=8400 [0.103572] INFO: Read: size=1, data=00 [0.103586] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [0.103602] INFO: Sleep: value=100 [0.203686] INFO: Flush: queue=1, input=118, output=0 [0.203937] INFO: Write: size=2, data=8400 [0.204913] INFO: Read: size=1, data=5A [0.208911] INFO: Read: size=17, data=4F43452056543320523244203531324BBF [0.208939] Registering the event handler. [0.208948] Registering the cancellation handler. [0.209039] Downloading the dives. [0.209046] Event: progress 0.00% (0/64992) [0.209067] Event: vendor=4F43452056543320523244203531324B [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 [3.324901] Event: progress 0.02% (16/64992) [3.324920] Event: model=16984 (0x00004258), firmware=0 (0x00000000), serial=7300 (0x00001c84) [3.325176] INFO: Write: size=4, data=B1000400 [6.328221] INFO: Read: size=0, data= [6.328240] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [6.328248] INFO: Sleep: value=100 [6.428331] INFO: Flush: queue=1, input=0, output=0 [6.428523] INFO: Write: size=4, data=B1000400 [6.430266] INFO: Read: size=1, data=5A [6.441137] INFO: Read: size=17, data=200210028003480530BE70B70000000019 [6.441154] Event: progress 0.05% (32/63408) [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 [6.555528] Event: progress 0.08% (48/63408) [6.555756] INFO: Write: size=4, data=B1005300 [9.558799] INFO: Read: size=0, data= [9.558818] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [9.558826] INFO: Sleep: value=100 [9.658909] INFO: Flush: queue=1, input=0, output=0 [9.659097] INFO: Write: size=4, data=B1005300 [9.660614] INFO: Read: size=1, data=5A [9.671487] INFO: Read: size=17, data=26861F1F16936AAD3389021F16D7BAB0DE [9.671502] Event: progress 0.10% (64/63408) [9.671799] INFO: Write: size=4, data=B1005200 [9.673490] INFO: Read: size=1, data=A5 [9.673521] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [9.673530] INFO: Sleep: value=100 [9.773608] INFO: Flush: queue=1, input=0, output=0 [9.773854] INFO: Write: size=4, data=B1005200 [9.774985] INFO: Read: size=1, data=5A [9.785865] INFO: Read: size=17, data=02111F1E1BA689A22685021E1B292AA91E [9.785881] Event: progress 0.13% (80/63408) [9.786098] INFO: Write: size=4, data=B1005100 [12.789144] INFO: Read: size=0, data= [12.789163] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [12.789171] INFO: Sleep: value=100 [12.889257] INFO: Flush: queue=1, input=0, output=0 [12.889449] INFO: Write: size=4, data=B1005100 [12.890959] INFO: Read: size=1, data=5A [12.901835] INFO: Read: size=17, data=43861F0ACA45B9965088020ACA6C599A5D [12.901851] Event: progress 0.15% (96/63408) [12.902035] INFO: Write: size=4, data=B1005000 [12.903804] INFO: Read: size=1, data=A5 [12.903819] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [12.903827] INFO: Sleep: value=100 [13.003939] INFO: Flush: queue=1, input=0, output=0 [13.004197] INFO: Write: size=4, data=B1005000 [13.005314] INFO: Read: size=1, data=5A [13.016331] INFO: Read: size=17, data=45100F18AAC6E88F09041F09CAFF48943D [13.016347] Event: progress 0.18% (112/63408) [13.016648] INFO: Write: size=4, data=B1004F00 [16.019691] INFO: Read: size=0, data= [16.019710] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [16.019718] INFO: Sleep: value=100 [16.119803] INFO: Flush: queue=1, input=0, output=0 [16.120080] INFO: Write: size=4, data=B1004F00 [16.121183] INFO: Read: size=1, data=5A [16.132159] INFO: Read: size=17, data=24060D18AA57088910090E18AA91588C3F [16.132168] Event: progress 0.20% (128/63408) [16.132373] INFO: Write: size=4, data=B1004E00 [19.135409] INFO: Read: size=0, data= [19.135429] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [19.135437] INFO: Sleep: value=100 [19.235521] INFO: Flush: queue=1, input=0, output=0 [19.235775] INFO: Write: size=4, data=B1004E00 [19.237157] INFO: Read: size=1, data=5A
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
On 07/03/14 18:23, Jef Driesen wrote:
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 wasn't able to run your pre-compiled universal binary on linux unfortunately as it requires GLIBC_2.14 (my Debian 7/wheezy has 2.13). I'm using the same cable on Windows and Linux, though they're different computers.
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.
I replaced the dive computer battery a couple of weeks ago. I've connected it directly to the front panel USB slots on the computer, and also via the hub in my monitor. I can try directly into the back of the PC later, but I wouldn't think that would change anything. I forgot to add that one of the failed download attempts left the VT3 displaying "BSL" which I gather means it's in the bootloader expecting new firmware. Seems there's some pretty serious corruption going on. What baud rate is used? Flow control issues? Some other setting wrong by default? Hamish
On 2014-03-07 08:30, Hamish Moffatt wrote:
On 07/03/14 18:23, Jef Driesen wrote:
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 wasn't able to run your pre-compiled universal binary on linux unfortunately as it requires GLIBC_2.14 (my Debian 7/wheezy has 2.13). I'm using the same cable on Windows and Linux, though they're different computers.
I have fixed that. I have build a 32bit version again. (I've always done 32bit builds in the past, not sure how that suddenly changed.)
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.
I replaced the dive computer battery a couple of weeks ago.
So that should be good then.
I've connected it directly to the front panel USB slots on the computer, and also via the hub in my monitor. I can try directly into the back of the PC later, but I wouldn't think that would change anything.
That's unlikely to make a difference. The hub in the monitor could make things worse, so if possible avoid that. One of the problems with usb-serial converters, compared to real serial ports is the increased latency. With a timing sensitive protocol (which the Oceanic is not) that could cause problems. You can find a good explanation here: http://projectgus.com/2011/10/notes-on-ftdi-latency-with-arduino/ You could try to adjust the latency as described there, although I doubt that is the problem. I have also prepared a new build which slows down sending the commands by waiting 100ms between the packets. I have the impression we might be sending commands too fast for your device. Can you give this a try? wget http://www.libdivecomputer.org/builds/experimental/linux/atom2 chmod +x atom2 ./atom2 /dev/ttyUSB0
I forgot to add that one of the failed download attempts left the VT3 displaying "BSL" which I gather means it's in the bootloader expecting new firmware. Seems there's some pretty serious corruption going on.
What baud rate is used? Flow control issues? Some other setting wrong by default?
If that would be the problem, then it would fail on Windows too, because the same settings are used on all platforms. Jef
On 07/03/14 20:15, Jef Driesen wrote:
I have also prepared a new build which slows down sending the commands by waiting 100ms between the packets. I have the impression we might be sending commands too fast for your device. Can you give this a try?
wget http://www.libdivecomputer.org/builds/experimental/linux/atom2 chmod +x atom2 ./atom2 /dev/ttyUSB0
Just back from a holiday weekend including a dive. The test build runs well, though slowly. So far over 700 seconds, with only one error being: [68.234123] ERROR: Unexpected answer start byte(s). [in ../../source/src/oceanic_atom2.c:340 (oceanic_atom2_send)] If you want to send me a patch or tell me where to add the delay, I can rebuild the source and play with timing and see what works for me? Hamish
On 2014-03-10 14:18, Hamish Moffatt wrote:
On 07/03/14 20:15, Jef Driesen wrote:
I have also prepared a new build which slows down sending the commands by waiting 100ms between the packets. I have the impression we might be sending commands too fast for your device. Can you give this a try?
wget http://www.libdivecomputer.org/builds/experimental/linux/atom2 chmod +x atom2 ./atom2 /dev/ttyUSB0
Just back from a holiday weekend including a dive. The test build runs well, though slowly. So far over 700 seconds, with only one error being:
[68.234123] ERROR: Unexpected answer start byte(s). [in ../../source/src/oceanic_atom2.c:340 (oceanic_atom2_send)]
If you want to send me a patch or tell me where to add the delay, I can rebuild the source and play with timing and see what works for me?
The slowness is expected. The attached patch introduces a 100ms delay before each command. With 4096 packets (of only 16 bytes), that means a total delay of at least 409.6 seconds. That alone is already a very good reason not to apply this patch, especially because most users don't need it. But it does give a good indication that the real problem is likely something timing related. The question is of course what and where. Something else that is worth trying is increasing the 100ms delay in the oceanic_atom2_device_open() function. I don't really understand why, but some interfaces seem to need some extra time between setting up the serial port and sending the first data packet. I suspect that the OS or driver is async and returns before the settings are actually applied, causing us to send data before the device is ready. But I'm not really sure about that. Anyway, adding some extra delay there isn't that much of a problem because it's just a one time delay. Jef
On 11/03/14 00:52, Jef Driesen wrote:
The slowness is expected. The attached patch introduces a 100ms delay before each command. With 4096 packets (of only 16 bytes), that means a total delay of at least 409.6 seconds. That alone is already a very good reason not to apply this patch, especially because most users don't need it. But it does give a good indication that the real problem is likely something timing related. The question is of course what and where.
Something else that is worth trying is increasing the 100ms delay in the oceanic_atom2_device_open() function. I don't really understand why, but some interfaces seem to need some extra time between setting up the serial port and sending the first data packet. I suspect that the OS or driver is async and returns before the settings are actually applied, causing us to send data before the device is ready. But I'm not really sure about that. Anyway, adding some extra delay there isn't that much of a problem because it's just a one time delay.
Increasing the delay in the oceanic_atom2_device_open() function didn't help (tried 1 second even). A delay of 1ms inside oceanic_atom2_send() was enough for a perfect transfer, but 0.5ms (via usleep() for hack's sake) was not enough. Hamish
participants (3)
-
Hamish Moffatt -
Jef Driesen -
Jef Driesen