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 вообще, но требует более продвинутый алгоритм работы ретрансляторов. Чтобы они понимали "туда" или "назад" идёт сообщение (по последовательности адресов ретрансляторов) и не делали излишних ретрансляций. Но что то слишком сложный алгоритм получается, и ОЗУ много нужно. А может что-нибудь и придумается...

[Aner]

Делали раньше несколько аналогичных проектов как с подвижными так и со стационарными проектами. На этих процессорах будет трудно построить сеть для подвижных объектов, проще для стационарных. Ресурса потребуется много. Для подвижных использовали ARMы. Сами протоколы достаточно сложны, хотя это на первый взгляд кажется просто, если планируете использовать хопы ( ретрансляцию). В штатах до сих пор пишут и защищают докторские по этой тематике.

Если уйти от ретрансляции, то есть вариант решения - опрашивать по кругу, до 100 устройств прямым опросом за несколько секунд на большой скорости. Дальность будет определяться мошностью, можно задействовать RSSI для управления мощностью. Решения до 1-2 Ватт есть на трансивере Si4463, можете поискать в AN-ах. Но при большой дальности нужно учитывать местность, хомистость, горая местность, и тп может не позволить иметь устойчивую связь.
Какое у вас максимальное расстояние для связи с объектами?

[galjoen]

Про сложность я уже понял. Поэтому вполне возможно, что так и придётся делать на Иридиуме. Но попытаться стОит...

Без ретрансляции никуда - карьер это дырка глубиной метров 100, точнее несколько перемещающихся дырок, разделённых кучами пустой породы, которые возвышаются метров на 50 (тоже перемещаются со временем). Стационарный ретранслятор установить возможности никакой нет.

Про Si4463 почитаю, спасибо за наводку.

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

[Aner]

Да тут сотни, десятки мегагерц не пройдут. Подойдёт диапазон 1-3 мегагерца, за счёт волновой дифракции. Но там антенны больших размеров нужны. Для покрытия 10км там меньше мощность нужна, но и диапазон тот шумный.
Ретрансляторы выход, но тоже не 100%. Нужно подумать...
C Иридиумом свои заморочки. Как с тарифом, так и со связью. Поскольку у вас карьеры, отвалы, то это сужает горизонт. Спутников не так много, чтобы покрыть и иметь непрерывную связь долго.

[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 кБ ОЗУ.

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

[Aner]

Без ACK не пройдет. Думаю вам нужно заняться и подумать на предмет динамически меняющейся топологии, её контроля и хопов. Как реагировать на выпадение из группы, как входить в группу. Возможно использовать 2-3-4 разные частоты, подумать над гарантированной синхронизацией. Предусмотреть аварийные ситуации по выпадению 1...10 объектов и реакцию динамически меняющейся топологии. И все же я бы ориентировался на ARMs однозначно, где есть запас ресурса, и максимальную скорость обмена между подвижными объектами.

[galjoen]

ACK не панацея, даже наоборот. Там весьма времязатратный механизм получается, чтобы оба поняли, что пропало - сама посылка или ACK на неё (по TAGу). А в случае постоянно изменяющейся топологии это вообще может не сработать.
Динамическая топология, вход/выпадение из групп - это оч. сложно и затратно, а главное практической пользы не принесёт, т.к. если связи с диспетчерской (через ретрансляторы) нет, то всё остальное бесполезно.
С синхронизацией по времени проблем никаких - там GPS у каждого будет.
Какой процессор использовать - большой разницы нет. ARM лучше тем, что ОЗУ достаточно имеет, а специализированный AVR - радио на борту. Если конечно такую частоту использовать. А вычислительной мощности, для вышеизложенного упрощённого алгоритма, у любого процессора с избытком.
Меня больше интересует будет ли он работать?

[Aner]

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

[ataradov]

Вы очень все усложняете. Делайте как работают броадкасты в нормальных сетях и получите результат близкий к максимально хорошему. Отдельно выделять TAG не нужно, но в жизни так и делают - всем пакетам присваивается последовательный исходящий номер (1 байт). На приеме пакеты идентифицируются по паре (исходящий адрес, счетчик). При приеме броадкаста в спец. таблице (в ZigBee она называется Broadcast Transaction Table, в LwMesh она объединена с обычной таблицей определения дублей) заводится запись для адреса и счетчика. По записи можно узнать пересылали мы этот фрейм или нет и сколько раз. Запись держится фиксированный интервал времени, который должен быть больше, чем время распространения кадра по сети, иначе возможны петли. По той же причине записи не вытесняются новыми, и если при приеме кадра таблица заполнена, то кадр просто игнорируется.

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

[galjoen]

Вы очень все усложняете.

Я пытаюсь сделать так, чтобы ACK не потребовался. Т.е. броадкаст гарантировано был бы доставлен ко всем "живым" участникам сети, и при этом автоматически бы выяснилось кто "жив" в данный момент. Накладные расходы - отражённые от границ сети сообщения (от девайсов имеющих связь только с 1 участником сети), но их будет немного и они несут функцию ACK. Забыл написать - битовое поле у всех ретрансляторов постоянно складывается по AND с битовым полем в принятых сообщениях.
ИМХО по затратам это получается лучше, чем 2 броадкаста - туда данные и назад ACK. А разруливание ситуации, когда был потерян ACK и девайс вновь посылает ту же посылку, требует введение ещё одного специального TAGа, кроме уже имеющегося (иначе ретрансляторы её зарубят).
Кроме того, за счёт того же битового поля, передающие автоматически выясняют, что произошла коллизия и были испорчены 2-е или более одновременные передачи. В случае ZigBee это не важно, а если использовать только PHY 433 МГц, например, то может оказаться весьма актуально (насколько я понял, но могу и ошибаться - пока не докурил).

Про то, что можно заводить запись на принятое сообщение, а не держать в памяти таблицу макс. возможного размера, понятно, я просто пытался изложить попроще.
Не понятно только почему записи не вытесняются? Я так считаю, что они должны вытеснятся в том случае, если отправитель тот же, а счётчик (исходящий номер) больше (с учётом перехода FF-00). А вот в противоположном случае, если исходящий N меньше, чем в уже имеющегося записи от того же устройства, нужно просто игнорировать это сообщение - маловероятно, что счётчик (исходящий номер) увеличился более чем на 127, а мы за это время не слышали ни одного сообщения от этого девайса.

[ataradov]

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

Я так считаю, что они должны вытеснятся в том случае, если отправитель тот же, а счётчик (исходящий номер) больше (с учётом перехода FF-00).

Это не вытеснение, это обновление записи, его естественно нужно делать. Нельзя заменять запись на запись с другим адресом.

[galjoen]

Я тоже не сторонник нестандартного, но тут сам случай нестандартный, похоже. Что то я в последнее время к 446 МГц склоняюсь т.к. там легально 0.5 Вт. НО скорость передачи крайне низкая, т.к. полоса узкая. Из-за этого получается, что время доставки секундами измерятся будет. А за это время топология уже может изменится, поэтому навряд ли LwMesh просто так без переделки заработает.
Но подумаю ещё, кое-какие мысли есть. Да и задача видоизменяется похоже - уже про вагонетки заговорили.

[dbush]

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

Добрый день!
Сейчас есть стек 6LoWPAN для диапазона 868 МГц. Дальность связи данного диапазона значительно больше чем у 2,4 ГГц. По мимо этого, преимущество по сравнению с ZigBee - каждый узел является маршрутизаторм. Не требуется никаких зафиксированных на одном месте маршрутизаторов. Сеть сама строится. Альянс ZigBee работает в данном направлении, но пока ничего не представил. На сайте www.sysmc.ru представлены модули поддерживающие 6LoWPAN.

[ataradov]

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

В ZigBee тоже все узлы являются маршрутизаторами если специально их не делать спящими.

Альянс ZigBee работает в данном направлении, но пока ничего не представил.

Уже опубликованы спеки на 6LoWPAN и ZigBee IP, который его использует. Ну и Smart Energy Profile 2 тоже недавно опубликовали, который является практически единственным разумным местом, где бред под названием 6LoWPAN можно применить.

[Aner]

Это все проделки тексаса, которому не терпиться быть первым в поддержке IPv6 и ICMPv6.

[ataradov]

Это все проделки тексаса, которому не терпиться быть первым в поддержке IPv6 и ICMPv6.

Так они уже не далеко не первые, компании типа Exegin, Grid2Home, Sensinode построили бизнес на этом. Они все ожидают, что SEP2.0 получит широкое распространение с минуты на минуту и они все огребут много много бабла. Проблема в том, что ожидают они уже года 2. И некоторые из ожидающих уже скопытиться успели за это время.

[Aner]

Также как и IPv6 не получила столь широких и массовых продаж и отстёгиваний.

[ataradov]

Также как и IPv6 не получила столь широких и массовых продаж и отстёгиваний.

Эти действуют умнее, они лоббируют обязательность умных счетчиков. Проблема была в том, что технически ничего не было готово, а крупные дистрибьюторы электроэнергии вполне были готовы покупать уже 2 года назад, так что сейчас может чего и получится. Электросети США в плачевном состоянии, так что способ снизить нагрузку нужен.

А умные счетчики без возможности управлять нагрузкой уже есть и сейчас, я могу у себя в личном кабинете PG&E посмотреть потребление энергии по часам/дням/месяцам.

[Aner]

Exegin, Grid2Home, Sensinode ... эти мелкие, карманные, там же с вами рядом в CA. TI мнит из себя слона и двигает все подряд без разбру, вдруг выпадет "три семерки". ... Как там погода в San Jose?

[ataradov]

Exegin в Канаде, Sensinode в Финляндии

Тут +25 - + 28, солнечно и сухо. Совсем не плохо и до океана 50 минут на машине

[Aner]

Exegin в Канаде точно. Остальные есть в USA, CA.
Sensinode Inc. ->14138 Arbolitos Dr. Poway, CA 92064
Grid2Home -> San Diego, CA 92111
Да хорошо там. Далеко от полу-лунного залива?

[dbush]

В ZigBee тоже все узлы являются маршрутизаторами если специально их не делать спящими.

Уже опубликованы спеки на 6LoWPAN и ZigBee IP, который его использует. Ну и Smart Energy Profile 2 тоже недавно опубликовали, который является практически единственным разумным местом, где бред под названием 6LoWPAN можно применить.

Если 6LoWPAN - бред, то что же тогда ZigBee?
Доступ к датчикам (счетчикам) через сокеты, на мой взгляд, шаг вперед. Отсутствие необходимости ставить выбирать место под маршрутизаторы - тоже плюс. В ZigBee у маршрутизаторов ограничена емкость на количество подключаемых узлов, а в 6LoWPAN этой проблеммы нет. Безусловно у ZigBee есть свои плюсы и минусы, так же как и у 6LoWPAN, но частотный диапазон явно 2,4 ГГц однозначно проигрывает по дальности связи.

[Aner]

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

[ataradov]

Если 6LoWPAN - бред, то что же тогда ZigBee?

Тоже бред, но в значительно меньшей степени для беспроводных сетей.

Отсутствие необходимости ставить выбирать место под маршрутизаторы - тоже плюс. В ZigBee у маршрутизаторов ограничена емкость на количество подключаемых узлов, а в 6LoWPAN этой проблеммы нет.

Вообще 6LoWPAN - это только способ сжатия заголовков и фрагментирования. Все остальное зависит от протокола маршрутизации, в последнее время стандартом является RPL. RPL подразумевает маршрутизацию всего через направленный граф и есть 2 режима хранения этого графа: только на пограничном маршрутизаторе или распределенном по сети. При распределенном методе существует очевидное ограничение на размер таблицы маршрутизации (куска графа). Это абсолютно аналогично режиму many-to-one в ZigBee - все что нужно знать устройству - путь до родителя. Только в ZigBee все это работало уже много лет назад.

Проблема со всем этим - очень мало приложений ложится на эту схему.

Безусловно у ZigBee есть свои плюсы и минусы, так же как и у 6LoWPAN, но частотный диапазон явно 2,4 ГГц однозначно проигрывает по дальности связи.

И ZigBee и 6LoWPAN могут работать во всех диапазонах.

[Aner]

Например ZigBee хорош для небольшой группы летательных аппаратов - типа стая. Которой можно управлять.

[ataradov]

Например ZigBee хорош для небольшой группы летательных аппаратов - типа стая. Которой можно управлять.

Зависит от того насколько аппараты самостоятельны без ведущего. У ZigBee время на обнаружение проблем и восстановление маршрутов сильно большое.
Никакие современные широко известные меш протоколы не предназначены для сильно мобильных устройств.

[Aner]

Программа загружается каждому своя. ZigBee используют для коррекции и поддержания группы, управление полетом группы. Скорость обмена в группе из 10...20 устраивает.

[dbush]

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

В формулу расчета дальности связи на в зоне прямой видимости используется частота. С ростом частоты дальность связи уменьшается при прочих равных. Так же, частотный диапазон 868 МГц внутри помещений имеет бОльшую дальность связи. Мощности у нас регламентированы, а направленные антенны подойдут далеко не для всех задач. Безусловно диапазон 2,4 ГГц имеет широкую полосу по сравнению с 868 МГц, но и задачи для которых предназначены данный протоколы (ZigBee и 6LoWPAN) да и в целом малопотребляющие устройства предполагают передачу небольших объемов информации.
Емкость ограничена не только группой задач, а так же служебным трафиком. При большом количестве узлов накладные расходы возрастают колоссально и для передачи полезной информации практически не остается места.
Кстати говоря, в модулях MBee со стеком ZigBee период проверки связи с родительским устройством (тот самый служебный трафик) настраивается пользователем под конкретную задачу.

[Aner]

В формулу расчета дальности связи на в зоне прямой видимости используется частота. С ростом частоты дальность связи уменьшается при прочих равных. Так же, частотный диапазон 868 МГц внутри помещений имеет бОльшую дальность связи. Мощности у нас регламентированы, а направленные антенны подойдут далеко не для всех задач. Безусловно диапазон 2,4 ГГц имеет широкую полосу по сравнению с 868 МГц, но и задачи для которых предназначены данный протоколы (ZigBee и 6LoWPAN) да и в целом малопотребляющие устройства предполагают передачу небольших объемов информации.
Емкость ограничена не только группой задач, а так же служебным трафиком. При большом количестве узлов накладные расходы возрастают колоссально и для передачи полезной информации практически не остается места.
Кстати говоря, в модулях MBee со стеком ZigBee период проверки связи с родительским устройством (тот самый служебный трафик) настраивается пользователем под конкретную задачу.

В данном аспекте обсуждения дальности связи частота не причем. С теорией спору нет, но мы тут не теоретизируем. Странно, но далее вы противоречите сами себе. Помешения всегда ограничены, сколь большими они не будут. бОльшую дальность связи привязать к конкретной частоте ну ... никак не получается В данном аспекте обсуждения! Только к мощности, антенне, чувствительности приёмника. А далее у вас эмоционально и банально.

[dbush]

В ZigBee тоже все узлы являются маршрутизаторами если специально их не делать спящими.

Уже опубликованы спеки на 6LoWPAN и ZigBee IP, который его использует. Ну и Smart Energy Profile 2 тоже недавно опубликовали, который является практически единственным разумным местом, где бред под названием 6LoWPAN можно применить.

К сожалению они пока еще не воплощенны, а всего лишь опубликованы

В данном аспекте обсуждения дальности связи частота не причем. С теорией спору нет, но мы тут не теоретизируем. Странно, но далее вы противоречите сами себе. Помешения всегда ограничены, сколь большими они не будут. бОльшую дальность связи привязать к конкретной частоте ну ... никак не получается В данном аспекте обсуждения! Только к мощности, антенне, чувствительности приёмника. А далее у вас эмоционально и банально.

Изначально вопрос стоял:
...
Понравился вариант на ATmega128RFR2, смущает только низкая максимальная выходная мощность передатчика. Какая реально дальность связи достижима? Или можно усилить?

При прочих равных условиях дальность связи у 868 МГц будет бОльшей, чем у 2,4 ГГц. Отсюда вывод: модули с имеющимся стеком 6LoWPAN партированным на CC430 обеспечат бОльшую дальность связи между двумя узлами, чем модули со стеком ZigBee на 2,4 ГГц, партированного на какой-либо кристалл. Стека ZigBee для 868 МГц еще нет.

Это если не теоритизировать.
Так же, практические измерения показали, что дальность связи между двумя модулями для диапазона 868 МГц, с выходной мощность 25 мВт (разрешенная ГКРЧ) значительно превышает дальность связи между двумя модулями для диапазона 2,4 ГГц с выходной мощностью 100 мВт.

Ваше утверждение ничем не аргументированно.

Сообщение отредактировал dbush - May 14 2013, 18:42

[Aner]

А у вас значит аргументировано. И где это? ... практические измерения показали, ... Смешно, да.
Вот вас цитирую:
... дальность связи между двумя модулями для диапазона ... значительно превышает дальность связи между двумя модулями ...
Вот ваш пустословный аргумент - значительно. Где количественная оценка? Где измеренные данные?

Да и сообщите об измерительных приборах, атненнах, параметрах приемного тракта, которыми вы делали такие измерения.
Тогда будет ясно, где вы ошибаетесь.

[ataradov]

К сожалению они пока еще не воплащены, а всего лишь опубликованы

Вы не в курсе как ZigBee альянс работает, все уже воплощенно, дока не в вакууме писалась, а срисовывалась с готовых устройств с стеков.

Стека ZigBee для 868 МГц еще нет.

У Atmel и Exegin есть.

[dbush]

А у вас значит аргументировано. И где это? ... практические измерения показали, ... Смешно, да.
Вот вас цитирую:
... дальность связи между двумя модулями для диапазона ... значительно превышает дальность связи между двумя модулями ...
Вот ваш пустословный аргумент - значительно. Где количественная оценка? Где измеренные данные?

Да и сообщите об измерительных приборах, атненнах, параметрах приемного тракта, которыми вы делали такие измерения.
Тогда будет ясно, где вы ошибаетесь.

Если Вы потратите немного своего времени на изучение основ теории распространения радиоволн, то довольно быстрой найдете формулу для расчета потерь в свободном пространстве :
= 33 + 20 * (lgF + lgD)
из формулы видно, что ослабление зависит от частоты и расстояния между точками. Так же, не сложно сделать вывод о том, что при прочих равных сигналы с более низкой частотой будут иметь меньшие потери, чем сигналы с более высокой частотой на одинаковом расстоянии. А отсюда уже, учитывая ограничение по чувствительности приемников делаем вывод, что сигналы с меньшей частотой имеют большую дальность связи, при прочих равных условиях.
Парируйте, если сможете

Вы не в курсе как ZigBee альянс работает, все уже воплощенно, дока не в вакууме писалась, а срисовывалась с готовых устройств с стеков.

У Atmel и Exegin есть.

К альянсу всегда относился с уважением. Такое количество коммерческих организаций. Просто так ничего не сделают, все должно быть взвешенно.
Возможно у Atmel есть и аппаратное и софтовое решение, но я пока в живую их не видел и ничего не могу сказать по этому поводу.
Если появится рабочий ZigBee для 868 МГц я буду очень рад

[Aner]

Если Вы потратите немного своего времени на изучение основ теории распространения радиоволн, то довольно быстрой найдете формулу для расчета потерь в свободном пространстве :
= 33 + 20 * (lgF + lgD)
из формулы видно, что ослабление зависит от частоты и расстояния между точками. Так же, не сложно сделать вывод о том, что при прочих равных сигналы с более низкой частотой будут иметь меньшие потери, чем сигналы с более высокой частотой на одинаковом расстоянии. А отсюда уже, учитывая ограничение по чувствительности приемников делаем вывод, что сигналы с меньшей частотой имеют большую дальность связи, при прочих равных условиях.
Парируйте, если сможете

Похоже вы еще студент, надеюсь не радио или физ вуза. Тогда вам простительны ошибки в формуле и ваше незнание предмета, не говоря о лабораторных которые вы не делали и практики в измерительных эхо камерах. Но если вы студент радио или физ вуза то это плохо. И вы еще не ответили на предыдущий мой вопрос, ушли в сторону.

[dbush]

Похоже вы еще студент, надеюсь не радио или физ вуза. Тогда вам простительны ошибки в формуле и ваше незнание предмета, не говоря о лабораторных которые вы не делали и практики в измерительных эхо камерах. Но если вы студент радио или физ вуза то это плохо. И вы еще не ответили на предыдущий мой вопрос, ушли в сторону.

Вы, простите, занялись словоблудием.
Здесь http://electronix.ru/redirect.php?http://a...rnye-ustrojstva есть некоторые формулы, среди которых приведены формулы для расчета потерь в свободном пространстве.
Если Вас интересует оценка, производимая у нас, то могу сказать следующее:
Качественная и количественная оценка дальности связи проводилась нами на отладочных наборах Texas Instruments и модулях нашей разработки. Реальные полученные данные отображены в документации. Качественная оценка показала, что внутри одного и того же помещения модули диапазона 868 МГц (работая на 25 мВт) обеспечивают связь между 4 этажами, в то время как модули диапазона 2,4 ГГц только между двумя (работая на 100 мВт).

Вы не в курсе как ZigBee альянс работает, все уже воплощенно, дока не в вакууме писалась, а срисовывалась с готовых устройств с стеков.

У Atmel и Exegin есть.

Посмотрел, действительно на сайте альянса есть информация о ZigBee IP и т.д. Только датировано 27 марта. То есть за 1,5 месяца Atmel успел перенести новый стек на свой кристалл? Сомнительно. Скорее - это какой-то свой проприетарный стек (как у DIGI). Хотя было бы интересно покрутить в руках.

Сообщение отредактировал dbush - May 15 2013, 06:32

[ataradov]

Посмотрел, действительно на сайте альянса есть информация о ZigBee IP и т.д. Только датировано 27 марта. То есть за 1,5 месяца Atmel успел перенести новый стек на свой кристалл? Сомнительно. Скорее - это какой-то свой проприетарный стек (как у DIGI). Хотя было бы интересно покрутить в руках.

При чем тут дата публикации? Atmel - член альянса, мы этот стандарт писали совместно с другими компаниями, и писался он естественно с уже реально работающей эталонной реализации. С этой же эталонной реализацией (Golden Unit) происходит сравнение при сертификации.

У Атмела своего стека ZigBee IP нет, есть партнерство с Sensinode и их стек уже сейчас можно скачать через Atmel Gallery в Atmel Studio 6.1.

[dbush]

При чем тут дата публикации? Atmel - член альянса, мы этот стандарт писали совместно с другими компаниями, и писался он естественно с уже реально работающей эталонной реализации. С этой же эталонной реализацией (Golden Unit) происходит сравнение при сертификации.

У Атмела своего стека ZigBee IP нет, есть партнерство с Sensinode и их стек уже сейчас можно скачать через Atmel Gallery в Atmel Studio 6.1.

Возможно, я не спорю. И еще раз повторюсь, интересно было бы подержать в руках отладочный набор, что бы в этом убедиться. Но в России пока не видел. Да и российские дилеры дискредитировали Atmel, демонстрируя муляжи ZigBee модулей.

Сообщение отредактировал dbush - May 15 2013, 07:21

[ataradov]

Да и российские дилеры дискредитировали Atmel, демонстрирую муляжи ZigBee модулей.

Можно подробнее об этом? Про муляжи в первый раз слышу, не сами же они их сделали?

[vladec]

У Atmel есть доступный для скачивания стек Zigbee - BitCloud ( http://www.atmel.com/tools/BITCLOUD-ZIGBEEPRO.aspx ) в том числе и на 868МГц. Просто, если захотите использовать в реальных разработках, то проект должен быть максимально подогнан под их отладочные платы, поскольку BitCloud очень сильно "заточен" на их аппаратные конфигурации.

[dbush]

Можно подробнее об этом? Про муляжи в первый раз слышу, не сами же они их сделали?

Один из наших клиентов (завод по производству электросчетчиков) рассказывал, что к ним приезжали представители официального дилера Atmel. Демонстрировали работу ZigBee модулей на микросхеме Atmel. Оставили. Оказалось, что это просто муляжи, эмитирующие работу сети подмаргиванием светодиодов. После этого клиент отказался от Atmel и нацелился на Texas Instruments.

[Pasha_a13]

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

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

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

[ataradov]

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

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

[x893]

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

[Pasha_a13]

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

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

[ataradov]

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

[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 устройств, потерь не видел ни разу. Из такой массы хоть один да будет принят всеми.

[Pasha_a13]

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

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

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

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

[ataradov]

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

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

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

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

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

[Pasha_a13]

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

[jcxz]

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

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

[ataradov]

В ZigBee координатор вроде как нужен только в начальный момент времени для сборки сети.

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

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

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

[Pasha_a13]

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

Я прочитал документацию по 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

[ataradov]

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

Все ответы ожидаются NWK_ROUTE_DISCOVERY_TIMEOUT мс.
По истечении этого времени если не было принято ни одного ответа, то запрос подтверждается со статусом NWK_NO_ROUTE_STATUS. Никаких попыток повторно послать запрос не производится - приложение само может это сделать если хочет.
Так же можно раскомментировать строку 353 в nwkRouteDiscovery.c, тогда первый же принятый маршрут будет использован для отправки данных, но остальные ответы все-равно будут приняты для поиска более оптимального пути. Недостаток - пакету придется пробиваться сквозь тучу броадкастов от route discovery.

Второй вопрос - "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?

В native route discovery нет route request и route reply кадров. Каждый кадр сам себе пробивает дорогу - если маршрут не известен, то он просто отправляется с MAC Dst = 0xffff (broadcast). Таким образом когда кадр доходит до назначения маршрут в одну сторону известен. И чтобы завершить поиск маршрута (найти маршрут назад) отправляется обычное сетевое подтверждение, даже если подтверждение не запрашивали. Так как к подтверждениям применяются те же правила, оно самим фактом доставки прокладывает маршрут.

[Pasha_a13]

Все ответы ожидаются NWK_ROUTE_DISCOVERY_TIMEOUT мс.

Спасибо за такой быстрый ответ!

Тоесть NWK_ROUTE_DISCOVERY_TIMEOUT это фиксированная величина (1000мс) независимо от количества узлов и скорости передачи данных между узлами? Просто ведь если в сети например 300 узлов, задержка перед ретрансляцией пакета в диапазоне 1..32 мс....пусть мы берем плохой вариант - например средняя задержка 20 мс+5мс(сам пакет)=25 мс. Пусть топология сети выстроена таким образом что она растянута вдоль одной какой-то оси, т.е. узлы выстроены практически в линию. При этом даже если узел назначения будет находиться на расстоянии 50 узлов от координатора, то задержка от момента отправки запроса координатором до момента получения route reply составит 50*25мс*2(туда-обратно)=2500мс.
Или подразумевается что пользователь при настройке системы сам устанавливает NWK_ROUTE_DISCOVERY_TIMEOUT исходя из топологии сети и приблизительно оценив возможную задержку?

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

Запрос подтверждается это имеется ввиду что уровень приложения получит ответ от более низкого уровня а не от другого устройства?

Так же можно раскомментировать строку 353 в nwkRouteDiscovery.c, тогда первый же принятый маршрут будет использован для отправки данных, но остальные ответы все-равно будут приняты для поиска более оптимального пути. Недостаток - пакету придется пробиваться сквозь тучу броадкастов от route discovery.

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

В native route discovery нет route request и route reply кадров. Каждый кадр сам себе пробивает дорогу - если маршрут не известен, то он просто отправляется с MAC Dst = 0xffff (broadcast).

Я уже перечитал первый абзац и понял что недопонял сходу по поводу отсутствия отдельной процедуры поиска пути - подвело мое не сильно хорошее знание английского
Из каких соображений было выбрано именно чтобы целый пакет пробивал себе путь? Ведь в таком случае пакет может быть довольно большой(много данных) и в процессе пробивания дороги больше вероятность что он побьеться да и больше ж времена передачи пакета. Ведь вроде как удобнее чтобы сначала найти путь а потом юникастом отправить данные к назначению.

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

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

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

[ataradov]

Или подразумевается что пользователь при настройке системы сам устанавливает NWK_ROUTE_DISCOVERY_TIMEOUT исходя из топологии сети и приблизительно оценив возможную задержку?

Именно это и подразумевается. Поэтому оно и вынесено в конфигурационный параметр, а не упрятано в исходниках.

Запрос подтверждается это имеется ввиду что уровень приложения получит ответ от более низкого уровня а не от другого устройства?

Нет. На уровне приложения есть возможность запросить подтверждение (NWK_OPT_ACK_REQUEST). Если оно запрошено, то принимающая сторона всегда посылает ответ. Если не запрошено, то ответ будет все-равно послан если nwkDst==<адрес устройства назначения>, а macDst= 0xffff (эта комбинация означает Native Route Discovery). В этом случае запрашивающая сторона ждать ответа не будет, и он просто будет проигнорирован, но как результат его прохождения будет найден маршрут.

Я понял что узел назначения приняв пакет route discovery от одного из узлов ожидает

На route discovery узлы отвечают сразу после приема. Часть может и потеряется, часть доедет. На практике все доходить как нужно. Туча броадкастов не так страшна как кажется.

Из каких соображений было выбрано именно чтобы целый пакет пробивал себе путь?

Из опыта. На практике кадры почти не бьются никогда, не зависимо от их размера.

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

Нет. Бит подтверждения - это именно бит подтверждения. Тот факт, что Ack используется для прокладки маршрута - это просто для удобства. Это могла быть совершенно независимая команда, но весь код для отправки Ack-ов и так есть, почему бы его не использовать?

[Pasha_a13]

Из опыта. На практике кадры почти не бьются никогда, не зависимо от их размера.

Вот тут наверное главный момент кроется почему у меня возникли проблема с броадкаст пакетами в моем алгоритме. Где-то я неправильно реализовал сам алгоритм отправки-ретрансляции пакетов.
Подскажет пожалуйста как на нижнем уровне происходит отправка-ретрансляция броадкаст(либо других) пакетов?
Например мы приняли броадкаст пакет и нам его нужно ретранслировать дальше. При этом мы выбираем случайную задержку а по истечении времени задержки просто посылаем пакет либо по истечении времени задержки мы оцениваем свободу канала(например по наличию несущей) и если она занята то увеличиваем задержку и снова ждем.
Либо мы постоянно смотрим наличие несущей...если она есть, то отсчет задержки приостанавливается, когда она исчезает, то продолжается отсчет?
Просто у меня были проблемы с определением несущей и я ее не задействовал а только оперировал с задержками. И у меня получались наложения пакетов (я смотрел контрольным приемником все пакеты и видел что происходит явное наложение )

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

[ataradov]

Подскажет пожалуйста как на нижнем уровне происходит отправка-ретрансляция броадкаст(либо других) пакетов?

Atmel-овские радио в соответствующем режиме всегда слушают канал, делают небольшую (порядка десятков мкс, единиц мс, прогрессивно увеличивающуюся с числом повторов) задержку если занято пробуют снова. Если за несколько повторов (4 по-умолчанию) не получилось отправить, то они сдаются и устанавливают соответствующий статус.

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

Если радио так не может, то нужно то же самое делать программно. Но тут есть туча тонкостей по времянкам и порогам наличия сигнала, которые в IEEE 802.15.4 хорошо выглажены, так что настройки по-умолчанию отлично работают в большинстве случаев.

Сообщение отредактировал Taradov Alexander - Jul 30 2013, 21:10

[Pasha_a13]

Александр, спасибо Вам большое! Понял свои ошибки, буду пытаться их исправлять.

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

[ataradov]

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

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

А что за радио у вас используются?

[Pasha_a13]

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

[Pasha_a13]

В процессе дальнейшей работы над ретрансляцией возникла проблема связанная с асимметричностью каналов - на выходах передатчиков при одинаковых настройках программных мощности на выходе отличаются, а также отличаются входные параметры приемных трактов (возможно связано с разбросом параметров индуктивностей-емкостей).
В результате получается следующая ситуация - например есть три узла:
узел 1 - координатор,
узлы 2 и 3 - конечные устройства.
Узел 2 - промежуточный узел, ретранслятор, находиться фактически на промежутке между узлами 1 и 3.
Когда узел 1(координатор) выполняет поиск узла 3, то пакет долетает до узла 3, однако у узла 3 передатчик чуток слабее и пакет от узла 3 не достает немного до координатора.
В итоге получается последовательность - пакет ушел от узла 1, его приняли узлы 2 и 3. При этом узел 2 готовиться его ретранслировать а узел 3 готовиться ответить. Получается в большинстве случаев(наскоьлко я вижу по информации с логгера) что узел 2 начинает ретранслировать пакет приблизительно в тот момент когда узел 3 еще не ответил на пакет а находиться в режиме ожидания освобождения канала и не принимает пакеты. И в итоге пакет от ретранслирующего узла теряеться а пакет от конечного узла не долетает до координатора.
Подобная ситуация была бы если бы на промежутке между узлом 1 и 3 были два ретранслятора...все равно наиболее вероятно что узел назначения успевал бы ответить только на один запрос пути.
Или тут есть какая-то особенность с временными задержками чтобы обеспечить приход всех ретранслированных пакетов к узлу назначения?
К сожалению увеличить приемный буфер и создать очередь принятых-готовых к отправке пакетов не представляется возможным в результате ограничения по ресурсам контроллера(ОЗУ).
Вообще я так понимаю что правильно было бы сделать чтобы конечное устройство принимало и отвечало на все без исключения пакеты от ретрансляторов-координатора, а уже потом когда все эти ответы придут к координатору то он, выждав предварительно некоторое время чтобы пришли все пакеты, выбрал уже среди них оптимальный путь?
Подскажите пожалуйста какие можно придумать еще пути выхода из сложившейся ситуации?
Замерять характеристики каналов(уровень сигнала на входе) во время приема пакетов проблематично, иначе бы можно было по этим параметрам вычислять более оптимальный путь и отсекать заведомо слабые каналы связи. Да и впринципе по пути к узлу назначения мне это особо ничего не даст, т.к. туда в данном случае канал получается довольно хороший, туда пакеты доходят...а вот назад...

Сообщение отредактировал Pasha_a13 - Aug 1 2013, 16:09

[ataradov]

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

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

[Pasha_a13]

я уже понял что как ни крути придется добавлять буфер принятых пакетов.
Я немного запутался с передачей пакета - ведь используется csma-ca алгоритм и перед передачей пакета сначала выдерживается пауза случайная а уже потом он передаеться. Или ответ на поиск маршрута узлом назначения передается без этой задержки как можно быстрее?

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

[ataradov]

CSMA/CA - это не пауза, это то самое прослушивание канала в течение единиц мкс и быстрая передача если канал свободен. Паузы нужны для повторных попыток.

Или это лишнее будет?

Так и нужно делать для AODV- маршрутизации.
Поля forwardLinkQuality, reverseLinkQuality в NwkRouteDiscoveryTableEntry_t в nwkRouteDiscovery.c - это накопленная прямая и обратная стоимость маршрута. Какой именно критерий брать за стоимость - это сами выбирайте. Это может быть уровень сигнала, число хопов, накопленная история по качеству связи или что-то еще.

[Pasha_a13]

Понял. Спасибо.
Я думал за счет задержек на ретрансляторах получить время для обработки пакетов узлом назначения, т.е. пока один ретранслятор передаст, узел назначения обработает-вернет ответ, а потом уже прилетит следующий пакет от другого ретранслятора и узел назначения уже будет готов его обработать.
У меня пока я смотрю получается сильное рассогласование по временным параметрам.
Попробую на днях всетаки переделать алгоритм и добавить буфера приема-передачи на несколько пакетов.

[ataradov]

Эти задержки тоже нужны.
Алгоритм передачи кадра:
1. Задержка на сетевом уровне (10-50 мс), можно только для броадкастов.
2. Задержка (10 мкс - 5 мс, причем верхняя граница плавно увеличивается с номером повтора начиная с совсем маленькой цифры, типа 20 мкс)
3. Слушаем канал как можно короче, но достаточно долго, чтобы определить наличие других передатчиков.
4. Если уровень ниже порога, то передаем кадр и выходим.
5. Если уровень выше порога: если число попыток < 4 то goto 2 иначе кадр не возможно отправить (Channel Access Failure).

ZigBee радио делают 2-5 автоматически.

[Pasha_a13]

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

Так а на сетевом уровне задержка все равно остается 10-50 мс или в случае ответа на броадкаст без этой большой задержки нужно передавать?

Эти задержки тоже нужны.
Алгоритм передачи кадра:
1. Задержка на сетевом уровне (10-50 мс), можно только для броадкастов.
2. Задержка (10 мкс - 5 мс, причем верхняя граница плавно увеличивается с номером повтора начиная с совсем маленькой цифры, типа 20 мкс)
3. Слушаем канал как можно короче, но достаточно долго, чтобы определить наличие других передатчиков.
4. Если уровень ниже порога, то передаем кадр и выходим.
5. Если уровень выше порога: если число попыток < 4 то goto 2 иначе кадр не возможно отправить (Channel Access Failure).

ZigBee радио делают 2-5 автоматически.

Спасибо большое за временные характеристики и за алгоритм! А то я когда просматривал спецификацию на физический уровень, то не все временные параметры нашел.

[ataradov]

Так а на сетевом уровне задержка все равно остается 10-50 мс или в случае ответа на броадкаст без этой большой задержки нужно передавать?

Все с задержками.

Спасибо большое за временные характеристики и за алгоритм! А то я когда просматривал спецификацию на физический уровень, то не все временные параметры нашел.

Времена очень приблизительные и верны для 2.4 ГГц. В IEEE 802.15.4 все задержки описаны в символах, так как длительность символа зависит от вида модуляции. В этом очень сильное преимущество использования стандартных радио - все это уже было посчитано и смоделировано умными дядями из IEEE. Для 2.4 GHz O-QPSK модуляции один символ = 16 мкс.

[Pasha_a13]

Добрый день, Александр!
Я пошел немного по другому пути - чтобы не переделывать сильно алгоритм у меня узел назначения, приняв броадкаст поиска пути, ожидает некоторое время остальных броадкастов, складывая их. Затем спустя это время он вываливает ответы на эти броадкасты по тем маршрутам по которым они пришли. А координатор ожидая ответ на поиск пути складывает тоже все ответы а потом уже перебираю эти все ответы с маршрутами в поисках наиболее оптимального с моей точки зрения.
Пока что работает нестабильно, но все равно это уже лучше чем то что было
Спасибо Вам за помощь!

[Pasha_a13]

Добрый вечер!
Возник такой вопрос связанный с маршрутизацией пакетов.
Например у нас узлы расположены как показано на рисунке:

Штриховкой показаны зоны покрытия узлов.
Узел 0 начинает искать узел 4. При этом он посылает броадкаст.
Его слышит только узел 1, который в свою очередь ретранслирует этот броадкаст дальше.
Далее ретранслированный узлом 1 пакет принимают узлы 2 и 3, которые в свою очередь ретранслируют пакет дальше.
Однако нюанс в зонах покрытия - узлы 1 и 3 находятся на краях зон покрытия друг друга и соответственно качество этого участка варьируется довольно сильно от окружающей радиочастотной обстановки, т.к. уровень приема на границе шумов фактически.
Однако броадкаст от узла 1 доходит до узла 3 быстрее, т.к. узел 2 ретранслирует пакет, а следовательно вносит задержку.
По принципам маршрутизации броадкаст пакетов узел 3 ретранслирует броадкаст полученный от узла 1 и дальше отсекает все остальные броадкасты, в том числе и от узла 2.
В итоге путь от узла 0 до узла 4 выстраивается по цепочке 0-1-3-4, хотя с точки зрения качества связи пожалуй лучше было бы выстроить по пути 0-1-2-3-4...хоть узел 2 и увеличивает путь, однако обеспечивает более качественную связь.
Как решаются подобного рода проблемы в беспроводных сетях?
Дело в том что у меня фактически именно топология где нет возможности размещать большое количество узлов чтобы у пакета была большая вариативность маршрута(т.к. каждый узел это деньги), а в основном узлы расположены по цепочке.

[ataradov]

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

Тут много не верных предположений.
1. Для поиска маршрута используется не настоящий броадкаст, а локальный, который принимактся только узлами, которые в непосредственной зоне слышимости.
2. Каждое принимающее устройство генерирует новый Route Discovery Request, так как в нем меняется полезная нагрузка - суммарный LQI или число хопов через которые прошел пакет или любая другая метрика показывающая качество связи. Для фиксации повторов используется Route Discovery Table, из которой по адресу источника и назначения ясно участвуем мы уже в этом поиске или еще нет.
3. Устройство назначения принимает все ответы не зависимо от времени их прихода (в переделах максимального времени поиска маршрута, конечно).
4. Устройство назначения отвечает только если у нового пакета показатель качества (всего маршрута) лучше чем у того, на который ответили ранее. Таким образом ответ на самый лучший маршрут уйдет последним.

[Pasha_a13]

Тут много не верных предположений.
1. Для поиска маршрута используется не настоящий броадкаст, а локальный, который принимактся только узлами, которые в непосредственной зоне слышимости.
2. Каждое принимающее устройство генерирует новый Route Discovery Request, так как в нем меняется полезная нагрузка - суммарный LQI или число хопов через которые прошел пакет или любая другая метрика показывающая качество связи. Для фиксации повторов используется Route Discovery Table, из которой по адресу источника и назначения ясно участвуем мы уже в этом поиске или еще нет.

я наверное просто неправильно сформулировал по поводу route request.
Узел 0 шлет RREQ, его принимает узел 1, изменяет в нем число хопов, фиксирует качество связи, фиксирует этот пакет в своей таблице маршрутизации и сам снова генерирует RREQ с тем же порядковым номером и тем же NWKsrc, однако с новым числом хопов.
Далее этот пакет принимают узлы 2 и 3, каждый из которых так же в свою очередь изменяет пакет, фиксируют в таблицах и отправляют далее.
Однако узел 3 приняв пакет от узла 1 запомнил комбинацию "номер пакета+NWKsrc" и уже не пропустит пакет от узла 2, т.к. у него будет такая же комбинация "номер пакета+NWKsrc" как и у пакета от узла 1, да и в таблице узел 3 зафиксирует что когда нужно будет пересылать пакет с NWKdst=0, то его нужно отправлять узлу 1....а если он примет и перешлет еще пакет от узла 2, то тогда затрется эта запись.
Наверное я тут немного не до конца понял процесс фиксации записей в таблице...

Для фиксации повторов используется Route Discovery Table, из которой по адресу источника и назначения ясно участвуем мы уже в этом поиске или еще нет.

Я не понял что Вы имеете ввиду под тем участвуем ли мы уже в поиске или нет. Если можно, опишите пожалуйста поподробнее.

Я просто не соображу как фиксируются повторы в таблице. Ведь вроде бы в таблице фиксируется узел источник NWKsrc и NextHop к этому узлу.

[ataradov]

Узел 0 шлет RREQ, его принимает узел 1, изменяет в нем число хопов, фиксирует качество связи, фиксирует этот пакет в своей таблице маршрутизации и сам снова генерирует RREQ с тем же порядковым номером и тем же NWKsrc, однако с новым числом хопов.

Нет, так делать нельзя ни в коем случае. Если содержимое изменилось - это новый кадр с новым порядковым номером.

Я не понял что Вы имеете ввиду под тем участвуем ли мы уже в поиске или нет. Если можно, опишите пожалуйста поподробнее.

Теперь, так как номер изменился, все остальные устройства тоже примут этот запрос еще раз. Чтобы его не передавать еще раз на время поиска маршрута в Route Discovery Table (это не тоже самое что Routing Table и Dplicate Rejection Table) создается запись, ключом в этой таблице является пара (NwkSrc, NwkDst), где NwkSrc - адрес запрашивающего узла, NwkDst - адрес узла до которого ищем маршрут. Причем такая запись будет всегда уникальна, так как запрашивающее устройство не будет слать повторный запрос пока на нем самом есть запись в Route Discovery Table о том, что оно уже ищет этот маршрут.

Я просто не соображу как фиксируются повторы в таблице. Ведь вроде бы в таблице фиксируется узел источник NWKsrc и NextHop к этому узлу.

Уже как минимум 3 таблицы, уточняйте какая имеется в виду.

[DASM]

Например ZigBee хорош для небольшой группы летательных аппаратов - типа стая. Которой можно управлять.

ОФФ - скоро уже пора будет делать ракеты самонаведения по таким стаям

[Pasha_a13]

Я делал так что узел 0 шлет RREQ: (NWKsrc=0, MACsrc=0, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=0 )
принял узел 1, сделал у себя запись (destination = NWKsrc(из пакета=0), nextHop = MACsrc(из пакета=0)),
посылает дальше RREQ: (NWKsrc=0, MACsrc=1, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=1 ),
принял узел 2 сделал у себя запись (destination = NWKsrc(из пакета=0), nextHop = MACsrc(из пакета=1)),
посылает дальше RREQ: (NWKsrc=0, MACsrc=2, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=2),
в это же время пакет принял и узел 3, сделал у себя запись (destination = NWKsrc(из пакета=0), nextHop = MACsrc(из пакета=1)),
посылает дальше RREQ: (NWKsrc=0, MACsrc=3, NumberPacket=1, NWKdst=4, MACdst=0xFF, hop_cnt=2),
просто дальше в моем варианте получается если узел 3 принял ретранслированный пакет от узла 2, то фактически ему нужно затереть запись (destination (=0), nextHop (=1)) и вместо нее будет запись (destination(=0), nextHop (=2)).
Однако когда будет идти RREQ от узла 4 через узел 3, то он пойдет только по последнему пути, т.к. через 2, а не через 1.

Теперь, так как номер изменился, все остальные устройства тоже примут этот запрос еще раз. Чтобы его не передавать еще раз на время поиска маршрута в Route Discovery Table (это не тоже самое что Routing Table и Dplicate Rejection Table) создается запись, ключом в этой таблице является пара (NwkSrc, NwkDst), где NwkSrc - адрес запрашивающего узла, NwkDst - адрес узла до которого ищем маршрут. Причем такая запись будет всегда уникальна, так как запрашивающее устройство не будет слать повторный запрос пока на нем самом есть запись в Route Discovery Table о том, что оно уже ищет этот маршрут.

Начинаю понимать что я упустил основной момент - именно что есть 3 таблицы а не одна....

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

[ataradov]

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

AODV - это только поиск маршрута, к нему относится только одна таблица - Route Discovery Table.

Независимо от способа поиска маршрута (хоть руками вбивайте) для маршрутизации необходима Routing Table. AODV в эту таблицу заносит информацию о найденном маршруте.

И независимо даже от наличия маршрутизации требуется Duplicate Rejection Table - для удаления повторных кадров.

Я не знаю описано-ли все это где-нибудь в одном месте. Скорее всего если и описано, то это академический труд из которого что-то понять сложно.

[Pasha_a13]

AODV - это только поиск маршрута, к нему относится только одна таблица - Route Discovery Table.

Независимо от способа поиска маршрута (хоть руками вбивайте) для маршрутизации необходима Routing Table. AODV в эту таблицу заносит информацию о найденном маршруте.

И независимо даже от наличия маршрутизации требуется Duplicate Rejection Table - для удаления повторных кадров.

Я не знаю описано-ли все это где-нибудь в одном месте. Скорее всего если и описано, то это академический труд из которого что-то понять сложно.

Теперь мне понятно почему я нашел информацию только относительно одной таблицы. У Перкинса в RFC3561 было написано что-то по поводу того что seq# отвечает за свежесть маршрута и т.п., что нужно следить за этим, но как именно и что делать я так толком и не понял.
а в самом zigbee при поиске маршрута эти все вещи учитываются? там тоже 3 таблицы используются?
Хотя чипы для zigbee вроде как только физический уровень обеспечивают типа задержек при передаче и т.п., а остальное программист должен делать?

Сообщение отредактировал Pasha_a13 - Aug 5 2013, 20:01

[ataradov]

У Перкинса в RFC3561 было написано что-то по поводу того что seq# отвечает за свежесть маршрута и т.п., что нужно следить за этим, но как именно и что делать я так толком и не понял.

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

а в самом zigbee при поиске маршрута эти все вещи учитываются? там тоже 3 таблицы используются?

В ZigBee Duplicate Rejection Table разделена на две - Duplicate Rejection Table для дубликатов и Broadcast Transaction Table для отслеживания состояния броадкастов, так как там для них сложные правила пересылки (некоторые повторяются 3 раза, некоторые повторяются 2 раз, некоторые совсем не повторяются, и есть еще Passive Ack). В ZigBee есть еще туча других таблиц (Neighbour Table, например).

Lightweight Mesh - это попытка объединить функции всех этих таблиц в абсолютно минимальный набор.

Хотя чипы для zigbee вроде как только физический уровень обеспечивают типа задержек при передаче и т.п., а остальное программист должен делать?

Да, для этого производители и выпускают стеки.

Чипы реализуют физический уровень IEEE 802.15.4. ZigBee - это один из многих протоколов использующих этот уровень.

[Pasha_a13]

Lightweight Mesh - это попытка объединить функции всех этих таблиц в абсолютно минимальный набор.

Читаю документацию по lightweight mesh и вспоминаю что я когда начинал заниматься этой темой то именно рисунки 4-8...4-13 из множества литературы по маршрутизации самым доходчивым образом показывали как заносить данные в таблицу.
Завтра постараюсь понять как в lightweight mesh решается проблема на которую я наткнулся(имею ввиду ту картинку с 5-ю узлами), потому что уже понял что сделать полноценную маршрутизацию со всеми таблицами, оптимальными путями и т.п. будет для меня явно неподъемно.
А у меня еще такой вопрос - а как во всех этих протоколах беспроводных передаются длинные пакеты?
я наткнулся на проблему что у меня скорость передачи порядка 19кБит, при этом у меня есть длинные пакеты с информацией длиной порядка 40 байт. При этом по времени эта посылка занимает где-то около 40мс(между соседними узлами, а если с ретрансляцией то до 200мс и больше). И получается что короткие посылки(порядка 15 байт) проходят практически все, а вот длинные посылки бьются. Мне просто нужно передавать массив данных порядка 200-300 байт и разбивать их на пакеты по 5-10 байт вроде как-то не хочется.
Или в таком случае для таких объемов данных нужно поднимать скорость передачи?

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

[ataradov]

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

Ограничение на физический размер кадра - 127 байт (1 байт на размер). После заголовков в LwMesh остается 109 байт полезной нагрузки.

Для передачи больших объемов данные разбиваются на мелкие куски и передаются отдельно.

[Pasha_a13]

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

я просто сегодня занимался с радиосистемой, пакеты бегали, изредка бились, но черед некоторое время по соседству включили пилораму. После ее включения длинные пакеты у меня перестали проходить в большинстве случаев . Частоты у меня 300-400МГц. Вроде как не должна пилорама влиять на это все, но видать где-то всетаки какие-то проблемы возникают(устройства питались от батарей, потому на помехи по сети не могу грешить).


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

[ataradov]

я просто сегодня занимался с радиосистемой, пакеты бегали, изредка бились, но черед некоторое время по соседству включили пилораму. После ее включения длинные пакеты у меня перестали проходить в большинстве случаев . Частоты у меня 300-400МГц. Вроде как не должна пилорама влиять на это все, но видать где-то всетаки какие-то проблемы возникают(устройства питались от батарей, потому на помехи по сети не могу грешить).

На диапазон 2.4 GHz некоторые микроволновки влияют, но та, что у нас в офисе никакого значительного влияния не оказывает. Вообще на 2.4 обычно сравнительно чисто, только Wi-Fi в непосредственной близости уровень шумов поднимает, но на качество связи это мало влияет.

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

И по всей видимости помеха ловит пакет где-то во время передачи.

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

У нас клиенты использовали 900 MHz радио на стройке для автоматизации всего и вся - полет нормальный, хотя и сварка рядом и много железа ездит.

[Pasha_a13]

Александр, добрый день!
Посидел поразбирался немного с atmel lightweight mesh и у меня возникли ряд вопросов.
Насколько я понял после принятия пакета смотрится наличие записи в таблице маршрутизации для nwkSrcAddr пришедшего пакета. Если запись не найдена, то она создается. В эту же запись заноситься и параметр качества канала LQI.
При этом если например у нас есть такая топология(цифры в разрывах стрелок обозначают показатель качества данного отрезка канала):

Когда узел 0 начинает поиск пути к узлу 6, то он посылает широковещательные пакеты, которые пройдя по путям 0-1-5, 0-2-5, 0-3-4-5 все проходят через узел 5, но в результате в таблице маршрутизации узла 5 остается лишь одна запись, в которой nextHop=4, т.к. у этого пути максимальное суммарное число LQI и обратные пакеты ответа (если они немного задержаться в узле 6), все пойдут только по этому пути к узлу 0, независимо от того пути по которому они изначально пришли к узлу 5.
Я правильно понимаю?
И еще вопрос - я так понял учитывается только полный LQI всего пути до узла, который заносит это в свою таблицу маршрутизации и выбирает nextHop исходя из максимального значения LQI. А как учитывается ситуация когда например весь канал довольно с хорошим качеством, но есть один участок между двумя какими-то из его узлов где плохие условия приема, но за счет большего количества узлов по пути набегает большее значение LQI...или я неправильно понял как именно считается LQI...

Сообщение отредактировал Pasha_a13 - Aug 7 2013, 17:34

[ataradov]

Я правильно понимаю?

Если речь идет о простом методе поиска маршрута (не AODV), то суммарная стоимость маршрута не считается, просто локально каждый сегмент берет в качестве узла назначения узел с максимальным LQI. Глобально этот алгоритм не оптимален, соответственно. В данном случае 5 в сторону 0 выберет узел 1 или 2.

AODV считает суммарный LQI, только это не арифметическая сумма, а произведение LQI отмасштабированных до диапазона 0-1. LQI еще нелинейно трансформируются чтобы отражать реальную вероятность доставки кадра через сегмент, тогда произведение вероятностей - это вероятность доставки через весь маршрут.
AODV будет использовать узел 4.

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

См. ответ про вероятности.

[Pasha_a13]

а в функции nwkRouteFrameReceived(frame) какой алгоритм используется?
я просто не уловил как тут переключается алгоритм поиска маршрута.

[ataradov]

а в функции nwkRouteFrameReceived(frame) какой алгоритм используется?
я просто не уловил как тут переключается алгоритм поиска маршрута.

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

Если NWK_ENABLE_ROUTE_DISCOVERY включена, то функция ничего не делает - это AODV, так как при AODV маршруты находятся один раз и позже не оптимизируются.
Если NWK_ENABLE_ROUTE_DISCOVERY выключена, то это простой алгоритм, который смотрит только на LQI принятого кадра не зависимо от того как он сюда добрался.

[Pasha_a13]

Если речь идет о простом методе поиска маршрута (не AODV), то суммарная стоимость маршрута не считается, просто локально каждый сегмент берет в качестве узла назначения узел с максимальным LQI. Глобально этот алгоритм не оптимален, соответственно. В данном случае 5 в сторону 0 выберет узел 1 или 2.

AODV считает суммарный LQI, только это не арифметическая сумма, а произведение LQI отмасштабированных до диапазона 0-1. LQI еще нелинейно трансформируются чтобы отражать реальную вероятность доставки кадра через сегмент, тогда произведение вероятностей - это вероятность доставки через весь маршрут.
AODV будет использовать узел 4.


См. ответ про вероятности.

Я понял насчет вероятности.
Упустил момент насчет того что выбирается максимальное из LQI на последнем участке, я подумал изначально что это полный LQI всего пути учитывается и исходя из него выбирается.
Но вообще идея получается в том что не конечный и не начальный уровень выбирает какой из путей для него самый оптимальный, фактически промежуточные узлы сами отсеивают менее хорошие пути и такие узлы как, например , 5, через которые проходят все маршруты, берут на себя роль выбирающего обратный маршрут узла. Так?

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

Если NWK_ENABLE_ROUTE_DISCOVERY включена, то функция ничего не делает - это AODV, так как при AODV маршруты находятся один раз и позже не оптимизируются.
Если NWK_ENABLE_ROUTE_DISCOVERY выключена, то это простой алгоритм, который смотрит только на LQI принятого кадра не зависимо от того как он сюда добрался.

уже увидел #ifNdef в начале функции
void nwkRouteFrameReceived(NwkFrame_t *frame). Упустил этот момент.

[ataradov]

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

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

[Pasha_a13]

Я правильно понял последовательность вызова процедуры поиска маршрута при разрешенном route discovery:
void nwkTxFrame(NwkFrame_t *frame) -> nwkRoutePrepareTx(frame) -> nwkRouteDiscoveryRequest(frame) -> nwkRouteDiscoverySendRequest(entry, NWK_ROUTE_DISCOVERY_BEST_LINK_QUALITY) ?
А сами функции обработки при приеме запроса маршрута nwkRouteDiscoveryRequestReceived(ind) и ответа маршрута nwkRouteDiscoveryReplyReceived(ind) ..это уже обрабатывается на уровне application?

[ataradov]

Я правильно понял последовательность вызова процедуры поиска маршрута при разрешенном route discovery:
void nwkTxFrame(NwkFrame_t *frame) -> nwkRoutePrepareTx(frame) -> nwkRouteDiscoveryRequest(frame) -> nwkRouteDiscoverySendRequest(entry, NWK_ROUTE_DISCOVERY_BEST_LINK_QUALITY) ?

Да, так начинается поиск маршрута.

А сами функции обработки при приеме запроса маршрута nwkRouteDiscoveryRequestReceived(ind) и ответа маршрута nwkRouteDiscoveryReplyReceived(ind) ..это уже обрабатывается на уровне application?

Нет, там же в nwkRouteDiscovery.c и обрабатываются. Приложение об этом и не знает, для него это выглядит как просто задержка в отправке данных.

[Pasha_a13]

Если Вам не сложно, можете пожалуйста, в двух словах расписать как работает функция NWK_OpenEndpoint(NWK_SERVICE_ENDPOINT_ID, nwkRxSeriveDataInd); и как мы узнаем когда пришел пакет запроса маршрута и как мы снова попадем в nwkRxSeriveDataInd, когда она вызовется?

static bool nwkRxSeriveDataInd(NWK_DataInd_t *ind)
{
uint8_t cmd = ind->data[0];
switch (cmd)
{
#ifdef NWK_ENABLE_ROUTE_DISCOVERY
case NWK_COMMAND_ROUTE_REQUEST:
nwkRouteDiscoveryRequestReceived(ind);
return true;

case NWK_COMMAND_ROUTE_REPLY:
nwkRouteDiscoveryReplyReceived(ind);
return true;
#endif
default:
return false;
}
}
Я честно говоря не очень крут в программировании, потому не все моменты для меня понятны

Сообщение отредактировал Pasha_a13 - Aug 7 2013, 18:12

[ataradov]

NWK_OpenEndpoint() регистрирует обработчик принятых данных для Enpoint (число 0-15, 0 зарезервирован за стеком, 1-15 для приложений).

nwkRxSeriveDataInd() - это обработчик всех принятых кадров с dstEndpoint = 0 и все команды внутри стека отправляются так.

Как видно Ack - это тоже обычная команда.