• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 353 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.

LAUNCHXL-CC26X2R1: BLE broadcast message content is erratic

Alex Zhang
Intellectual 1305 points

Part Number: LAUNCHXL-CC26X2R1

Hi team

Broadcast cycle: 60ms

Acquisition duration: 60s

Acquisition Method: Acquire with the Ellisys analyzer

The normal broadcast message is populated as follows:

A830005F-88C0-4369-844A-583E837760F4

Some 5 exceptions occur as follows:

3033154F-C565-6769-844A-783E837760F4

A830005F-88C0-4369-844A-583E837761F4

Is the broadcast data error normal? If OK, what is the reasonable range for the incorrect broadcast percentage?

Best regards

Alex

  • 0
    TI__Guru** 101570 points

    Hi Alex,

    - Can you specify the SDK version and example used?

    - Can you provide the Bluetooth LE sniffer log showing the issue and steps to reproduce?

    Thanks and regards,

  • 0 in reply to Clément
    TI__Intellectual 1305 points

    SDK: Simplelink_cc13xx_cc26xx_SDK_7_10_01_24

    Project: Is the OAD_onchip_app

    Hardware: Official LAUNCHXL-CC26X2R1 development board

    BLE advertisement interval 60 ms

    Acquisition time: 60 s.

    Acquisition method: Capture with Ellisys analyzer

    the code has been modified, leaving only the classic broadcast

  • 0 in reply to Alex Zhang
    TI__Guru** 101570 points

    Hi Alex,

    Thank you for the details provided.

    Based on the screenshot provided, I see the advertisement's CRC seen by the Bluetooth analyzer is invalid. This means the RF packet has probably suffered some interference causing one or several bit-errors. An other explanation is the one of the devices' radio has introduced this error (either in transmission or reception).
    When using RF systems, this kind of error is pretty likely to occur, especially in crowded environment.

    In all the cases, a device receiving a packet with erroneous CRC should reject it.

    In summary, the issue encountered here should be considered as part of the normal way of working of a radio-based system. Existing mechanisms (CRC) seem to work as expected in order to allow scanning devices to reject this kind of erroneous packets.

    I hope this will help,

    Best regards,