AT command mode entry one-time-only

I’m finding that sending AT commands only works “one-time-only.” When the XBee is powered up I can send commands with the sequence “+++” followed by a delays ranging from 0 to 1.5 seconds (the delay doesn’t seem to matter), and a command, e.g. “ATSL,” and get a response. Type in another command and repeat the sequence (including the time delay) and get a response.

If no commands are sent for 10 seconds (which is the default time out duration), or a “ATCN” command is sent, I can no longer get any response to the commands. It behaves as if the AT command mode can only be entered once after a power up. This is contrary to the documentation. My understanding is that the “+++” sequence/timing should always take the unit out of idle and into AT command mode.

Also, the documentation is quite clear about guard time after the “+++”, yet I find that doesn’t (always !) matter. The behavior isn’t making sense.

Another surprise is that after power up a sequence of "+++ " returns a “OK” and it won’t respond to further commands. If a command is entered the first response is “OK” and when the next command is entered the response is for the previous command.

My hardware setup is a XBee series 1 connected to USART2 on a STM32 board. The PC sends commands to USART1 on the board and the program takes care of sending the “+++”, time delay, and sending responses from USART2 back to the PC.

I’m using the following documentation–
XBee/XBee‐PROTM OEM RF Modules ‐ 802.15.4 ‐ v1.xAx [2007.05.031]

page 24 specifies the following–

To Enter AT Command Mode:
Send the 3-character command sequence “+++” and observe guard times before and after the
command characters. [Refer to the “Default AT Command Mode Sequence” below.]
Default AT Command Mode Sequence (for transition to Command Mode):
No characters sent for one second [GT (Guard Times) parameter = 0x3E8]
• Input three plus characters (“+++”) within one second [CC (Command Sequence Character)
parameter = 0x2B.]
• No characters sent for one second [GT (Guard Times) parameter = 0x3E8]
All of the parameter values in the sequence can be modified to reflect user preferences.

I would assume what was intended was that “No characters sent for greater than one second…”, which would also mean that a valid AT command would have to be sent in less than 10 seconds, followed by more than one second. Net–it doesn’t make sense to specify one second without some thing that indicates the the max and min values of a real system.

Can you point me to some documentation or posts that go beyond this that might help explain the AT command behavior?

USART2: XBee 802.15.4 BETA V 10EC, Build: Feb 22 2011 17:05:54
USART2: Hardware Version: W45
USART2: Software Compatibility: 01
USART2: MAC FFDNB V1061 Build: Jul 23 2007 14:47:59
USART2: PHY XBEE4 V1061 Build: Feb 22 2011 16:41:52
USART1: ATHV [At this point the unit no longer responds until XBee power cycled]

Experimenting I found what appears to work (it would be nice to find documentation that confirms this). With the following sequence (to enter the AT command mode and send a command) the unit behaves as I would expect–

Send: “+++”
Delay: more than 503 ms, less than 10.100 seconds
Send: command, e.g. ATSH,SL
Delay: more than 503 ms.

The guard band delay setting was the original setting (1000 ms) for the above. The findings from the experiments on the timing suggests that the delay must be greater than 1/2 the guard band time plus 1 ms each for each of end of the RS-232 link, plus some tolerance due to oscillator differences, i.e. about 3 ms. Similarly, the maximum time would be governed by the timeout that returns the XBee back to idle state, which the original setting was 10 seconds, in 0.1 sec increments.

The key is the sending the just after the AT command. Without that the XBee ends up in a state where the sequence will not enter the command mode.