[plombir 0]

Всем доброго дня.

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

 

Решил взяться за проект: 20-30 устройств, связь между ними по радио-каналу, заложился на частоту 430-465MHz (или ~900MHz резерв), растояние между устройствами 50-150м, максимальное удаление между крайними 2км. Где то, примерно в центре есть головное устройство.

Задача: постоянный сбор данных со всех устройств на головное.

Время цикла: максимум в 10 секунд надо уложиться.

Трудности: исходя из разрешённой мощности передатчиков + железо вокруг + помехи - крайние устройства не могут связатся на прямую с головой. Необходима ретрансляция. Возможно двойная или тройная.

 

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

С физической реализацией данной задачи проблем не возникнет.

[Dir 0]

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

 

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

[_artem_ 0]

Ну тогда тебе надо чтото вроде интернета сварганить ) То есть каждое устойство должно содержать рутинг тейбл .

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

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

Немного сумбурно получилось но если надо разясню на примере но не сегодня.

[viakon 0]

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

[Harbinger 10]

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

[vesago 0]

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

[Yura_K 0]

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

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

Изменено 15 мая, 2006 пользователем Yura_K

[AndreyMS 0]

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

[rezident 0]

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

http://www.rateos.ru/spectr433.shtml

[plombir 0]

Благодарю Всех кто откликнулся.

Пока, без комментариев...

Сижу, информацию перевариваю... :)

[Karl 0]

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

[viakon 0]

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

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

[Yura_K 0]

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

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

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

[plombir 0]

Всех благодарю за ответы!

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

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

Ещё раз, всем спасибо!

[defunct 0]

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

Ещё раз, всем спасибо!

 

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

 

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

 

В пакет можно заложить адрес получателя 1 байт и адрес передатчика 1 байт, а также номер сообщения (16-32 байт), для пресечения повторной обработки пакета.

Каждый узел сети представить потенциальным ретранслятором.

Каждый ретранслятор должен дописывать к пакету свой номер, чтобы исключить закольцовку и зацикливание сообщения, что может привести к бесконечному блужданию сообщения по сети. (дописывать номер предпочтительнее чем вводить поле TTL, как в IP, в следствии того что узлов в сети не так много и пакет сильно раздуть не получится, зато 100% пресечение повторов гарантировано).

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

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

 

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

 

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