The link for "Series 2" provided by Arduino.cc does not provide a complete configuration solution:
). This article will only provide one way communication. Remote control is only possible with two way communication. For point to point this is achieved by ensuring that the SH/SL and DH/DL parameters mirror each other in the Coordinator and the Router as demonstrated in the following two X-CTU screens:
Assuming that you have followed the above article but selected the more current software "ZIGBEE ROUTER AT" (first), entered a PAN ID and note the SH and SL addressing numbers. When completing the "ZIGBEE COORDINATOR AT" (second) use the same PAN ID and also enter the Router SH/SL numbers in the DH/DL numbers for the Coordinator. This configuration provides two way communication.
Once you have installed the Xbees and you wish to upload a modified program to the Arduino follow these steps: move the two jumpers on the Arduino board to the USB position, remove the Xbee chip from the Xbee / Arduino Shield, connect the USB cable from your PC to the Arduino board, startup the Arduino Programming Environment, then hit the upload button.
To demonstrate Xbee Two Way Comm here is a result received by my PC:
This picture shows readings from RobotTank via Xbee to "SerialPort Terminal". "R" for infrared "P" for Sonic Ping "L" for Light Sensor. When I entered a "s" for a stop command RobotTank stopped and carried out a sonic scan providing an array of "H" for angle and "S" for sonic (cm to object) data to be loaded into a graph object.
The second picture demonstrates a too close object detected by infrared ("R282" up to "R535") thus causing an automatic stop and RobotTank sending morse code of "SOS".
What are the unsolved problems? Firstly the Xbee Shield blocks the Arduino Pin 0 (RX) and Pin 1 (TX) and I do not know what might happen if I soldered wires direct to Pin 1 for the Pololu Micro Serial Servo Controller and the Pololu Low-Voltage Dual Serial Motor Controller (Note the yellow wire sticking up in the RobotTank photo). Did the designer of the Xbee Shield deliberately block Pin 1 to protect the Xbee chip? The recommended solution is to use the NewSoftwareSerial Library but the Servo Library conflicits with this library and may be a barrier to future design. I will try the NewSoftwareSerial Library to determine whether it is a real solution.
The aerial supplied by Robotshop for the Xbee has a male connector and so has the Xbee chip got a male connector!
Subject: RE: DIGI International, Update for Case: 1295307.
Date: Tuesday, 29 June 2010 11:10 a.m.
Thanks for the screen shots.
Yes, I can see why this is only transmitting in one direction. It is due to the DH=0 and DL=0 setting on your coordinator. Right now the coordinator is addressed to itself. The coordinator always has the 16 bit address of 0x0000. You should set the DH and DL of the coordinator to match the SH and SL of the router device respectively.
So, on your coordinator set:
This will allow the coordinator to transmit to the router.
As a side note, the ZNet 2.5 firmware is quite old and has been superseded by the XBee ZB firmware. I recommend that you upgrade the modules to ZB firmware. This can be done by selecting XB24-ZB in the modem pull down list, select Zigbee Coordinator AT for the function set and 2070 for the version. Then click the "Write" button. The module will be upgraded to XBee ZB
For the Router:
Select XB24-ZB in the modem pull down list, select Zigbee Router AT for the function set
and 2270 for the version. Then click the "Write" button. The module will be upgraded to XBee ZB
Please let me know if there is anything else I can help you with.
Yes your addressing looks good. Of course, if you use API, the addressing on the modules is irrelevant as packet addressing is contained in the API packet.
I can tell from the screen shots that at the time the router had not yet associated with the Coordinator as the OP, OI and CH are not yet matching the coordinator’s.
If you make changes to the coordinator after the network is formed (i.e. change the SC parameter) it will likely form a new PAN with a new OI and channel. If this happens you will need to issue a network reset of the routers to allow them to join the new network. In AT mode, you can do this by going to the terminal screen and issuing an ATNR0 command.
This will cause the module to discard its network settings and look for a new PAN to join.
Another hint: You may already know this but, If you have the “Always Update firmware” checkbox checked when you try to write a single parameter, the entire firmware will be re-written and this will take a considerable amount of time.
Please let me know if you have any further questions.