[PATCH] Fix reading Cressi Leonardo data.

Mon Oct 9 02:35:23 PDT 2017

On 2017-10-03 23:58, Vsevolod Velichko wrote:
>> Can you send me some logs from those experiments? It will help me 
>> understand what's going on.
> 
> Sure. I've attached them with corresponding outputs and dumps from
> wireshark. See the comments about differences and effects at the
> beginning of each .py file.

With those python scripts it's a bit harder to see what's going on, 
compared to the libdivecomputer logging where everything is in a single 
file. It's also not exactly the same. Especially the reading is subtle 
different. You have some 10ms sleep calls there. I don't think that will 
make a difference, but you never know. After all, it's some subtle 
difference that we're trying to find.

Have you tried my suggestion of doing the DTR toggling in the existing 
retry code? Something like the attached patch (the pinging is commented 
out, so try with and without). That should behave almost the same as 
your working code. It will do the DTR toggling during setup. And as long 
as the packet fails, it will keep doing the DTR toggling. But once the 
first packet is received correctly and the connection is stable, it's no 
longer done except when packets start to fail again.

Can you try to capture the serial communication between the cressi 
application and the dive computer. But with a serial sniffer instead of 
the wireshark. I would like to have a look at the timings, but ideally I 
would like to avoid having to look into the details of the ftdi (and 
usb) protocol overhead.

If you have a 32-bit windows, then you can use the freeware Portmon 
application, as described here:

http://libdivecomputer.org/contribute.html#protocol

Note that in order to capture timestamps, you need to use "File -> Log 
to File As..." before starting the capture. When using "File -> Save 
As..." afterwards, it only records the duration of each request, and 
that's not what we need.

The alternative (on both 32 and 64 bit Windows) is a commercial tool 
like Eltima. It has a time limited trial version that can do everything 
we need.

https://www.eltima.com/products/serial-port-monitor/

I looked again at my portmon capture files. Before sending the first 
read command, the serial port is configured as follows:

2223    0.00000037  IOCTL_SERIAL_GET_BAUD_RATE  SUCCESS
2224    0.00000032  IOCTL_SERIAL_GET_LINE_CONTROL   SUCCESS
2225    0.00000030  IOCTL_SERIAL_GET_CHARS  SUCCESS
2226    0.00000029  IOCTL_SERIAL_GET_HANDFLOW   SUCCESS
2227    0.00050920  IOCTL_SERIAL_SET_BAUD_RATE  SUCCESS Rate: 115200
2228    0.00143484  IOCTL_SERIAL_SET_RTS    SUCCESS
2229    0.00143572  IOCTL_SERIAL_SET_DTR    SUCCESS
2230    0.00134276  IOCTL_SERIAL_SET_LINE_CONTROL   SUCCESS StopBits: 1 
Parity: NONE WordLength: 8
2231    0.00000073  IOCTL_SERIAL_SET_CHAR   SUCCESS EOF:0 ERR:0 BRK:0 
EVT:0 XON:11 XOFF:13
2232    0.00140348  IOCTL_SERIAL_SET_HANDFLOW   SUCCESS Shake:1 
Replace:40 XonLimit:64 XoffLimit:64
2233    0.00000077  IOCTL_SERIAL_GET_BAUD_RATE  SUCCESS
2234    0.00000048  IOCTL_SERIAL_GET_LINE_CONTROL   SUCCESS
2235    0.00000033  IOCTL_SERIAL_GET_CHARS  SUCCESS
2236    0.00000033  IOCTL_SERIAL_GET_HANDFLOW   SUCCESS
2237    0.00000034  IOCTL_SERIAL_SET_QUEUE_SIZE SUCCESS InSize: 640 
OutSize: 640
2238    0.00000039  IOCTL_SERIAL_SET_TIMEOUTS   SUCCESS RI:-1 RM:0 RC:0 
WM:0 WC:500
2239    0.00000106  IOCTL_SERIAL_GET_COMMSTATUS SUCCESS
2240    0.00053458  IOCTL_SERIAL_CLR_DTR    SUCCESS
2241    0.00138172  IOCTL_SERIAL_SET_DTR    SUCCESS
2242    0.00030484  IOCTL_SERIAL_CLR_DTR    SUCCESS
2243    0.00000128  IOCTL_SERIAL_GET_COMMSTATUS SUCCESS
2244    0.00000221  IOCTL_SERIAL_GET_COMMSTATUS SUCCESS
2245    0.00047142  IRP_MJ_WRITE    SUCCESS Length 14: 7B 31 30 30 30 30 
30 31 33 39 33 30 36 7D
2246    0.00000090  IRP_MJ_FLUSH_BUFFERS    SUCCESS

And then, just before the dump command it reconfigures the port as 
follows:

2372    0.00000115  IOCTL_SERIAL_PURGE  SUCCESS Purge: RXABORT RXCLEAR
2373    0.00000048  IOCTL_SERIAL_GET_COMMSTATUS SUCCESS
2374    0.00000032  IOCTL_SERIAL_GET_BAUD_RATE  SUCCESS
2375    0.00000048  IOCTL_SERIAL_GET_LINE_CONTROL   SUCCESS
2376    0.00000030  IOCTL_SERIAL_GET_CHARS  SUCCESS
2377    0.00000030  IOCTL_SERIAL_GET_HANDFLOW   SUCCESS
2378    0.00054569  IOCTL_SERIAL_SET_BAUD_RATE  SUCCESS Rate: 115200
2379    0.00126694  IOCTL_SERIAL_SET_RTS    SUCCESS
2380    0.00147820  IOCTL_SERIAL_CLR_DTR    SUCCESS
2381    0.00145135  IOCTL_SERIAL_SET_LINE_CONTROL   SUCCESS StopBits: 1 
Parity: NONE WordLength: 8
2382    0.00000065  IOCTL_SERIAL_SET_CHAR   SUCCESS EOF:0 ERR:0 BRK:0 
EVT:0 XON:11 XOFF:13
2383    0.00277028  IOCTL_SERIAL_SET_HANDFLOW   SUCCESS Shake:0 
Replace:40 XonLimit:1024 XoffLimit:1024
2384    0.00000075  IOCTL_SERIAL_GET_BAUD_RATE  SUCCESS
2385    0.00000047  IOCTL_SERIAL_GET_LINE_CONTROL   SUCCESS
2386    0.00000033  IOCTL_SERIAL_GET_CHARS  SUCCESS
2387    0.00000033  IOCTL_SERIAL_GET_HANDFLOW   SUCCESS
2388    0.00000374  IOCTL_SERIAL_SET_QUEUE_SIZE SUCCESS InSize: 80960 
OutSize: 640
2389    0.00000035  IOCTL_SERIAL_SET_TIMEOUTS   SUCCESS RI:-1 RM:0 RC:0 
WM:0 WC:500
2390    0.00000074  IOCTL_SERIAL_GET_COMMSTATUS SUCCESS
2391    0.00000291  IOCTL_SERIAL_GET_COMMSTATUS SUCCESS
2392    0.00052760  IRP_MJ_WRITE    SUCCESS Length 8: 7B 31 32 33 44 42 
41 7D
2393    0.00000105  IRP_MJ_FLUSH_BUFFERS    SUCCESS

This is almost identical, except for:

The "Shake" setting in the IOCTL_SERIAL_SET_HANDFLOW is different 
(changes from 1 to 0). This values corresponds to the SERIAL_DTR_CONTROL 
bit. So that causes the change from SET_RTS to CLR_DTR a few lines 
earlier. Since DTR was already cleared, this leaves DTR unchanged.

In IOCTL_SERIAL_SET_QUEUE_SIZE, the input queue size changes from 640 to 
80960 bytes. This call communicates the recommended buffer size to the 
underlying driver. Libdivecomputer doesn't do this. The function to 
configure this existed in the past, but was removed a few years ago. It 
was windows only anyway. Linux doesn't have such an api, so I doubt this 
is the problem.

In the first case, the cressi application does the double DTR toggle 
(CLR_DTR , SET_DTR and CLR_DTR), but not in the second case. So 
basically the DTR setting doesn't change in the second case.

So nothing really special here. The only missing part for me is the 
timing info.

BTW, I also remember we had another timing related issue in the past on 
Linux with FTDI devices. It turned out to be due to different default 
values for the FTDI low-latency setting. See commit 
f0faebb3a1ee5ae1cdeffac2cd7afe78a68b46c9 for the details. Maybe this is 
also relevant here?

>> Not sure why, but there are two full downloads in there. I also don't 
>> know what that last command does.
> 
> I tested it and it is a command to force DC to turn off. So computer
> probably was later reattached, and Cressi software automatically
> starts download when connection is detected.

Okay, that may be something to look into later.

PS: I'm leaving for a dive trip to Bonaire tomorrow, so I may not be 
able to answer emails for the next week.

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip_leonardo_retry.patch
Type: text/x-diff
Size: 2091 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20171009/40697035/attachment.patch>