I’m currently working on a project that transmits high-speed data received from an external chip to SW I2C to the connected BLE.
As shown in the figure above, 2BYTE data is received in approximately 103us cycles.
Wehn receiving 2 bytes and passing it by using notification API, the order of data is changed.
As shown in the figure above, data is delivered in order from 0x01 to 0x12, but the order of data delivered to notification is changed.
How can I send it in normal order?
Your question is not clear.
You said “the order of data delivered to notification is changed.”
Does that mean you sent notification data “0x01 0x02 0x03 0x04 0x05” and your BLE receiver side has got different order for these data?
The data received from the receiver is output to uart. As shown in the figure above, the order of data is continuously changed.
current receiver is RSL10. The same symptoms appear when using the receiver of Android phone.
Hi @shna ,
Thanks for your clarification.
Since I don’t have your project to verify, you could use our RSL10 sample project to verify the BLE notification and see if its order is correct or not.
a. peripheral_server_UART and central_client_UART. you can use that to verify notification data order.
b. peripheral_server with Android to see notification data order.
For example: (in the peripheral_server sample code)
and you will have this result.
so you can see there is no order issue.
First of all, thanks for quick reply.
I know that there is no order issue if we pile up the data in the buffer and send it all at once.
however, currently I have to continuously transmit the high-speed data received through I2C data.
It seems that the issue occurs when notification is sent quicly in 2(4,8)Byte units.
Hi @shna ,
You’d better to reference our peripheral_server_UART and central_client_UART. and see if you can find better BLE throughput. and try to find where is the bottle neck. It also depends on your application as well.