Перейти к содержанию
    

Mesh сеть между подвижными объектами.

Повторять передачу и уменьшать счетчик в таблице маршрутизации. Если счетчик достиг нуля, то убирать запись и заново искать маршрут. Если препятствия частые, то есть шанс, что оно будет там при поиске и найдется более хороший маршрут. Других вариантов нет, если не хочется копить статистику и учитывать ее при поиске.

Понял. Спасибо! Я так и делал, я просто думал может есть какой-то другой еще путь.

Хотя у меня там были некоторые "нюансы", которые нужно исправить и без них думаю будет работать боле корректно.

Изменено пользователем Pasha_a13

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да тут сотни, десятки мегагерц не пройдут. Подойдёт диапазон 1-3 мегагерца, за счёт волновой дифракции. Но там антенны больших размеров нужны. Для покрытия 10км там меньше мощность нужна, но и диапазон тот шумный.

Ретрансляторы выход, но тоже не 100%. Нужно подумать...

C Иридиумом свои заморочки. Как с тарифом, так и со связью. Поскольку у вас карьеры, отвалы, то это сужает горизонт. Спутников не так много, чтобы покрыть и иметь непрерывную связь долго.

 

Только что делал обзор по этой тематике для руководства.

 

Из уже зарекомендовавших себя в разработках клиентов модулей:

 

Есть целая серия ZigBee модулей от Telit на различные дельности связи.

Под эту задачу подходит.

 

ZE61

Частота: 2.4-2.483 ГГц.

Дальность до 4000 м.

– 40 … +85ОС (industrial).

Выходная мощность 100 мВт (встроенный усилитель), чувствительность -99 дБм и улучшенная RF часть.

На основе чипа CC2430 от TI.

Стоимость - примерно 27 USD.

Дилер в РФ - ATOMA.

 

Что ещё... Тщательный анализ новостей и обновлённых даташитов производителей просто умилил. У многих вендоров, спустя года два-три (было и 4 года спустя), вдруг появляется радостный вопль в новостях "Теперь наш модуль ПОЛНОСТЬЮ соответствует стандарту

IEEE 802.15.4 / ZigBee !!!" О чём идёт речь? Как раз о том, что до этого момента сеть не поддерживала алгоритмы оптимизации своей связности и живущей на ней маршрутизации+алгоритмы безызбыточного повышения вероятности доставки сообщений в сторону "Мастера" и от него. И тут, наконец, стала это делать. Речь о том, куда были вынесены алгоритмы всех этих дел: на плечи конкретных разработчиков конкретных конечных устройств или же уже зашиты в самом модуле и используется по умолчанию, и для их активации нужны лишь небольшие настройки - мощность устройств, предпочтительная топология, скоростные ограничения, подчинённость (master/slave). Т.е. до этого момента шла речь о неких изделиях, которые лишь МОГУТ быть использованы в сетях ZigBee, при должных наворотах в обвязке этих модулей (включая управляющее ПО).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

О чём идёт речь? Как раз о том, что до этого момента сеть не поддерживала алгоритмы оптимизации своей связности и живущей на ней маршрутизации+алгоритмы безызбыточного повышения вероятности доставки сообщений в сторону "Мастера" и от него.
Это какие-то домыслы, за последние несколько лет ничего кардинально в имплементациях ZigBee не менялось.

 

Более того модулей и стеков "полностью соответствующих" стандарту нет в принципе. В настоящее время в тестовой спецификации есть пункты, которые выполнять не имеет смысла (очень много сервисов ZDO, которые сначала пихали в стек, а потом одумались и растащили по профилям, где они нужны).

 

Но это не страшно. Сертификация ZigBee построена по очень интересному принципу - производитель заявляет какие функции поддерживаются и потом только эти функции тестируются. Стек получатся сертифицированным только по этим пунктам. Так что просто "сертифицированного стека" не существует, есть только стеки сертифицированные по соответствующим PICS (Protocol Implementation Conformance Statement).

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Уже сам понял. Когда создается запрос RouteDiscoveryRequest, то обнуляются reverseLinkQuality и forwardLinkQuality и когда пришел ответ, то его lqi не должно быть равно нулю.

Изменено пользователем Pasha_a13

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

entry->reverseLinkQuality содержит лучшее значение из тех, что мы видели. Какой смысл доставлять его, если заведомо известно, что мы уже отправили лучший маршрут?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо! Уже понял. Я в частности рассматривал случай когда координатор принял ответ, то у него по умолчанию записан ноль в lqi.

 

entry->reverseLinkQuality содержит лучшее значение из тех, что мы видели. Какой смысл доставлять его, если заведомо известно, что мы уже отправили лучший маршрут?

Т.е. получается что мы удаляем запись в RouteDiscoveryTable только по таймауту в независимости от того прошел через наш узел уже ответ RREP на этот RREQ или нет, и пока не удалили то сверяем лучше ли пришедший маршрут чем пропущенный ранее и если лучше то ретранслируем его?

Изменено пользователем Pasha_a13

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е. получается что мы удаляем запись в RouteDiscoveryTable только по таймауту в независимости от того прошел через наш узел уже ответ RREP на этот RREQ или нет, и пока не удалили то сверяем лучше ли пришедший маршрут чем пропущенный ранее и если лучше то ретранслируем его?

Да. Нет гарантии, что первый прошедший ответ самый хороший. К моменту его прохождения еще не все узлы получили запрос обычно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да. Нет гарантии, что первый прошедший ответ самый хороший. К моменту его прохождения еще не все узлы получили запрос обычно.

Спасибо!

да уж...с точки зрения логики тут все классно продумано и получается что один из самых важных моментов(даже скорее самый важный) для работы всей системы это именно правильный LQI, правильное его вычисление.

Т.е. фактически получается что как ни крути все-таки упираюсь в железо, в то что оно долно быть заточено под работу с подобными алгоритмами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е. фактически получается что как ни крути все-таки упираюсь в железо, в то что оно долно быть заточено под работу с подобными алгоритмами.
Программно можно накапливать статистику потерь и вычислять LQI исходя из них. Это не легко, но реализуемо. Так даже спецификация ZigBee предлагает делать если другие метрики работают плохо.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Программно можно накапливать статистику потерь и вычислять LQI исходя из них. Это не легко, но реализуемо. Так даже спецификация ZigBee предлагает делать если другие метрики работают плохо.

Т.е. что-то наподобии того чтобы на каждом из участков вести статистику по количеству принятых-битых пакетов от соседних узлов и исходя из статистики этой расчитывать LQI?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да, LQI - это вероятность доставки кадра до узла.

Понял. спасибо! Буду думать в этом направлении :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...