XBEE09P not working ?

Wireless & IoT
1

Hi, all.

I have 2 XBEE09P modules, an FTDI 5V cable assembly, and the Sparkfun 3v3 regulated adaptor.

Problem is that the only response I can get using X-CTU is when I ‘Test / Query’ the modem - it responds that 'comms with modem OK, modem type = name unknown, then a long ID number (same for both XBEEs, and then 'modem firmware version = ’ and the rest is blank …

I can’t get any other response from any other feature of X-CTU.

Is it possible that I have just bought two ‘dead-in-the-box’ modules ? or is there something simple I am getting wrong ?

Any help will be greatly appreciated.

Charlie

2

Most likely the XBees are not dead.

The response from the Test/Query is not correct and is an indication the the communications parameters are not correct. Nothing else in X-CTU will work until the Test/Query response is correct. The response should have a readable Name for modem type and the firmware version is a 4digit hex number.

Set:

Flow Control = NONE

Data Bits = 8

Parity = NONE

Stop Bits = 1

and ensure that you have the correct Comm port selected.

Then try each Baud rate that is selectable with the API box unchecked.

If still not getting a good response then check the API box and try each Baud rate again.

3

CharlieD:

Hi, all.

I have 2 XBEE09P modules, an FTDI 5V cable assembly, and the Sparkfun 3v3 regulated adaptor.

Problem is that the only response I can get using X-CTU is when I ‘Test / Query’ the modem - it responds that 'comms with modem OK, modem type = name unknown, then a long ID number (same for both XBEEs, and then 'modem firmware version = ’ and the rest is blank …

I can’t get any other response from any other feature of X-CTU.

Is it possible that I have just bought two ‘dead-in-the-box’ modules ? or is there something simple I am getting wrong ?

Any help will be greatly appreciated.

Charlie

When I've seen that with XBee 2.4GHz Series 1, it means that the modem response is garbled due to a baud rate mismatch, serial data voltage levels wrong/inverted data, or some such. I can't say what most often cures it. But in the 50 or so XBees I've worked with, only had one true hardware failure.
4

Thanks for the replies

I got as far as I did by trying all the baud rates, with the API both un-checked and checked. The 9600,n,8,1,n parameters are as you suggest, the com port is correct - it is the one I use with the Arduino IDE - the only other thing to change is the FTDI cable - I only have one - so later I will jig a loop-back test on it’s own.

Cheers,

Charlie

edit : I will also try two stop bits to see what that does :slight_smile:

5

If the XBee’s default baud rate has become other than 9600, you’ll see this.

There are odd-ball reset sequences to recover a hosed up XBee.

One is to have the RESET input true before powering up the XBee and using XCTU.

6

Nice one Steve - would never have thought of that. I will try the reset procedure as soon as I get back home on Tuesday.

Charlie

7

Okay, here’s some feedback …

The first picture shows the signal levels on the Dout pin of the Xbee Regulated breakout board, a ‘+’ character as transmitted by the FTDI cable - all good so far …

The second picture is of the same signal, but WITH the XBEE blugged in – NOT GOOD !

It appears as though the XBEE is pulling the Dout line up harder than the FTDI can pull it down … Strange, no ?

For both the 'scope pictures, the Vert Sensitivity is 2V/div, the time-base is .2mSec per div, the ZERO Volt line is one division from the bottom of the screen.

Any and all comments welcomed

Charlie

P.S. sorry for the crappy picture quality - I will get a better 'phone one day :wink:

8

The XBee’s DOUT line is the data from the XBee, output pin, to the Explorer board and is being DRIVEN by the XBee.

The XBee’s DIN line is the data into the XBee’s input pin.

Are you sure you have the connections correct?

9

Well - that is interesting…

The FTDI cable is as it came - connection wise, and the Sparkfun Regulated breakout board is supposed to be a straight plug-in (pin-to-pin compatible) - maybe mine came with the txd and rxd wires swapped.

On the FTDI, TXD (from the P.C.) is the orange wire, between Rxd and Vcc, whereas on the Sparkfunny breakout board, that pin is labled Dout, goes to the Dout LED, and pin 2 of the Xbee module - so, time to swap the FTDI cable’s socket pins arround …

Will report back later.

Thanks

Ok, so later is now …

I have changed the wiring on the FTDI socket - not that easy, but done - now when I ‘test/queery modem’ in Xctu, the Din LED flashes - which does make sense, opposed to the Dout led before…

BUT … for all the combinations of Baud rate, API enable, and most of the Stop bit combinations I could try - I STILL get NOTHING in response to the ‘test/queery modem’ - I also tried this with my second XBEE - same result.

C

10

Did the signals look better on the scope?

11

Yes, the Din now has a full 5v to 0v swing, but Dout stays pegged at 3v3.

I tried the ‘power on with reset tied low’ suggestion to reset the Xbee to factory defaults as suggested earlier - no change.

It appears as though a faulty FTDI cable has helped me fry two Xbee modules :slight_smile:

Charlie

12

Further to this thread ----

The FTDI Cable, as shipped and backed-up by the Sparkfun “FTDI cable 5V” circuit diagram has the following pin-outs

GND Black

CTS Brown

VCC red

TxD Orange

RxD Yellow

RTS green

so Txd, orange wire is the line carrying data from the PC to whatever … good so far

The “XBee Regulated -v10” shematic, also from the Sparkfun website, has the following pin-outs

GND

CTS

VCC

Txo

RXi

DTR

This implies that the Txo line is the data transmitted by the Xbee, BUT that is the FTDI cable’s transmit line

This is maybe why I now have two dead Xbee modules, although, surely, the TXD line of the XBEE should be able to survuve the input from the FTDI cable’s driver ?

Surely I can’t be the only or first person to have this ???

Charlie