Home/Support/Support Forum/Module stops responding to Remote AT commands on Application Service UDP port
New and improved user forum site going live on 12/6 (All users will need to reset their password when the new forum is active)

Module stops responding to Remote AT commands on Application Service UDP port

0 votes
I've noticed some strange behavior with my Xbee Wifi module when using the Xbee Application Service (XAS) on UDP port 0xBEE. If several UDP packets are sent in a short period, the module stops responding to the remote AT commands. However, the modem is still associated with the access point and functioning. Even stranger is that the data ends up going out the UART port but the module responds with a UDP acknowledgement for the received packet.

Here is my current case:
The module is configured to transmit the I/O samples on five second intervals (IR is set to 0x1388). The destination IP (DL) is (limited broadcast). I have one computer on the network listening for broadcasts from the Xbee.

A second computer has a small program to assemble and transmit the remote AT command packets using the documented format.

The I/O samples are arriving as expected on 0xBEE via the limited broadcast IP. The packets are as expected with all the right number of bytes and sample data in place.

Assuming I've just started up the Xbee everything seems fine as the I/O samples come through. I can then have the second computer send two ATIO commands with this format with a two second delay between the packets:

0x42 0x42 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x02 0x49 0x4F 0x10 0x00

0x42 0x42 0x00 0x00 0x00 0x00 0x00 0x02 0x01 0x02 0x49 0x4F 0x10 0x00

This is supposed to turn DIO12 on then off. The command works fine and I receive both the UDP acknowlegement and the AT command response since bit 1 of byte 7 is set (the first 0x02 above) and the command is applied immediately (the second 0x02). For the above two packets the responses are typically:

0x9b 0x91 0xd9 0xd3 0x00 0x00 0x80 0x00
0x42 0x42 0x00 0x00 0x00 0x00 0x82 0x02 0x01 0x49 0x4F 0x00

That works and the DIO12 output toggles as expected. The problem happens if I send the command several times in a short span. For example, if I send the commands (with two second delays between them) four or five times in a row the modem stops responding to the commands. Instead I get the UDP acknowledgement (the first of the two response packets ending with 0x80 0x00) but no response to the AT command. If I observe the modem UART using X-CTU, I see my AT command payload appearing at the UART output.

Meanwhile, the interval timer continues to run and send I/O reports every five seconds to the broadcast IP. So it's obvious that the CPU isn't locked up, the network connection is still functioning but somehow all the Remote AT commands coming in the through the XAS port (0xBEE) go out the UART. The only way to correct the problem is to power cycle the Xbee. Then the problem clears up for a while. However, it is very repeatable. I just have to send the remote AT commands a few times in succession at a very mild rate (one command every 3-5 seconds) and the modem will start ignoring the packets and send them out the UART (it's behaving like the transparent serial mode but on the wrong network port).

Just to double check, both the C0 and DE registers are set to 0x2616 so there's no port conflict with the Serial Communication Service. In fact I'm not even using the SCS, only the XAS.

Everything else seems to be fine with the device. Signal strength is very good, the device does respond properly when the above issue hasn't occurred yet, and all signals are read or written according to the various commands. But eventually the device does get stuck and all my data goes out the UART instead of commanding the modem.
asked Dec 20, 2013 in IEEE 802.11 (Wi-Fi) by radioforall New to the Community (0 points)
reshown Dec 20, 2013 by mcarver

Please log in or register to answer this question.