Can't send more than 90 bytes BLE Android CC2640

Hello. Do you need the prepare write capability? You can accomplish this with just a GATT_WRITE if you increase the PDU size in bleUserConfig.h, i.e.:

// Maximum size in bytes of the BLE HCI PDU. Valid range: 27 to 255
// The maximum ATT_MTU is MAX_PDU_SIZE - 4.
#ifndef MAX_PDU_SIZE
#define MAX_PDU_SIZE 132
#endif

Hi tim,

sorry for the delayed response, i was busy working on another part of the project. 

I have always had an issue with MAX_PDU_SIZE. If i change the value to something different than the minimum value (27), i no longer see the characteristics on my android device. The Android application tries to discover characteristics but it fails and finally disconnects (due to timeout i guess)

The problem happens with both nRF Master Control Panel and my application. 

Any idea why?

PS: Another problem occured which might be related: When i do long reads, i can only have one packet per connection event, which reduces the throughput a lot (around 1kByte/sec). I would really like to improve this throughput.

Thanks.

Regards,

Etienne 

For information, i tried modifying both MAX_NUM_PDU and MAX_PDU_SIZE while taking into account the following preprocessor condition:

#if ( MAX_NUM_BLE_CONNS > 0 ) && !defined( NO_HEAPSIZE_VALIDATE )
#if ( ( ( ( ( MAX_PDU_SIZE / 27 ) + 1 ) * MAX_NUM_PDU ) * ( 27 + 14 ) ) > ( HEAPMGR_SIZE / 3 ) )
#warning Not enough heap for configured MAX_NUM_PDU and MAX_PDU_SIZE! Adjust HEAPMGR_SIZE.
#endif
#endif

Still doesn't work though...

This is highly dependent on the Android version / phone. For example, some combinations may not accept higher MTU sizes than 27. ARe you aware of the limitations of your system? Can you send a sniffer capture?

Hey Tim,

we were actually still running with BLE stack 2.0.

Updating the stack to version 2.1 improved a few things. I can make long reads with MTU up to 255 bytes.

Anyway, i still have issues with long writes. If I change the MAX_PDU_SIZE to something else than the minimum value (27), the long write fails and the connection is aborted. This is different than before because i can discover characteristics and do "simple" writes.

This is quite weird because changing the MTU size works for long reads.

The long writes work with nRF Master Control but i assume they don't change the MTU size.
Could it be Android still trying to do a "prepare write request" instead of a simple write??

Sending you a packet capture won't be that useful as i run with pairing + bonding, and the connection stops when i try long write.


Any suggestion on that issue??

Thanks.

Regards,

Etienne

PS: i run my application on Android 5.1.1

Hello. It's difficult to comment without more information. Can you turn off pairing/ bonding and perform the same test to get a sniffer capture? 

Or can you replicate this using a TI device as a master so that we could easily debug it?

Hi Tim,
I actually made it work by using another smartphone. What is quite strange is that both phones were running on Android 5.1.1. One didn't work, the other did.

Could it be a hardware problem? The phone which worked was rooted, could it improve the BLE performances? I'm not very familiar with this :/

Have you ever experienced something like this before?

Anyway, thank you for your help and patience.

Regards,

Etienne

I was having the same issue, and first tried changing GATT_MAX_NUM_PREPARE_WRITES in gatt.h, with no effect. However, using GATTServApp_SetParameter() to set GATT_PARAM_NUM_PREPARE_WRITES at run time worked. (tested with NRF and my own app)

Thanks,

Kyle

Could you please share how you made configuration for changing MTU size to more than 23 bytes.

Thanks for your support in advance.

Thanks,

Siva.