NXT Bluetooth Overview
|For ROBOTC Bluetooth NXT functions, check out the NXT Bluetooth Functions page!|
We are always impressed with what users are able to accomplish with ROBOTC. Our community continues to grow, and over time we find “power users” out there that not only understand the more difficult programming concepts, but are able to create tutorials to help many others perform certain tasks. Bluetooth is one of those harder behaviors to program. Luckily, Laurens over at Robot Square wrote up a nice tutorial on how to use Bluetooth communication with ROBOTC.
Take a look at Laurens‘s writeup over on robotsquare.com: http://robotsquare.com/2012/03/21/tutorial-robotc-bluetooth/
|Bluetooth (BT) is an industry standard short-distance (up to 10 meters) wireless communications protocol operating at 2.4 GHz. It can optionally use a higher power transmission to achieve distances up to 100 meters. The NXT utilizes the 10 meter option.
BT includes not only the low-level radio transmission (at 2.5 GHz) but also several higher layer message protocols (or profiles) designed for different applications. There are over 25 different BT profiles currently defined. Some of the more popular profiles include:
In order to connect two devices via BT, the devices must not only support BT but also support the type of profile that will be used for the connection. The NXT only supports the SPP so that it cannot, for example, directly connect to a Nintendo or Sony game controller.
It is very easy to set up Bluetooth communications between two NXTs.
ROBOTC measured performance to send a BT message, receive it at far end, process it, generate a reply and receive it at original device is about 36 such transactions per second. Other implementations (e.g. NXT-G) typically support about 13 transactions per second.
ROBOTC allows full duplex operation over a single BT stream. Measured performance indicates that each end of the stream can autonomously send 250 messages per second. The half-duplex implementation is limited to 13.
This functionality is similar to that found on the LEGO Mindstorms RCX with a few notable exceptions:
Sending Messages via Bluetooth
|Once you have two NXTs connected via BT, it is very easy to send messages between them. There are only three functions that are needed:
After calling each of the above functions you should check the returned value to determine the success/failure of the function. Use the function cCmdMessageWriteToBluetooth(nQueueID, nXmitBuffer, nSizeOfMessage) to send a BT message to the far end NXT. Check the error code to make sure message was transmitted successfully. This sends the message (up to 58 bytes in length) in the variable nXmitBuffer to queue or mailbox number nQueueID on the far end NXT. nSizeOfMessage is the length of the message.
When messages are received over BT by a NXT they are automatically added to the end of one of the 10 message or mailbox queues. Use the function cCmdMessageGetSize(nQueueID) to determine whether any messages have been received. A positive return value indicates that a message was received and is the number of bytes in the message.
Use the function cCmdMessageRead(nQueueID, nRcvBuffer, nSizeOfMessage) to retrieve the first message from the specified mailbox and copy it to a user’s buffer at nRcvBuffer. Only the first nSizeOfMessage bytes of the message are copied. nQueueID is the mailbox number to obtain the message from.
The sample program "NXT BT Messaging No Error Checking.c" is a simple program to show how to use all three of the functions.
|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.
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.
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.
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.
Array containing optional message parameters (up to 3 16-bit words) for messages received over the RCX infrared channel. messageParm is the same as message. messageParm and messageParm are additional 16-bit values.
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.
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.
Skipping Queued Messages
|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:
|The code in the receiving NXT:
Master vs Slave Device
|One end of a BT connection is the master device and the other end is the slave device. The master device generates the clocking signal used for the BT connection and the slave device derives its clock from the received radio signal. This results in the following restrictions:
Bluecore Bluetooth Information
|BT implementation on the NXT uses a "Bluecore" chip from CSR. Bluecore is a self-contained implementation of BT that manages the BT hardware and protocols. It has a few limitations that are common to many other BT hardware implementations:
NXT-G Bluetooth Messaging Compatibility
|The NXT-G firmware has built a message passing system on top of the NXT Bluecore implementation. It works as follows: