• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Low Power RF & Wireless Connectivity » Low Power RF Bluetooth® Low Energy & ANT Forum » Changing MTU Size on 2540
Share
Low Power RF & Wireless Connectivity
  • Forums
  • Announcements
  • Files
  • E2E Wiki
Options
  • Subscribe via RSS

Forums

Changing MTU Size on 2540

This question is answered
Christian Joly
Posted by Christian Joly
on Oct 30 2010 21:32 PM
Intellectual330 points

I have an application that requires to send 1000 bytes of data every second and I am trying to find the best way to do that.

I saw in the docs that the MTU size can be from 23 to 517. It is set by default to 23 and I cannot find a way to change its value.

Any feedback on this ?

I also want to send this data through a GATT_Notify but the length parameter of the notify value is uint8 limiting the notification to 256 (so cannot notify to 517)

Can the uint8 limit be changed to get to 517 ? The GATT_Notify is a library compiled routine so cannot really be accessed.

At last, I saw in the HCI doc (8.1.2) a way to send data differently than through a GATT Characteristics but there is not much information about it. When dealing with large amount of data, should it be the way ? Are there any functions that can be used to do that directly in the peripheral to send data from the peripheral to the USB Dongle ? 

Thanks

Christian

Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • GregS
    Posted by GregS
    on Nov 03 2010 17:05 PM
    Expert4165 points

    Hi Christian,

    I haven't messed with large data yet, but there are a few things which might not seem intuitive. The max data per connection event is limited to 80 bytes at app level. There is a 4X20 buffer right now, and when the connection event happensany data here will be sent out.  The way around this may be to have shorter connection event intervals, and slave latency for power savings.   There is a buffer limit of 4 buffers in link layer.  If you are hitting this limit, then you should receive an error code 0x04 for "Buffer Not Available".  I'm not aware of any fragmentation ability for this kind of data, so it may be up the app to handle this.

    Br,

    -Greg

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Christian Joly
    Posted by Christian Joly
    on Nov 04 2010 11:48 AM
    Intellectual330 points

    Greg,

    You can actually have more than 4 GATT buffers is you redefine the GATT profile but the big problem is that each of these buffers are limited to 20 bytes. This limit is set by the MTU Size (L2CAP_MTU_SIZE or 23 - 20+3 overhead) in the att.h - This cannot be change because when you change the L2CAP_MTU_SIZE, you will get all kind of compiler error and warning for functions that are encoded in the binaries libraries that TI is providing.

    The limit of 23 when you are dealing for 1000 bytes of data is totally impractical. It adds too much overhead, requires data to be sent every 10ms and will consume too much power and this just does not work.

     

    Per the BLE specification, I should be able to set the MTU_SIZE to up to 517. Is there an L2CAP function I can use to change that setting dynamically or any other function ?

     

    Thanks

     

    Christian

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • GregS
    Posted by GregS
    on Nov 12 2010 16:37 PM
    Verified Answer
    Verified by Willis1
    Expert4165 points

    Hi Christian,

    After talking with developers here, we are going to be limited to around 80bytes of application data per connection event.  The 512 size attribute will still be broken down and handled automatically, but the amount of data sent per connection event is still limited.  With the small connection interval and some slave latency - you should only be on when you need to transmit data.  There are some peak current power savings achieved with this implementation,  although it does add overhead with large amounts of data which is the situation you are seeing.

    Br,

    -Greg

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Christian Joly
    Posted by Christian Joly
    on Nov 29 2010 20:21 PM
    Intellectual330 points

    Is there a plan to be compliant with the BLE spec on this and allow up to 512 bytes of data per connection ?

    Christian

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Martin Bruner
    Posted by Martin Bruner
    on Jan 14 2011 08:47 AM
    Prodigy130 points

    Hi Everyone,

    I am a newbie to the BT LE world and I am trying to convert one of my existing IrDA devices.  From the posts I have seen on this forum, there appears to be some need for large data transfers.  I have up to 2MB that I would need to download to a host.  Has anyone had any success and using GATT to transfer more than the single byte attributes I have seen in the two example programs?  I am trying to determine whether this chip set or the upcoming BlueGiga BT LE module (suppose to be sampled next month) would work best for my application (or if BT LE is even the right interface to use!).

    I apologize if this is covered in another thread.

     

    Thanks,

    Marty

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Willis1
    Posted by Willis1
    on Jan 14 2011 11:35 AM
    Expert8185 points

    The Bluetooth spec does not require that 512 bytes of data must be sent per connection event. The BT spec states that the length of each attribute may be a maximum of 512 bytes, but that does not mean that the entire value necessarily needs to be sent in a single event. GATT contains the following sub-procedures for reading or writing characteristics / descriptors who's values are greater than 20 bytes:

    Read Long Characteristic Value

    Write Long Characteristic Value

    Read Long Characteristic Descriptor

    Write Long Characteristic Descriptor

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Martin Bruner
    Posted by Martin Bruner
    on Jan 14 2011 15:16 PM
    Prodigy130 points

    I must be on the wrong thread.  That wasn't my question.  I was trying to see if anyone has built something on top of GATT to do longer data transfers. 

     

    Marty

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Kevin Tallevi
    Posted by Kevin Tallevi
    on Feb 22 2012 08:19 AM
    Prodigy30 points

    Is there any sample code that shows the usage of those sub procedures?

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use