Another thing, more on the point of what you actually want to do (I've always been a big fan of NXT performance and stress tests, especially for Bluetooth performance):
- Can you just protect all the Bluetooth operations from different tasks with a single "BT-access-mutex" to see if the packet loss goes away? I know this mutex will kill performance, BUT: If the firmware does these Bluetooth calls "async" and processes them internally with its own modules etc., then the mutex won't be acquired for too long during your sends...
- I've been experimenting with "data-logging to memory" before. Can't you just put a unique message number, the mailbox number, and a timestamp (CurrentTick()) in a log-queue /array inside memory? And then inspect these data later? A short example how to data-log to memory (big word, it's just filling an array -- I'm sure you could've done this on your own) is here: http://www.mindstorms.rwth-aachen.de/tr ... ataLogging
- If I remember correctly, each mailbox has its own message-queue, and it's very short. So you could do some sort of "mailbox round-robin" to keep the mailboxes from overflowing.
- You said your production code is running smoothly. How did you solve it? Do you have one "bluetooth task" which handles all BT stuff, and other tasks just defer their data sending to this task via some protected channel (vars/structs/flags with mutexes or some sort of queue)?
- You probably know the groundbreaking analysis of the NXT bluetooth protocol by Silvan Toledo? http://www.tau.ac.il/~stoledo/lego/btperformance.html