BLE Master-Slave mode can avoid colision?

[zhangkui]

            We have 3 nRF52840 to establish a net. one for master device, One for Master device, One for HUB(Msater-Slave) device, and One for Slave device. The data flow is Slave device--> HUB(Master-Slave) device -->Master device.

             So there is two BLE link: one for the master device and the HUB device. One for the HUB device and the Slave device. For the HUB device , The most important design is to avoid the link colision. I think if the HUB connect the master first,  then connect slave, nRF52840 can arrange the anchor proper to avoid link colision. because if HUB connect the Master device, The master deivce deside the anchor point and notify the HUB the anchor point by connect req PDU. when the HUB decide the anchor pointer for slave connection, It can arrange it proper to avoid colision.

              So when the HUB connect the master device, It will disconnect the Slave device and rescan for the slave device for connect.

              But it fullfilled in the nRF52840 SDK, It just a guess, I can't confirm it. 

              Can Noridc engeneer confirm it, Or tell me the how the WInoff and winsize are caculated in the SDK?

              

             

[Karl Ylvisaker]

Hello,

Yes, the SoftDevice will handle this for you as detailed in the SoftDevice scheduling documentation.
When the SoftDevice is working in the multirole configuration (both central and peripheral role) it will use the Timeslot API to makes sure that there are no collision between the radio usage of each role.

Best regards,
Karl

[zhangkui]

So I want to confirm if the multirole device connect the slave device first , Can Nordic avoid the colision. We have test that it can't. But I think if the multirole device connect the master device first , It will be different.

Can you help confirm it?

[zhangkui]

I want to know whether the same MIN and MAX interval will stop the SDK updata connect parameter?  If the MIN and MAX interval are different values, when a new BLE is connected, Will the SDK of master change the interval and rearrange the anchor point?

[Karl Ylvisaker]

zhangkui said:

If the MIN and MAX interval are different values, when a new BLE is connected, Will the SDK of master change the interval and rearrange the anchor point?

The central is the one that decides which connection parameters that will actually be used - the peripheral can only set some preferences, but the central may choose to ignore the peripheral's preferences. The SoftDevice will perform scheduling so that the different timeslots for the different roles do not overlap as according to the documentation, correct.

Best regards,
Karl

[zhangkui]

Can you tell me the detail scheduling logic that center SDK excute?

We have different dropping data when the hub be center only or be center-peripheral.

So when the hub be a peripheral to connect a center . Maybe the schedule is not as good as be center only.

[zhangkui]

And the schedule can only be excuted when connecting or connection parameter update?

[Karl Ylvisaker]

zhangkui said:

Can you tell me the detail scheduling logic that center SDK excute?

What do you mean when you say center SDK?
If you would like to know more detailed information about the timeslot scheduling please see the SoftDevice scheduling documentation I linked earlier.

zhangkui said:

And the schedule can only be excuted when connecting or connection parameter update?

No, the scheduling happens every time a new timeslot or role is added or removed to the list, but the central will have to use connection parameters that fits into the timeslot that the central role has available.

Best regards,
Karl

[zhangkui]

Maybe I describe inaccurate. The center set anchor point only through connect Ind and connect update request.

If a hub have connected a peripheral. There is two case:

1. A new peripheral connect the hub. Will the hub ajust anchor point of the new connection by sending connect ind to the new peripheral?

2. A new center connect the hub. Will the hub ajust anchor point of the old connection by sending connect update request to the old peripheral?

[zhangkui]

       In the SoftDevice scheduling documentation, It said the centle and peripheral roles are scheduled indepently. I have underline it with red line in the pic below.

       so we think it hub have centle and peripheral roles. there will be collsion.

       But If the hub as peripheral role send connect paramter request message with ReferenceConnEventCount and offset0--offset5 ,  the peripheral role also can schedule  the timeslot .and anchor point.

        I don't know the reason why nordic say there the centrle and the peripheral are scheduled indepently. Can you tell me?

        And I want to know If there is a collision, Will the SDK adjust the timeslot by send connect paramter request message to the centrle or send connect update request to the peripheral?

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this.

zhangkui said:

I don't know the reason why nordic say there the centrle and the peripheral are scheduled indepently. Can you tell me?

This is because it is the central that determines the connection parameters entirely, which means that in the peripheral role the device will have no say in what connection parameters will be used - it can only request to have them updated to its own preferences, which the central device may decline.
So in the multirole setting the SoftDevice is able to neatly schedule multiple central roles, but whenever it enters into a peripheral role it will have to follow the direction of the central in the connection.
The priority of the different events will then follow the table from the scheduling documentation you reference above, to make sure that the connection run as smooth as possible.

zhangkui said:

And I want to know If there is a collision, Will the SDK adjust the timeslot by send connect paramter request message to the centrle or send connect update request to the peripheral?

If there is a collision then the SoftDevice will follow the priorities listed in the documentation - it will not send connection update requests on its own, so if you would like for this to happen you must implement it into your application yourself. I would suggest that you then move the central timeslot that is colliding, since the central is the one that decides (so you do not need to rely on the other central to resolve your collisions).

For more information you could also see the answer by my colleague Einar here.

Best regards,
Karl