This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Notifications arriving out of order

I'm using the nRF51822 with the version v5.2.1 S110 soft device and have implemented a communication scheme that is very nearly identical to the Nordic UART protocol as implemented in the "ble_app_uart" example that I found out about elsewhere in this forum.

The issue I'm running into is that the notifications will occasionally arrive out of order at my Windows .Net application that utilizes the Master Emulator DLLs. As far as I can tell, this only occurs in a single direction (from the nRF51822 peripheral to the PC) and packets aren't getting dropped, but actually are arriving up the Master Emulator stack in an order different than submitting them to the S110 soft device. The ordering issue also seems to happen in waves -- a large number of packets get through OK, but then a bunch will then be out of order then ordering is fine again.

It was my understanding that BTLE notifications should have their ordering preserved as they are transmitted and received. Is this a faulty assumption on my part? Is there some mechanism that I should use when sending notifications with sd_ble_gatts_hvx() that would preserve their order?

Any suggestions or information on where I should look to understand notification ordering issues would be very helpful. Thanks.

Parents
  • The issue of "out of order" packets was with my implementation in the nRF51822 firmware and the S110 soft device. It turns out I was queuing notifications from a loop in the main() function and from a timer handler. I suspect the timer would preempt the sending of the packet from the main() function and the race condition caused me to send packets through the S110 in an order different from what I expected. Fixing the code to only send notifications from the main() function solved the issue and packets do indeed preserve their order. :)

    Sorry for the dumb question...

Reply
  • The issue of "out of order" packets was with my implementation in the nRF51822 firmware and the S110 soft device. It turns out I was queuing notifications from a loop in the main() function and from a timer handler. I suspect the timer would preempt the sending of the packet from the main() function and the race condition caused me to send packets through the S110 in an order different from what I expected. Fixing the code to only send notifications from the main() function solved the issue and packets do indeed preserve their order. :)

    Sorry for the dumb question...

Children
No Data
Related