can't download Oceanic VT3 on linux

[Jef Driesen]

On 2014-03-11 00:16, Hamish Moffatt wrote:
> 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.

Even a sleep of just 1ms per packet is pretty bad. If I remember 
correctly, the resolution of the Windows Sleep() function is in the 
order of 10-15ms only. So that would still be a delay of approximately 
40.96 seconds.

I wonder if this is another case where the tcdrain() function isn't 
waiting properly until all bytes have been send out. We had a similar 
problem with Suunto devices before. There we implemented a workaround 
with serial_set_halfduplex() function. Could you try that as well? Just 
call it somewhere in the oceanic_atom2_device_open() function, but 
before the call to the oceanic_atom2_device_open() function.

How many wires does the Oceanic interface have? Just two or more?

I have been looking at the kernel history for the ftdi usb-serial 
driver, and there have been some changes related to waiting until the TX 
buffer is empty, so there could be something there as well. Which kernel 
version do you have (uname -a)?

PS: Don't forget to attach the logfiles. I want to have a look at the 
timings.

Jef