pySerial данные, полученные от XBee, не отображаются должным образом

Question

Я пытаюсь получить несколько XBees, работающих как датчики и устройства вывода, чтобы отправить их образцы координатору XBee, подключенному как показано ниже, и включить и выключить все эти удаленные XBees при указании , Эта проблема с моими «полученными данными» похожа на вопрос «Переполнение стека» pySerial and reading binary data, но я не считаю, что это ответ на эту проблему и ее разрешение.

Итак, какие шаги воспроизведут проблему?

1. Использование питон-XBee (версия 2.1.0 или 2.0.0), pySerial последняя версия 2.6.0, Python 2.7.3 на Raspberry Pi работает Debian Wheezy (7.0).

2. Выполнить скрипт ниже

3. Все XBees являются XB24-Z7-WIT-004 Series 2. Координатор находится в режиме API2. Я попробовал свои двух- датчика XBee в обеих AT и API1 или API2 режимах без разницы (заметки о версии встроенного программного обеспечения отражается в качестве комментариев в прилагаемом .py скрипта)

Что такое ожидаемый результат? Что я вижу вместо этого?

Я ожидаю, что адрес, полученный в результате сценария, или в качестве выхода из Minicom быть правильным «source_addr_long», а именно: x13 \ xa2 \ x00 \ x40 \ x79 \ XE6 \ x5f, но вместо этого я получаю \ x00 \ x13 \ xa2 \ x00 @ у \ XE6. 'Source_addr' возвращает \ xe3 +. («Источник адр» связанные вещи обрабатываются/сделано библиотеками python_XBee.) Вот мой сценарий:

#!/usr/bin/env python2.7 

# NOTE - Not my own code - Abrie Willemse 
# NOTE - I am not a programmer - Abrie Willemse 

# I am using XBee XB24-Z7 WIT-004 for all devices 
# Coordinator is running API 
# SENSOR_1 and SENSOR_2 are Sensor Routers running AT (firmware XB24ZB 22A7) (I have tried API firmware XB24ZB 23A7) too) 

import serial 
from xbee import ZigBee 
import time, sys, datetime 

serial_port = serial.Serial('/dev/ttyAMA0', 9600) 

zb = ZigBee(serial_port) 


while True: 
    try: 
     data = zb.wait_read_frame() #Get data for later use 
     print data # To check what comes in before processing/parsing (already buggered up) 
     addr = repr(data ['source_addr_long']) # Working sort of, but with @y... issue in results 
     file = open('/media/log/senslog.txt','a') 
     value = float(((data['samples'])[0])['adc-0']) 
     num = (value * 3.0)/1023.0 
     file.write(datetime.datetime.now().strftime('%d-%m-%Y %H:%M:%S') + ' ' + str(addr) + ' ' + str(value) + ' ' + str(num) + '\n') 
     print str(datetime.datetime.now().strftime('%d-%m-%Y %H:%M:%S') + ' ' + str(addr) + ' ' + str(value) + ' ' + str(num) + '\n') 
     file.close() 

    except KeyboardInterrupt: 
     break 

serial_port.close() 

Это выход:

{'source_addr_long': '\x00\x13\xa2\x00@y\xe6_', 'source_addr': '\xe3+', 'id': 'rx_io_data_long_addr', 'samples': [{'adc-0': 516, 'adc-3': 519, 'dio-6': False}], 'options': '\x01'} 
18-06-2013 14:32:15 '\x00\x13\xa2\x00@y\xe6_' 516.0 1.51319648094 

Обратите внимание на проблему, начиная с @y выше в выводе. Обратите внимание на правильные данные, полученные при подключении в тот же координатор на ПК Windows (это весь пакет получил от удаленного XBee):

Какие версии я использую? В какой операционной системе?

Использование python-xbee (версия 2.1.0 или 2.0.0), новейшая версия PySerial 2.6.0, Python 2.7.3 на Raspberry Pi Model B, работающая с Debian Wheezy (7.0) (обновленная до последней версии в последнее время , в попытке решить этот вопрос

Примечание:.

при использовании программного обеспечения ZigBee оператора (на базе Windows, через старомодный COM порт), адрес и целые сообщения отправляются и принимаются правильно Наконец, вполне возможно, что нет ничего плохого в pySerial, я могу просто подкачать его в коде, хотя это не объясняет, почему Miniterm уже показывает это неправильно. Кроме того, все параметры последовательного порта были проверены, XBee тщательно развязан или отфильтрован между Vcc и штырьками заземления и т. Д.

ОБНОВЛЕНИЕ, после дальнейшего изучения, казалось бы, что проблема может быть связана с библиотекой pySerial, а не с библиотеками python-XBee. Я основываю, что на следующий (имеется в виду ожидаемых результатов, перечисленных в предыдущей части моего поста, а также фактические результаты, также перечислены выше:

x40 = ascii @ and 
x79 = ascii y and 
xe6 = seems undefined in [ASCII][7], therefore seems to be coming through OK as xe6 and then finally, 
x5f = ascii underscore (_) 

Поэтому моя теория состоит в том, что по какой-то причине, pySerial перестает обрабатывать поток/строку (или какой бы то ни было правильный технический термин) после последнего x00 в \ x00 \ x13 \ x2A \ x00, а затем начать добавлять символы ASCII эквивалентными шестнадцатеричным символам/значениям. Использование терминальной программы, которая полагаясь на библиотеку pySerial (Miniterm), на Raspberry Pi, I , уже, получают данные неправильно. Это до моего сценария. (См. комментарий к этому сообщению в результате последующего обнаружения.)

Для меня важно правильно получить «аппаратный адрес», так как МОЙ адрес в XBee может динамически меняться (я думаю, координатор назначает его на лету). Это было бы проблемой при отправке определенных команд в определенный модуль XBee, что, очевидно, имело бы очень специфический результат. Как я могу исправить эту проблему?

Answer 1

По-настоящему @является\x40. И yis\x79. Таким образом, «ценность» правильна ...

>>> '\x13\xa2\x00\x40\x79\xe6\x5f' == '\x13\xa2\x00@y\xe6_' 
True 

Если это только вопрос форматирования, вы могли бы использовать что-то подобное, чтобы довольно отображать адреса:

>>> value = '\x13\xa2\x00@y\xe6_' 

>>> pretty_value = ':'.join("{:02X}".format(ord(c)) for c in value) 
>>> print(pretty_value) 
13:A2:00:40:79:E6:5F 

---

На с другой стороны, мне кажется, что вы с помощью одного байта при обращении к адресу:

Expected:   \x13\xa2\x00\x40\x79\xe6\x5f 
Actual value: \x00\x13\xa2\x00\x40\x79\xe6 

одной из возможных причин является то, что вам пропустил тот факт, что в режиме API 2 некоторые символы могут быть экранированы. Таким образом, изменение фактического смещения различных полей в кадре данных. Поскольку вы используете библиотеку, уверены ли вы, что она правильно обрабатывает режим API 2? Правильно ли он настроен?

---

Что касается вашего кадра:

 
7E 00 16 92 00 13 A2 00 40 79 E6 5F 
DF 13 01 01 00 40 09 00 40 02 04 02 
07 2E 

Просто декодирования первых полей полей заголовка:

• Это 0x92 "IO Sample Rx" кадр 16 байт длиной.
• адрес источника 64 бит 00: 13: A2: 00: 40: 79: Е6: 5F
• адрес источника 16 бита является ДФ: 13
• Упакованными было признано (0x01)