Для типичной задачи по созданию распределенной сети ZigBee датчиков и исполнительных механизмов предсказуемо встал вопрос выбора между применением в датчиках готовых модулей или разработкой собственного решения на контроллерах TI или NXP. На сервере используется JN5148-001-M04 и заменить его на какой-то получше нельзя. С целью снижения себестоимости датчиков, просматривался выбор CC2530. Но, поскольку прикладное ПО как для сервера, так и для датчиков мне делать самому, разбираться с библиотеками и тулчейнами разных вендоров не хотелось бы.
Отсюда два вопроса к коллегам, кто применял ZigBee контроллеры и модули разных производителей. Во-первых, насколько обосновано стремление использовать в сети ключевые компоненты только одного вендора, в данном случае NXP (Jennic), или связка сервер на NXP - клиент на TI вполне допустима? Во-вторых, будет ли в выигрыш в разработке своего беспроводного модуля, например, на CC2530, если числе датчиков и исполнительных механизмов в сети не превысит 50...100 шт?

Если вы будете использовать контроллеры, то перед вами встанет задача использования довольно непростого софта.
Вот как это происходило в Freescale до того как их купило NXP. Потом я с этим не сталкивался и не знаю как происходит сейчас. Думаю так же.
Вы ставите бесплатный пакет от Freescale , который вам сгенерирует сверхзаумно (чтобы вы сами легко не смогли использовать. Его легче самому написать чем разбираться как они все зашифровали) написаный код устройства, выбранного вами посредством множества конфигурационных параметров.
Генерировать без компилятора от IAR за 5-10 тысяч долларов оно откажется.

Для того, чтобы всети разработку вам надо стартовые 5-10 тысяч долларов. Если есть деньги, то для разработчика этот путь самый простой.
Это для большой серии рациональнее

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

Если вы хотите использовать свой код для зигби и не привязываться ни к кому то можно попробовать Zboss например. Про Zboss ничего не могу сказать. Только начал изучать.

Мы использовали CC2480 (потом переродившийся в CC2530). Ни с какими другими ZigBee-модулями по эфиру он дружить не хотел. Максимум что получалось - войти в одну сеть, но передача данных между ними - никак.

Функционала модулей должно быть достаточно. Управление реле, измерение U,I в статике (аналоговые датчики). На ваш взгляд, кто из производителей предлагает наиболее сбалансированные с точки зрения функционала/параметров и освоения/поддержки модули?


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



Что-то подобное о частичной совместимости продукции разных вендоров было ожидаемо. CC2530 по цене и параметрам мне очень подходит, но как заметил Tarbal, затраты на разработку модуля существенны. К сожалению, подходящих модулей на CC2530 не нашел. Видел, например, http://www.sysmc.ru/solutions/wireless_mod...modems/modules/ - отказался, не предусмотрен uFl connector.

Мы паяли свои, с печатной антенной и усилителем CC2591.
У CC2530 есть огромный минус: вся собственно работа с RF скрыта в бинарной библиотеке (оч. приличного размера). На си там только интерфейсная да сервисная часть.
А в этих бинарных библиотеках кроме несовместимости ещё и много багов.
Сборка делается с помощью огромной кучи дефайнов (много десятков) очень мутно и путанно описанных или неописанных вовсе. Самому эти дефайны как надо выставить практически нереально, можно рассчитывать только на готовые пресэты.

А поддержка от техаса или их форум - эффективны?

Не особо. Помнится когда мы ещё только начинали с ZigBee (много лет назад) на СС2480, то нарвались на целое стадо багов в его работе. На какие-то из них сумели приладить костыли, какие-то обошли ограничив используемый функционал. Но что-то победить не смогли и жить без этого никак.
Тогда обратились в поддержку. Прошли путь от "инженеров по использованию" вначале в РФ, потом в европейском центре (где в восточной европе, уже не помню точно где), дошли до какого-то важного немецкого дядьки по направлению поддержки, который нам много раз звонил. Потом, когда они наконец-то убедились, что проблема в их закрытом софте, то переслали описание уже разработчикам. Потом долго ждали ответа оттуда (месяца 2). Потом пришло короткое письмо, содержания примерно: "да, это так. и это - да. А эта проблема нам известна, но в данном чипе исправить невозможно так как OTP. Но на подходе новый чип (CC2530) где это можно будет легко исправить перепрошивкой".
Дождались нового чипа и.... вот они!, уже почти родные баги

PS: Хотя поддержка у них хорошая, внимательная - тут вообще всё отлично. Вот только проблема так и не решилась...
Вообще когда их представители как-то приезжали к нам в контору, они очень удивились что мы вообще запустили более-менее стабильную работу на CC2480. Сказали: "Из всех кто у нас покупал и использовал у себя в проектах CC2480 в РФ, ни у кого больше не получилось нормально заставить её работать". В результате - CC2480 сняли с производства, с заменой на CC2530

На форуме я получал хорошие советы по назначению различных дефайнов из исходников стека для CC2530. Так как в документации описание этих дефайнов или отсутствовало вовсе или очень куцее.
Так что форум - весьма полезен был.

Есть ещё ZigBee от Atmel. Стек закрыт. Но вроде как работал, т.к. запускал его наверное ещё лет 6 назад. Сеть подымалась, данные передавались. Но на нужную мне задачу скорости не хватало, т.к. есть существенные затраты на поддержку сети и таймауты для передачи данных. Есть у них мене тяжеловесный стек LwMesh. Тоже запускал и тоже работает, но тоже не подошло в чистом виде для задачи. После этого, на базе изученного, был написан свой радиостек (к этому рано или поздно придёте) с поддержкой ретрансляции.
Доступ к регистрам приёмопередатчика и их описание, можно взять из разных rf стеков Atmel, кроме ZigBee. Платы все свои. Но можно купить и готовые модули. Поддержка есть русскоязычная и очень быстро отвечает.

Я вроде года полтора назад находил открытый стек от Атмел. В исходниках.

Монетизировать свои наработки по стеку и CC2530 не пробовали?

Честно говоря: после стольких злоключений с ним, больше даже и прикасаться не хочется....

В исходниках есть стек LwMesh, это легковесная версия построения Mesh сети. ZigBee стек тот, что соответствует спецификации ZigBee, называется BitCloud, никогда в исходниках не был. Да и вряд ли будет. ZigBee подойдёт там где нужно раз в несколько секунд, передать пакетик данных, иначе эта сеть загнётся или будут потери пакетов. Минус ZigBee, что нужен ещё обязательно координатор. LwMesh гораздо лучше в этом плане плане, да и можно подкорректировать при необходимости. Эволюция собственных девайсов была BitCloud -> LwMesh -> Свой стек и драйвер приёмопередатчика.

Сочувствую, но тогда на чьи контроллеры или модули, на ваш взгляд, лучше сориентироваться?

Да, это был он.


У нас были на ZigBee в основном сети сбора данных АСКУЭ/АСТУЭ. С потоками данных отнюдь не байты в секунду. И обновление прошивок и скачивание журналов со счётчиков в десятки-сотни кБ - обычное дело там.
И передача данных происходила не только между одним устройством (центром сбора) и счётчиками, но и между разными счётчиками.
Все устройства были роутерами (+ координатор). EP не было.


Не могу подсказать. Мы на CC2480 сели лет 10 назад, тогда вариантов было немного - выбрали его. А потом когда уже написали тучу кода (с костылями всеми), то слишком сложно было на что-то другое перелезть. Тем более то, что было оно как-то более-менее работало (при определённых ограничениях). Да, рассматривали в процессе всего этого дела другие решения, но так и не решились перейти на что-то другое (так как совсем не было уверенности, что провозившись с их изучением, написанием ПО, испытаниями кучу времени, не наткнёмся и там на баги).
В принципе можно и CC2530, но надо сразу быть готовым к реализации некоторых костылей

Что-то все производители практически выкинули предложение стека ZigBee для своих продуктов.
Intel в своей Zephyr OS специально для IoT не имеет ZigBee. Проект mbed без ZigBee. Только поддержка модулей осталась.
Смотрю Nordic, NXP для своих новейших nRF52840 и MKW41 не предлагают ZigBee. Перешли на Bluetooth Mesh.
Может и вам стоит.

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

К таким выводам пришлось прийти самому, потом они подтвердились в процессе переписки с представителем. Потоки данных это хорошо, но их можно предавать и час, и два, и сутки. От этого они не перестанут быть потоками данных. Интересна скорость с которой у Вас работали устройства в сети. Не думаю, что больше 2-5кбит/сек в общей сети.

При передаче прошивки от одного устройства к другому (прямая видимость, без ретрансляций) - около 1кбайта/сек и немного выше. Хотя всё очень сильно зависело от количества устройств в сети: это цифры для больших сетей - несколько десятков устройств, при очень малом количестве удавалось получить и намного бОльшие скорости.
Это информационная скорость - по полезным данным. Кроме них много передаётся служебной инфы: всякие обрамления, заголовки, подтверждения с удалённой стороны и т.п. Например - необходимость передачи подтверждений на каждый кадр сильно ограничивает общую скорость потока.

ZigBee реально умер, хотя на выставках вижу иногда чудиков, предлагающих это решение.
Может вам не нужна mesh-сеть? Сейчас происходит прорыв с трансиверами, может достаточно точка - точка?
Или NB IoT?

Mesh, скорее всего, не нужна. У меня сеть обычных датчиков, но расстояние до некоторых может быть 1...2 км, или рельеф сложный, например, холмы+овраги. Возможен вариант инициативной передачи состояния каких-то датчиков в любой момент времени. Вопрос минимальной стоимости датчиков также актуален. По этой причине услуги GSM-операторов (NB IoT) не рассматривались. Вот, собственно, и все.

Устройства ZigBee различных производителей могут быть совместимы между собой, только если они используют один и тот же профиль приложения верхнего уровня, например, Home Automation, ZigBee Lihgt Link или ZigBee 3.0. Устройства ZigBee могут вообще не использовать никакой стандартный профиль уровня приложения, а использовать только сетевой уровень ZigBee. Такие ZigBee-сети предоставляют пользователям преимущества саморганизации, самовосстановления, автоматической ретрансляции сообщений, но при этом не являются совместимыми с устройствами других производителей. В России мало кто заботился о совместимости своих устройств ZigBee и стандартные профили никто не использовал. Поэтому, думаю, что трудно будет использовать какой-то другой ZigBee-микроконтроллер со стеком другого производителя, не NXP.

10 лет назад отладочный комплект ZigBee у Ember стоил порядка 3 тысяч долларов. Сейчас отладочный комплект на базе микросхем EFR32MG13 c полноценным стеком и профессиональными отладочными средствами
стоит порядка $560, а отладочный комплект на базе радиомодулей ETRX357 стоит еще меньше.
ZigBee, по-прежнему, целесообразно использовать для систем автоматизации зданий благодаря наличию библиотеки верхнего уровня ZigBee Cluster Library, которая призвана обеспечить совместимость устройств различных производителей. В настоящее время на базе ZigBee Cluster Library ZigBee-альянс разработывает спецификацию dotdot, как стандарт уровня приложения для устройств IOT, который должен будет обеспечить совместимость устройств не зависимо от того, какая технология связи используется на физическом уровне. Также технология ZigBee явилась основой для разработки стандарта Thread беспроводных малопотребляющих сетей с IP-адресацией узлов.
Если совместимость ни с кем не требуется и нужно быстро разработать малопотребляющую сеть датчиков, то, по-прежнему, доступны модули ETRX357. Они, кстати, подешевели с тех пор, как Silabs купил Telegesis.
К сожалению, автору вопроса они не пойдут из-за несовместимости с NXP. Просто хотелось внести ясность относительно ZigBee.

Автору вопроса ZigBee вообще может не подойти, если передавать данные нужно на 1,5 км без ретрансляции.
На 1,5 км из технологий, работающих в диапазоне 2,4 ГГц, сейчас есть Bluetooth 5.0 Новейшие микросхемы Silabs EFR32MG13 и EFR32BG13 являются мультипротокольными и поддерживают и ZigBee и Thread и Bluetooth 5.0 c дальностью до 1,5 км, и новейший, только опубликованный в июле стандарт Bluetooth Mesh.

Смею заверить, автор рассматривал возможность перехода с NXP на Silabs. Есть мелкие вопросы по поводу московского офиса и состояния склада по модулям MGM12P. И хотелось бы знать о времени появления модулей на EFR32MG13, EFR32BG13

Если под Вашу задачу подойдет Longest Range Bluetooth5 то есть еще модули на основе чипа от Нордик - http://www.fanstel.com/bt832x-bluetooth-5-module/

Модули MGM12P появятся уже на складе в сентябре. Анонсированы модули BGM13P ( 13.9 мм x 15.0 мм LGA) и BGM13S (6.5 мм x 6.5 мм LGA) с полной поддержкой Bluetooth 5.0, т.е поддержку функции Long Range в этих модулях тоже обещают. Ждем эти модули к концу года. Сейчас на складе уже имеются отладочные средства на базе мультипротокольных EFR32MG12 как для диапазона 2,4 ГГц, так и на базе двухчастотных микросхем, которые имеют два встроенных приемопередатчика, одновременно работающих в диапазоне 2,4 ГГц и в диапазоне < 1 ГГц.

Похоже, в плане поддержки они больше под oem заточены.

На таможне РФ с ним проблем не боитесь? Нотификация - есть?