задача на выбор беспроводного интерфейса для устройства Опции

[Димитрий]

приветствую всех.

была поставлена следующая задача. есть прибор состоящий из двух блоков.
первый блок это измерительный который расположен на улице. второй блок это индикатор плюс 1 кнопка для листания параметров индикации который устанавливается в помещении. растояние между ними не более 100 метров будем считать по прямой видимости. Для каждого дома в поселке устанавливается отдельной свой индивидуальный прибор. растоянии между домами не более 100 метров. на краю поселка находится контрольный пунк с удалением не более 100 метров от крайнего прибора.
необходимо обеспечить считывания информации с блоков №1 каждого прибора в контрольном пунке. Необходимо выводить индикацию на блоке №2 только своего прибора. Необходимо обеспечить простое (горячее) подключении дополнительных контрольных пунктов при необходимости а также их безболезненное отключение.
Необходимо обеспечить автоматическую смену маршрута передачи данных от приборов при изменение внешних условий.
Блок №1 питается от сети. Блок №2 предположительно питается от батареки.
Скорость передачи данных от каждого прибора не более 2кбит. Допускается поочередное считывания информации с приборов в контрольном пункте.
Количество приборов в одной сети не более 10 тысяч. Время задержки передачи данных от наиболее удаленного прибора до контрольного пункта не более 10 сек.
Необходимо иметь возможность разделение нескольких сетей.
само устройство обеспечивающее передачу расположенные в 1 и 2-ом блоках в сумме должны быть не дороже 10$ в партии 10к штук.

все описанное по моему виденью относится к zigbee сети возможно по верх которой поставлен ip/tcp протоколы. опыта в zigbee нет потому есть сомнения начинать лм разработку основывась на этом протоколе.

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

[Pasha_a13]

Добрый вечер!

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

[ataradov]

В описании ZigBee пишется что в таких сетях используется синхронный доступ.

Нет такого в описании ZigBee. Цитату можно?

У меня возник вопрос - координатор посылает сетевой сигнальный пакет с полезной информацией для остальных узлов и относительно него они вроде как должны синхронизироваться.

Это похоже на описание Slotted CSMA, но он был опционален в ZigBee 2004 и был убран совсем из ZigBee PRO.

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

Промежуточные устройства являются сами по себе источниками синхропакетов (beacons). Это была попытка использовать все что только можно из IEEE 802.15.4, но попытка провалилась, так как это очень фигово масштабируется и микроконтроллеры не имеют достаточно ресурсов для попадания в свои слоты.

[Pasha_a13]

Нет такого в описании ZigBee. Цитату можно?

Я эту информацию почерпнул не из самого описания оригинального ZigBee, а из статьи "Программно-аппаратное обеспечение беспроводных сетей на основе технологии ZIGBEE/802.15.4" журнал "Электронные компоненты" №12,2004г. стр.81
Цитата:
'Функция синхронизированного доступа применяется в сетях с расширенной топологией, такой как "кластерное дерево" и "многоячейковая" сеть.'
Может я просто неправильно понял что-то...

Промежуточные устройства являются сами по себе источниками синхропакетов (beacons). Это была попытка использовать все что только можно из IEEE 802.15.4, но попытка провалилась, так как это очень фигово масштабируется и микроконтроллеры не имеют достаточно ресурсов для попадания в свои слоты.

Тоесть получается что сеть с древовидной топологией как-бы разбивается на части(на небольшие отдельные сети) с топологиями "звезда" где маршрутизатор находящийся в центре является как-бы координаторов в своей небольшой подсети и он формирует синхропакеты?
Чтобы исключить коллизии то делается временной сдвиг между синхропакетами соседних координаторов чтобы узлы находящиеся между ними могли нормально воспринять и один и второй синхропакет без наложения.
Я правильно понимаю суть?

[ataradov]

журнал "Электронные компоненты" №12,2004г. стр.81

Да, на момент публикации эта информация верна. Спецификация ZigBee PRO официально вышла в 2006. Там этого уже нет.

Тоесть получается что сеть с древовидной топологией как-бы разбивается на части(на небольшие отдельные сети) с топологиями "звезда" где маршрутизатор находящийся в центре является как-бы координаторов в своей небольшой подсети и он формирует синхропакеты?

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

[Pasha_a13]

Да, на момент публикации эта информация верна. Спецификация ZigBee PRO официально вышла в 2006. Там этого уже нет.


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

Спасибо большое за пояснения!

Скачал NXP ZipBee PRO Stack User Guide, но не нашел там ничего по поводу синхронизации в ZigBee PRO.
Не подскажете где можно найти какую-то информацию по этой теме?

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

[ataradov]

Скачал NXP ZipBee PRO Stack User Guide, но не нашел там ничего по поводу синхронизации в ZigBee PRO.Не подскажете где можно найти какую-то информацию по этой теме?

Вас все еще интересует механизм 2004 года или что-то другое?
Как slotted режим на MAC уровне нужно читать IEEE 802.15.4, как оно именно использовалось в ZigBee тогда - это нужно искать тот стандарт, я понятия не имею есть-ли он еще в доступе где.

PS: Сорри, не прочитал, что PRO. Никакой синхронизации нет, устройство, которое хочет передать данные слушает эфир, если тихо - шлет.

Это называется CSMA/CA, описано все в том же IEEE 802.15.4-2006.

Сообщение отредактировал Taradov Alexander - Mar 26 2013, 19:56

[Pasha_a13]

Вас все еще интересует механизм 2004 года или что-то другое?
Как slotted режим на MAC уровне нужно читать IEEE 802.15.4, как оно именно использовалось в ZigBee тогда - это нужно искать тот стандарт, я понятия не имею есть-ли он еще в доступе где.

PS: Сорри, не прочитал, что PRO. Никакой синхронизации нет, устройство, которое хочет передать данные слушает эфир, если тихо - шлет.

Это называется CSMA/CA, описано все в том же IEEE 802.15.4-2006.

У меня вообще такая задача что есть сеть беспроводных датчиков на базе CC1101. Изначально она сделана под топологию звезда, т.е. у меня есть главный коммуникатор и много датчиков. Все датчики работают только через коммуникатор.
Проблема в том что довольно часто возникает ситуация когда не получается соблюсти такую топологию и часть датчиков оказываются вне зоны действия коммуникатора.
Потому у меня стоит задача переделать программное обеспечение с тем чтобы каждый датчик еще имел и функцию роутера, т.е. мог через себя удлинить радиус действия коммуникатора, пропустить через себя пакет к дальнему датчику.
Вот я и думаю пока как лучше к этому подойти. С точки зрения маршрутизации мне понравилась идея насчет LwMesh, которую Вы предложили в этой ветке.
Вопрос встал по поводу синхронизации всей сети.
Дело в том что в данный момент датчики имеют постоянное питание и потому можно не ломать голову насчет экономии энергии. Однако я понимаю что вскоре встанет задача относительно того чтобы и портативные датчики с батарейным питанием тоже могли выполнять роль ретрансляторов. А тут мне без синхронизации насколько я понимаю не обойтись, потому что много потребляют микросхемы в режиме приема.
Потому я и задавал изначально вопрос по поводу прохождения синхропакетов через роутеры, сдвиги по времени...я просто пытаюсь понять как можно синхронизировать систему.
Если питание постоянное то тут могу просто сделать как в PRO слушая эфир, но хотелось бы всетаки синхронизировать как-то все узлы.
Можете подсказать какие-то соображения по поводу всего этого?
Вообще асинхронный режим мне конечно удобнее всего, т.к. если какой-то из датчиков охранных дает сработку то пакет сразу пойдет к центральному блоку а не будет ждать своей очереди. Однако как быть с режимом ретрансляции в датчиках...без периодического просыпания и слушания эфира в момент потенциально возможной передачи не обойтись.

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