Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: XBee
Форум разработчиков электроники ELECTRONIX.ru > Аналоговая и цифровая техника, прикладная электроника > Rf & Microwave Design
Djam
Кто нибудь реализовывал проекты с применением XBee- модулей?
at90
Я реализовывал сбор данных на этих модулях. Только использовал модули XbeePro. Модули простые и надёжные.
Djam
Цитата(at90 @ May 14 2007, 03:03) *
Я реализовывал сбор данных на этих модулях. Только использовал модули XbeePro. Модули простые и надёжные.

а в каком режиме работали модули - AT/API, какова была скорость передачи между модулем и ПК? как с надежностью?
я пробовал в режиме API - там почему то очень низкая скорость передачи данных.
at90
я апи не включал. Скорость у меня была 9600. Мне больше ненедо было. Xbee Pro у меня бил на 1500 метров с направленной антенной.

Там есть программа XCTU. В ней можно проверить качество сигнала.
и обмен пакетами.
George!
Сейчас приходиться. И видимо придется API подключать - необходимо знать дошел пакет или нет. Что касается скорости работы с API. То что есть меня пока устраивает, поэтому как проверить максимальную еще не знаю... Но т.к. RS подключение XCTU у меня по умолчанию 9600, то точно не больше smile.gif
Djam
пробовал и с API, и с АТ. Результаты прикреплены в файле. Видимо, в режиме API модули теряют время на определение статуса переданного пакета (доставлен/недоставлен). Может быть этот недостаток будет устранен в XBee 2. В итоге решили использовать режим AP с программным подтверждением приема пакета.

Цитата(at90 @ May 14 2007, 11:51) *
я апи не включал. Скорость у меня была 9600. Мне больше ненедо было. Xbee Pro у меня бил на 1500 метров с направленной антенной.

Там есть программа XCTU. В ней можно проверить качество сигнала.
и обмен пакетами.

На 1500 м - это в помещении? а пакеты не терялись?
George!
Крайне интересна методика эксперемента. В XCTU возможности замерить врямя передачи пакета не нашел... В гипертерминале тоже ).
Для проверки скорости в режиме API встает еще ряд проблем. Как передавать пакеты?... Такой утилиты вроде нет, которая эти пакеты формирует...
Цитата
В итоге решили использовать режим AP с программным подтверждением приема пакета

Ткинете пальцем плиз где об этом написано... Я найти не смог. Возможно я тоже буду этим пользоваться
at90
у меня 1500 метров было на открытой местности.
Модули Xbee Pro 100 мватные.

Антенны логопериодические направленные.
У меня протокол запрос-ответ.
Если ответ не пришел, делаю повторный запрос.
Djam
Цитата(George! @ May 15 2007, 02:54) *
Крайне интересна методика эксперемента. В XCTU возможности замерить врямя передачи пакета не нашел... В гипертерминале тоже ).
Для проверки скорости в режиме API встает еще ряд проблем. Как передавать пакеты?... Такой утилиты вроде нет, которая эти пакеты формирует...

Ткинете пальцем плиз где об этом написано... Я найти не смог. Возможно я тоже буду этим пользоваться

1.эксперимент проводился с помощью собственного (специально написанного) ПО.
2. В XCTU это тоже можно сделать следующим образом: на Range Test формируешь пакет требуемого размера (create data),устанавливаешь требуемый таймаут (datarecivtimeoout) -я пробовал с 0,10,100 мс-, затем устанавливаешь требеумое количество пакетов (Stop At-например 100) и засекаешь обшее время передачи, а потом делишь на количество пакетов.
3.Для проверки скорости в режиме API можно использовать вкладку Terminal->Assemble Packet. там вручную набираешь 2-3 пакета разного размера и повторяешь их например 100 раз. дальше как в п.2.
4. Опечатка - не АP, а АТ. А программное подтверждение реализеутся в собственном ПО на компе, к-е принимает пакеты (читает с COM-порта) проверяет CRC16 и отправляет подверждение.

Цитата(at90 @ May 15 2007, 04:11) *
у меня 1500 метров было на открытой местности.
Модули Xbee Pro 100 мватные.

Антенны логопериодические направленные.
У меня протокол запрос-ответ.
Если ответ не пришел, делаю повторный запрос.

Видимо придется тоже остановиться на таком варианте -запрос-ответ.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.