Connection event collision

[Stayhungry]

For the connection event collision, I have some doubts, I hope to get help in devzone

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.sds%2Fdita%2Fsoftdevices%2Fs130%2Fmultilink_scheduling%2Finitiator_timing.html&cp=2_3_1_0_14_1

1, Figure 2 in above link, this situation will cause the slave to miss the anchor point, C0, then how to ensure that when sending C0 behind CREQ, the slave is in the listening state?

BLUETOOTH SPECIFICATION Version 5.0 | Vol 6, Part B page 2638
The slave listens for the packet sent by its master at the anchor point.

According to the spec, I don't know if the slave is starting a listener at the anchor point, or listening from this point until the end of the connection event.

2, about slave closes the event

BLUETOOTH SPECIFICATION Version 5.0 | Vol 6, Part B page 2643
If a packet is not received from the master by the slave, the slave will close the connection event.

According to spec,i dont know slave is based on what to determine it does not receive packet, like figure 2 in above link, will be judged by the slave can not receive and close connection event?

hope nordic can help answer these two questions, thanks.

[Kenneth]

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.

[Stayhungry]

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.

[Kenneth]

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).