Mindboards

Thanks for digging down and explaining the failures I'm seeing. And regarding the timing of BT, I agree, as I experiment
more, including using Waits and whiles to check that the current BT op has completed, or at least know its state, before
starting the next op. (I'm still on the BT learning curve.)

Bluetooth communication is not timing dependent so much as it is dependent upon checking that you aren't stepping on top of a previous attempt to send or receive a bluetooth message.

that's probably why I observe it to be shaky.
If several tasks of the master send and/or receive independently (to/from 1 or more slaves to/from different mailboxes or trying to receive response messages) then often the program hangs up.

Doc, tabby, I found this article http://www.tau.ac.il/~stoledo/lego/btperformance.html while looking for NXT Bluetooth information. Although it is not written for NXC, it explains the communication protocol of NXT Bluetooth, the "dialog" between Master and Slave, and why/how you can loose messages. It also has information about timing of Master/Slave communication.

mc, thank you for posting that link.
It indeed was really helpful, especially the chapters "NXT as a slave" and "conclusions".
I first of all will insert longer wait states of at least 50 ms between each sending to slaves by the master and also between all slaves' putting sensor values into out-boxes.
Unfortunately the BT send/receive tasks all are asynchronous so it's quite sure that there still will occure interferences, but hopefully they now can be handled by the firmware protocol.