Possible XIG parsing issue

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Multiple Xbee's connected to XIG
2. Startup includes time\r 
3. next command is a GET request \r

What is the expected output? What do you see instead?

RECV: 7 bytes from ('[00:00:00:00:00:00:00:00]!', 0, 49413, 139, 0, 0) 
('\x8b\x9bQ\xf8\x00\x00\x00')
RECV: 4 bytes from ('[00:13:a2:00:40:66:44:4e]!', 232, 49413, 17, 0, 0) 
('tim\xc3')
RECV: 36 bytes from ('[00:13:a2:00:40:66:44:4e]!', 232, 49413, 17, 0, 0) 
('\rhttp://xxxxxxxx\r')

The system sends a 'time\r' to XIG.  The command is being received as a 
'tim\xc3'  - the \r is being added to the next command, which is also truncated 
with \r

What version of the product are you using?

XIG 1.4.1

Please provide any additional information below.

The system can be running fine for hours, and then exhibit this 'tim\xc3' 
behaviour.  It will be doing this for awhile, and then start working normally 
(receiving time\r)

Original issue reported on code.google.com by rhaist...@gmail.com on 29 Feb 2012 at 1:12

[GoogleCodeExporter]

It would be very strange for this to be a parsing issue on the gateway or the 
XIG. The trace is showing what's being received by the gateway before it gets 
submitted into the XIG parse routines.  The gateway _is_ receiving a hex 0xc3 
byte from the remote XBee.  Is it possible your remote microprocessor could be 
originating this data?

Original comment by Jordan.H...@gmail.com on 1 Mar 2012 at 11:56

[GoogleCodeExporter]

I have been trying to track down this specific bug for a few weeks now.  As you 
can see from the http request, it is starting with '\r'   It appears that the 
\r is somehow ending up in the wrong XIG request.  The remote xbee is sending 
time\r  and then after it gets a response, it sends a http: GET request.   For 
some reason the devices eventually start sending tim\xc3  with the \r starting 
the GET request.  Haven't been able to track down why this has been happening.

One of our test systems is a single XIG / Xbee combination.  That system never 
exhibits the tim\xc3 issue.  This only shows up on our other system that has 
multiple Xbee's transmitting through XIG.

Original comment by rhaist...@gmail.com on 2 Mar 2012 at 1:25

[GoogleCodeExporter]

I increased the delay between transmissions, and this problem has gone away.

Original comment by rhaist...@gmail.com on 13 Mar 2012 at 3:33

[GoogleCodeExporter]

Original comment by Jordan.H...@gmail.com on 13 Mar 2012 at 3:50

• Changed state: Invalid