how to change Xbee baud using Axon

[Admin]

Anyone have proven code to send a serial command to change the baud rate of an Xbee?

Reading the manual and browsing the web, I gathered this below code is what I should do . . . but no luck. I'm sure its something simple I'm not doing right . . .

Code: [Select]

rprintf("+++++++++++++++++++++++");
delay_ms(3100);
rprintf("ATBD7,WR,CN");
(I know it doesn't work as I can still send data at the default 9600bps without data corruption)

[madsci1016]

You only need three +'s.

Not through an Axon, but I just tried your command. Got the OK response, and had to guess what baud rate it was talking at afterwards to get it to come back.

I also only delayed for less then a second, not 3, but shouldn't make a difference as the time out is 10 seconds before it closes the settings time window.

[Admin]

hmmmm not sure what I'm doing wrong . . .

I tried it with hyperterminal, still no luck.

I am however able to change it using the X-CTU software.

[madsci1016]

Are you at least getting an OK after three rapid +'s?

What series are your Xbee's?

[Admin]

Nope, didn't see an OK when using Hyperterminal, although it did stop echoing data it was receiving wirelessly from another Xbee after the +++ command.

Using XBP24, according to the X-CTU software.

[KurtEck]

I don't currently have code on the Axon2 to change the baud rate, I did this earlier with an external program. But I do have my code switch to packet mode at startup.  That code looks like:

Code: [Select]

// Set us into API mode
rprintfInit(WIRELESS_ACTIVATE);
delay_ms(20); // wait 20ms for guard time to enter into command mode
rprintf("+++"); // Now output the string to enter command mode
WaitForXBeeTransmitComplete();
delay_ms(20); // wait 20ms for guard time to enter into command mode

rprintf("ATAP 1\rATCN\r"); // Ok output the enter API mode command and also the exit from command mode
delay_ms(20); // wait 20ms to let the xbee have time to respond...
Note: My external code also switched the guard time to 3 (ATGT 3) so I don't have to wait very long to get into command mode.

A couple of things. You need to have the XBEE not receive anything for the Guard time before the +++ is sent without a CR. And you must wait the guard time after the +++
Then you can issue your commands. You must then either wait for the guard time after your last command for the XBee to time out of API mode or you can issue the ATCN command.

Good Luck
Kurt

EDIT: I forgot to mention, if you wish for the changes to be permanent, issue the ATWR command.

[madsci1016]

You need to have the XBEE not receive anything for the Guard time before the +++ is sent without a CR.

This is Admin's problem then.

data it was receiving wirelessly from another Xbee after the +++ command.

 I figured this was the case with my own observations of not being able to change settings using X-CTU while SAGAR was transmitting to the Xbee I was attempting to program, but never confirmed my suspicions by looking it up.

[Admin]

I forgot to mention, if you wish for the changes to be permanent, issue the ATWR command.

So the XBee baud returns to default upon power reset, unless that command is issued?

If so, thats another reason why it wasn't working . . . I'm reseting very often over here . . . doh!

You need to have the XBEE not receive anything for the Guard time before the +++ is sent without a CR.

This is Admin's problem then.

Too lazy to redo baud rates to verify, but hmmmm doh! (again)

[KurtEck]

I forgot to mention, if you wish for the changes to be permanent, issue the ATWR command.

So the XBee baud returns to default upon power reset, unless that command is issued?

If so, thats another reason why it wasn't working . . . I'm reseting very often over here . . . doh!

Actually this depends.  If the Axon resets, but not the XBEE (ie it still has power), than it still has whatever parameters like new Baud rate and trying to communicate at the default baud rate (9600) will fail...   

That is one reason why I did the majority of my init stuff external to my main program.

Kurt

[Admin]

Wait, looking at my command from earlier, I was already calling the ATWR command

[madsci1016]

Wait, looking at my command from earlier, I was already calling the ATWR command

Then the second 'doh!' was most likely the problem then.