Соединить 20-30 устройств по радио-каналу., Нужен совет по выбору протокола... Опции

[plombir]

Всем доброго дня.
Где эту тему положить не нашёл, но так как основная часть будет сделана на AVR выкладываю здесь.

Решил взяться за проект: 20-30 устройств, связь между ними по радио-каналу, заложился на частоту 430-465MHz (или ~900MHz резерв), растояние между устройствами 50-150м, максимальное удаление между крайними 2км. Где то, примерно в центре есть головное устройство.
Задача: постоянный сбор данных со всех устройств на головное.
Время цикла: максимум в 10 секунд надо уложиться.
Трудности: исходя из разрешённой мощности передатчиков + железо вокруг + помехи - крайние устройства не могут связатся на прямую с головой. Необходима ретрансляция. Возможно двойная или тройная.

Господа! Посоветуйте протокол для данной задачи, т.е. логический уровень. Возможно, есть уже такое. Достаточно будет названия его.
С физической реализацией данной задачи проблем не возникнет.

[Dir]

Если бы не частота 430МГц, то все идеально на Zigbee ложится. Причем как раз на ATmega128 и Чипконовском CC2420 есть много Reference Note. Иди на www.ti.com (или www.chipcon.com) и там смотри все.

PS. Да, частота 2,4ГГц

[_artem_]

Ну тогда тебе надо чтото вроде интернета сварганить ) То есть каждое устойство должно содержать рутинг тейбл .
Это на самом нижнем уровне . То есть физически на каждом приемопередатчике жестко должны быть поставлены кто кого видит а если не видит то на кого надо послать который или видит или же видит того который знет кто его видет ))
(или возможно динамическое кофигурирование этого по какому то заумному алгоритму в момент включения - но это немного трудно и требуется времюа чтобы довести все это до ума для работы без конфликтов).
Немного сумбурно получилось но если надо разясню на примере но не сегодня.

[viakon]

Какая мощность разрешена? Главное здесь будет удаление от базы до объекта. Как показывает опыт 2вт в городских условиях на указанном диапазоне, FFSK модуляция, 1200 бод с коррекцией ошибок, вполне стабильно работает на 2 км. А если у тебя еще и направленные антенны будут то гораздо больше.

[Harbinger]

15 мВт - 9 км с Yagi на крышах зданий, 12kBps (эмулятор телефонной линии с модемом). Так что резервы здесь имеются.

[vesago]

Пример реализации http://aly.projektas.lt/Projects/SimpleRFNet/ Правда под ваши параметры не совсем пойдет. Но может что-то почерпнете.

[Yura_K]

протокол для данной задачи, т.е. логический уровень

А может взять как в Ethernet по MAC адресам. Там вроде тоже все абоненты на одной шине. Или как в Token Ring передавать маркер.

Сообщение отредактировал Yura_K - May 15 2006, 13:55

[AndreyMS]

Может вот это поможет?

[rezident]

У людей в радиомодемах Спектр433 задача ретрансляции решена. До 8 устройств в цепочке. Гляньте пользовательский мануал, может на нужную мысль натолкнет?
http://www.rateos.ru/spectr433.shtml

[plombir]

Благодарю Всех кто откликнулся.
Пока, без комментариев...
Сижу, информацию перевариваю...

[Karl]

Посмотри микросхему nRF24AP1. Это однокристальный трансивер с интегрированным протоколом ANT. Протокол ANT позволяет организовать беспроводные сети сложного типа с динамической конфигурацией.

[viakon]

А может взять как в Ethernet по MAC адресам. Там вроде тоже все абоненты на одной шине. Или как в Token Ring передавать маркер.

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

[Yura_K]

А может взять как в Ethernet по MAC адресам. Там вроде тоже все абоненты на одной шине. Или как в Token Ring передавать маркер.

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

Мда, действительно. Тогда можно определить статический маршрут. Ведущее устройство (база) отправляет по этому маршруту маркер, а ведомое, захватившее маркер отвечает. Маршрут кольцевой, можно даже несколько конфигураций таких маршрутов. Скорость опроса конечно упадет.

[plombir]

Всех благодарю за ответы!
Решение у меня принято. Протокол собственный. Прикинул его на бумаге - вроде получается. Инициализация устройств с их последующей маршрутизацией. Всего, взято по немногу от всех протоколов. От tcp/ip, от сотовой связи, от Зеленоградцев (spectr433), от множества протоколов на 2,4ГГц + от старых протоколов забытых в Советское время.
В трансивер заложил м/с гибридного трансивера на 433Mhz, в качестве драйвера slave mega8, для master mega64 т.к. озу, по расчётам вычисления оптимального маршрута с таблицей всех адресов - требуется прилично.
Ещё раз, всем спасибо!

[defunct]

В трансивер заложил м/с гибридного трансивера на 433Mhz, в качестве драйвера slave mega8, для master mega64 т.к. озу, по расчётам вычисления оптимального маршрута с таблицей всех адресов - требуется прилично.
Ещё раз, всем спасибо!

Непонятно откуда там взялись вычисления маршрута... Ведь маршрут можно прокладывать на ходу по мере необходимости без всяких расчетов... Тем более что радоисеть этому сопутствует. Маршрутизацию в радиосети можно свести к тупой ретрансляции по тому же каналу. Устройств по вашим словам 20-30, соответсвенно у каждого устройства есть свой номер, требующий не более 1 байта.. Таблица канальных маршрутов здесь совершенно не нужна, т.к. в таблице обычно прописывается номер канала по которому требуется перенаправлять сообщение, а каналов у вас всего 1 (или 2 если используются направленные антены, но и здесь тоже нет никаких затруднений с выбором канала).

Алгоритм адаптивного прокладывания маршрута может быть таким:

В пакет можно заложить адрес получателя 1 байт и адрес передатчика 1 байт, а также номер сообщения (16-32 байт), для пресечения повторной обработки пакета.
Каждый узел сети представить потенциальным ретранслятором.
Каждый ретранслятор должен дописывать к пакету свой номер, чтобы исключить закольцовку и зацикливание сообщения, что может привести к бесконечному блужданию сообщения по сети. (дописывать номер предпочтительнее чем вводить поле TTL, как в IP, в следствии того что узлов в сети не так много и пакет сильно раздуть не получится, зато 100% пресечение повторов гарантировано).
При приеме пакета, ретранслятор должен анализировать пройденный пакетом маршрут, и если пакет еще не проходил через этот ретранслятор, тогда одно из двух или ретранслировать сообщение (дописав свой номер) или обработать (если номер получателя совпадает с номером получателя).
После обработки сообщения, занести в таблицу "мертвых" пакетов номер сообщения и адрес отправителя из полей пакета, на случай если этот же пакет придет к получателю другим маршрутом.

Таблица "мертвых" пакетов, будет не очень большой, она будет ограничена максимально возможным временем доставки пакета, которое в вашей сети будет не сильно большим (на мой взгляд не более 1 с). Заполнять таблицу "мертвых" пакетов можно циклически (обычный кольцевой буфер).

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

[plombir]

2 defunct!
Интересный вариант. Над ним стоит подумать.

А идея с маршрутом у меня такая получилась:
Мах узлов 32. Пакет: [заголовок][адр. кому][адр. от кого][данные][crc]. Обязательное условие передачи - подтверждение приема пакета.
Любой обмен начинает только мастер. Узел-ретранслятор работает по тупому алгоритму, не думая ни о чём. В [данных] как Вы и написали, будет весь маршрут прописан, но узел точно знает к кому следующему ему обращаться.
При инициализации (поиску всех узлов) каждый возвращает номера всех кого услышал (32 адреса). На мастере создается матрица 32х32. И если надо запросить узел, по ней логически вычисляется самый короткий маршрут (минимальное число ретрансляций). Если пакет не проходит - помечается в матрице ошибка на узле. И в другой раз ищется другой маршрут.

Я в первом посте не смог все тонкости задачи описать. Они позднее появились. Узлы со временем могут пропадать и появляться новые. И постоянного адреса у них может не быть (менталитет пользователя), но даже через него должна ретрансляция работать. И ещё, связь по разным причинам может становится то хуже то лучше. Поиск всех узлов получается процесс постоянный (раз в 30-60 секунд например).

[_artem_]

при соединении узлов было бы хорошо вычислять BER и мошность принятого сигнала (если чип позволяет это сделать) а затем использовать эти данные при выборе маршрута.

[defunct]

Я в первом посте не смог все тонкости задачи описать. Они позднее появились. Узлы со временем могут пропадать и появляться новые. И постоянного адреса у них может не быть (менталитет пользователя), но даже через него должна ретрансляция работать. И ещё, связь по разным причинам может становится то хуже то лучше. Поиск всех узлов получается процесс постоянный (раз в 30-60 секунд например).

С таким изменением условия, считаю, что адаптивное прокладывание маршрутов будет уместней жесткого PTP, т.к. снизится влияние пропадания узлов (все возможные маршруты будут использоваться), а также проще будет реализовать рассылку BROADCAST сообщений. Дублирование номеров (адресов) узлов конечно крайне нежелательно.

[plombir]

при соединении узлов было бы хорошо вычислять BER и мошность принятого сигнала (если чип позволяет это сделать) а затем использовать эти данные при выборе маршрута.

В выбраном трансивере гарантируют скорость 100кб/с (ЧМ) максимум до 500кб/с. Там есть выход уровня несущей. Можно к нему АЦП подключить и мерить. C битовыми ошибками - сложнее. Если прикинуть АЦП в AVR (mega8 + ZQ11.0592) однократное измерение + небольшие вычисления 200-250мкс. За это время получится пакет принять. И не очень хотелось бы усложнять всю конструкцию.
Испытания готовой системы на обьекте покажут, хватит ли ему определений принял/не принял данные. А если этого будет не достаточно, то придётся усложнять алгоритм.

[plombir]

С таким изменением условия, считаю, что адаптивное прокладывание маршрутов будет уместней жесткого PTP, т.к. снизится влияние пропадания узлов (все возможные маршруты будут использоваться), а также проще будет реализовать рассылку BROADCAST сообщений.

Если я правильно понял, под "Алгоритмом адаптивного прокладывания маршрута" подразумевается, что все узлы которые приняли пакет от мастера начинают его передавать дальше другим, не зная слышат его или нет. Или, данному узлу найти всех кто его слышит игнорировав повторы и только им передавать, не зная дойдёт ли пакет до адресата.
Если представить всю сеть как линия, где то в середине мастер находится, то сигнал пойдёт и вправо и влево. И крайние от мастера при передачи начнуть друг другу мешать, не подозревая о том.

Дублирование номеров (адресов) узлов конечно крайне нежелательно.

От дублирования адресов узлов, в сам адрес добавлено избыточных 2 байта случайно сгенер. числа (rnd). Получилось что адрес любого узла в системе 4 байта. 2(rnd) + 2(заданных в ручную).

[defunct]

Если я правильно понял, под "Алгоритмом адаптивного прокладывания маршрута" подразумевается, что все узлы которые приняли пакет от мастера начинают его передавать дальше другим, не зная слышат его или нет.

Именно. И если его хоть кто-то слышит, то этот кто-то и будет в ответе за дальнейшую судьбу сообщения.

Если же вы жестко проложете PTP маршрут, то например в ситуации, когда имеется 2 узла обеспечиваюших маршруты равной длины, и один, как раз тот который участвует в PTP маршруте вдруг временно пропадет, то сообщение не будет доставлено, хотя вполе могло бы пройти к адресату другим маршрутом (через другой узел).

Получилось что адрес любого узла в системе 4 байта. 2(rnd) + 2(заданных в ручную).

Нормальное решение, сразу закладываете возможность расширения, это хорошо.

[KWTR]

Не обязательно прибегать к ретрансляции. На 433МГц 2км вполне реально - при использовании а)пассивных направленных антенн в хорошим усилением + дополнительный внешний МШУ на входе приёмника
б)активных направленных антенн с большим усилением.

Задавайте вопросы на censored

[SasaVitebsk]

Не обязательно прибегать к ретрансляции. На 433МГц 2км вполне реально - при использовании а)пассивных направленных антенн в хорошим усилением + дополнительный внешний МШУ на входе приёмника
б)активных направленных антенн с большим усилением.

Задавайте вопросы на censored

Не совсем в тему, но, поскольку у меня вообще нет опыта в данной сфере то, какой приёмопередатчик кто посоветует. Расстояние до 150м прямая видимость внутри здания. С одной стороны - комп. Скорость нужна приличная, не менее 9600. Соединение на замену rs485. Желательно высокая устойчивость связи и минимальность внешней обвески. Можно готовое ус-во. Но только опробованное лично.

[bloodden]

CC1100 - самый оптимальный выбор. Это моё личное мнение.

[Muadib]

Сдесь схожая тема http://forum.roboclub.ru/IPBoard/index.php...cc1100&st=0

[zltigo]

но так как основная часть будет сделана на AVR выкладываю здесь.

Железнгая логика . Наверное паять будете? Тогда в "Пайку, Монтаж,.." поместить можно .
Перенес к беспроводным интерфейсам....