XBee DigiMesh странный бит в кадре и неправильная контрольная сумма

Я использую XBee DigiMesh 2.4 API-2 и Raspberry Pi. Я транслирую кадр с одного узла на другой.

Кадр для передачи:
7e 0 12 10 1 0 0 0 0 0 0 ff ff ff fe 0 0 41 6c 65 78 69

Кадр получен в другом узле:
7e 0 10 90 0 7d 33 a2 0 40 91 57 26 ff fe c2 41 6c 65 78 1e

Байт, который беспокоит меня, это c2. Должно быть 02. Почему это так выглядит?
Более того, контрольная сумма не верна (я читал, как контрольная сумма должна рассчитываться в режиме API 2).

С байтом 0x02 это должно быть 0xe3 или с байтом c2 это должно быть 0x23. Я пытался получить результат 0x1e разными способами, но я так и не получил это значение.

Когда я транслирую пакет в противоположном направлении (от второго узла к первому), возникают те же проблемы.

Оба XBee сконфигурированы со скоростью 9600 бод, без чётности. Raspberry Pi UART также.


—— Редактировать: Я нашел ответ относительно байта C2. С2 — это битовое поле. С2 = 1100 0010.
Биты 7 и 6 равны 11, это означает, что это Digimesh. Бит 1 установлен так, что это широковещательный пакет.
https://dl.dropboxusercontent.com/u/318853/XBee%20900.PNG

Все еще ищу причину этой контрольной суммы.

0

Решение

Вы можете упростить свой код, используя режим API 1 и избавляя от необходимости экранировать и удалять значения по мере их отправки и получения. Это действительно не так сложно, чтобы ваш код разбирался в кадрах и игнорировал 0x7E в середине кадра: если вы видите 0x7E сопровождаемый неправильной длиной, продолжайте искать. Если у вашего кадра неверная контрольная сумма, пропустите 0x7E и искать следующий.

Если вам абсолютно необходимо использовать экранирование, убедитесь, что значение длины и контрольная сумма в вашем кадре не содержат экранирующие байты и что вы правильно экранируете необходимые байты при их отправке.

На приемном конце откройте байты и вычислите контрольную сумму.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]