• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1557 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: Extended Advertising Length

Mark Ackerson
Genius 10190 points

Part Number: CC2642R

Customer is working with Extended Advertising on the CC26x2 Launchpad.  There seems to be a difference in the advertising lengths depending on if the advertisement is configured as scannable or connectable. 

The advertisement data is a static 300 byte array.  When the advertisement is scannable, BTool shows all 300 bytes split between two separate events.  However, the data is truncated to 245 bytes when the advertisement is connectable.

Can the advertisement be more than 245 bytes when it is configured as connectable?

Thanks,
Mark

  • 0
    TI__Guru* 84751 points
    Hi Mark,

    I'm looking into this. I think I have reproduced the behavior by taking the Project Zero, setting it to use the 2M phy for advertising per the SimpleLink Academy lab on 2M PHY dev.ti.com/.../ Bonus Task 2, and modifying the advertising data to be 300 bytes long (stuffed it with some random data of manufacturer specific type).
    With GAP_ADV_PROP_CONNECTABLE set, in bTool when I scan I see 200 bytes of advert data in the first event and 45 in the second event.

    I will continue to dig into the details to determine if this makes sense with the spec or if it perhaps could be something with the implementation. Does my method to reproduce look similar to what the customer is doing?

    Regards,
    Katie
  • 0 in reply to Katie Pier
    TI__Guru* 84751 points
    Hi Mark,

    Sorry for the delay. It looks like this is part of the spec. If you have the SIG core v5.0 spec, refer to Vol 6 Part B table 2.5, Common Extended Advertising Payload Format fields permitted in the AUX_ADV_IND_PDU. For connectable undirected advertising on the aux channels, observe that the spec lists the Aux Ptr field as X or "RFU." Since the AuxPtr is what is used for Chaining to indicate subsequent AUX packets, this means there is no chaining for a connectable AUX_ADV_IND. Therefore, you see the situation that you have where you are limited to <255 bytes (and it probably works out to 245 after subtracting some headers etc), basically the size limitation of the sole AUX_ADV_IND.

    For scannable, you'll see in the same table that the AUX_ADV_IND also cannot have an AUX Ptr. However, in the scannable case the data will instead be sent as a Scan Response to a scan request from the master. And the AUX_SCAN_RSP can have chaining. So then the limit becomes 1650 which is the longest data you can chain.

    I hope that this helps to explain the difference in these 2 cases for the BLE5 spec.

    Regards,
    Katie