• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 201 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.

CC2652P7: dynamically changing advertising packet.

Nick Braun
Prodigy 110 points
Part Number: CC2652P7


Tool/software:

Hello. I am developing an application on the CC2652P7 processor, and the project is based on an example from the SDK. I have two devices, one of which acts as the master and the other as the slave. The master device is constantly in the air and transmits advertising packets. The slave device occasionally scans the air and looks for packets from the master device.

I want the slave device to update the advertising packet at a fixed interval. For example, the advertising packet will contain a simple counter that increments every second. The update will be performed using the functions "GapAdv_prepareLoadByBuffer" and "GapAdv_loadByBuffer."

In this regard, I have several questions:

  1. Is this acceptable in the context of the BLE standard?
  2. If it is acceptable, which of the "GAP Advertisement Data Types" should be used?
  3. According to the description, data types from 0x00 to 0x3D are already reserved. Is it permissible in the BLE standard to use other values, such as 0xAA? I know that there is also 0xFF (Manufacturer Specific Data), but it implies either use in testing, without commercial use, or monetary contributions. Therefore, this option is likely not suitable for us.

Perhaps the "GAP_ADTYPE_SERVICE_DATA" data type with the service UUID and data following it would be suitable for me?

Thank you for your help!

  • +1
    TI__Expert 4760 points

    Hello,

    Thank you for reaching out! Great questions!

    Nick Braun said:
    Is this acceptable in the context of the BLE standard?

    This is perfectly acceptable and is very common. Please refer to our API guide to perform this correctly.

    Nick Braun said:
    • If it is acceptable, which of the "GAP Advertisement Data Types" should be used?
    • According to the description, data types from 0x00 to 0x3D are already reserved. Is it permissible in the BLE standard to use other values, such as 0xAA? I know that there is also 0xFF (Manufacturer Specific Data), but it implies either use in testing, without commercial use, or monetary contributions. Therefore, this option is likely not suitable for us.

    Using the Manufacturer data is perfectly fine, however, you are absolutely correct, can also use the Service Data.

    I hope this answers your questions!

    Best Regards,

    Tarek D

  • 0 in reply to Tarek D
    Prodigy 110 points

    Hi,
    Am I correct in understanding that the BLE standard allows me to freely insert a field with an undefined tag into the advertising packet? By an undefined tag, I mean the range from 0x3D (exclusive) to 0xFF (exclusive).
    That is, part of the advertising packet will contain approximately the following values:

    0x05 0xAA 0x11 0x22 0x33 0x44

    where 0x05 is the length,
    0xAA is a custom tag that is not defined by the BLE standard,
    and 0x11 0x22 0x33 0x44 are the custom data that I want to transmit using advertising packets.
    Did I understand correctly?

  • 0 in reply to Nick Braun
    TI__Mastermind 42320 points

    Hi Nick,

    Can you clarify what you mean about the manufacture specific section of advertisements? Many commercial products use this advertising section for their custom data as its the most convenient place for it. I think this would be the best place to add your custom data.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    If we consider this in the context of advertising, the manufacturer-specific information starts with the tag 0xFF, which looks something like this:

    <TAG: 0xFF> <DATA: [Identifier 2 bytes][some data N bytes]>

    As I understand, the information after the tag 0xFF contains 2 bytes, which is the identifier of a specific company. Based on these identifiers, other devices CAN (if possible) correctly read the following data and somehow use it for themselves. A list of these identifiers is available in the BLE documentation. It is mentioned online that this tag (0xFF) can be used for debugging purposes. In that case, the identifier can be arbitrary. However, if we want to use our devices for commercial purposes (i.e., to sell), then this identifier must be defined. Otherwise, other devices may misinterpret us. To obtain a unique identifier, it seems that one needs to pay membership fees to the BLE association. This path is not suitable for us. Based on these thoughts, it seems that I cannot use this method.

    Therefore, I am interested in whether the BLE standard allows the use of tags in the range from 0x3D to 0xFF, which are not defined in the standard, for personal purposes (including commercial purposes).

  • 0 in reply to Nick Braun
    TI__Mastermind 42320 points

    Hi,

    I believe that range of AD types is currently marked as Reserved for Future Use. This means that technically you may be able to use them but if they are defined by the spec at some point then you must ensure your use is complaint.  The best and most common practice is to use the company custom data section 0xFF. If you are concerned about having plain-text data on the advertisements, then you may encrypt the data in the advertisement with a private known key. Another option is to perform validation upon connection establishment to ensure to peer devices that they are not connecting to an imposter device.

    Best Regards,

    Jan