XBee отбрасывает пакеты и фактическая скорость передачи данных ниже ожидаемой

Я постоянно передаю со скоростью 9600 бит/с, используя настройки по умолчанию для обоих моих XBees XB24-B. Связь только в одну сторону, передатчик подключен к ATMega328 UART, а приемник подключен к ПК через USB (FTDI). Вот фактическая скорость передачи данных для данной программы:

  • Проводное соединение (без XBee): 7694 бит/с
  • от маршрутизатора/конечного устройства ZNET 2.5 AT к координатору ZNET 2.5 AT: 6800 бит/с (некоторые потерянные пакеты)
  • от ZNET 2.5 Coordinator AT до ZNET 2.5 Router/End Device AT: 0356 бит/с (много потерянных пакетов)
  • от Zigbee Router/End Device AT к Zigbee Coordinator AT: 0000 бит/с (не работает)
  • от Zigbee Coordinator AT до Zigbee Router/End Device AT: 0328 бит/с (много потерянных пакетов)

Почему это? Могу ли я что-нибудь сделать, чтобы улучшить эти показатели?

Изменить . Для более высоких скоростей передачи (115200) я получаю еще худшие скорости отбрасывания пакетов:

  • Проводное соединение (без XBee): 94200 бит/с
  • с использованием XBee XB24-B ZNet 2.5: 27900 бит/с

Изменить . Если я сделаю адрес координатора конечным устройством, то скорость отбрасывания пакетов упадет до нормального уровня (6800 бит/с), что не идеально, но лучше, чем в предыдущем сценарии.

Кросспостинг на форуме Arduino и форуме SparkFun
но я все равно туда запостил

Ответы (3)

Вы можете [свести к нулю отброшенные пакеты][1], назначив правильный адрес назначения перед началом передачи.

Сообщается, что связанная страница является сайтом атаки вредоносного ПО.
Да, к сожалению, оригинального сайта больше нет.

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

Необработанная скорость передачи данных Zigbee составляет всего 250 кбит/с в диапазоне 2,4 ГГц, и это протокол с очень высокими накладными расходами. При почти идеальном уровне сигнала и включенном шифровании вы должны ожидать максимальную пропускную способность только ~ 20-25 кбит / с без настройки стека, немного больше без шифрования. Протокол Zigbee на самом деле поддерживает только отправку данных, которые помещаются в один пакет, размер которого, как мне кажется, составляет около 100 байт. Если вы отправляете поток данных, прикладной уровень должен разбить эти данные на пакеты и включить дополнительную информацию в пространство данных пакета, чтобы его можно было собрать. Этот процесс может быть довольно медленным и еще больше сократить пропускную способность данных.

Стек Digimesh немного быстрее, поскольку он сокращает накладные расходы и позволяет использовать пакеты большего размера.

Не знаю, какое конечное приложение вы здесь планируете использовать, но Zigbee вовсе не предназначен для потоковой передачи данных. Это для отправки небольших битов информации, показаний датчиков, инструкций и т. д., которые помещаются в один пакет. Возможно, вы только что выбрали неправильный протокол для своего приложения.

Я транслирую аудио. Есть ли более подходящий протокол, использующий то же оборудование? Какой протокол вы рекомендуете? Bluetooth?
Если это еще не цифровое аудио, используйте FM. Если вы можете найти готовый трансивер с нужной пропускной способностью, то это легко.
@Jader: Как вы собираетесь передавать аудио со скоростью 9600 бит/с? 1,2 Кбит/с — это слишком медленно. Если вы по какой-то причине хотите остаться в цифровой сфере, Bluetooth имеет интерфейсы PCM, предназначенные для потоковой передачи звука.
@Nick Я не буду транслировать аудио с такими скоростями, я просто пытался решить одну проблему за раз. Моя забота сейчас состоит в том, чтобы оптимизировать XBee. Я посмотрю на Bluetooth, спасибо!
вы абсолютно никогда не должны использовать zigbee для потоковой передачи звука или чего-либо, что имеет решающее значение по времени или пропускной способности.

ОБНОВЛЕНИЕ: В связи с недавним подтверждением того, что Zigbee не предназначен для потоковой передачи данных, я бы предложил выбросить его в мусорное ведро и купить лучший трансивер с большей функциональностью, большей пропускной способностью и примерно в 1/4 раза дешевле .

Я настоятельно рекомендую использовать управление потоком, если это возможно, для устранения потерянных пакетов. Скорее всего, небольшие, но значительные периоды времени, когда одно устройство обрабатывает, не смотрит на свои выводы UART и, таким образом, пропускает биты/байты и может зависнуть. Внедряя аппаратное управление потоком (выводы RTS и CTS), каждое устройство может сообщать другому, когда оно готово или нет для получения дополнительных данных.

Как только вы подключите управление потоком, я думаю, вы достигнете более высокой пропускной способности, которую ищете =)

Я работаю с устройствами Bluetooth OBD, которые связывают мое приложение Android с автомобильными сетями, поэтому я немного работаю с беспроводной связью/Bluetooth.

У моего MCU нет встроенного управления потоком, поэтому мне придется его реализовать.
управление потоком не решит проблем с пропускной способностью на zigbee, оно никогда не предназначалось для потоковой передачи данных.
Обновил мой ответ. Я использую устройство, с которым я связался, и с ним легко работать.
Вы понимаете, что bluetooth и zigbee — это очень разные протоколы? Если вам нужен zigbee bluetooth, это не поможет. Одно устройство к другому по блютусу, идеально. Для набора рабов и хозяина, да. Для ячеистой сети с большим количеством узлов блютуз не подойдет.
XBee отбрасывает пакеты и фактическая скорость передачи данных ниже ожидаемой
СпросиСетьПолитика конфиденциальности1y, 0v