• State Suggested Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 200 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 339900
Options

When does a change of which PAwR subevents to subscribe to, take place?

Jakob Ruhe

I am evaluating Bluetooth Periodic Advertising with Responses (PAwR) using a NRF52840 Development Board. I am very satisfied with the development environment and the nRF Connect SDK including Zephyr! 

I use the Bluetooth soft device stack and toolchain version v2.9.0.

One scenario I am looking at is the following:

1. A node is synced to a PAwR train that consists of (for example) 25 subevents in a period.

2. The node only subscribes to subevent 0 in this train.

3. At a random point in time the node wakes up and decides that it wants to subscribe to all 25 subevents.

When I am testing this scenario, it looks like the first subevent the node receives is always subevent 0.

I would like to know why the node seems to always wait until the next period before subscription of all subevents takes place.

Perhaps there is a logical reason as to why it is designed like this or perhaps my measurements are just wrong.

I look forward to get your input on this!

Parents
  • 0

    Hi Jakob
    I have asked internally and will update you as soon as I have something
    regards

    Runar

  • 0 in reply to runsiv

    I got an update from our developers:
    They have managed to reproduce the issue, the issue is that if the currently

    There is an issue if the the currently synced subevent is a part of the new list the Host wants to be synced to. Then it may take the entire periodic interval before the new list is applied. 

    It doesn't look like it is breaking the specification, but it may cause a bit decreased performance depending on use case.

     

    It is not the best workaround, but it is a workaround,  if the you excludes subevent 0 from the new list, that is: subscribe to subevents 1, 2, 3, ..., 24, it should be able to start receiving the new synced subevents sooner. But he will not be synced to subevent 0.

    Regards Runar

Reply
  • 0 in reply to runsiv

    I got an update from our developers:
    They have managed to reproduce the issue, the issue is that if the currently

    There is an issue if the the currently synced subevent is a part of the new list the Host wants to be synced to. Then it may take the entire periodic interval before the new list is applied. 

    It doesn't look like it is breaking the specification, but it may cause a bit decreased performance depending on use case.

     

    It is not the best workaround, but it is a workaround,  if the you excludes subevent 0 from the new list, that is: subscribe to subevents 1, 2, 3, ..., 24, it should be able to start receiving the new synced subevents sooner. But he will not be synced to subevent 0.

    Regards Runar

Children
Related
Terms of service