Mesh сеть между подвижными объектами., Подходит ли ZigBee? Опции

[galjoen]

Задача передачи телеметрии от экскаваторов/бульдозеров/самосвалов в карьере в диспетчерскую. Сразу скажу, что GSM там нет, иначе было бы просто, а Ирридиум дорог.
Вот подумываю о ZigBee, прочитал описание XBee. Но, насколько я понимаю, это не совсем то, т.к. сеть должна постоянно перенастраиваться - никаких роутеров, закреплённых в фиксированном месте, там быть не должно.
Так же подумываю использовать только физику ZigBee, а всё остальное сделать самому (на базе готового стека, конечно). Получается, что в сети должны быть только broadcast сообщения т.к. маршруты будут постоянно меняться. И наличие координатора тут не имеет смысла.
Понравился вариант на ATmega128RFR2, смущает только низкая максимальная выходная мощность передатчика. Какая реально дальность связи достижима? Или можно усилить?
Про ограничения в курсе.

[x893]

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

[Pasha_a13]

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

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

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

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

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

[ataradov]

А у меня еще вопрос немного другого плана - а в ZigBee модулях реализовано два буфера - один на приме, другой на передачу?

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

Я правильно понимаю что одним из главных условий широковещательной рассылки есть то, что каждый узел только 1 раз ретранслирует пакет с определенной комбинацией его номера и узла-источника?

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

Я не до конца понимаю как быть с номерами пакетов в сети общей, нужно ли их синхронизировать от разных узлов..

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

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

[Pasha_a13]

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

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

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

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

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

[ataradov]

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

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