We are testing BLE peripheral device throughput with PSoC63. We know that with another peripheral device we can achieve up to 6-7kB/s but with PSoC63 only 3kB/s. We sniffed communication between central and peripheral (PSoC63) device and there are duplicate packets like frame 12678 and 12680 (attached).
Do you know why the central device needs to resend packets when communicating with the PSoC63 device?
Is it that PSoC63 stack doesn't process messages quickly enough and its internal buffer is full and therefore packet is rejected?
The central device is BLE 4.0. BLE communication uses 7.5ms interval windows with 4 packets in each.
The PSoC 6-PSoC6 throughput measured 1270 Kbps with extended datarate enabled.
Please go through the code example provided byt Cypress from the link below:
Please ensure that you are following the same firmware flow in your application. If you follow that and still if you are getting low throughput means, please attach the minimal project for us to debug at our side.
the example uses notifications to measure throughput. Unfortunately we are in oposite situation. We are using write without response (CY_BLE_EVT_GATTS_WRITE_CMD_REQ) and an BLE 4.0 android device. It means only 4 x 20B packets per interval window. Teoretical throughput in such environment is 10.4KB/s.
We calls Cy_BLE_ProcessEvents(); each 5ms. From documentation Cy_BLE_ProcessEvents should process all pendling operations. "
On calling at every interval 't', all pending operations of the BLE Stack are processed." Still, We see that each packet needs to be resent when central device sends 4 packets per 7.5ms window.
Each packet is one incomming operation? Does it mean that we have to call Cy_BLE_ProcessEvents more frequently? Have BLESS a function to know that an operation is ongoing and Cy_BLE_ProcessEvent should be called?