Failed to receive the answer (from Suunto Vyper Air)

[Amit Chaudhuri]

...

If you need additional diagnostics, apply this patch [1] to log the
> serial communication. This will allow you to see what is going on. The
> same patch is also used in the pre-compiled test applications on the
> libdivecomputer website.
>
> If you need some info on the protocol look here [2].
>
> [1] http://www.divesoftware.org/libdc/tmp/serial.patch
> [2] http://www.sarnau.info/papers:suunto_d9
>
> Possible areas of interest are the serial_sleep calls (especially the
> one at startup, try to make it larger) and the half-duplex emulation
> (which is basically a variable length sleep).
>
> Jef
>
>
> Jeff - many thanks for the patch - very simple to apply and far more
comprehensive than I had in mind.

Initial results (not sure if I should post here or elsewhere - so anyone
please let me know if feel I ought to shift elsewhere):

Configure: baudrate=9600, databits=8, parity=0, stopbits=1, flowcontrol=0
Timeout: value=3000
DTR: value=1
Sleep: value=100
Flush: queue=3, input=2, output=0
Sleep: value=600
RTS: value=1
Sleep: value=6
Write: timer=7, size=4, data=0F00000F, remaining=0
RTS: value=0
Read: timer=3003, size=0, data=, remaining=0
suunto_vyper2.c:193: Failed to receive the answer.
Sleep: value=600
RTS: value=1
Sleep: value=6
Write: timer=8, size=4, data=0F00000F, remaining=0
RTS: value=0
Read: timer=3004, size=0, data=, remaining=0
suunto_vyper2.c:193: Failed to receive the answer.
Sleep: value=600
RTS: value=1
Sleep: value=6
Write: timer=8, size=4, data=0F00000F, remaining=0
RTS: value=0
Read: timer=3004, size=0, data=, remaining=0
suunto_vyper2.c:193: Failed to receive the answer.
suunto_common2.c:252: Cannot read memory header.


At first glance the calls upstream of the read operation looks deficient to
me.  Size and remaining are both 0 and data looks to be empty. I think
calls to suunto_vyper2_device_packet are being made with zero size which
gets sent through to serial_read.  There the main loop compares that zero
with nbytes (also 0) and so never gets off the ground.  I've a trip to make
this w/end so may not get much further until next week.  I'll try out
suggestions on serial_sleep then.

FYI - At this point I haven't changed anything beyond applying the patch to
libdivecomputer.  If I repeat the log, import call several times behaviour
is consistently as above.

Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120623/a2eed050/attachment.html>