I also went down the checklist of common xbee mistakes at http://www.faludi.com/projects/common-xbee-mistakes/
Not using the latest firmware (especially if ATD0 or ATIR is giving an error)*
-The first thing I did was update the firmware to 10E6.
No reference voltage to VREF pin on the 802.15.4 radios (analog and digital reads give wrong values)
-I put 3.3V on VREF pin. Even a wrong value would be better than seeing nothing, though.
Forgetting that AT commands use hexadecimals
-All my AT commands are using values less than 10 anyway
Hitting return after +++ (or otherwise not respecting 1 second default guard time)
Conversely, not hitting return after an AT command
Letting the XBee time out of command mode before issuing an AT command (you’ll know because you get no response)
Forgetting to write the configuration to firmware with ATWR (unless your application configures the radio interactively)
-These four are not applicable because I was not using the terminal. I was using the Modem Configuration tab on X-CTU. I know the settings were saved because they are still read even after power to the xbee was disconnected.
Not using ATRE (restore factory defaults) before re-configuring a previously used radio (previous settings lurk unless you manually reset them all)
Not applicable because xbees were bought new (but I did this anyway)
Looking for analog output on the analog input pins instead of pins 6 and 7 (P0, P1)
-I’m looking for output everywhere. I’ve got LEDs on pins 11, 12, 15, 16, 17, 18, 19, 20, and there’s one LED that I’m moving around to check pins 2,3,and 7. LEDs are lighting up on pins 11, 12, 15, and 16, but they remain lit even if the corresponding inputs are put low. So this output is still not satisfactory. I want the output to respond to changes in input.
Using a voltage regulator without decoupling capacitors (10uF on input, 1uF on output is good)
-Not using a regulator right now because I’m testing the xbees in isolation, so 3.3V is being put in directly from the power supply.
Mixing up TX and RX pins (fastest way to check this is switch the wires and see if it starts working)
-I think this is only if we’re using a microcontroller. While I will eventually want to do this, right now I just want to see the output xbee change with the input xbee, i.e. I just want to see them working.
Using ZigBee version (ZB Pro or ZNet 2.5) when 802.15.4 version would do just fine (if you don’t need to make a mesh network)
Trying to read more than 1.2 Volts on the ZB Pro and ZNet 2.5 analog inputs (that’s the limit)
Buying Pro radios when you don’t need them. (Cost more, bigger, use a lot more battery)
-These 3 are not applicable
Deciding the XBees are flaky. (You may not be using them correctly, but they are very reliable)
-I’m still trying
Deciding an XBee is burned out when it’s set to a different baud rate (check ON and ASSC lights)
Deciding an XBee is burned out when it is just sleeping (Check ON light to see if it blinks occasionally)
-For these two, I have a different breakout board that doesn’t have these lights, they are set to the same baudrate, and I don’t think they are burned out because they are new. I couldn’t have gotten two bad ones, could I?
Forgetting to supply power or ground (ON light may go on and ASSC light may blink but both will be significantly dimmer)
-I’m fairly certain I supplied power and ground. Again, I lack these lights but I checked with a voltmeter.
Not contacting Digi sooner for support, especially if your radio seems dead or you keep getting an error you don’t understand.
-I may well have to do this. I tried running the range test and for both the radios it just says “Timeout waiting for data” even though the modem configuration tab is able to read the AT commands. But like I said, what are the odds of getting 2 new xbees and both of them are bad?
