BLE on CYBLE-022001-00

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JoGr_3357391
Level 4
Level 4
10 likes given 5 likes given First like received

The data sheet for this part ( http://www.cypress.com/documentation/datasheets/cyble-022001-00-ez-ble-creator-module ) indicates that it offers a "BLE stack compatible with Bluetooth 4.1". I'm using PSoC Creator 4.2 (4.2.0.641), which documentation for the BLE component indicates that it "implements the core BLE functionality as defined in the Bluetooth Core Specification 4.2".

We are encountering a situation in which our abnormally large MTU is not being properly conveyed to the client. I'm wondering whether we are hitting the 32-byte MTU limit in BLE 4.1.

I find it interesting that at no point in the connect/notify/read/disconnect cycle does the client request the MTU size. It might well be the client program (Microchip's SmartDiscovery on Android) that simply does not ask for this information.

If all of my assumptions are incorrect, can someone show me how to notify on large packets?

(we would use shorter packets and just keep the channel open if it weren't for battery power constraints)

0 Likes
1 Solution

Hello John,

Central device with having Bluetooth v4.1 and above will send the CYBLE_EVT_GATTS_XCNHG_MTU_REQ event to the peripheral where we can get client MTU size. In the peripheral we can negotiate the MTU size (the minimum of the GATT MTU client and server size).

For some Central devices with having Bluetooth v4.0 is not sending the CYBLE_EVT_GATTS_XCNHG_MTU_REQ event to the peripheral and these devices accepts the default MTU size of length 20 bytes. So these devices will not accept more than 20bytes MTU size.

Can you please share your project.


Thanks,
P Yugandhar.

View solution in original post

0 Likes
8 Replies
Yugandhar
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 5 likes given

Hello John,

Client will send the MTU request to the peripheral. CYBLE_EVT_GATTS_XCNHG_MTU_REQ event will be generated at the Peripheral device. The client and server exchange the maximum size of a packet that can be received using the Exchange MTU Request and Response PDUs. Both devices then use the minimum of these exchanged values for all further communication.

Can you please tell what are the Bluetooth specifications that your client device is having.

Thanks,

P Yugandhar.

0 Likes

My device ( the server), as previously described, is apparently a 4.2 compatible stack on 4.1 compatible hardware - using PSoC Creator 4.2 generating code for a CYBLE-022001-00. The client, as previously mentioned, is SmartDiscovery, an Android app from Microchip. I have no idea what its specs are.

I do find it interesting (thank you for the hint) that the CYBLE_EVT_GATTS_XCNHG_MTU_REQ event does not appear to be called, at least it does not breakpoint at that case statement in AppCallBack().

Am I completely missing a few points about BLE communications? Probably.

Thanks

0 Likes

Hello John,

Please refer the LE Data Packet Length Extension section in the attached file for more information.

Thanks,

P Yugandhar.

0 Likes

Thanks for the link. Yes, I've read that, but perhaps too superficially. It's interesting to see that the 3.53 version of the BLE docs from Cypress indicate the MTU can go as high as 512 bytes. The attached doc says the max is 251. Am I comparing apples and oranges? Is MTU used at the higher layers, and something else in the lower layers?

Thanks

0 Likes

Hello John,

The maximum transmission unit (MTU) is the maximum size of payload data, that the upper layer entity is capable of accepting. This value is used to respond to an Exchange MTU request from the GATT Client. The valid range for the negotiated MTU size for a Cypress BLE connection is from 23 to 512 bytes.

The link layer implements key procedures to establish a reliable physical link and features that help make the BLE protocol robust and low power. The link layer transmit payload size is from 27 to 251 bytes. The actual size of the link layer transmit packet is decided based on the peer device’s link layer receive packet size.

Thanks,

P Yugandhar.

0 Likes

Thank you. As you can probably tell, we are a few engineers without much BT experience...

0 Likes

Hello John,

BLE stack protocol layers is as shown below:

pastedImage_1.png

If you consider the data flow is from peripheral to central then in the peripheral the data will flow from ATT protocol ->L2CAP ->Link layer ->physical layer to Central.
In the ATT protocol if the ATT MTU size is 203bytes, and if the L2CAP MTU size is 27bytes and the Link Layer(LL) MTU size is 29bytes then it takes 9 Link Layer packets to transmit all the ATT MTU size of 203bytes.
Please see the data flow in the below block diagram.

pastedImage_0.png

Here the ATT MTU is the maximum size of payload data and the valid range is from 23bytes to 512bytes. The Link Layer MTU transmit payload size is from 27 to 251 bytes for Bluetooth v4.2.

Thanks,

P Yugandhar.

Hello John,

Central device with having Bluetooth v4.1 and above will send the CYBLE_EVT_GATTS_XCNHG_MTU_REQ event to the peripheral where we can get client MTU size. In the peripheral we can negotiate the MTU size (the minimum of the GATT MTU client and server size).

For some Central devices with having Bluetooth v4.0 is not sending the CYBLE_EVT_GATTS_XCNHG_MTU_REQ event to the peripheral and these devices accepts the default MTU size of length 20 bytes. So these devices will not accept more than 20bytes MTU size.

Can you please share your project.


Thanks,
P Yugandhar.

0 Likes