Hi all; after reading all the posts of people having trouble with their XBees generally due to user error or a misunderstanding, I figured I should ask the experts. My strength is very much on the software side, not the hardware, so please be gentle
I’m building a robot that will be controlled from a remote computer via an XBee. The robot will be using the [Axon II microcontroller. I need to be able to send data to the robot from the computer and receive data back from the robot. I don’t plan on there being a massive amount of data but obviously the more I can support the better. I have no range or antenna requirements at all but I’d love all the range I can get just 'cause.
On the computer side, I was planning on using the “[XBee USB Explorer”. The computer control would be written in ideally Java but either C++ or C# work too. All of this leads me to a couple of questions:
1) What XBee module and firmware should I use for the computer side?
What XBee module and firmware should I use for the robot side?
Any suggestions on how to interface the XBee to the robot easily?
I’ve read that XBee’s have “error correction” but not the details on that. Should I write my own protocol layer with checksum and retransmit capabilities or does it do that internally? Losing a packet and ignoring it is not an option for this project and I’m comfortable writing a protocol if need be.
What questions should I be asking but don’t know to ask?
You may or may not be aware that the Series 1 and Series 2 XBees cannot talk to each other. You need to use the same type of XBee on the controller and robot sides.
Will your robot be 3.3V friendly, or is it all 5V? That will make a difference to the type of board you use for your XBee modules.
I have never used the Series 2 XBees, so I might not have the most informed opinion here, but it doesn’t sound to me as though you’re planning anything that would require that fancy-danged “mesh” stuff. The Series 1 XBees are nice and simple, and work well right out of the box (as it were - they seem to normally come in a tube, actually).
That being said, I’ve found that XBees seem to arrive with somewhat dated firmware loaded. I believe that there are no disadvantages to using the newest firmware (someone correct me if I’m wrong about that), so I’d plan to update them to that. That of course means having a connection to your computer with all of the pins needed for updating firmware (VCC, ground, DIN, DOUT, RTS, DTR).
Thanks for the quick reply. The Axon II is mostly 5v, though it can drive some very low current 3.3v stuff. I’d rather keep things in the 5v area. Thanks!
Works great for two way communication to my Bot. Just connect four wires.
I use the Series 2 XBee modules running ZigBee firmware. These require one XBee to be a coordinator to create a network. The XBee on the Bot integrates into the existing ZigBee network I have.
The Series 1 modules running 802.15.14 protocol is all that’s necessary for just point to point communication. These are the recommended XBees for simple applications such as yours.
If you need greater distance then there are the PRO modules that have greater RF output power.
I think the idea of being able to have a network of these is very interesting in general and so I’m totally open to going that route. I assume the coordinator has to route messages or is their a broadcast concept that sends messages to every connected node? Also, is the mesh network bi-directional? Finally, what about data loss - do I need to account for that in my protocol?
the default: One PAN coordinator and any number of PAN “end-points”. End-points “associate” to the coordinator and can send data packets to the coordinator or other nodes. Packets are sent using a coordinator-assigned “network layer” address.
Changing the XBee’s register settings from the default, you can use a peer-to-peer network. Here, there is no coordinator. No network layer addresses. All XBee nodes are identical in function. Any node sends data to any other node using the destination node’s radio MAC address in the DH:DL registers (64 bit). Or send to the broadcast address (0xFFFF). To do peer to peer mode, use XCTU or AT commands to turn off coordinator mode in that node, turn off association required in all, and turn off the Digi protocol (MAC layer mode) - where 2 bytes of the payload are unique to Digi - used for virtual wire.
webgeek:
Finally, what about data loss - do I need to account for that in my protocol?
Thanks!
Mike
In Broadcast mode there isn’t any data ACK’s or retransmissions.
When a Designation address is used there are ACKs and retransmissions. As with almost any serial protocol if the data integrity most be high then add your own layer to at least ensure the data is correct.
