CC2642R: CC2642R: [CLAOA][Multi tag] CREATE_SYNC fail issue(didn't get SYNC_EST)

In SDK5.2, i modified parameter skip to "100", that will cause the coordinator to reply IQ data once every 100 CTEs.

This parameter currently has a bug?

Hi,

Valery Wu said:

In SDK5.2, i modified parameter skip to "100", that will cause the coordinator to reply IQ data once every 100 CTEs.

This is actually the way this parameter is intended to work. This should have freed-up some air time.

Once you have all the devices synced, you can update the skip parameter to its original value.

Best regards,

thx your comment.

   What command can used to update parameter "skip"?

    Sometimes we may lost sync when catch IQ, so i think we still need the "Skip" parameter as a value for the maximum loss limit , not always ignore these packets

Hi Valery,

Actually, it is not possible to modify the parameter skip after synchronization is established. It requires to drop the synchronization and re-establish.

Best regards,

1.What is the SKIP parameter used in your definition?

as a value for the maximum loss limit or always ignore these packets?

if used for maximum number of allowed losses, SDK5.2 seems to have some bugs

2.I'm not quite able to understand why it sometimes takes more than 4 seconds or more to create sync, can you explain what create_sync actually does and how many periodicity packets need to sync before it's done?

3.if the RX period will get interrupted by another synchronized devices,  some tags may always fail to sync in the worst case when the number of tags is large and the interval is short.(we used 50ms)

Can you tell me how to calculate a suitable limit of tags when the interval time = 50ms, and how long the RX period cannot be interrupted to avoid longer establishment time?

================================================================================

In addition to that, synchronization establishment requires the device to listen on the primary channels for a fairly long time. When several devices are synchronized, this Rx period gets interrupted by the reception of the messages of the already synchronized devices. As a consequence the synchronization establishment time may become longer.

===================================================================

Hi Valery,

Thank you for your patience.

1- It sounds like we have a hard time understanding each other with the terms "synchronization timeout" and "skip". Let me try to clarify this 

The definitions I have being using for these parameters are the ones given in the Bluetooth Specifications (BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E, §7.8.92).

• The Skip parameter specifies the number of consecutive periodic advertising packets that the receiver may skip after successfully receiving a periodic advertising packet.
• The Sync_Timeout parameter specifies the maximum permitted time between successful receives. If this time is exceeded, synchronization is lost.

2- The synchronization establishment duration depends on a three main parameters:

• The long range advertisement interval
• The periodic advertisement interval
• The duration the scanning device spends in listening mode

Here, my hypothesis was the air time available for the scanner is too small. In other words, the scanner spends too much time listening for the periodic advertisements it is connected with, hence does not have time to listen for new advertiser. To confirm/reject this hypothesis, I would suggest to enable the radio debugging signals (you can find the procedure here).

The second hypothesis I am thinking about is a too big long range advertisement interval.

3- I haven't any resource giving this value.
Based on the radio debugging signals I have, the reception of each periodic advertisement takes ~2.5ms.

• Based on the number of devices synchronized, you can compute the average air time is left
• Based on the long range advertisement interval, you can estimate the average time to catch the long range advertisement
• Based on the number of devices synchronized, you can estimate the probability for collisions between already synchronized devices and the new device. These collisions may delay the synchronization establishment.

I hope this will help,

Best regards,