On 12/28/25 18:09, libdivecomputer.vanity547@simplelogin.com wrote:

I am currently testing the download from a Halcyon Symbios device using a BLE connection, and I noticed very frequent timeouts. To compare, the same code works very reliably with Shearwater devices, I own also a Perdix and a Petrel 2.

I noticed the timeout is the same for Halcyon Symbios and Shearwater:

https://github.com/libdivecomputer/libdivecomputer/blob/4f5abbddc66843c83fab... https://github.com/libdivecomputer/libdivecomputer/blob/4f5abbddc66843c83fab...

Each backend uses its own timeout. The default value is typically around 3 seconds, because that's not too short to cause connection problems and not too long to result in unresponsive applications when something does go wrong. Where necessary the actual value can be made shorter or longer, based on our measurements during testing.

In my tests, the Halcyon device often timeouts immediately while negotiating the connection:

``` 2025-12-28 17:17:49.451313+0100 0x90987 Info 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Connecting to device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:49.452269+0100 0x90987 Info 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Successfully opened device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:52.661264+0100 0x90991 Error 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Download failed with status: Timeout (-7) 2025-12-28 17:17:52.661388+0100 0x90987 Info 0x0 36508 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Disconnecting from device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 ```

or after downloading the first dive:

``` 2025-12-28 17:17:05.026093+0100 0x904fa Info 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Connecting to device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:05.027610+0100 0x904fa Info 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Successfully opened device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 2025-12-28 17:17:11.716335+0100 0x904fb Debug 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Dive callback called: size=12524, downloaded so far=0, maxDives=Optional(3) 2025-12-28 17:17:11.725085+0100 0x904fb Debug 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Dive processed successfully, returning 1 (continue) 2025-12-28 17:17:16.944712+0100 0x904fb Error 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Download failed with status: Timeout (-7) 2025-12-28 17:17:16.944939+0100 0x904fa Info 0x0 36165 0 DiveComputerApp: [codes.swiftdivecomputer:Device] Disconnecting from device: C4037FA6-7E9F-962F-79AF-1F4978C8A443 ```

...

From various tests, it looks like Symbios often requires up to 5s. I changed the timeout to 10s and it works quite reliably now.

Can you share a complete download log with the libdivecomputer log level set to debug? Without this more detailed information it's difficult to see where exactly things went wrong.

In my binding I implemented the `set_timeout` callback to set the timeout specifically for this device type, so that I don't need to change/customize the libdivecomputer C source code and maintain a fork.

That's exactly how it supposed to work. Note that the timeout applies to a single read operation. I assume you have implemented that correctly?

However, I am wondering if this is a change you would be interested to apply directly to the libdivecomputer C code, considering you have per-device timeouts. If so, I can likely provide a patch.

It depends on what the underlying problem is. If the timeout is indeed the problem, then we can certainly increase it, but a timeout can also have other causes. During testing I never noticed any timeout related problems and there is also some retry logic present for certain types of errors. If you also generate a debug log after increasing the timeout, we can see exactly how long each request takes. Jef