s130-0.5.0 disconnect when central fail to connect another central

RE: s130-0.5.0 disconnect when central fail to connect another central

Petter Myhre — Tue, 30 Jun 2015 11:14:48 GMT

I'm assuming you are using High Duty Cycle Directed Advertising, please see Vol 6, Part B, Section 4.4.2.4.2 in the Bluetooth Core Specification.

It seems to me the behaviour actually is as expected. Please see this section in the S130 SoftDevice Specification:

Directed advertiser is different compared to other advertiser types because it is not periodic. The scheduling of the single event required by directed advertiser is done in the same way as other advertiser type events. Directed advertiser is also started as early as possible, and its priority (refer to Table 1) is raised if it is blocked by other roles multiple times.

The directed advertiser event will be scheduled as a single event, and it will require a timeslot of 1.28s. In this timeslot no other events will be handled. This means that with a connection supervision timeout of 100ms you will lose the connection.

If you need to use High Duty Cycle Directed Advertising I think you need to increase the connection supervision timeout. You can also look into Low Duty Cycle Directed Advertising, described in Vol 6, Part B, Section 4.4.2.4.1 in the Bluetooth Core Specification.

RE: s130-0.5.0 disconnect when central fail to connect another central

bingo — Tue, 30 Jun 2015 01:00:30 GMT

Hi Petter, as you understand, 3 is not expected behaviour. I think connection between A1 and B1 shounld not terminated. Here is the list of connection parameters between A1 and B1: conn_params.min_conn_interval = 10; conn_params.max_conn_interval = 20; conn_params.slave_latency = 0; conn_params.conn_sup_timeout = 100;

I will add issue 1 as a separate question, sorry for the inconvenience.Thank you for your response.

RE: s130-0.5.0 disconnect when central fail to connect another central

Petter Myhre — Mon, 29 Jun 2015 12:59:28 GMT

Issue 1 seems to have nothing to do with 2, 3 and 4. Please add this as a separate question if you are unsure about it.

I'm not sure I understand exactly what the issue with 2, 3 and 4 is, since you haven't asked any specific questions. But to me it seems scenario 2 and 4 is expected behaviour, but 3 is not? Have you tried to sniff the connection between A1 and B1 to see what is happening? What kind of connection parameters are you using between A1 and B1? Connection interval and connection supervision timeout?