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

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

Сообщение отредактировал Pasha_a13 - Mar 25 2013, 14:39

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

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

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

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

Сообщение отредактировал Pasha_a13 - Mar 25 2013, 19:21

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

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

Сообщение отредактировал Pasha_a13 - Mar 25 2013, 20:06

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

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

Добрый день!

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