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

[galjoen]

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

[ataradov]

Какие скорости передачи данных интересуют? Можно взять Atmel LwMesh, там по умолчанию стоимость для поиска маршрута равна по ресурсам стоимости бродкаста. И настроить сделать так, чтобы записи с таблице маршрутизации удалялись при первой же ошибке. Таким образом таблица будет просто кешем.

Реальная дальность надежной связи - 50-100 м, в идеальных условиях до 150, но это не в карьере точно При желании можно и усилить.

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

[galjoen]

Скорость небольшая. От каждого объекта передаётся порядка 50 байт примерно раз в 10 сек, всего около 100 объектов. Но получается много ретрансляторов, а в случае броадкаста это напряжно.

Обязательно нужно как то усиливать. Китайцы продают свои поделия типа DRF2617 и др. на базе CC2530, так у них реально до 500 м работает (четвертьволновая антенна в зеркале заднего вида самосвала) - пробовал. А параболы вообще на 8 км связываются, может и больше - дальше не проверял. Я понимаю, что оно не соответствует никакому стандарту (сконфигурировано на макс мощность). А уж как это Китайское чудо работает... Реально только броадкаст до 32 байт (причём обязательно без координатора в сети, а то всё заткнётся), да и то всё равно периодически затыкается без видимых причин, помогает только выкл/вкл питание (только за счёт этого и работает). Хотя такая тестовая системка (всего 6 подвижных и 1 неподвижный ZigBee) на Китайских изделиях уже успешно работает, но делать так - себя не уважать.
XBee вроде тоже можно сконфигурировать на существенно бОльшую мощность, чем по стандарту, но с ним не экспериментировал. Опасаюсь, что работать не будет вообще - там похоже всё по стандарту сделано, в отличие от того, что у Китайцев. Хотя периодические выкл/вкл питания должны помочь (заново сконфигурируются), но тогда с ретрансляцией проблемы будут (ретранслятор неожиданно пропадать может).
Но почему же у Атмела возможности увеличить мощность нет? Или я не нашёл? Честно признаться не специалист я в этом - как усилить даже не представляю.
Ещё есть 433 мГц и др. варианты, но там пока вообще не смотрел...

С LwMesh пока не разбирался.
По прикидке планирую делать так:
1. У каждого девайса имеется жёсткий адрес 1 байт (хватит, более 256 устройств в сети точно не будет).
2. Передающий и каждый ретранслирующий добавляет в посылку свой адрес.
3. Если ретранслятор видит, что его адрес в посылке уже есть, то ретранслирует эту посылку ещё 2 раза.
4. Ещё ограничение по вложенности наверное придётся сделать. Не более 50 ретрансляций в посылке (по кол-ву добавленных адресов), например.
5. Возможно и оптимизацию по излишним ретрансляциям (если прямая связь есть) сделать, но придётся запоминать маршруты недавно ретранслированных посылок. Для этого ОЗУ может не хватить, его там 8 или 16 кБ всего.
6. То, что каждой посылке отправитель присваивает уникальный TAG (точнее не скоро повторяющийся), это само собой.

[ataradov]

Но почему же у Атмела возможности увеличить мощность нет? Или я не нашёл?

Только внешними усилителями. Делать большую выходную мощность на одном чипе сложно, а мест где ее можно легально использовать без дорогого процесса сертификации не так много. Обычно аналоговые фронтенды дают +15 - +17 dB усиления. Я слышал от клиентов, что в чистом поле это работает на 2-3 км, но своими глазами не видел.

1. У каждого девайса имеется жёсткий адрес 1 байт (хватит, более 256 устройств в сети точно не будет).

Лучше оставить 2 байта и использовать аппаратный фильтр адресов.

2. Передающий и каждый ретранслирующий добавляет в посылку свой адрес.

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

3. Если ретранслятор видит, что его адрес в посылке уже есть, то ретранслирует эту посылку ещё 2 раза.

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

5. Возможно и оптимизацию по излишним ретрансляциям (если прямая связь есть) сделать, но придётся запоминать маршруты недавно ретранслированных посылок. Для этого ОЗУ может не хватить, его там 8 или 16 кБ всего.

Это дофига даже для полноценных протоколов. LwMesh может хранить маршруты для 120 устройств в 1 кБ.

[galjoen]

Обычно аналоговые фронтенды дают +15 - +17 dB усиления.

А что такое аналоговые фронтенды и где их взять? У XBee и DTK они используются? Там за счёт них такая высокая мощность получена? Понимаю, что это ламерский вопрос, но с радиосвязью до этого дело не имел.
+15 Дб - это будет даже с избытком.
А как там на 433 МГц? Там ведь разрешённая мощность, а значит и дальность, побольше.

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

Счётчик - это присваивание отправляющим каждому сообщению своего TAGа? Да, конечно, такая таблица тоже должна быть, но по ней ретранслятор не может сделать вывод кто его слышит, и вообще слышит ли его кто-нибудь.

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

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

Это дофига даже для полноценных протоколов. LwMesh может хранить маршруты для 120 устройств в 1 кБ.

9 ретрансляций (7*9=63) максимум?
Я то подумывал выделить в каждом сообщении битовое поле по числу устройств (128 устройств - 16 байт) - это позволит отправителю узнавать дошло ли его сообщение до адресата, т.е. отказаться от ACK вообще, но требует более продвинутый алгоритм работы ретрансляторов. Чтобы они понимали "туда" или "назад" идёт сообщение (по последовательности адресов ретрансляторов) и не делали излишних ретрансляций. Но что то слишком сложный алгоритм получается, и ОЗУ много нужно. А может что-нибудь и придумается...

[ataradov]

А что такое аналоговые фронтенды и где их взять?

По сути чип усилителя мощности на передачу (PA) + малошумящий усилитель на прием (LNA). Называются front end module (FEM). Например аппнот AVR2080 описывает как сделать систему с Skyworks SE2431L, но в целом все зависит от цены и возможности достать конкретный чип.

А как там на 433 МГц? Там ведь разрешённая мощность, а значит и дальность, побольше.

Я не знаю, я с 433 МГц плотно не работал.

Счётчик - это присваивание отправляющим каждому сообщению своего TAGа? Да, конечно, такая таблица тоже должна быть, но по ней ретранслятор не может сделать вывод кто его слышит, и вообще слышит ли его кто-нибудь.

А зачем ему это знать?

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

Но в это узкое место будут долбиться сразу несколько устройств.

9 ретрансляций (7*9=63) максимум?

Не понял.

[galjoen]

А зачем ему это знать?

В общих чертах опишу как я представляю представляю броадкаст между подвижными объектами.
Вот мой домодощенный, упрощённый за счёт отказа от маршрутов (не хватит ОЗУ и вычислительной мощности), алгоритм (сделаны и ещё кое-какие упрощения для простоты восприятия):
1. У каждого девайса имеется свой жёсткий N. Допустим, в сети может быть не более 256 устройств, тогда этот N будет размером в 1 байт.
2. Каждый отправляющий присваивает сообщению TAG (для примера - 2 байта), состоящий из своего фиксированного номера (1 байт) и N-ра отправленной посылки (циклический сч-к, тоже 1 байт - в реале, конечно, не так примитивно, но писать много...). По этому TAGу ретрансляторы идентифицируют посылку.
3. В каждой посылке имеется битовое поле, число бит в котором соответствует макс возможному числу устройств в сети. Т.е. если в сети может быть максимум 256 устройств, то поле будет иметь размер 32 байта. И каждый бит жёстко соответствует N устройства.
4. Отправляющий сообщение, и каждый ретранслирующий его, сбрасывает бит, соответствующий своему N, в 0. Изначально, при отправке сообщения, все биты, кроме бита отправителя, =1 (тут возможна оптимизация, но пока не будем об этом).
5. Отправляющий сообщение так же работает как ретранслятор.
6. Если девайс видит, что у принятого и отправленного им сообщение отличается битовое поле, то он производит 2 ретрансляции. Первую сразу же, а 2-ю милисекунд через 5 (так же возможна оптимизация).
7. Таким образом сообщение будет циркулировать (ретранслироваться) по сети пока в нём не окажутся сброшенными все биты, соответствующие устройствам, которые хоть кто-нибудь слышит. А устройства, которые слышат других, а их никто не слышит, поймут сложившуюся ситуацию.
8. ACK при таком алгоритме не нужен. Сообщение гарантировано будет услышано всеми девайсами, присутствующими в сети, и вернётся к отправителю со сброшенными битами всех девайсов, получившись его.
9. Сколько времени каждый девайс должен хранить сообщение (идентифицируемое по TAGу) у себя в ОЗУ - пока не решил. Скорее всего - бесконечно. Т.е. зависит от объёма выделенного ОЗУ - новое сообщение от данного девайса затирает предыдущее. Тогда объём потребного ОЗУ будет зависеть от кол-ва устройств в сети, умноженного на макс размер сообщения (без оптимизации - заранее выделенная таблица). Девайс не должен слать след. сообщение (с другим TAGом) пока не получит предыдущее сообщение со сброшенным битом желаемого приёмника, или у него не закончится таймаут. Если в сети 256 девайсов и длина сообщения со служебными битами, такими как TAG (только 1 байт) и битовое поле, равна 128 байт, то нужно 256*128=32 кБ ОЗУ.

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