Hi devs,

I am seeing some variance in the handling of `duration_ms` param to
`ble_gap_connect` (on develop). Below are two log traces that demonstrate
it. In both cases, duration_ms=1280; the first shows the timeout event
(status=13) after 535 ticks (4280 ms), while the second timeout is at a
much more respectable 169 ticks (1352 ms).

```
23352163:[ts=2050146956ssb, mod=4 level=1] GAP procedure initiated:
connect; peer_addr_type=1 peer_addr=46:e9:00:75:ce:af scan_itvl=16
scan_window=16 itvl_min=16 itvl_max=32 latency=0 supervision_timeout=256
min_ce_len=16 max_ce_len=768
23352693:[ts=2054287572ssb, mod=4 level=1] GAP procedure initiated:
advertise; disc_mode=2 peer_addr_type=0 peer_addr=none adv_channel_map=0
own_addr_type=0 adv_filter_policy=0 adv_itvl_min=338 adv_itvl_max=338
adv_data_len=28
23352698:[ts=2054326632ssb, mod=64 level=2] gatt_cli: connection failed;
status=13
```

```
23355205:[ts=2073912596ssb, mod=4 level=1] GAP procedure initiated:
connect; peer_addr_type=1 peer_addr=46:e9:00:75:ce:af scan_itvl=16
scan_window=16 itvl_min=16 itvl_max=32 latency=0 supervision_timeout=256
min_ce_len=16 max_ce_len=768
23355333:[ts=2074912596ssb, mod=4 level=1] GAP procedure initiated:
advertise; disc_mode=2 peer_addr_type=0 peer_addr=none adv_channel_map=0
own_addr_type=0 adv_filter_policy=0 adv_itvl_min=338 adv_itvl_max=338
adv_data_len=28
23355374:[ts=2075232888ssb, mod=64 level=2] gatt_cli: connection failed;
status=13
```

I remember at some point some changes that were supposed to make the
timeouts more reliable - any ideas what might be causing this much variance?

Cheers,
simon

Reply via email to