Changing MTU Size on 2540

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

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

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

Christian

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

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

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

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

Sorry for digging up corpses, but I happen to face a similar situation Christian did:
We have a device that uses a CC2541 running heavily modified code based on the keyfob demo of the 1.3.2 stack. This devices features a self-update mechanism where it is to receive a ~120kB image via GATT characteristic writes. So far I have set the system up to request a parameter update as soon as the image transfer starts to reduce the connection interval to 10-20ms. However the image still requires a couple of minutes to upload.

To further speed things up I would like to increase the MTU. When requesting the update from the pc side the device returns a max MTU of the default 23B.

As this topic is a couple of years old I just wanted to ask if the stack-side limitations Greg mentioned are still in effect in the current/coming versions of the BTLE stack? Or is there a method to get larger packets over the air I did not yet find?

Thanks,

Jann

We don't have any way to increase the pakcet size (this is fixed by BT core spec), but we do now (as of our v1.4.0 release) have a way to send more packets per connection event. You can do this by enabling our "overlapped processing" feature by adding the following code to your application init function:

HCI_EXT_OverlappedProcessingCmd( HCI_EXT_ENABLE_OVERLAPPED_PROCESSING );

The cost here will be slightly higher peak currents during Tx and Rx, and beware that even though this allows our device to send/receive more packets per event, if the peer device has limitations then you will still be bound by those limitations.

Hi Willis,

Regarding your comment above "We don't have any way to increase the pakcet size (this is fixed by BT core spec)" - Do you mean the MTU size is fixed to 23?

Best Regards

Sri

Yes. It is fixed to 23.

Hello,

Is there any solution (say a work around) to allow us to change this value. It has implications for our prototyping work.

Or will TI consider changing this in a future software release?

Thank you in advance

Sri

We are looking into changing this in a future release.