XBee has written all sorts of really great things into their firmware. Fortunately for us, they’re pretty easy to use.
Setting up a secure network can be useful even if you’re not sending back and for TSSCI packets of security information on Al Queda. Your reasons could be more mundane though. The radio signals that XBee use are very common, especially in urban areas, and if your setup is running on an open line (the default), you can easily pick up interference from other people’s XBee radios. If you’re running a remote controlled car for example, you can start getting signals from other networks.
One final reason may be that you want to use the NXTBee to communicate during competitions where others may be using them. They may not be interested in the information you’re sending your robot, but with a bunch of folks using the radios, they may interfere. Using this code will prevent any crosstalk between robots.
To prevent this, we’ll just setup a private radio network with our sensors in a few easy steps. Below, we’ll outline what they are. Most of the comments are commented into our example code.
First, we will establish the Network ID the radio will talk on. You can set this to just about anything you like if you want to keep it secret. YOu can also let the radio do the work. By setting it to ‘0’, where the radio will select a random ID and join.
In RobotC, the array we’ll send to do to radio looks like this:
const ubyte cmd_ID[] = {'A','T',' ','I','D','0',13};
Next, we will Enable Encryption. This is just a matter of turning on the encryption. The call is “EE” and followed by a “1” to turn encryption on, and a “0” to turn it off. Here’s what it looks like:
const ubyte cmd_EE[] = {'A','T',' ','E','E','1',13};
Next is optional: set the Network Encryption Key. You can read more about this here, but this step is optional. If we set the variable to “0” the radio will do the work again.
const ubyte cmd_NK[] = {'A','T',' ','N','K','0',13};
Finally, we will setup the Link Key. This is another 128-bit key that helps establish the network. This can be randomly assigned, but you must add it to each radio that you want on your network. If we set this to “0” the first radio will transmit the key out openly, which can corrupt your network.
const ubyte cmd_KY[] = {'A','T',' ','K','Y','4','4','5','5',13};
// Our Key is "4455"
And that’s it. Once you’ve run this on each of your NXTBee sensors, they will all be on the same network and able to communicate without interference. Now your NXTBee’s can talk in complete confidence.
Undoing your work: Let’s say you now want to run your NXTBee’s on an open network again and let everyone hear and see what you’re up to. No problem! Running our configuration example to reset the firmware and baud rate will get you back to where you started!
You can download the code for a secure network of NXTBee Sensors here.
You can also download other examples for the NXTBee Sensor and other sensors from our downloads section here.
Related Articles
14 Comments
-
The code for setting up the secure network has an error on line 158. Not all paths return a value in the CheckResponse function.
-
Thanks for pointing this out! Small detail, and the old code seemed to compile ok for us.
We’ve reposted a corrected version with a “false” return on the bool.
-
-
For anyone interested in what the values mean being passed from the AT command (in particular the NK key value) you can find it in this document http://www.dexterindustries.com/files/90000976_D.pdf
The values in the code are taken from the security example on page 64 (with exception to the network id).
-
Is the Exit Command byte stream correct? In the code I copied it says cmd_ExitCommandMode[] = {‘A’,’T’,’C’,’N’,13};
Shouldn’t there be a space between AT and CN like so
cmd_ExitCommandMode[] = {‘A’,’T’,’ ‘,’C’,’N’,13};Also on line 33 it says cmd_SetPin[] = {‘A’,’T’,’ ‘, ‘D’,’7′,’7′, 13};
Should there be a space between D7 and 7 (setting the D7 pin RS-485 to transmit
enable (high enable))?? -
Author
Dennis,
This code seems to work fine for us in the current form. You should be able to use, or not use, spaces as they are in the code. Were you having trouble with this call? -
Thanks John,
Actually it is working fine for me I was just asking given I relatively new to this.
I am wondering if anyone has written code that sent packets via unicast instead of broadcasting? I have 3 NXTBees all on the same network and by default a call to nxtWriteRawHS() will broadcast to all devices the data being sent.
It looks like I can set the address for unicasting (if I know the 64 bit address) by going into command mode and setting the DH and DL to the upper and lower bytes respectively.
I read this in the XBee-PRO® ZB RF Modules at http://www.dexterindustries.com/files/90000976_D.pdf pg 42-43
Just curious if this has been tried yet. I will be giving it a shot within the next couple of days anyway and if I get it working I’ll post something up.
-
Dennis:
Nope, we haven’t written anything like this yet. It should definitely be doable though! When you finish it, please let us know! We’d like to share it with everyone. -
Ok I tried it out and I have it working sort of. It isn’t pretty because I had to hard code in the 64 bit hardware addresses. Also it doesn’t always seem to return an “OK” in the response buffer but it still seems to work nevertheless.
I’ll post something up when I have the code a bit cleaner or should I email it to you directly.
-
How does using encryption prevent interference and cross-talk on the radio spectrum (as mentioned in the original blog? I don’t think it does. It simply prevents others from intentionally listening to your radio traffic.
I’ve found that some XBee/ZigBee channels can be congested or electrically noisy and it’s sometimes best to switch to a different ZigBee channel. XBee has commands for this.
-
Dick this is a really good point and we
apologizefordidn’t mean to cause any confusion on this. Using encryption doesn’t prevent interference from other RF sources. However, it does prevent confusing signals from other sources. It’s a good point. And that’s a great point that you can change the channels of the XBees. Do you have experience with this or an example we can reference?
-
-
Regarding unicasting vs broadcasting.
If you want to send directed unicast messages to one of several different XBees then you probably want to use the XBee’s API mode rather than AT commands. The “difficulty” with AT commands is that it takes a couple of seconds to enter AT command mode to change the destination address and exit AT command mode. Then you can send some data. And if you want to communicate with a different XBee you have another couple seconds of waiting to change the address.
-
Again, another good point. If anyone is interested in this sort of communication, we’re happy to work on an example solution.
-
-
Hi:
I am very interesting in the code for sent packets via unicast. I have some NXT Robots. I can communicate them using XBee from a PC through a Gateway and a Java App. But I need to communicate the robots one each other.
Thank you very much -
I use API (1) mode and 16 bits Address
Leave a reply
You must be logged in to post a comment.
