XBee Pro S3B and Parallex 32400 USB Adapter Board not communicating

I can not get modem communication in X-CTU with a Parallex 32400 USB adapter board and a XBee Pro S3B. Any ideas?
Thanks for your help
Rick

If you connect an XBee XSC (S3B) module into a third-party interface board (such as the Sparkfun USB Explorer, or Parallax USB Adapter) you may be unable to communicate to the module using X-CTU. This is because several third-party interface boards have an LED connected to pin 6 of the XBee header. This LED provides an indicator for the RSSI (signal strength) for most XBee modules. To verify that you are being affected by this particular issue, when viewing the UART of the radio, you will notice a sequential series of numbers being generated.

The XBee XSC (both S3 and S3B) modules have a slightly different pinout than the rest of the XBee product line. Pin 6 is used as a config line rather than an RSSI indicator. A legacy feature on the XSC is a diagnostic tool called “pitch mode”, when the config line is pulled low during startup, it starts sequentially counting numbers and outputs it to the UART. This feature was originally used to perform a range test and allows further backwards compatibility with the XStream radio.

Because an LED indicator is connected to this CONFIG line on the third-party interface board, the XSC (S3B) module will enter pitch mode due to the pin being pulled low. There is no way to bypass this mode on the XBee itself. The best solution is to remove the current limiting resistor or LED on the interface board that is tied to pin 6, which will leave the pin unused. Please refer to the manufacturer’s schematic of the interface board to locate these components.

The older XSC (S3) module should not be affected by this problem because it has a lower value internal pull-up resistor on that pin and can more easily overcome the current draw by the LED.

We have found that with some third-party voltage shift boards have an additional problem. The DIN pin of the XBee also acts as a config line. If this pin is pulled low upon startup, it will enter a “command mode” and all data sent to the XBee from the UART will be interpreted as a command. If you wait for 10 seconds, it will exit command mode and the XBee will return to normal operation.
Some of these regulator boards pull the DIN pin low and will cause a long delay in startup before the radio can be used. A simple fix is to use a 10k ohm resistor between DIN (pin 3) and VCC (3.3V), this will drive the pin high and can prevent this delay.

If you can see the COM ports in X-CTU (http://digi.com/xctu) then you should be able to talk to the radios. Other than the known issues on 3rd party boards (http://www.digi.com/support/kbase/kbaseresultdetl?id=3325) it is usually a straight forward approach. If you are using things like a Parallax board can I assume that you are at least moderately skilled in electronics? If so I would suggest removing the Digi radio and jumpering Din and Dout where the radio was. Then go to the terminal tab of X-CTU and type a character or two. Did it echo, blue and red? If so then you know that from PC to Interface board up to the point where the data touches the Xbee is working—If not you know where to start looking. This method also ignores things like baud rate mismatches which could be at issue. (The default baud rate is 9600 baud.)
I believe parallax is using FTDI drivers. If so you may need to drop the frame size down. Digi has found issues with recent drivers and found that the smaller frame size works best. (http://www.digi.com/support/kbase/kbaseresultdetl?id=3418)
If everything seems to check out on the interface board you might try reprogramming the module: http://www.digi.com/support/kbase/kbaseresultdetl?id=3402
If you still have issues I’d call Digi Support at 801-765-9885 Option 3 which will take you right to the RF team bypassing that huge Digi phone tree system.

http://www.karlssonrobotics.com/tutorials/zigbee/setting-up-your-xbee-pro-900hp/

Follow this …

I use FT232RL XBee Explorer USB adapter not Parallax or Sparkfun, and have the same problem. If i remove the led from the board, can i solve this problem too?