• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 646 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R: Advertising Data ID

Masashi Ohhashi
Expert 4805 points
Part Number: CC2642R
Other Parts Discussed in Thread: LAUNCHXL-CC26X2R1, , BLE-STACK

Hi,

my customer is developing software of BT5.1 to use SDK for CC2642R. They are using LAUNCHXL-CC26X2R1.

In BLE5 extended (Coded PHY) advertisement, the Advertising Data ID (DID) in Advertising Data Info doesn't change even if the data content is changed every period transmission. The Bluetooth specification Core_v5.1 has the following description, and they think it should be changed originally.

2.3.4.4 AdvDataInfo field

The Advertising Data ID (DID) is set by the advertiser to indicate to the scanner whether it can assume that the data contents in the AdvData are a duplicate of the previous AdvData sent in an earlier packet.

If they can set the DID value themselves, that is fine, they can't find an API to set the DID value either. The SID can be set with GapAdv_setParam (handle, GAP_ADV_PARAM_SID, & value); but there is no API for updating DID in the document. Note that the value of the transmitted DID is not 0 and changes each time the device power is turned off / on.　What value is this DID sending?

In the case of GapAdv_enable → transmission → GapAdv_disable → transmission → GapAdv_enable, the value of DID did not change.

Best Regards,

M.Ohhashi

  • 0
    TI__Guru* 82121 points

    Hi Masashi,

    Yes, if the payload of the advertisement data is changed the DID should change. The BLE-Stack should handle this.

    1) What version of the SimpleLink CC13x2/CC26x2 SDK are they using?

    2) Can you tell me k update the ADV data (GapAdv_loadByBuffer or GapAdv_loadByHandle )?

  • 0 in reply to Marie H
    Prodigy 60 points

    Hi Marie,

    1)I used SDK ver 3.40.00.02,

      it includes TI BLE5-Stack 2.01.01.00.

    2)I used GapAdv_loadByHandle .

    Best Regards,

    T.Tatsugami

  • 0 in reply to Marie H
    Prodigy 60 points

    Hi Marie,

    1)I used SDK ver 3.40.00.02

      It includes TI BLE5-Stack 2.01.01.00.

    2)I used GapAdv_loadByHandle .

    Best Regards,

    T.Tatsugami

  • 0
    TI__Intellectual 2180 points

    Hi Masashi and Tetsuo,

    Thanks for bringing this to our attention. I will be investigating this and will get back to you by next Wednesday for an update.

    Regards,
    Michael

  • 0
    TI__Intellectual 2180 points

    Hello,

    I attempted to reproduce this issue, but so far had no luck as I am able to see the DID value change after updating the advertisement data. Could you please confirm the following:

    1. When you are loading new advertising data, are you creating a new handle, or using an existing one?
    2. If you are using an existing handle, are you freeing the data buffer by calling GapAdv_prepareLoadByHandle before updating the advertising data?
    3. Which contents of the advertising data are you attempting to change?

    Regards,
    Michael

  • 0 in reply to Michael Hollister
    Prodigy 60 points
    Hi Michael,
    1.I am using an existing one when I load new advertising data.
    2.I have not used GapAdv_prepareLoadByHandle before.
      And the DID value is changed by using GapAdv_prepareLoadByHandle.
      But another problem occurs.
     
      The adverting interval cycle becomes very short.
      GapAdv_prepareLoadByHandle may reenable advertise after disable immediately,
      and it ignores the parameters: GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX and GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN.
      GAP_EVT_ADV_START and GAP_EVT_ADV_END also run at very fast cycles.
     
      My INTERVAL_MAX/MIN parameter is 532 (532 * 0.625 = 332.5ms), and my sniffer receives advertise evey 333 ms before.
      But sniffer receives every 0.02 ms when I use GapAdv_prepareLoadByHandle.
     
      Do you have any workaround ?
      This issue is effectively making GapAdv_prepareLoadByHandle API unusable.
    Best Regards,
    T.Tatsugami
  • 0 in reply to Tetsuo Tatsugami
    TI__Intellectual 2180 points

    Hi Tetsuo,

    I attempted to reproduce this behavior, but I did not observe the advertisement interval changing in the sniffer after updating the advertisement set data. Couple of follow-up questions for debugging:

    1. I believe the sequence of function calls you make when updating the advertising set is is the following:
      1. GapAdv_disable(handle)
      2. GapAdv_prepareLoadByHandle(handle, GAP_ADV_FREE_OPTION_ADV_DATA)
      3. GapAdv_loadByHandle(handle, GAP_ADV_DATA_TYPE_ADV, sizeof(advData), advData)
      4. GapAdv_eanble(handle, GAP_ADV_ENABLE_OPTIONS_USE_MAX, 0)

      Is this correct? If not, what is the sequence of GapAdv_xxx function calls you make?

    2. Each of the GapAdv_xxx functions returns a status value. Is each status return value successful?
      1. If you built the program off of the simple_periperal SDK example, you could add SIMPLEPERIPHERAL_ASSERT(status == SUCCESS) after every GapAdv_xxx call.

    Regards,
    Michael

  • 0 in reply to Michael Hollister
    Prodigy 60 points
    Hi Michael,
    1.I insert following sequence to update the advertising.
      a.GapAdv_prepareLoadByHandle(handle, GAP_ADV_FREE_OPTION_ADV_DATA)
      b.GapAdv_loadByHandle(handle, GAP_ADV_DATA_TYPE_ADV, sizeof(advData), advData)
      GapAdv_disable and GapAdv_eanble seems to be executed automatically in above functions.
    2.Those functions returns SUCCESS.
      I am using SIMPLEPERIPHERAL_ASSERT(status == SUCCESS),
    And I found the workaround for the interval problem.
    The interval problem occured in below code,
    but it's gone if I changed the event to GAP_EVT_ADV_START, but not GAP_EVT_ADV_END.
        case GAP_EVT_ADV_END:
            // update advertising buffer
            status = GapAdv_prepareLoadByHandle(advHandleLongRange, GAP_ADV_FREE_OPTION_ADV_DATA);
            SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
            status = GapAdv_loadByHandle(advHandleLongRange, GAP_ADV_DATA_TYPE_ADV, sizeof(advData2), advData2);
            SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
            break;
    However, I found an additional problem.
    My advertising parameter is below. The primary channel map is all, and primary msg must be transmitted on channel 37, 38, 39.
      GapAdv_params_t advParams2 = {
        .eventProps =   GAP_ADV_PROP_CONNECTABLE,
        .primIntMin =   532,
        .primIntMax =   532,
        .primChanMap =  GAP_ADV_CHAN_ALL,
        ...
    It was OK without GapAdv_prepareLoadByHandle.
    As far as I confiredm using sniffer, primary msg is not transmitted often on one or two channel
    when I inserted GapAdv_prepareLoadByHandle in GAP_EVT_ADV_START.
    This problem occurs only immediately after executing GapAdv_prepareLoadByHandle, it disappear soon.
    But I want to change every adverting data, so this problem occurs everytime.
    For example, 38 ch is transmited twice and 39 ch is not transmited on attached image.
    Best Regards,
    T.Tatsugami
  • 0 in reply to Tetsuo Tatsugami
    TI__Intellectual 2180 points

    Hi Tetsuo,

    Thanks for sharing all those details. I noticed you are changing advertising data on every advertising event. Additionally, it looks like you are reusing the advertising data buffer instead of allocating memory for a new buffer. If you are going to reuse your advertising data buffer and change its contents, you will want to use the GAP_ADV_FREE_OPTION_DONT_FREE parameter instead of GAP_ADV_FREE_OPTION_ADV_DATA when calling  GapAdv_prepareLoadByHandle. For information regarding parameters and behavior of GapAdv_prepareLoadByHandle is available in the linked API docs.

    In regards to seeing two advertisements on a single channel, I can confirm this and can reproduce the behavior for extended advertisements. Thanks for bringing this to our attention. I will follow up with the software development team to further investigate and resolve this issue. 

    Regards,
    Michael