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.

LE Data Length Extension with Android 6.X

Other Parts Discussed in Thread: CC2640

I am experimenting with the LE Data Length Extension feature in the CC2640 and 2.2 stack. I am attempting to negotiate the use of extended data lengths between the CC2640 and various Android phones running the V6.0 Marshmallow operating system.

If I enable the data length extension in the 2.2 stack, the following LL sequence occurs when I initiate a connection with the CC2640 as the peripheral:

  1. The Nexus 6P sends a LL_LENGTH_REQ with a RX of 251 bytes and TX of 27 bytes.
  2. The CC2640 sends a LL_LENGTH_RSP with a RX of 251 bytes and TX of 27 bytes.
  3. The CC2640 then sends a LL_LENGTH_REQ with a RX of 251 bytes and TX of 27 bytes.
  4. The Nexus 6P sends a LL_LENGTH_RSP with a RX of 251 bytes and TX of 27 bytes.

If I add  the HCI_LE_SetDataLenCmd() call to my CC2640's link event handler with a PDU size of 251 and time of 2120 the following LL sequence occurs:

  1. The Nexus 6P sends a LL_LENGTH_REQ with a RX of 251 bytes and TX of 27 bytes.
  2. The CC2640 sends a LL_LENGTH_RSP with a RX of 251 bytes and TX of 251 bytes.
  3. The CC2640 then sends a LL_LENGTH_REQ with a RX of 251 bytes and TX of 251 bytes.
  4. The Nexus 6P sends a LL_LENGTH_RSP with a RX of 251 bytes and TX of 27 bytes.

It looks to me like the CC2640 is properly requesting TX and RX PDU's of 251 bytes but the Nexus 6P will only allow a RX of 251 and a TX of 27. I don't see any method in the Android API's that allows adjustment of the TX PDU size. Am I missing something or is this a current limitation of the Android BT 4.2 support?

I have also tested this with a Samsung Galaxy 7 with similar results. I have also tried various other PDU sizes.

Thanks

Mike

 

  • Hi Mike,

    Thanks for sharing your results. From my experience the phone OS APIs usually don't allow the application to specify Controller level functionality (or many aspects of the Host for that matter). I'm not sure if this is a limitation of the Android software (Host/App) or just the Controller, which does perform Wi-FI and classic BT functions as well.

    Out of curiosity, have you tried Android 7?

    Best wishes
  • Thanks for the reply. So far, I only have Android 6 phones to experiment with. I will post more info once I have tried an Android 7 device.

    Mike

  • Hi 

    I am trying to activate Datalength extention with BLE stack 2.2 ; from cc2640 sensortag platform to an Android 6 Samsung note 5 smart phone. I following the instructions in SWRU393C section on LE data extension with no luck, calling HCI_LE_setdatalencmd returns HCI_ERROR_CODE_UNKNOWN_HCI_CMD 

    Was wondering if the problem was the Android phone, or whether I am missing something in configuring the cc2640, if this is a cc2640 configuration issue can you direct me to the best example/description on how to add data length extension, sending data from the cc2640 to an android phone?

    your help is appreciated.

    Thanks

    MF

  • It sounds to me like the EXT_DATA_LEN_CFG option has not been enabled in your stack image. Take a look in the build_config.opt file for the stack. 

    Thanks,

    Mike

  • Thanks Mike,

    The option is enabled, any other suggestion

    MF
  • MF,

    Are you using an embedded project, such as simple_peripheral, or network processor, such as Host_test? Did you rebuild and reprogram your stack project? Do you see the Data Length control procedures on the sniffer?

    Best wishes
  • when uncommenting the EXT_DATA_LEN_CFG in the BLE_stack project, need to: clean, build project and then configure the stack.
    now I get another problem, which is a crash at bios_start() in main after enabling data length extension; a similar problem is described in processors.wiki.ti.com/.../CC2640_OAD_User's_Guide ; there they suggest that there is a memory corruption and the way to solve that with IAR is to Uncheck the "Fill unused code memory" box in the checksum pane link options of the app project. I didn't find anything similar for CCS.
    any suggestion?
    MF
  • Update 11-Jan-17:

    Regarding performance of the Google Pixel running Android 7.1.1, this handset supports a Data Length Update (PDU size) with a max TX and RX of 123 bytes in each direction. When running our BT4.2 high throughput demo (GitHub), we observed that the Pixel can continuously receive data from the CC2640 for the entire duration of the default 45ms connection interval.

    Best wishes