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

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

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

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

Скорость небольшая. От каждого объекта передаётся порядка 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 (точнее не скоро повторяющийся), это само собой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не понял.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

У Atmel и Exegin есть.

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



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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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