Problem in data transfer in Bluetooth at 10ms

[sharmelaraju]

Hi,

We are using NRF52840 Dk board to transfer the data at 10ms through Bluetooth which is central and peripheral  as other cc250moda controller  Bluetooth. Our objective is to send the data of 8 bytes at  10ms from the NRF52840 Bluetooth to other Bluetooth. We are able to send the data from NRF52840 Bluetooth of 8 bytes at 30ms,50ms,100ms,500 ms to other controller Bluetooth correctly which means at every 50ms  we are sending 8  of bytes data which is receiving  8 bytes of data at every 50ms in the receiving controller Bluetooth. The problem here is when we are sending the  8 bytes of data at 10ms from NRF52840  Bluetooth to  receiving Bluetooth it should read  8 bytes of data at 10ms but here the problem is it is reading as 8 bytes, 16 bytes ,24 bytes ,0 bytes ,0 bytes, 24 bytes,16 bytes, 0 bytes, 0 bytes  as such at every 10 ms.Can you please tell me what is the problem . How to resolve the issue.

[Karl Ylvisaker]

Hello again,

sharmelaraju said:

I have tried  cc2564moda Bluetooth(central) with  cc2564moda Bluetooth(peripheral) .With this communication it is working fine.

That is very strange to hear. Are you saying that the cc2564moda peripheral behaves differently with a cc2564moda, without any changes to the peripheral code? Could you detail how it is different - do you not see the occasional double or triple message appear on the debug terminal of the peripheral?
I do not think this is likely.

From the logs you sent, it is evident that the nRF sends all the data as expected when configured as the central. 10 ms connection intervals delivering your custom data to the peripheral.

Do I have it correctly that you in your cc2564moda peripheral code use a 10 ms timer to trigger reading of the BLE RX buffer?
In the case that I was correct:
Did you attempt what I suggested in my last comment - switching the cc2564moda peripheral code to instead react to radio RX events rather than a 10 ms timer? I think this would solve your problem, as the central is sending everything it is supposed to, when it is supposed to, according to the logs.
It would also free up resources on your peripheral advice, and conform more to best-practice principles of embedded development.

Looking forward to hearing from you,

Best regards,
Karl