CC2652R: Synchronization between central and peripheral

Hello Tomas,

Thanks for reaching out.

To understand your case further, please help me with the following question.

1. How did you setup the guard time? You can see this in Sysconfig under BLE - Advanced Settings - Extended Stack Settings. I suggest to look into our User Guide section here.                                                                                                                                                                                 
2. Is this guard time set for both central devices?
3. What do you mean by synchronization here, does it mean to avoid collisions or to sample sensor data with same timestamp? (I just want to make sure we are referring to the same)

BR,

David.

Hello David,

thanks for reply.

I will try to answer your questions above.

1. The guard time is only allowed for the multirole device.

2. If I set the guard time for the central device, nothing happens. The central device does not seem to know anything about the anchor points of the multirole device.

3. I would like to avoid a collision between the data of the peripherals and the central station. The peripheral sample data should have the highest priority.The delay of sending sampling data should not be more than 40 ms. Unlike central station data, which can be retransmitted.

Best regards,

Tom

I am attaching some screenshots from the oscilloscope (IOC_PORT_RFC_GPO0 a IOC_PORT_RFC_GPO1 signals)

Both peripherals send 3 notifications with dummy data with connection interval 20ms.
Central device sends dummy data with connection interval 31.25ms.
Yellow - PA signal from central (sending data)
Orange - PA signal from peripheral (sending data)
Blue - LNA signal from multirole device (data reception)
Green - PA signal from multirole device (sending data)

The first example where no priorities are set. There are several connection colisions (red rectangle). The yellow rectangle captures the situation when the connection event exceeded the guard time.

In the second example, the central connection priority is set to low. Some connection intervals from the central device are ignored. There is one connection collision.

Maybe this is because the connection fairness mechanism is calculated for a single connection event.

Or the central connection event is at the end of the peripheral connection interval and then there is not enough time to create a peripheral connection event anchor point.

Best regards,

I add that if the connection intervals of the central device and the multirole device were the same, it is only a matter of time before they meet.

The same connection priority will cause peripherals data to be delayed.

Adjusting the central station priority to low will disconnect the central station due to a high number of lost connection attempts.

A better solution than adjusting priorities would be to have synchronous anchor points.

Hello Tomas,

Thanks for the information.

Could you please help me with a couple of extra tests:

1. Could you please try increasing the connection interval to 30 ms for example instead of 20 ms?
2. Could you try setting up the guard time option such that the device randomly schedules the anchor points in time?

I am reviewing this with a college to get more insights as well on your case. Please bear with me.

BR,

David.

Hello David,

Can you please give me more information about the test configuration?

Should the connection interval of both central devices have the same value of 30ms?
Should the guard time be set to default on both central devices?
What should be the connection priority setting (LL_QOS_CONN_TASK_TYPE)?

Tomas

Hello Tomas,

1. Yes, try increasing both connection intervals.
2. Yes, no guard time in both multi-role devices.
3. Lets try first without changing the priority of the central to low.

BR,

David.

Hello David,

I am attaching screenshots from the oscilloscope. The second picture was taken after about 12 minutes.

It can be seen here that the anchor points of both central devices are constantly moving due to the inaccuracy of their RF clock.

Best regards,

Tomas

Hello Tomas,

Understood.

The other peripheral is sending the 3 notifications as well right? Similar to the Orange - PA signal from peripheral (sending data)? Then in the first image we would me missing at least 3 groups of data from the other peripheral. If you setup the central with low priority do you still get a disconnection due to timeout?

BR,

David.

Hello David,

Yes, you are right. Both peripherals send 3 packets of data.

The first image shows how the Connection Fairness algorithm works. There are equal connection priorities, so RF switches between connections.

If the priority of the second central station is changed to low, the RF will not serve the central station as long as it collides with the periphery. This can cause disconnection.

BR,

Tomas

Hello Tomas,

Apologies for the delay due to public holidays. Could you please share the status of your case if it is different? After how long does the disconnection occurs, maybe increasing the timeout disconnection if this is not a constraint to your use case.

BR,

David.

I discovered a few interesting things while testing:

• The device with higher connection priority is always served first.
• Devices with the same connection priority are served alternately.
• Advertisements do not interrupt the peripheral's connection event.
• Periodic advertisements are not synchronized with peripheral anchor points. If they have the same interval as events, they may never be sent.
• There is a short time before the anchor point that can cause the periodic advertisement train to be sent and the connection event to be dropped (no idea why, the peripheral still has a higher priority). Shown in the screenshot below.

Yellow: The Periodic advertisement train is sent.
Red: The Periodic advertisement train is sent and the Connection event is discarded (no idea why)
Blue: The Periodic advertisement train not sent due to peripheral connection priority

These are just my notes. No need to worry about it.

BR,

Tomas