On 12/03/14 22:08, Jef Driesen wrote:
I just remember something that could matter here. If you look at the commands that are being send, they all end with a 0x00 byte that doesn't really serve any purpose afaik. When I originally reverse engineered the protocol, that byte was send by the Oceanic application, and I just duplicated that. But I now recall that I think I've seen that newer versions of there software no longer do this. Maybe this extra byte is what is causing us trouble now?
Imagine the dive computer expects a 3 byte read command (e.g. B1XXXX). It will first receive the command type 0xB1, and then expect two more bytes for that command. Than it has everything to process the request and send back the response. But if we send that extra 0x00 byte it will probably try to process that as the next command type. This is likely a non-existing type and the device will probably just ignore it. But that might take just enough time to prevent the next command from being received correctly.
I think that's something worth trying. Hamish, can you try without that last 0x00 byte? And maybe also try Oceanlog on Windows and capture the communication to double check whether they send this extra 0x00 byte or not.
I can see how the extra 0x00 might confuse the logical state of the serial interface in the dc. I've got good news and bad... I removed the extra 0x00 byte from the read version and read data commands, and the commands work, but the behaviour hasn't changed.
[0.000032] DATETIME 2014-03-12T11:17:39Z (1394623059) [0.000055] VERSION 0.5.0-devel (575f2e9016ac9baa2b1b031caa6fe0bc77cdbbee) [0.000059] DEVICE=/dev/ttyUSB0 [0.000065] oceanic_atom2_device_open [0.000071] INFO: Open: name=/dev/ttyUSB0 [0.000725] INFO: Configure: baudrate=38400, databits=8, parity=0, stopbits=1, flowcontrol=0 [0.000837] INFO: Timeout: value=3000 [0.000839] INFO: Sleep: value=100 [0.100909] INFO: Flush: queue=3, input=23, output=0 [0.101118] INFO: Write: size=1, data=84 [0.103245] INFO: Read: size=1, data=5A [0.107241] INFO: Read: size=17, data=4F43452056543320523244203531324BBF [0.107252] dc_device_dump [0.107858] INFO: Write: size=3, data=B10000 [0.109243] INFO: Read: size=1, data=A5 [0.109249] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:338 (oceanic_atom2_send)] [0.109252] INFO: Sleep: value=100 [0.209320] INFO: Flush: queue=1, input=0, output=0 [0.211906] INFO: Write: size=3, data=B10000 [0.211916] INFO: Read: size=1, data=5A [0.221744] INFO: Read: size=17, data=0416041120081001425800730000000075 [0.223887] INFO: Write: size=3, data=B10001 [3.226909] INFO: Read: size=0, data= [3.226920] ERROR: Failed to receive the answer. [in oceanic_atom2.c:332 (oceanic_atom2_send)] [3.226923] INFO: Sleep: value=100 [3.326992] INFO: Flush: queue=1, input=0, output=0 [3.327861] INFO: Write: size=3, data=B10001 [3.328711] INFO: Read: size=1, data=5A [3.339732] INFO: Read: size=17, data=6701DA064204E506E206DC06FF0FAAFBF6 [3.343861] INFO: Write: size=3, data=B10002 [6.346882] INFO: Read: size=0, data= [6.346893] ERROR: Failed to receive the answer. [in oceanic_atom2.c:332 (oceanic_atom2_send)] [6.346897] INFO: Sleep: value=100
The procedure on how to setup Portmon is described here:
http://www.libdivecomputer.org/contribute.html#protocol
Unfortunately you'll need a 32bit Windows version to run Portmon. If you use some other capture application that's of course fine too. Portmon is just convenient because it's freeware and the output is easy to parse with scripts.
Just to make things slightly more perverse, my only 32 bit Windows handy is a VM on the linux machine. OceanLog runs fine within the VM (letting VirtualBox give the USB device to the VM). But PortMon isn't even giving me a Computer menu so I can't get anywhere with that. I'll look into it more a bit later.
Hamish