The NXT has a very powerful communication capability between two NXTs using the wireless Bluetooth functionality built into every NXT. The “Messaging” functions described here provide a easy approach for using this communication. It limits the communication to messages containing three 16-bit parameters.
It is very easy to set up Bluetooth communications between two NXTs.
1. Use the NXT’s on-brick user interface to make a connection between two NXTs. [It is also possible to set up the connections within a user’s program but that is for the advanced user.
2. Use the sendMessage(nMessageID)and sendMessageWithParms(nMessageID, nParm1, nParm2) functions to send outgoing messages.
3. Use the variables message and messageParms to retrieve the contents of a message. When you’ve finished processing a message, use the ClearMessage() function to “zero out” the message so that your program can process subsequent messages. The next time your program references the message variable, it will be for the next message that has arrived.
There are two functions for easily sending messages. One sends a single 16-bit value and the other sends three 16-bit values. Either of the two NXTs can send messages at either time. It is the responsibility of the user program to not send messages too frequently as they may cause congestion on either the Bluetooth link or overflow of the NXT’s transmit and receive queues.
sendMessage(nMessageID) Sends a single 16-bit word message. 'nMessageID' should range in value form -32767 to +32767. Message value 0 is invalid and should not be used. It is a special value to indicate "no message" received when using the "message" variable.
sendMessageWithParm(nMessageID, nParm1, nParm2)
This function is identical to the sendMessage function except that the message contains three 16-bit values. This is useful in easily sending separate items of information in a single message.
Do not use a value of zero for 'nMessageID'.
The NXT firmware automatically receives messages and adds them to a queue of incoming messages. The application program takes the messages from this queue and processes them one at a time. The variables message and messageParm contain the contents of the current message being processed. The function ClearMessage discards the current message and sets up to process the next message.
message
This variable contains the 16-bit value of message received over the Bluetooth channel.
It has a range of -32767 to 32767.
A value of zero is special and indicates that there is “no message”. Whenever
the value is zero and the message variable is accessed, the firmware will check
to see if it has any received messages in its queue; if so, it will take the
first message and transfer its contents to the message and messageParms
variables. These two variables will continue to contain the message contents
until the user’s program indicates it has finished processing the message by
calling the ClearMessage() function.
messageParm[] Array
containing optional message parameters (up to 3 16-bit words) for messages
received over the RCX infrared channel.
messageParm[0]
is the same as message
messageParm[1] and messageParm[2] are additional 16-bit
values.
bQueuedMsgAvailable() Boolean function that indicates whether a unprocessed message is available in the NXT's received message queue. This is useful when multiple messages have been queued and your program wants to skip to the last message received. Your program can simply read and discard messages as long as a message is available in the queue.
ClearMessage() Clears the current message. The next time the message variable is accessed, the firmware will attempt to obtain the first message from the queue of messages received by the NXT.
Do not send messages faster than about one message per 30 milliseconds or it is possible for some messages to be lost.
A typical application might have one NXT send a message to the NXT on a periodic basis. For example, it might send a message containing the current values of sensors S1 and S2 every 100 milliseconds. Due to processing delays in the receiving NXT, several messages may have been queued and your program may want to rapidly skip to the last message received. The following are two code snippets that show how this might be accomplished.
The code in the NXT sending the sensor values:
while (true)
{
sendMessageWithParm(SensorValue[S1], SensorValue[S2], 0);
wait1Msec(100); // Don’t send messages too frequently.
}
The code in the receiving NXT:
while (true)
{
//
// Skip to the last message received
//
while (bQueuedMsgAvailable())
{
word temp;
ClearMessage(); // We’re ready to process the next message
temp = message; // Obtain the next message
}
if (message == 0)
{
// No message is available to process
wait1Msec(5);
continue;
}
// A message is ready to be processed
remoteSensor1 = message; // the value of ‘S1’ from the remote NXT
remoteSensor2 = messageParm[1]; // the value of ‘S2’ from the remote NXT
. . . user code to process the message. It may have many delays.
}
NOTE: The RobotC IDE debugger can operate over either USB or Bluetooth connection to the NXT. When an application program uses the Bluetooth connection to send messages to another NXT then you cannot use the Bluetooth debugger connection. They are incompatible.
This functionality is similar to that found on the LEGO Mindstorms RCX with a few notable exceptions:
1. The RCX uses an infrared communications link. The NXT uses a wireless Bluetooth link.
2. The RCX used broadcast messages that could be received by any RCX. The NXT uses “directed” messages that go to a single NXT.
3. Two RCXes sending messages simultaneously would corrupt both messages. The NXT’s Bluetooth allows simultaneous message transmission.
4. There was no queueing of received messages on the RCX. When a new message arrives at the RCX it overwrites previously unhandled messages or it is discarded if the current message is not finished processing.