CC1352R: Updating BLE Scan Response Data Prevents BLE Beacons from Being Sent

Hi Peter,

First, thank you very much for giving us a reproducible example. That helps us a lot. I do not know why it behaves like so, at the moment.

As you probably read in the Generic Access Profile (GAP) document, and mentioned, you can indeed update "blindly" the scan response data, in a controlled fashion:

https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_20_00_29/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gap-cc13xx_cc26xx.html#directly-manipulating-a-buffer-while-advertising-is-enabled

By modifying the example you provided, at line 436:

status = GapAdv_setEventMask(advHandle1,
                                     GAP_ADV_EVT_MASK_START_AFTER_ENABLE |
                                     GAP_ADV_EVT_MASK_END_AFTER_DISABLE |
                                     GAP_ADV_EVT_MASK_SET_TERMINATED |
                                     GAP_ADV_EVT_MASK_END);

and line 501:

if (event == GAP_EVT_ADV_END)
{
  scanResData1[27]++;
}

I can update the scan response data and see both beacons.

Would the following way work for you?

Regards,

Arthur

Arthur,

Thank you for your prompt response! 

The workaround that you suggested sounds feasible but not ideal.
If I understand correctly, the GAP_EVT_ADV_END event occurs just after a beacon is sent. If I wait to update the scan response until after each advertisement, then the scan response data is at least one advertisement interval old (in this case 1 second). If would be better if I could update the scan response as new sensor data becomes available without a 1-second latency.

I suppose I could use the GAP_EVT_ADV_END event to start a timer that would trigger an update to the scan response just prior to the next advertisement interval, but that seems unnecessarily complicated. I would rather just update the scan response each time I receive new data from an external sensor.

I am interested to know if you are able to find the root cause of this issue. In the mean time, I will use the workaround that you suggested or reduce the advertisement interval on one of the beacons.

Thanks for your help!
Peter

Hi Peter,

We will of course be looking for the root cause, and share it with you, as it is of interest to us!

Regards,

Arthur

Arthur,

Any update on the root-cause investigation? I am anxious to find an optimal solution.

Thank you!
Peter

Hi Peter,

We are still looking for it, I have checked with other people and nobody has seen such behavior, yet. Please bear with us.

Regards,

Arthur

Hi Peter,

From what I understood, it seems like the BLE Stack is discarding commands when its start time might collide with another one.

I modified your workaround a bit. By allowing the second advertisement time to be lenient in the configuration, like so:

We then tell the stack that its okay to wait a bit for the next advertisement. Now, when observing the packets, we see that both advertisements are being sent at a 1s interval because the advertisement is being sent immediately upon re-activation.

The Scan_RSP data is also getting updated.

Let me know if that works for you.

Regards,

Arthur

Arthur,

Thank you for your response. The approach you suggested seems to work but is still not ideal.

With this configuration, I have observed that the beacon interval is only 1-second so long as the payload is updated consistently. The interval drops to 500ms if the payload is not updated (e.g. if no new sensor data is available). Power usage is critical in our application, so we would like to maintain a consistent advertisement interval regardless of whether the payload needs to be updated.

Also, can you confirm whether changing the maximum interval has any effect? gap_advertiser.h states that GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX "will be ignored as the GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN is always used": https://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/doxygen/ble/html/group___gap_adv___params.html#ggaa58afceb7db92df94b51adb77393744aa27bc46d1fbcc99ce9ed00d9b6ec47dca

Thank you for your help!
Peter

Hi Peter,

It then means we have not found the root cause yet.. We will have to keep looking.

However, I can confirm that you are right about the GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX. It indeed does not have any effect.

Regards,

Arthur

Hi Peter,

It seems that this issue has been documented on our side as well, I will share more information once I find the data.

Regards,

Arthur

Thank you for the update! I look forward to hearing more.

Peter

Arthur R☑️ any more information on this topic? I has been almost a month since I've heard from you.

Thanks,
Peter

Hi Peter,

The issue I was talking about was supposed to have been fixed. Unfortunately, it seems like this was not the same one your experienced.

Regards,

Arthur

Arthur,

Are you and/or your team continuing the root-cause investigation then? Please continue to keep me informed of any updates.

Thanks,
Peter

Hi Peter,

We'll keep you updated, I will try to push it more to the stack steam.

Regards,

Arthur

Arthur,

Can you provide a link to this issue in your internal ticketing system (e.g. https://sir.ext.ti.com/jira/browse/EXT_EP-9743) so that I can monitor its progress?

Thank you for all your help!
Peter

Hi Peter,

Now you can finally monitor the ticket's progress: https://sir.ext.ti.com/jira/browse/EXT_EP-11985

I hope now it should be soon moving.

Regards,

Arthur