galjoen,
если не секрет, расскажите удалось ли Вам решить Вашу задачу и к какому решению Вы всетаки пришли?

По поводу броадкаст-рассылок сообщений - для устранения коллизий я так понимаю в беспроводных сетях используется CSMA/CA с предварительным прослушиванием канала на занятость? Но при броадкаст рассылке весь не решается никак проблема скрытых узлов, когда пакет расходиться по сети, ретранслируется одновременно узлами которые не слышат друг друга, однако в это же время узел находящийся между ними получает битый пакет.

Taradov Alexander,
подскажите пожалуйста как можно избежать или максимально уменьшить воздействие проблемы скрытых узлов? Подразумевается что система не имеет общего синхронизатора и , т.к. устройства не синхронизированы, то сообщения от разных датчиков могут ретранслироваться со случайной задержкой.
Я делал контроль несущей по показанию RSSI, однако когда датчик находиться далеко и уровень RSSI от него практически находиться на уровне шума, то получается что наш узел не слышит этот пакет, соответственно может начинать передачу и тем самым запортить входящий пакет всем окружающим его узлам.

Обычно каждый пересылающий узел добавляет случайную задержку к широковещательным кадрам, а если так получилось, что сложившись все задержки привели к тому, что пакет побился, то просто не судьба - никто не обещал, что доставка без подтверждения надежна. Но на деле так случается редко, так как сами по себе ситуации когда один узел слышит только 2 других и все - редки.

Сообщение отредактировал Taradov Alexander - Jul 27 2013, 18:14

Я делал в таксопарке обмен данными.
По приезду (или в дороге - если связь есть) происходит соединение и данные обмениваются между устройствами (некоторые машины долго не возвращаются, но встречаются в городе).
По приезду в парк - данные скачивают (и свои и от других машин).
Использовал Simpliciti (с небольшими правками) и модули на 433Mhz - по дороге даже при встречном за 300 м контакта - успевает 3-4Kб отправить. Машин примерно 1500 каждая привозит маленькие куски данных от других - в результате данные быстрее приходят, чем ждать когда машина придет сама с данными.

Относительно двух узлов я немного не то имел ввиду. Узел может слышать много других узлов(быть в зоне приема сигналов от них), однако в этом случае он не сможет принять нормальный пакет в случае если хотя бы частично пересекутся промежутки передачи двух и более узлов, которые он слышит. Просто посылки хотя бы частично но наложатся друг на друга и в точке приема(на входе нашего узла) мы не получим корректный пакет.
Просто я немного не могу уловить идею как рассылать широковещательный пакет в сети где довольно большая концентрация узлов...с одной стороны хорошо что между конечными узлами много промежуточных возможных ретрансляторов, расположенных относительно близко к друг к другу и с перекрывающимися зонами передачи-приема, но с другой стороны возникает проблема что чем больше узлов тем больше вероятность того что пересекутся ретранслированные ими пакеты.
В этом случае конечно можно расширить временные ворота, в которых выбирается псевдослучайная задержка. Например сделать диапазон от 0.1 общей длины пакета до 10-100 общих длин пакетов, однако это приведет к тому что возрастет общее время прохождения пакета до конечно узла(рассматриваю случай когда так попадет и на пути выпадут максимальные задержки в узлах ретрансляции).
Или всетаки в ситуации с широковещательными пакетами больше полагаются на такие понятия как вероятность успешной доставки пакета и т.п., т.е. нельзя гарантировать что пакет в 100% случаев дойдет до получателя а не побьется по пути из-за плохого совпадения задержек и наложения пакетов. Я просто все думал как бы еще совместить подтверждения и широковещательную рассылку и не придумал пока.
Широковещательная рассылка мне нужна именно для поиска пути, потому что обдумывал другие варианты поиска(последовательный опрос сначала своих соседей, потом соседей соседей и т.п), но все они упирались в огромные задержки при увеличении числа узлов в сети.
Сумбурно как-то изложил свои мысли...надеюсь поймете что я имел ввиду.

Абсолютно надежной доставки не будет по понятным причинам. Единственный способ избежать наложения - пересылка с задержками. Конкретный пример - в ZigBee на 2.4 GHz максимальная длинна кадра 4.5 мс, случайные задержки при пересылке кадра от 1 до 32 мс. Этого достаточно чтобы на практике в сетях из 100+ устройств в одной комнате броадкасты доходили до всех всегда.

Впечатляет!
А какую Вы скорость использовали для связи?
Я так понимаю каждое устройство периодически посылало запрос в эфир и ждало подтверждения о том что в зоне есть другое устройство, при получении подтвердения начинался сеанс обмена данными? Но такой вариант хорош если в зоне взаимной видимости только 2 устройства, но если больше, то как в таком случае быть...получается они должны между друг другом обменяться информацией...при 2-х машинах это 2 транзакции, но при 3-х это уже 6...или они обменивались не только своей бортовой информацией, но и одновременно синхронизировали информацию в их памяти относительно других машин?
Вы использовали внешнюю какую-то память для загрузки данных? Потому что 1500 машин пусть даже и с небольшим объемом данных с каждой уже выплывает в довольно приличный объем...


интересно. Спасибо! Полезная очень информация. Я думал что диапазон задержек при более 100 устройств должен быть явно побольше.
А у меня еще вопрос немного другого плана - а в ZigBee модулях реализовано два буфера - один на приме, другой на передачу? Т.е. я имею ввиду что например узел принял пакет для ретрансляции и у него случайная задержка предположим оказалась 30 мс. Как ведет себя узел в эти 30 мс - висит в состоянии готовности на передачу пока не освободиться канал или он принимает другие пакеты, складывает их в буфер с тем чтобы потом обработать когда освободиться?
Просто у меня в системе я не до конца реализовал нумерацию транзакций и отслеживания новых-устаревших пакетов. Получается ситуация что узел принял пакет для ретрансляции и сидит в ожидании освобождения канала (другие пакеты в это время не принимает, т.к. банально не хватает ОЗУ контроллера на увеличения буферов приема-передачи (рассчитаны на один пакет) ), задержка у него довольно большая, он ждет. В это время другим путем пакет доходит с короткими задержками до узла назначения и уже обратно идет ответ узконаправленный и пока этот ответ опять таки с задержками где-то в пути, наш узел посылает дальше пакет запроса пути и те узлы, которые не слышали ответ от результирующего узла, начинают дальше ретранслировать вперед пакет поиска. Возникает лишняя нагрузка на сеть...
Я правильно понимаю что одним из главных условий широковещательной рассылки есть то, что каждый узел только 1 раз ретранслирует пакет с определенной комбинацией его номера и узла-источника?

Я не до конца понимаю как быть с номерами пакетов в сети общей, нужно ли их синхронизировать от разных узлов...ведь при запуске узлов у каждого из них начальный адрес пакета нулевой и инкрементируется в процессе работы. Но получается что если узел источник шлет пакет №5 узлу назначения, узел назначения отвечает ему с тем же номером пакета и должен ли узел назначения как-то изменять-привязывать свой номер в зависимости от номера принятого пакета? Или если узел назначения захочет послать узлу источника другой пакет, то он будет слать со своим например №3, несмотря на то что от узла назначения до этого приходил пакет №5 ?

ZigBee - это стек протоколов, ожиданием занимается сетевой уровень, приемом/передачей - физический, к моменту когда нужно задержку делать кадр уже давно покинул радио. После задержки он будет отправлен на передачу в радио заново.

Да, для этого в ZigBee есть Broadcast Transaction Table.

Ничего не нужно синхронизировать транзакция однозначно определяется по адресу отправителя и номер кадра.

Одна из самых простейших реализаций всего этого - Atmel Lightweight Mesh http://www.atmel.com/tools/LIGHTWEIGHT_MESH.aspx. Даже если напрямую использовать не получится, то там есть документация, которая описывает все процессы и исходники полные и читаемые. Я автор, так что могу ответить на вопросы, если появятся.

Я понял, я неправ. Некорректно сформулировал вопрос. У меня просто немного все в куче и нет как такового разделения по уровням.


Спасибо! Впечатлило конечно что Вы автор. Теперь мне понятно почему Вы так круто ориентируетесь в вопросах связанных с ZigBee.
Я когда начинал все делать в общих чертах тогда вроде бы просмотрел документацию по Atmel Lightweight Mesh, но сейчас понимаю что явно в сильно общих чертах просмотрел. Сейчас попробую вникнуть более основательно. Просто когда начинал делать систему вопросы были одни, а в процессе экспериментов, проб и ошибок возникло еще намного больше вопросов. Так что нужно по-новому перечитать информацию с которой начинал.

Сообщение отредактировал Pasha_a13 - Jul 27 2013, 20:29

Сеть из 204 узлов в одной комнате https://dl.dropboxusercontent.com/u/6121480...h_204_nodes.png. Тут правда броадкастов нет, все юникастом шлют данные на координатора.

С броадкастами я проверял на сетях до 50 устройств, потерь не видел ни разу. Из такой массы хоть один да будет принят всеми.

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

А WSNmonitor это программа специально разработанная именно для железа Atmel или она более-менее универсальна и ее можно использовать с другим железом? Просто по картинке, которую Вы прислали, видна очень информативная картинка всей сети...очень удобно для отладки, настройки когда видна вся структура сети.

В ZigBee - да, в LwMesh - нет.

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

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

WSNmonitor - это из состава ZigBee стека Atmel (BitCloud), но в принципе я не вижу проблем использовать ее в своих целях. Единственное ограничение - это нужно соблюдать протокол и архитектура сети - все шлют информацию одному. Так что в вашеи случае, где все шлют всем, она не поможет скорее всего.

Сообщение отредактировал Taradov Alexander - Jul 27 2013, 20:56

Александр, спасибо большое за ответы!
Перед дальнейшими вопросами более детально разберусь с документацией на LwMesh, думаю многое для себя открою и буду переделывать свою систему(сейчас она работает но с ограничением - нет широковещательной рассылки и может быть только один промежуточный узел(который заодно и выполняет функции ретранслятора) на пути пакета).

В ZigBee координатор вроде как нужен только в начальный момент времени для сборки сети. Когда узлы вошли в сеть они могут работать и без него (его можно выключить) и даже могут новые узлы входить в сеть.
Но в реальности, из-за множества багов в реализации стеков, я в своём ПО периодически проверяю наличие координатора в эфире и перегружаю модуль если координатор не отвечает.
Это спасает от многих багов.
У нас тоже передача данных возможна между любыми устройствами в сети. Траффик не привязан к координатору.
CC2480 & CC2530.

Координатор да, нужен только для старта, но вот Network Manager, который обычно совмещают с координатором, нужен всегда. Он отвечает за разрешение конфликтов адресов и выбор нового канала в случае помех. А при использовании некоторых режимов security еще нужет Trust Center, который тоже обычно совмещают с координатором. А некоторые профили (Home Automation, Smart Enregy, например) требуют, чтобы TC был на координаторе, так как часть логики устройств завязана на это.

Ну и вышеупомянуты способ проверки целостности сети тоже много стоит.

Так что как ни крути, а координатор нужен всегда.

Александр, добрый день!

Я прочитал документацию по Atmel Lightweight Mesh и у меня возникли пару вопросов.

Первый вопрос - я не совсем понял как ведет себя координатор после того как он инициировал route discovery, сколько времени он ожидает route reply от узла назначения и если route reply не пришел(узел назначения вне зоны досягаемости сети либо выключен), то делает ли он повторные попытки поиска узла назначения?

Второй вопрос - "4. If native route discovery is used and received frame had a unicast network address and broadcast MAC address (route discovery). In this case acknowledgment is used to facilitate discovery of the reverse route."(стр.20, вверху) - здесь под acknowledgment понимается пакет route reply или есть еще какие-то другие acknowledgment сообщения? Я просто не совсем понял какие есть acknowledgment пакеты в сети, т.е. в каких случаях они посылаются и понимаются ли под acknowledgment пакеты route reply и route error?

Я просто смотрю что в составе пакета есть бит Ack Request, который вроде как говорит узлу назначения нужен ли acknowledgment или нет. Какие именно пакеты и в каких случаях он отключает. Поясните пожалуйста, если можно.

Спасибо!

Сообщение отредактировал Pasha_a13 - Jul 30 2013, 19:57