Bluetooth sniffer

[ricardocrl]

My understanding around these topics is not the best, but I am quite sure that, at least, queue overflow never happens in your case.

The master sends the messages to the slave; the slave's FW handles this messages, through the Bluetooth module and places them in the right mailboxes queues. This means that when you do a "ReceiveMessage" from the NXC program on your slave, it just reads from the local mailboxes. So, I think this takes very short time, compared to the Bluetooth tasks.

My guess is that the SendRemote functions are placing data on the BT output buffers in higher rate than the firmware (or other entity lol) can handle.

[mcsummation]

The question I'm trying to answer is: Are the messages being lost in the master or slave?

I finally developed a test case that answers the question, as far as I'm concerned. What I did was:
- Stubbed out everything in the master except the 2 threads that are running hard.
- Changed the slave code so it only sees if it has lost a message and reports the number of lost messages when one is lost.
- Got this working properly by putting a Wait(5) in the master loops; otherwise, they either overrun the slave or don't get equal numbers of messages sent. This ran for over 35000 messages sent through each mailbox with none lost at the slave.
- Added a Wait(1) to one of the slave receive loops. It immediately started missing messages.

So, I conclude that the messages are being lost in the slave, not the master.

[mcsummation]

- You probably know the groundbreaking analysis of the NXT bluetooth protocol by Silvan Toledo? http://www.tau.ac.il/~stoledo/lego/btperformance.html

I had not seen that analysis and am reading it now.