Jump to content

    

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

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

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

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

Edited by Pasha_a13

Share this post


Link to post
Share on other sites
Да тут сотни, десятки мегагерц не пройдут. Подойдёт диапазон 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, при должных наворотах в обвязке этих модулей (включая управляющее ПО).

Share this post


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

 

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

 

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

 

 

 

Share this post


Link to post
Share on other sites

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

Edited by Pasha_a13

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

Edited by Pasha_a13

Share this post


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

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

Share this post


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

Спасибо!

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

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

Share this post


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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Да, LQI - это вероятность доставки кадра до узла.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this