While using QN908x to send multiple (i.e,30 to 50) packets (of size 20 bytes) of data through BLE notification an error gBleOverflow_c is getting thrown from the GattServer Callback method.
This issue we are facing only on few PC (laptop) which are bit old so guessing those might be loaded with older version BLE module. Adding delay of 80 to 100ms between the packets fixes the issue for now but not very sure about the right approach to handle this issue.
Do we need to resend the last packet after we receive the gBleOverflow_c error, what's the standard process to handle this error. @nxf63973
The gBleOverflow_c means that an internal limit is reached. So, in this case, will depend on your implementation, you could resend the same packets that you didn't receive.
This overflow is generated because the Maximum number of pending L2CA packets was reached. gMaxL2caQueueSize_c
This queue is used by the L2CAP layer to buffer packets when the LE controller cannot accept ACL Data packets any more.
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. ble_config.h file
Need few inputs on the below points mentioned in your previous reply:
>> The gBleOverflow_c means that an internal limit is reached.
=> Is there a way to increase the internal limit (or buffer size).
>> This overflow is generated because the Maximum number of pending L2CA packets was reached. gMaxL2caQueueSize_c
=> Is there a way to configure this from BLE data sender or a host.
Followed other threads in this community where they also mentioned about the gBleOverflow_c error, and followed guide lines and make sure to configure gAppMaxConnections_c to 1. And also tried resending the packet but that does not seems to work.
Need your assistance.
Thank you Mario for the update.
So this error is thrown from the BLE receiver end, this error is thrown when the Host sends packets faster than the receiver acknowledges and process the packet. Since we dont have a control on the receiver implementation I guess we left with the option of resending the last packet to which receiver has not acknowledged.