CC2642R: Advertising Data ID is not changed without GapAdv_loadByHandle

Tetsuo,

I tested a simple_peripheral project modified with Extended Advertising and Coded PHY but I could not see the issue here. The channel index was properly modified through the series of advertisements. Also, the process of disable/enable does not happen unless the board is connected/disconnected.

Please check attached the sniffer capture and the project I am using, perhaps you can spot differences in configuration that may be relevant for your case?

Regards,

Rafael

ExtAdv_CodedPHY_Index.zip

simple_peripheral_CC26XR1_LAUNCHXL_tirtos_ticlang_ExtAdv_LR.zip

desouza,

I confirmed your sniffer capture and project.
But advertising DID is not updated, it's always same value.
This was the problem that I wrote at first, and occured even if my software updated advertising data in every advertising event.

Regards,

Tetsuo Tatsugami

Tetsuo,

In the sniffer log I sent, I am neither changing data nor responding to a scan, so the Advertisement DID would not change.

However, when I added a simple_central to the mix I noticed the Advertisement DID changed normally. In the attached scan, the generated DID is 4C3. At time frame 85.773 871 750, the simple_central scans and its response has a changed DID (8C3).

In subsequent advertisement packets (advertising is still enabled in the simple_peripheral), the DID is back to the original value (4C3). 

What is still unclear to me from the specification is if the change is only required to happen in response to a scan or if it needs to be changed permanently after that. I will consult with some colleagues to confirm that.

Regards,

Rafael

ExtAdv_CodedPHY_AdvDID_change.zip

Rafael,

Thanks for your information.
Advertising DID in AUX_SCAN_RSP should be updated if it was scannable and scanned by central.
But my peripheral software is non-scannable same as yours.
So Advertising DID in AUX_ADV_IND should be updated regardless of the scanning from central, I think.

BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B
4.4.2.11 Using AdvDataInfo (ADI)
The AdvDataInfo (ADI) field is used to identify advertising sets and duplicate AdvData in either the AUX_ADV_IND or AUX_SCAN_RSP PDUs.
For scannable advertising events using the ADV_EXT_IND PDU, AdvData is not permitted in the AUX_ADV_IND PDU so the ADI only refers to the AdvData contained in the AUX_SCAN_RSP PDU.

Regards,
Tetsuo Tatsugami

Tetsuo,

The dev team is out in a national holiday and I will be able to get a reply only next week. Sorry.

Regards,

Rafael

Rafael,

Did the dev team start investigating this problem? 
Please let me know if you have any updated info.

Regards,
Tetsuo Tatsgami

Tetsuo,

The dev team confirmed that GapAdv_loadByHandle() is one of the scenarios where the DID changes, therefore the behaviour mentioned in your original post is expected.

The entirety of their comment is as follows:

The ADI consist of 2 parameters:

• SID – a value between 0 to 15 (4 bits) sets by the Host.
• DID – a value between 0 and 0xFFF (12 bits) sets randomly by the Controller.

The controller updates the DID only if the Host execute the following commands:

• In case of HCI Test application – use HCI_LE_SetExtAdvDataCmd or HCI_LE_SetExtScanRspDataCmd
• In case of Host Test application – use GapAdv_loadByHandle

I checked both cases and it works fine.

(Host and controller are the two cores of the device)

With this, I suspect you need to use the API to actually change the DID.

Regards,

Rafael

Rafael,

• In case of HCI Test application – use HCI_LE_SetExtAdvDataCmd or HCI_LE_SetExtScanRspDataCmd

Could you please tell me how to use them? I could not find documents or header file in SDK.
Can I use them in peripheral software?

• In case of Host Test application – use GapAdv_loadByHandle

There is another problem in that case as I wrote at first in this thread.
It cannot avoid collisions because the channel index is always zero.
The channel index was updated if I didn't use GapAdv_loadByHandle().

It is recommended that sufficient channel diversity is used to avoid collisions in BLUETOOTH CORE SPECIFICATION.
>BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B
>4.4.2.1 Advertising channel index selection
>For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising channel index used in the Channel Index subfield of the AuxPtr field is implementation specific.
>It is recommended that sufficient channel diversity is used to avoid collisions.

Regards,
Tetsuo Tatsugami

Tetsuo,

The first case is for HCI test (done via an external device) - something similar to what is seen at the Btool Advanced Commands utility. This is more commonly used when the product is going through certification - I simply provided this for completion.

The second case is indeed strange, given that in my sniffer capture I don't see this - the channel index walks around without trouble. I am not sure if you have done so, but did you run my project to see if you see a static or random channel ID?

Regards,

Rafael

Rafael,

Your project simple_peripheral_CC26XR1_LAUNCHXL_tirtos_ticlang_ExtAdv_LR.zip executes GapAdv_loadByHandle in GAP_DEVICE_INIT_DONE_EVENT.
It is NOT executed in every advertising event.
In that case, the channel index is updated correctly, but DID (Data ID) is NOT updated.

My project executes GapAdv_loadByHandle to update DID (Data ID) in every advertising event. 
Then, the channel index is always zero.

I attached my test project that the channel index is always zero.
You don't need any key operation, please just run,
And it starts advertising automatically and executes GapAdv_loadByHandle in every advertising event.

Regards,
Tetsuo Tatsugami
simple_peripheral_CC26X2R1_LAUNCHXL_tirtos_ccs.zip

Tetsuo,

Please apologize for the delay; unfortunately I don't have the sniffer with me and therefore couldn't experiment with the different scenarios mentioned by you, but I forwarded these concerns to the dev team.

Regards,

Rafael

Rafael and the dev team,

It's okay.
Will it take a few days for the dev team to confirm?
Please tell me if you have any updated info.

Regards,
Tetsuo Tatsugami

Tetsuo,

Tetsuo Tatsugami said:

In that case, the channel index is updated correctly, but DID (Data ID) is NOT updated

Yes, this is expected and confirmed by the dev team. The DID is only updated when the GapAdv_loadByHandle() is called. 

Tetsuo Tatsugami said:

My project executes GapAdv_loadByHandle to update DID (Data ID) in every advertising event.

I haven't heard from the dev team yet (I'll ping them again) and I couldn't get ahold of a packet sniffer, but in the project you sent it seems you are duplicating operations on the modification of the advertising events. For example, the GapAdv_prepareLoadByHandle() already disables advertisements for that particular handle, rendering the previous call to GapAdv_disable() unnecessary. Same thing for the GapAdv_loadByHandle() and GapAdv_enable().

I also modified your project to change advertisement data every 100 events, so it is given time to advertise and better track the changes.

I will ask a colleague to collect the data capture from the sniffer and see how these minor modifications affect the outcome. I will keep you posted on the results.

Best regards,

Rafael

simple_peripheral_CC26X2R1_LAUNCHXL_AdvChg_TI.zip

Rafael said.
Yes, this is expected and confirmed by the dev team. The DID is only updated when the GapAdv_loadByHandle() is called. 

How can I implement that DID and the channel index are both updated correctly at the same time?
They should be both updated for each purpose.
If we don't implement them at same time, it's violation for the Bluetooth Core Specification.

>BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B
>4.4.2.1 Advertising channel index selection
>For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising channel index used in the Channel Index subfield of the AuxPtr field is implementation specific.
>It is recommended that sufficient channel diversity is used to avoid collisions.

It cannot avoid collisions if the channel index is not updated.

>4.4.2.11 Using AdvDataInfo (ADI)
>The AdvDataInfo (ADI) field is used to identify advertising sets and duplicate AdvData in either the AUX_ADV_IND or AUX_SCAN_RSP PDUs.
>...
>The Advertising DID for a given advertising set shall be initialized with a randomly chosen value.
>Whenever the Host provides new advertising data or scan response data for a given advertising set (whether it is the same as the previous data or not), the Advertising DID shall be updated.
>The new value shall be a randomly chosen value that is not the same as the previously used value.

The receiver(central) cannot identify the changes of advertising data, if peripheral didn't update DID(advertising Data ID).
For example, if I set SCAN_FLT_DUP_ENABLE using GapScan_setParam() in simple_central, the central application cannot get advertinsg data because BLE stack does not notify advertising data to application because DID is not updated.

Regards,
Tetsuo Tatsugami

Rafael,

Could you tell me current status?

Regards,
Tetsuo Tatsugami

Rafael,

It's been days since then, so I'll write it again.

Rafael said.
Yes, this is expected and confirmed by the dev team. The DID is only updated when the GapAdv_loadByHandle() is called. 

How can I implement that DID and the channel index are both updated correctly at the same time?
They should be both updated for each purpose.
If we don't implement them at same time, it's violation for the Bluetooth Core Specification.

>BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B
>4.4.2.1 Advertising channel index selection
>For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising channel index used in the Channel Index subfield of the AuxPtr field is implementation specific.
>It is recommended that sufficient channel diversity is used to avoid collisions.

It cannot avoid collisions if the channel index is not updated.

>4.4.2.11 Using AdvDataInfo (ADI)
>The AdvDataInfo (ADI) field is used to identify advertising sets and duplicate AdvData in either the AUX_ADV_IND or AUX_SCAN_RSP PDUs.
>...
>The Advertising DID for a given advertising set shall be initialized with a randomly chosen value.
>Whenever the Host provides new advertising data or scan response data for a given advertising set (whether it is the same as the previous data or not), the Advertising DID shall be updated.
>The new value shall be a randomly chosen value that is not the same as the previously used value.

The receiver(central) cannot identify the changes of advertising data, if peripheral didn't update DID(advertising Data ID).
For example, if I set SCAN_FLT_DUP_ENABLE using GapScan_setParam() in simple_central, the central application cannot get advertinsg data because BLE stack does not notify advertising data to application because DID is not updated.

Regards,
Tetsuo Tatsugami

Hi Rafael,

Can we have any update for this, please?

Tatsugami-san needs to resolve this issue as soon as possible. it will be really appreciated if you will be able to share Expert's further advice/comments on this issue.

Best regards,

Miyazaki

Miyazaki-san, Tatsugami-san,

Please apologize for the delays; I don't have a sniffer with me and had several delays, including a personal leave.

At any rate, a colleague of mine was able to run the two executables on our sniffer: the one you created and the one I modified removing some of the redundancies indicated in my last post. Please check the executables ran and the sniffer captures attached below.

In both cases I see the same scenario: the legacy advertising packets (ADV_EXT_IND) cycle around the three primary advertising channels (37, 38, 39) with the same Advertising Data ID. The subsequent extended advertising packet (AUX_ADV_IND) is transmitted in the secondary channel 1 with the same Advertising Data ID as the first three packets.

Once this cycle completes, the Advertising Data ID is updated but the channel sequence is the same - i.e., three legacy packets are sent on the three primary advertising channels and the extended advertising packet is sent on the secondary channel 1. 

Tetsuo Tatsugami said:

For AUX_ADV_IND and AUX_CHAIN_IND PDUs, the secondary advertising channel index used in the Channel Index subfield of the AuxPtr field is implementation specific.

In the light of the excerpt of the spec you mentioned above, the choice of secondary advertising channel index is implementation specific - in other words, each vendor can have a different implementation for this choice depending on prior allocation of channels from the advertiser, thus not indicating necessarily a bug in our protocol stack.

Given this is an enhancement to the stack, I filed a report for approval by the dev team and should have a reply tomorrow.

Best regards,

Rafael

Miyazaki-san, Tatsugami-san,

As I mentioned before, I have been discussing with the dev team and we are trying to find a workaround to prevent the secondary advertising channel from resetting back to "1" at every advertising data change.

Our method of assigning the secondary advertising channel is incrementing by one, thus increasing the diversity.

Does that sound a reasonable workaround to the issue you are facing?

Regards,

Rafael

Rafael,

Yes, it's a nice workaround if it will update DID and increment channel index.
Thanks for your suggestions.

Regards,
Tetsuo Tatsugami

Tatsugami-san,

In internal discussions we found out that a change to the strategy of assigning the RF channel will demand a very thorough evaluation, but a possible workaround is to update the advertisement data without disabling/enabling advertisements.

The way to do this would be to disable HW interrupts during the process of data updating.

To do this, first you include the proper HWI module include file at the top of the file where the advertisements will be updated

#include <ti/drivers/dpl/HwiP.h>    // Added for interrupts

Then, remove the GapAdv_disable()/GapAdv_enable() (you don't want to disable advertisements)

Replace the calls to GapAdv_prepareLoadByhandle() and GapAdv_loadByHandle() with the following construct.

        uintptr_t key = HwiP_disable();
        // Sample buffer modification
        HwiP_restore(key);

Keep in mind this disables interrupts and therefore try to keep those calls to a minimum and encompassing a narrow amount of code.

Please give this a try and see if this helps overcome the problem.

Hope this helps,

Rafael

Rafael,

Your suggestion improves only the channel index problem.
The channel index is updated because GapAdv_loadByHandle() is not executed.
But Advertising Data ID (DID) is NOT updated.
Both values should be updated.

Regards,
Tetsuo Tatsugami

Hello Rafael,

Can we have any advice/comments on this solution, please?

If you will share other Expert's thoughts, Tatsumi-san's team will try to do it.

I'm sorry to rush you, but it is really appreciated your quick reply.

Best regards,

Miyazaki

Rafael,

It's been days since then, so I'll write it again.

Your workaround does not improve the problem that Advertising Data ID is not updated.
Please consider it again.

Regards,
Tetsuo Tatsugami

Tatsugami-san,

Please apologize for the delay.

Since we are considering a specific change to the behaviour of our stack (either by means of a patch or a configurable option), is there any reason other than increasing randomness on the advertisement secondary channel (following an advertisement data update) for this request? I understand you want to increase randomness, but if you have any additional requirements it would be helpful to bring it to the attention of the dev team. 

Reiterating my prior post, the spec leaves to each vendor how to assign of the RF Channel ID of the AUX_ADV_IND packet after a data update, thus no violation is occurring.

Best regards,

Rafael.

Rafael,

Do you know Remote ID ?
It's Remote Identification for Drone Pilots.
All drones will be necessary to be equipped with Remote ID wireless system in near future.
UAS Remote Identification Overview (faa.gov)

ASTM F3411-19 specified two method (BLE or Wifi aware) to transmit ID and some information.
And there is also description for channel index. (I don't explain details, although the document has some typo...)
Anyway, I think channel diversity is important for TI BLE solution to be chosen.
Because it's unsuitable for Remote ID if reception success rate is low.
ASTM F3411 - 19 Standard Specification for Remote ID and Tracking

Regards,
Tetsuo Tatsugami

Tatsugami-san,

Thank you for the additional details. A patch will be created that will prevent the RF Channel ID to be reset at the call to GapAdv_loadByHandle().

I will evaluate the work needed and report back with a timeline to make this available.

Best regards,

Rafael

Rafael,

Thank you very much for your cooperation.
Could you tell me when patch is available ?
I'd like to know the schedule if possible.

Regards,
Tetsuo Tatsugami

Rafael,

I confirmed the problems were fixed.
DID and channel index were both updated by the patch.

Thanks and Best Regards,
Tetsuo Tatsugami

Tatsugami-san,

Thank you for the confirmation the patch is suitable for your needs.

Best regards,

Rafael