Issue with information received on coordinator XBee

[GoogleCodeExporter]

What steps will reproduce the problem?

1.using python-xbee (ver 2.1.0, or 2.0.0), pyserial latest version 2.6.0, 
Python 2.7.3 on Raspberry Pi running Debian Wheezy 7.0
2.run the script attached as file (XbeeR1.py)
3. All XBees are XB24-Z7-WIT-004 Series 2. The Co-ordinator is in API(1) mode. 
I tried my two sensor XBee's in both AT and API modes with no difference(notes 
on the firmware version is reflected as comments in the attached .py script)

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

I expect the address received as result of the script to be the correct 
'source_addr_long', namely x13\xa2\x00\x40\x79\xe6\x5f, but instead I receive 
\x00\x13\xa2\x00@y\xe6.  The 'source_addr' returns \xe3+.  Also, the Node 
identifier does not come through correctly, yet the sensor samples are correct 
(and consistently so).  The attached file called output.txt is the result of 
the 'print data' line of code from one of the sensors, as received on the 
Raspberry Pi.

None of this makes sense.  The little I understand seems to tell me that I am 
parsing / processing the wrong information, or perhaps from the worn location 
in the data stream.  I worked through the libraries / modules (zigbee.py, etc.) 
but it is pretty foreign to me.

What version of the product are you using? On what operating system?

using python-xbee (ver 2.1.0, or 2.0.0), PySerial latest version 2.6.0, Python 
2.7.3 on Raspberry Pi Model B running Debian Wheezy 7.0 (upgraded to the latest 
version last night, in an attempt to address this matter.

Please provide any additional information below.
I am not a programmer, and therefore admit to being challenged in the code 
space already.  My electronics and IT knowledge is solid, however.  I have been 
battling for more than two weeks on this already.  When I use ZigBee Operator 
software, the addresses are sent and received properly.  Finally, it is quite 
possible that nothing is wrong with your library, I might just be buggering it 
up in code.

Regards,
Abrie

Original issue reported on code.google.com by abrie.wi...@gmail.com on 18 Jun 2013 at 12:39

Attachments:

• xbeeR1.py
• output.txt

[GoogleCodeExporter]

Hi there, following further investigation, it would appear that if anything, 
the problem is possibly related to the Pyserial library, and not with the 
python-XBee libraries.  I base that on the following (referring to the expected 
results listed in my original post, as well as the actual results, also listed 
above:
x40 = ascii @
x79 = ascii y
xe6 = seems undefined in ascii, therefore seems to be coming through OK as xe6
x5f = ascii underscore (_)

Therefore, my theory is that for some reason, pyserial stops treating the 
stream / string (or whatever the correct technical term is) following the last 
x00 in \x00\x13\x2A\x00 and then start adding ascii characters instead. Using a 
terminal program which is reliant on the Pyserial library, on the RasPi, I 
already receive the data wrong.

If you have an appropriate forum to move this non-python-XBee issue to, it 
might help others, once I find a solution to the issue.  Should you have any 
advice for me, I would be grateful.

Regards,

Abrie

Original comment by abrie.wi...@gmail.com on 20 Jun 2013 at 7:38

[GoogleCodeExporter]

I have a similar issue, my source address is printing the character "K" at the 
end, when it should be "\x4B" (the last byte of the address of my coordinator, 
which happens to be the ASCII code for "K"). 

Original comment by alias.ne...@gmail.com on 25 Jun 2013 at 9:28

[GoogleCodeExporter]

My apologies for the delay in getting back to you; somehow I missed this thread 
earlier.

This is a feature of Python; it will print any ASCII bytes it encounters in a 
byte string as its equivalent printed character. You can try this by typing the 
following into a Python 2.X shell:

>>> '\x40'
'@'

A similar result will be printed for Python 3.X.

Also FYI, python-xbee and your XBee device validate their messages to one 
another using a simple checksum, so it is unlikely that your message(s) were 
tampered with during transmission.

Does this answer your question?

Original comment by pmalms...@gmail.com on 25 Jun 2013 at 11:07

[GoogleCodeExporter]

Closing this as WontFix since no code change was required.

Original comment by pmalms...@gmail.com on 21 Sep 2013 at 12:13

• Changed state: WontFix