API Frame 0x82 not supported (64-bit addressing I/O sample)

[GoogleCodeExporter]

This frame is not supported when it should be.

How to reproduce:
1. Set up an XBee device to send I/O samples periodically
2. Use 64-bit addressing
3. A KeyError exception 'Unrecognized response packet with id byte \x82' is 
raised.

Expected behavior:
An exception should not be raised, and the I/O samples within it should be 
properly parsed.

Original issue reported on code.google.com by pmalms...@gmail.com on 6 Jul 2010 at 10:17

[GoogleCodeExporter]

This has been fixed as of version 1.7.1 (SVN revision 11).

Original comment by pmalms...@gmail.com on 7 Jul 2010 at 7:26

• Changed state: Fixed

[GoogleCodeExporter]

thanks for the prompt fix, Paul,

below is a frame printed from a print statement i put in base.py to view the 
unpacking. it does echo the same as in the x-ctu terminal. the correct 64-bit 
address is in the frame & the len is correct, 0x26. [00 13 A2 00 40 2C 4F A8]

7E 00 26 82 00 13 A2 00 40 2C 4F A8 32 00 06 22 00 00 C2 00 97 00 21 00 2F 00 
45 00 37 00 D1 00 99 00 85 00 7B 00 18 00 28 3C

however, the source_addr_long': '\x00\x13\xa2\x00@,O\xa8' is missing 3 bytes in 
its printout

{'source_addr_long': '\x00\x13\xa2\x00@,O\xa8', 'rssi': '2', 'id': 
'rx_io_data_long_addr', 'samples': [{'adc-0': 194, 'adc-4': 151}, {'adc-0': 33, 
'adc-4': 47}, {'adc-0': 69, 'adc-4': 55}, {'adc-0': 209, 'adc-4': 153}, 
{'adc-0': 133, 'adc-4': 123}, {'adc-0': 24, 'adc-4': 40}], 'options': '\x00'}

i see in the struct, "source_addr_longit", is listed for a size of '8', though 
upon returning the packet, it appears to get truncated or something. the "@" 
char in the 4th byte of the "source_addr_longit", is that supposed to be there?

just something i noticed and this may be by design as i'm quite new to python. 

Bill

Original comment by G2subsPstLC@gmail.com on 8 Jul 2010 at 7:53

[GoogleCodeExporter]

That looks correct to me. If you take a close look at the 'source_addr_long' 
string, you will see 4 raw bytes '\x00\x13\xa2\x00', followed by the @ sign, a 
comma, and a capital O. Finally, there is the last raw byte '\xa8', for a total 
of 8.

When representing string of binary characters, you will tend to see random real 
characters, such as these, pop up whenever a byte happens to be of equivalent 
value to a non-whitespace ASCII character.

For example, in the interpreter:

    >>> '\x61'
    'a'
    >>> '\x00'
    '\x00'
    >>> '\x40'
    '@'

Also, to verify that I'm sane:
    >>> print len('\x00\x13\xa2\x00@,O\xa8')
    8

Original comment by pmalms...@gmail.com on 9 Jul 2010 at 2:38

[GoogleCodeExporter]

thanks for pointing that out. indeed that is correct. i [see] it now & i didn't 
investigate far enough. 

you are still sane, and i'm still on the edge. ;-)

thanks
Bill

Original comment by G2subsPstLC@gmail.com on 9 Jul 2010 at 6:49