Notifications arriving out of order

[Mike Thomspon]

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.

[Ole Morten]

You're right that notifications should have their ordering preserved, and I can't say that this is something we've heard about before. Could you please upload the log file that Master Emulator generates? It will typically be placed in C:\ProgramData\Nordic Semiconductor\MasterEmulator on Windows 7, and in the C:\Documents and Settings\All Users\Application Data\ tree on Windows XP.

Also beware that Master Emulator isn't really meant to be used for production solutions, but only for development and testing, and is not a qualified Bluetooth Central solution. If you need this, you'll most likely be better off using the S120.

[Mike Thomspon]

OK, I'll look into getting at the log files. I basically wanted to verify that the ordering of the notifications should indeed preserved. It's possible there is a race condition in sending the packets and perhaps that is where things might be messing up -- firmware issue will be easier for me to deal with. :-)

For the Master Emulator, I'm simulating the client application side which will eventually be iOS and Android apps. It's just easier for me to do protocol and firmware development using the Master Emulator than having the overhead of having to navigate the iOS and Android SDK to create test applications.

[Mike Thomspon]

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...