Connection event collision

RE: Connection event collision

Kenneth — Thu, 31 May 2018 12:53:28 GMT

Hi, we follow the specification, so if it's in the spec, then you can assume that is the way it is done.

The stack will stay in receive mode for a long enough period to ensure it should be able to receive a packet, even compensating for clock drift (window widening).

RE: Connection event collision

Stayhungry — Thu, 31 May 2018 12:06:09 GMT

Yes, I know that softdevice will help us deal with all this, I just curious how to deal with it.

" The peripheral will listen at every anchor point until a packet is received. "

Do you mean that the slave has been turned on radio after the anchor point until the slave receives paket or timeout?

In Vol 6, Part B page 2644: At each subsequent connection event, the slave should listen for windowWidening before the start of the slaveExpectedAnchorPoint and until windowWidening after slaveExpectedAnchorPoint for the master’s anchor
point.

Or if slave doesnt receive packet until windowWidening after slaveExpectedAnchorPoint for the master’s anchor point, the slave will judges the data packet is lost at this moment.

I think my problem will eventually be attributed to two problems:

1. What criteria does the master use to determine that it has not received a packet from the slave?
2. What criteria does the slave use to determine that it has not received a packet from the master?

Can you help me, I did not find the clear answer I wanted in the spec.

RE: Connection event collision

Kenneth — Thu, 31 May 2018 11:24:04 GMT

Hi, this is fully handled by the BLE softdevice stack, and not something the application need to consider.

1. The peripheral will listen at the anchor point only when there is no packet from the central.

2. The peripheral will listen at every anchor point until a packet is received or supervisor timeout. If supervisor timeout then link is lost.