bluetooth low energy connection events

A connection event is used for one slave only. There is no hard limitation on the time of the connection event, except it has to end before the next one.  However, the implementations on both the master and the slave side may limit the number of packets to be transmitted in each interval. On the TI CC254x BLE stack, I believe there is a limit of 4 packets per connection interval.

thanks for the answer,

can you explain me better what it means "A connection event is used for one slave only"? What happens if there are more slaves?

Is it possible to increase the number of the packets that can be trasmit in each interval on On the TI CC254x BLE stack?

A connection exists between one master and one slave. A master may have several connections. In that case, it has to set up one connection event per slave. The exact schedule is up to the master implementation, but having many connections will reduce the maximum duration of a connection interval that can be supported, since it has to interleave the connection events.

Note that dual-mode devices also have to include BR/EDR (legacy Bluetooth) in their schedule. This means that the duration they can support for each connection event will be even more limited.

I don't think there is any way to increase the number of packets per event supported on the CC254x. Lowering the connection interval will increase the supported throughput.

thanks so much for the answers.

can you give me a numerical example?

1 master and two slave, connectionInerval1 = 1s and connectionInterval2 = 2s. What happens?

In this case thare is a connection event each 1s for the slave1 and each 2s for the slave2. Bat the two connection events are superimposed.

|---||---||---||---||---||---||---||---| slave1

|-------|||-------|||-------|||-------| slave2

Exactly what would happen here is implementation specific and decided by the master. For instance it could choose to send the anchor points for connection 1 at times 1000 ms, 2000 ms, 3000 ms, 4000 ms, 5000 m,s ... and the anchor points for connection 2 at times 1500 ms, 3500 ms, 5500 ms, ... But it could also choose to send the anchor points for connection 1 at times 1000 ms, 2000 ms, 3000 ms, 4000 ms, 5000 m,s ... and the anchor points for connection 2 at times 1010 ms, 3010 ms, 5010 ms, ...

I am not sure what the TI BLE stack master implementation would do in this case.

if no limits are imposed to the number of packets in each connection event, it is possible that the slave1 is still sending packets when the master sends the anchor points for connection to the slave 2?

If the master has done a poor job of limiting the connection event in time, there is a chance that one packet is sent from the slave when the master is not listening (the master would probably be violating the spec in this case, as I explain below). If you have not already done so, you should read Volume 6, Part B, Section 4.5 (in particular 4.5.1 and 4.5.6) of the Bluetooth Core 4.0 spec (https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737).

Once the master stops responding to the slave, the slave will also stop sending packets in that connection event. The spec says: "The master shall ensure that a connection event closes at least T_IFS before the anchor point of the next connection event." For a master running several connections, my interpretation is that the next connection event may be on another connection, even though the spec is not very clear on this. So the master should stop sending packets in time so that the slave does not send another packet after the master has stopped listening. It should also set the MD bit of the last packet it sends to 0 to indicate that it will close the connection event.

thanks so much.

there is a way to know the real number of the packets that can be trasmit in each interval on On the TI CC254x BLE stack?

i've used the GATT_Notification(connHandleVector,&notify,FALSE); and i've seen that:

three packets are sent if the payload is max,

four packets are sent if the payload is min,

You are probably right that three packets from slave to master is the maximum with our stack implementation using the maximum payload. With other master implementations, there is no guarantee on what number of packet the slave is allowed to send per connection event, other than at least one.

thanks a lot to make learn me more about BLE.

i've another question

http://e2e.ti.com/support/low_power_rf/f/660/t/189662.aspx

i hope you can help me again.