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