Всем привет
Мне предстоит сделать сеть девайсов на CC430. Самих мартышек ещё нет, пока только въезжаю в тему, поэтому вопрос совсем нубский
Питание у девайсов батарейное, большую часть времени проводят в спячке, территориально разнесены могут быть далеко от точки доступа (вне досягаемости), но в то же время ретрансляторы нельзя использовать (как пишут в мануале, потому как они должны быть включены всегда). Там же пишут что нет возможности store-and-forward для p2p соединений и explicit routing shall not be supported. Собственно вопрос: можно ли программно реализовать динамическую маршрутизацию на p2p соединениях чтобы девайсы вне досягаемости точки доступа всё же могли до неё достучаться по цепочке p2p соединений?

Сколковец?
На динамической маршрутизации и сложных топологиях в западных университетах делают ученые степени.
Общий принцип такой: для маршрутизации нужна энергия на транзитных узлах. Либо ваши узлы экономят энергию в спячке и вы забываете про маршрутизацию либо они все время работают на прием и/или посылают зондирующие пакеты чтобы оперативно перестраивать таблицы маршрутизации. Вы хотите чтобы все узлы были с батарейным питанием. Транзитный узел святым духом будет уведомляться что ему нужно принять пакет от узла вне досягаемости базы ??? Прчем дальний узел может еще и не быть синхронизирован с остальной частью сети.

ОК, а если забыть про батарейное питание. Сам протокол теоретически позволит реализовать это при условии что все всегда включены но без range extender-ов?

Делать свою хопинговую сеть.

Возможен компромис.Вся система должна работать по жестким таймингам и соответственно ретрансляция возможна только во время активного состояния.Это приведет к бОльшим затратам энергии и сложностям с синхронизацией.Но компромис он на то и компромис....

Примерно так и планировали, но т.к. я не имел дело раньше с симплисити то и возник вопрос можно ли в принципе на прикладном уровне это реализовать. Ну раз можно, значит попробуем сначала со статическими маршрутами зашитыми в каждый девайс. А потом если получится можно попробовать динамическую маршрутизацию. Пока читаю литературу об этом

Добрый день!
Скажите пожалуйста Вам удалось реализовать динамическую маршрутизацию на симплисити?

Нет, от симплисити отказались. Помучившись в итоге реализовали AODV протокол.

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

В симплисити хаб должен быть включен постоянно. Нам же требовалась mesh-сеть со спящими узлами

Понятно. Спасибо большое!
У меня задача попроще, т.к. есть хаб постоянно включенный и узлы имеют источники питания свои постоянные, т.е. нет необходимости экономить энергию.
А не подскажите какие-нибуть полезные ссылочки почитать по маршрутизации в mesh-сетях, по построению этих сетей.
Просто я честно говоря новичек с области связанной с маршрутизациями, я никогда не имел с ними дело.
Я проектировал беспроводные устройства, однако там были топологии либо точка-точка либо звезда, без переадресаций.

Да я тоже далеко не супер спец чтобы советовать что-то конкретное. Начал самостоятельно с нуля, сейчас напарник тянет этот проект.
Мы использовали AODV протокол маршрутизации, про него pdf в аттаче. Он же используется в ZigBee так что можно про них почитать для ознакомления.
Вам конкретнее что требуется? Может и симплисити достаточно. Mesh сети сложнее. Если допустимо иметь выделенные ретранляторы, то симплисити вполне подойдёт

Я почитал про AODV и очень Вам благодарен за то что "ткнули носом" в него, потому что протоколов большое множество, я сначала углубился в протоколы типа RIP и т.п., а по самому ZigBee не нашел доходчивой спецификации или описания по самой маршрутизации.
Нашел документик от Freescale, они там описывают в общих чертах работу ZigBee, но хотелось бы поподробнее понять именно то что связано с маршрутизацией.
А почитав про AODV и понял что он близок к тому что мне нужно, довольно хорошо описаны общие принципы маршрутизации.
По поводу выделенных ретрансляторов в том то и дело что нужно чтобы все узлы сети были одинаковые, т.е. каждый совмещал в себе функции как конечного устройства так и ретранслятора.
У меня имеется беспроводная сеть датчиков охранные-умный дом и главный коммуникатор который подключен к главному управляющему блоку. Я использую топологию звезда и все работает.
Проблема возникает в том случае когда некоторые датчики по дальности не достают до коммуникатора.
Добавлять второй коммуникатор или выбирать место для его установки не всегда удобно, потому необходимо чтобы промежуточные датчики, которые находятся невдалеке от коммуникатора, взяли на себя роль ретрансляторов.
Плюс есть еще в системе беспроводные узлы которые обеспечивают удаленный 485-й для управления камерами, подключения клавиатур и других блоков, рассчитанных на работу по 485-му интерфейсу.
Пока не учитываю питание датчиков, спящие режимы, пока считаю что питать их буду постоянно от внешнего источника.
Важным нюансом является то что события от датчиков должны доставляться до коммутатора в наиболее короткие сроки, т.е. насколько много времени нужно датчику чтобы послать сообщение исходное на расчет маршрута (считаю что маршрут неизвестен пока), дождаться прихода ответа и послать тревожное сообщение...


Спасибо за документ приложенный!

Это не совсем так. Для спящего режим возможна другая дисциплина обмена. Нужно чтобы на Join нашелся ответивший. Т.е. не спать должен тот, кому нужно передать - хаб очнулся, передал свой Join, а желающий(EP) тут же ему свой и понеслась. Пока передавать не нужно - EP спит и иногда выдает Join (для хаба, у которого вдруг найдётся что ему передать), как только нужно передать что-то важное - становится в приём и ждёт Join от хаба. В рамках SimpliciTI это реализуемо.

Я правильно понял что Вы имеете ввиду синхронный режим работы когда хаб инициирует любые обмены данными в сети и опрашивает остальные узлы? Если я правильно понял из документации на ZigBee, то в случае синхронного режима работы период опроса в случае большого числа датчика может быть довольно большой, до единиц и десятков секунд.
В моем случае наверное это будет не совсем правильно потому что если происходит тревожное событие когда какой-то из датчиков сработал то не должно быть паузы в течении которой он не сможет передать событие, т.е. он должен фактически сразу послать пакет(особенно это касается тех случаев когда к примеру датчик пытаются вывести со строя - он передает событие вскрытие корпуса а потом уже неважно выведут его со строя или нет...событие уже ушло на центральный блок).

Время доставки в рамках одного хопа зависит от периода побудки хаба. Т.е. при побудке 1 раз в секунду максимальное время отправки сообщения от EP составит менее 1 с. Если пара EP возжелает передавать одновременно, то какой-никакой, но механизм борьбы с коллизиями (по уровню в канале) есть. Если же рассматривать более одного хопа, то тут да - пока не проползёт через все хопы - не доставит. Можно чуток ускорить - ретрансляторам и хабам при активном List+ не спать какое-то время

Я планировал делать асинхронный обмен данными. Для предотвращения коллизий использовать технологию подобную csma/cd. Даже если возникнет коллизия, т.е. два датчика полностью одновременно попытаются передавать события, то при прохождении через следующий узел сети этот результирующий пакет будет отброшен. Если в течении скажем 50 мс датчик исходный не получил подтверждения приема пакета центральным блоком то он делает переповтор. Таким образом после двух-трех переповторов пакет всетаки просочиться к центральному блоку. Во всяком случае так у меня работает в старой топологии.
А вот как это будет работать при добавлении маршрутизации я пока не знаю, тут надо еще подумать.
Возможно действительно имеет смысл перейти к синхронной передаче по опросу центральным блоком. Надо будет посчитать и прикинуть насколько большая частота опроса нужна будет.
Просто если в сети например было 5 датчиков а стало 30-40 датчиков и больше то при одинаковом периоде опроса каждого датчика нужно увеличивать частоту опроса в 10 раз чтобы получить ту же скорость реакции на какое-то событие. Если я ничего не путаю конечно.
Хотя если используется асинхронный режим, маршрутизация и батарейное питание то получается что мои все датчики должны постоянно висеть в приеме и ждать не придет ли от кого-то пакет для пересылки. С энергетической точки зрения это конечно никуда не годиться. Тогда всетаки нужно привязываться к опросам центрального блока и относительно него синхронизировать временные параметры прием-передача-сон.

Обычно ISM-трансиверы работают в полудуплексе, т.е. слышать свою передачу они не могут, следовательно определить коллизию во время передачи не могут, т. е. CSMA не получится. Пакеты же имеют контрольную сумму и для многих трансиверов от TI она формируется и проверяется(и дропаются) аппаратно, потому обнаружить битый пакет, да ещё и передать киляющий пакет, как в CSMA/CD, опять же практически не реально.
Вы бы сначала определили, сколько хопов Вам необходимо, а уж потом занимались протоколом. Потому как один хоп намного проще многохоповой системы.

Ну я имел ввиду не слышать свою передачу а посмотреть есть ли несущая на этой частоте, если есть то ждет пока исчезнет, если нет то (как вариант) включил несущую на некоторый период времени либо послал пакет преамбулы а потом сразу начал передачу.
Я знаю что контрольная сумма там формируется и проверяется аппаратно, только я немного не понял относительно того почему нереально обнаружить битый пакет...ведь у него то как раз контрольная сумма не должна совпасть и таким образом должно быть понятно что значит пакет битый. Может я просто что-то не учитываю или недопонимаю в логике работы, я сильно глубоко не разбирался относительно CRC потому могу ошибаться. Поправьте меня пожалуйста.
Насчет хопов мне в любом случае не подходит один хоп(если я правильно понимаю то это соединение точка-точка), ведь у меня фактически и работает система таким образом когда много подчиненных датчиков работают независимо на один главный блок. Я ж потому и разбираюсь с тем как лучше сделать ретрансляцию пакетов потому что довольно часто возникают ситуации когда невозможно разместить базовый блок так чтобы в его поле попали все датчики одновременно.

Если не ошибаюсь, детект несущей в SimpliciTI встроен в функцию передачи пакета. Случайная пауза интересна в довольно узких временных пределах, потому наверно её туда не положили, да и снятие флага уровня несущей довольно случайное явление, потому как и мощность сигнала, и АРУ, и шум...
от слова "прыгать" - я понимаю это как требуемое количество пересылок (прыжков), т.е. для звезды без ретрансляторов до AP один hop. Насчет битых пакетов - помнится, что в пакетных трансиверах обычно при приёме покалеченного пакета он просто дропается - даже не выдаётся флага готовности для чтения. Могу ошибаться, но DS и прочая в руки
В Вашем случае - звезда - может оказаться лучше поиграться с мощностями и антеннами, а то и уйти в более низкочастотный диапазон (конечно, если уж куплено, то другие проблемы). Или разместить не одну базу, а между ними "туннель" с фиксированными адресами/портами в маршруте (опять же можно поставить чуток костылей в рамках SimpliciTI) - тогда можно порезать переговоры и уменьшить расход ОЗУ.

Прошу прощения за допущенную мной ошибку по поводу csma/cd...я имел ввиду csma/ca.
Понял насчет проблем с обнаружением несущей, покопаю в этом направлении. Попробую может позаимствовать с simpliciTI детект несущей...ведь микросхемы те же используются.
Да, в CC1101 можно в настройках задать чтобы приемный буфер чистился если принят битый пакет. Если пакет принят битый то его нет смысла анализировать, он просто удаляется и главный блок считает что пакет вообще небыл послан, потому датчик пославший пакет подождал немного, нет ответа, шлет переповтор.
Не получиться поиграться с мощностями, антеннами к сожалению. Железо уже есть, в топологии звезда оно работает и теперь его нужно чисто софтверно переделать не добавляя лишних узлов-ретрансляторов.
Потому вот и размышляю пока в каком направлении двигаться - взять что-то типа simpliciTI, убить на него время а потом упереться в какие-то его ограничения или попытаться сгородить что-то свое, пусть не особо быстро, с багами, но посидеть и довести его до ума. Понимаю что ZigBee стек полноценный не получу, даже и не замахиваюсь на это, хочется что-то попроще. Для меня не важны такие нюансы как распределение нагрузки на узлы(пока что не забочусь о сохранности их элементов питания), выбор именно самого идеального пути...для меня важно пусть все это будет попроще, с ограничениями, но главное перенаправляет пакет по какому-то возможно более длинному пути, но он всетаки достигает адресата.

В SimpliciTI можно "добыть" MRF, а NWK выбросить или покалечить до неузнаваемости, например, введя жесткую карту адресов сети (убрать Join и Link), но оставить ретрансляцию, внедрив адрес "хозяина" сообщения в payload, ещё можно урезать длину поля адреса, выделить порты для туннелей, заодно выбросить прочую служебку, но задействовать подтверждения, а может и уведомления (хотя как по мне сеть или работает или нет, а логи помогают только при чудесатостях)

Спасибо большое за советы!
Пока, к сожалению, не могу ими воспользоваться, т.к. еще не разбирался настолько глубоко с simpliciTI.
Сейчас буду понемногу разбираться в ней и думать какие части из нее задействовать.
Подскажите пожалуйста маршрутизация в simpliciTI выполняется с использованием какого-то общеизвестного алгоритма или там используется что-то свое?
Меня очень заинтересовала идея насчет AODV протокола маршрутизации, которую я позаимствовал у Cosmojam.
Не знаю правда насколько Я в состоянии реализовать такой протокол в своих устройствах, но идея пока мне нравиться.
По мере вникания в ZigBee у меня возникают вопросы.
Немного не понял по поводу того что после пакета синхронизации от координатора выделяется 16 временных интервалов для доступа датчиков к сети. А как быть если датчиков штук 30, т.е. за один проход каждый датчик не может что-то ответить? нужно вводить разделение что например в первом 16-слотовом интервале могут отвечать датчики с 1 по 16-й а во втором 16-слотовом интервале могут отвечать остальные 14 датчиков? Или датчики состязаются кто первый смог захватить тайм-слот тот и передает?
Убрал вопрос по поводу 50-и датчиков и 20 мс потому что понял что написал глупость, что еще не до конца разобрался с временными параметрами пакетов синхронизации и как задаються те самые временные интервалы в течении которых могут отвечать датчики.

Там вполне внятная документация по протоколу. В пакете нечто похожее на UDP с бубенцами и хороводами. А дисциплину обмена (MAC-уровень) форматом пакета не опишешь - в доке достаточно понятно.
Что касается кода, то, судя по стилям, его проектировали, писали и поддерживают совершенно разные команды. Но как для бесплатного проекта, так очень даже вменяемо. Отдельно уровень железа - дрова - настроить, включить/выключить, принять пакет, отправить пакет (папка вроде как звалась MRF) иотдельно сетевой уровень (папка NWK), а к нему примеры приложений.
Припоминаю там в NWK в AP "закат солнца вручную" - пулы массивов... я их заменил где было нужно списками, заодно выбросил обертки IOCTL к вызовам MRF.
Насчет скорости опроса - я Ваших задач не знаю, но сдается мне, что масштабы времени в разных режимах нужны разные. Для датчиков вторжения важно иногда докладывать о наличии себя и срочно лупить в эфир когда чего случилось. И то, 1 секунда по сравнению с дозвоном на мобилку просто ничто. Для пожарки почти так же. ИМХО. А постоянно мониторить далеко не всегда нужно.
Насчет ZigBee для начала посмотрите, какие там, в IEEE 802.15.4, приняты размеры Payload, а потом на свой кремний. Калечить ZigBee под свои нужды я бы не стал.

Спасибо! Воспользуюсь Вашими советами!

Добрый день!

Подскажите пожалуйста такой нюанс по поводу ZigBee.
К примеру у нас топология многоячейковая сеть, т.е. есть центральный координатор, маршрутизаторы и оконечные узлы.
Расположение элементов такое что некоторые из маршрутизаторов не могут напрямую обратиться к координатору т.к. не достают по дальности. Обратиться они могут только через промежуточные маршрутизаторы.
В описании ZigBee пишется что в таких сетях используется синхронный доступ.
У меня возник вопрос - координатор посылает сетевой сигнальный пакет с полезной информацией для остальных узлов и относительно него они вроде как должны синхронизироваться.
Однако не все узлы получают его напрямую, получается что к части узлов(которые он не может охватить по дальности) эти сигнальные пакеты идут через промежуточные маршрутизаторы и соответственно они сдвинуты по времени.
Вроде как уже неудобно по ним синхронизироваться...
Или я что-то неправильно понял?
Как в таком случае осуществляется синхронизация?
В частности интересует как дальние узлы могут принимать участие в состязательном доступе к каналу и попадать четко в отведенные для этого тайм-слоты ведь начало этих тайм-слотов отсчитывается от синхропакета координатора, а до них синхропакеты доходят с задержкой...