Background thread crashes occasionally on faulty frame data

[GoogleCodeExporter]

Hiho,

with an Arduino (or actually a Sense/Stage MiniBee [1]) attached to an XBee
sending data out, I occasionally get this error when it parses a faulty frame.
After this, the thread stops working alltogether, so it would be nice if it
were so robust to continue after this error.

sincerely,
Marije

Exception in thread Thread-3:
Traceback (most recent call last):
 File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
   self.run()
 File "/usr/local/lib/python2.6/dist-packages/xbee/base.py", line 94, in run
   self._callback(self.wait_read_frame())
 File "/usr/local/lib/python2.6/dist-packages/xbee/base.py", line 387, in
wait_read_frame
   frame = self._wait_for_frame()
 File "/usr/local/lib/python2.6/dist-packages/xbee/base.py", line 132, in
_wait_for_frame
   frame.fill(newbyte)
 File "/usr/local/lib/python2.6/dist-packages/xbee/frame.py", line 133, in
fill
   byte = chr(ord(byte) ^ 0x20)
TypeError: ord() expected a character, but string of length 0 found

Original issue reported on code.google.com by pmalms...@gmail.com on 28 Oct 2011 at 2:02

[GoogleCodeExporter]

Marije provided the following patch:

diff --git a/XBee-2.0.0/xbee/base.py b/XBee-2.0.0/xbee/base.py
index 38327f0..b4a8734 100644
--- a/XBee-2.0.0/xbee/base.py
+++ b/XBee-2.0.0/xbee/base.py
@@ -126,10 +126,12 @@ class XBeeBase(threading.Thread):
                    continue

                # Save all following bytes
-                frame.fill(byte)
+                if len(byte) > 0:
+                 frame.fill(byte)
                while(frame.remaining_bytes() > 0):
                   newbyte = self.serial.read()
-                    frame.fill(newbyte)
+                   if len(newbyte) > 0:
+                     frame.fill(newbyte)
                    if self.verbose:
                     print "%x"%ord(newbyte)

Original comment by pmalms...@gmail.com on 28 Oct 2011 at 2:03

[GoogleCodeExporter]

This has been resolved as of revision a74b455d4aa0 and revision 8ee2a776d4e4.

Original comment by pmalms...@gmail.com on 20 Dec 2011 at 12:17

• Changed state: Fixed