Is it possible to increase the gMaxL2caQueueSize_c Queue size in the BLE Server.

[kishans]

BLE Server sends a large number of Data Packets using Attribute Protocol Handle Value Notification there are high chances of getting gBleOverflow_c  error. 

Can we fix this error by increasing the size of the queue by modifying gMaxL2caQueueSize_c constant value in ble_config.h file in the BLE Server (or a Peripheral device)? If not then please let me know the way to resolve this issue.

@mario_castaneda @nxf56274 

[mario_castaneda]

Hi @kishans,

What is the process that you are doing to transmit data?

Are you using the 2MPHY?

Be aware of the amount of memory that you are using, You can check more about the footprint in the release notes in the documentation folder of the SDK that you donwloaded.

However, as your requirement, I recommend the USB example and Bluetooth LE, the device supports both protocols, there is even an example for USB and one for the Bluetooth Le functionality. 

Also, please take into account that we do have those examples in a separate files but there is an effort you need to do when combining both examples in one, as well as you will need to create your custom profile for the Bluetooth LE communication based on the FIDO alliance specification.

Regards,

Mario

[kishans]

Hi Mario , 
 sorry I couldn't find info about mQppsTxInterval_c please let me know where to look for. 

Am not clear on how to get the right waiting time, because waiting_time = x msec might work on most of the devices but might fail on some other devices, so any suggestion on how to derive a right delay time. 

Is there any way to know whether L2CAP is ready to take next set of packets ?

 Regards,
 kishan

Attn: @mario_castaneda   

[mario_castaneda · Accepted solution]

Hi @kishans,

Please look at the QPP example, I am assuming that you want to work with the throughput.

You will find the mQppsTxInterval_c.

Is there any way to know whether L2CAP is ready to take the next set of packets?

The QPP could help you with your requirement. What is the final application that you are developing?

Regards,

Mario

[kishans]

@mario_castaneda 

 As I said in my earlier post the initial tries where not successful, then using the analyzer taken out the time between two packets and adjusted the delay such that at the max three packets sent in one connection interval, this fixed the issue. 

Regards and Thanks,

 kishan

[kishans]

Thank you @mario_castaneda , I looked into the QPP example and implemented BLE communication similarly but unfortunately am not able to get the stable communication. 

also tried with different values for mQppsTxInterval_c. 

BTW we are trying to implement FIDO authenticator device.

Regards,

 kishan

[mario_castaneda]

Hi @kishans,

This define is for the Bluetooth Stack usage, the definition is just for reference. It can not be changed.

However, the overflow explains this.

/*! Maximum number of pending L2CA packets.
This queue is used by the L2CAP layer to buffer packets when the LE controller cannot accept ACL Data packets anymore.
Any new requests sent from the Host or application layer after this queue is full will generate a gBleOverflow_c event.
Also, when the queue transitions to empty state, a gTxEntryAvailable_c generic event will be generated. */.

So, you could try to wait for some time to be sure that the L2CAP could send more packets. Also, you could enable the timer to send some packets for some ms. please look at the mQppsTxInterval_c.

Regards,

Mario