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