Я использую 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
Все еще ищу причину этой контрольной суммы.
Вы можете упростить свой код, используя режим API 1 и избавляя от необходимости экранировать и удалять значения по мере их отправки и получения. Это действительно не так сложно, чтобы ваш код разбирался в кадрах и игнорировал 0x7E
в середине кадра: если вы видите 0x7E
сопровождаемый неправильной длиной, продолжайте искать. Если у вашего кадра неверная контрольная сумма, пропустите 0x7E
и искать следующий.
Если вам абсолютно необходимо использовать экранирование, убедитесь, что значение длины и контрольная сумма в вашем кадре не содержат экранирующие байты и что вы правильно экранируете необходимые байты при их отправке.
На приемном конце откройте байты и вычислите контрольную сумму.
Других решений пока нет …