• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 51 subscribers
  • Views 1028 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.

CC2640R2F: Payload limitation in connection mode

Bhavin Parmar
Expert 1550 points

Part Number: CC2640R2F
Other Parts Discussed in Thread: LAUNCHXL-CC2640R2

Hi,

I am using SDK 1.50.00.71 host test example ( Peripheral GAP role ) and i am testing connection mode with generic mobile app about data convey between mobile and CC2640R2F but i am able to send only 20 bytes from CC2640R2F to mobile as SDK 1.50.00.71 supports BLE5.0 version.

Mobile detail on which i tested listed below 

1)       

Android : 7.1.1. version

Device : Motorola G5s plus

2)       

Android : 8.0.0

Device : One Plus 3T

As per BLE specification at least BLE 4.2 should transmit minium 200 bytes in connection mode.

Can you explain what could be the reason its not able to send more then 20 bytes.

Regards,

Bhavin

  • 0
    TI__Guru* 84121 points
    Hi Bhavin,

    Per the Bluetooth 4.2 spec the minimum MTU is 23 octets for BLE, which for example for notifications results in a 20-byte message length (couple bytes protocol overhead). While the maximum MTU size is much larger, if your CC2640R2F is acting as the server in the connection, it cannot initiate the Exchange MTU Request to try to get a larger MTU size used for the connection - only the client (the phone in this case) can initiate this exchange of max MTU size. Additionally, you can also only get a larger MTU size if your phone also supports the larger MTU size - as mentioned the minimum required is only MTU = 23. So unless you can control what the mobile app does (e.g. by making a call to have an Exchange MTU Request occur) you cannot get a longer payload - that is a phone side issue.

    In your final application, will you create your own mobile app, or will you be communicating with some other device that you also have control over/you know will send exchange MTU? If it's another device, it is probably better to start out your testing with a second LAUNCHXL-CC2640R2 launchpad running the Host test example from the SDK and using Btool from your PC to control it, so you can control all the sequences going on. Using Btool, after making the connection you can initiate the exchange MTU request with a size and if your code is set up to support it then the connection can continue with the larger size. There's more detail about the changes to your code and how to try this out here: e2e.ti.com/.../2491866

    If you are going to have to work with the phone in your end-application instead, and you will write your own app, you should look into the Android developers APIs to see if there is one for causing Exchange MTU and supporting larger MTU size. If you cannot force a larger MTU size from the app that you create, then there are other things that you'll have to do for sending large amounts of data across multiple packets. There is more information on doing this in these other threads here: e2e.ti.com/.../590726 and here: e2e.ti.com/.../2334627

    I hope that this helps you to get something up and running!

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Expert 1550 points
    Hi Katie,

    Thank you very much for very good explanation.

    Can you share info about how can i know my mobile is supporting Exchange MTU and Supporting larger MTU size ?

    Any detail available online by mobile part no or other method.

    Regards,
    Bhavin
  • 0 in reply to Bhavin Parmar
    TI__Guru* 84121 points
    Hi Bhavin,

    For phone side issues, I'm limited on how much I can help, but Exchange MTU has to be supported, and you can see that the API for it is listed on the Android Developer's website: developer.android.com/.../BluetoothGatt.html There is also usually some good information for Android developers on StackOverflow stackoverflow.com/.../how-to-know-the-mtu-size-of-android-smartphone

    For support for larger MTU size - this can vary by phone. For example for iOS devices the MTU size isn't even published in their accessory design guidelines, it just says you have to be able to handle the exchange MTU request. So, since all you can control to a certain extent is the server (CC2640R2F device) side of the communication, you need to write your code be able to handle anything from the minimum MTU size up to the maximum that you want to support and anything in between because you don't know what MTU size the client will provide with its exchange MTU request. If you want to keep the development simple, you could only support the minimum size, but that can have impact on throughput so it depends on your application. But you have to be able to tolerate that the client may only support that minimum value if you are not in control of the client for your application (which is basically the case with phones).

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Expert 1550 points
    Hi Katie,

    Thank you for information.

    Regards,
    Bhavin
  • 0 in reply to Bhavin Parmar
    Expert 1550 points
    Hi Katie,

    I am using SDK 1.50.00.71 and running host test in that but when i test central gap role it is able to scan only advertise packets sent by CC2640R2F LAUNCH PAD but when i send adv packets through mobile app it is not able to scan....while in case of SDK 1.50.00.58 host test example i test, its able to scan both mobile adv packets as well as CC2640R2F LAUNCH PAD adv packets.

    what can be the issue...is there requirement of specific command for that ?

    Regards,
    Bhavin
  • 0 in reply to Bhavin Parmar
    TI__Guru* 84121 points
    Hi Bhavin,

    SDK 1.50.00.71 is the BLE5 version of the stack that you can request for evaluation. SDK 1.50.00.58 is the BLE4.2 stack.

    Your phone likely doesn't support BLE5, but since you loaded the CC2640R2F from the same SDK version it did, hence seeing the Launchpad packets but not the phone packets. Therefore, I'd recommend sticking with SDK 1.50.00.58 for your testing with your phone so that your device and phone are speaking the same BLE version.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Expert 1550 points
    Hi Katie,

    Yes we have tested with SDK1.50.00.58 no issues with that but we want to go ahead with SDK 1.50.00.71 only.

    Can you please explain what could be the time line to resolving this issue in SDK 1.50.00.71 ?

    Regards,
    Bhavin
  • 0 in reply to Bhavin Parmar
    TI__Guru* 84121 points
    Hi Bhavin,

    As mentioned, the SDK 1.50.00.71 is implementing a BLE5 version of the stack, which many phones do not yet support, which is why you are having issues with the phone. What is the reason for using SDK 1.50.00.71 and BLE5? The latest BLE4.2 stack is SDK1.50.00.58 and that is what would be recommended to use unless there is a specific need for BLE5 support for your application.

    Regards,
    Katie