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