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.)
NXC - adding hex digits and timing
Re: NXC - adding hex digits and timing
that's probably why I observe it to be shaky.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.
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.
-
- Posts: 220
- Joined: 23 Jan 2012, 17:07
- Location: Round Rock, TX
Re: NXC - adding hex digits and timing
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.
McSummation aka James
http://www.mcsummation.com/Mindstorms/
http://www.mcsummation.com/Mindstorms/
Re: NXC - adding hex digits and timing
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.
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.
Who is online
Users browsing this forum: No registered users and 1 guest