Какой чип выбрать для шлюза Bluetooth Mesh: Telink, Silicon Labs или Nordic?
Сравниваем Telink mesh_gw, Nordic Zephyr и Silicon Labs NCP/BGAPI для шлюза Bluetooth Mesh: прошивка, последовательный протокол, ёмкость узлов, стоимость и наш выбор.
В предыдущей статье мы определились с двумя вещами: устройства и шлюз общаются по SIG Mesh, а на шлюзе Mesh-стек живёт в отдельном Bluetooth-модуле, которым Linux-программа управляет через последовательный порт.
Остаётся вполне прикладной вопрос: какой Bluetooth-чип взять?
Мы сравнивали трёх производителей: Telink, Silicon Labs и Nordic. По ходу дела один раз передумали и в итоге остановились на Silicon Labs в шлюзе и Telink в устройствах. В этой статье — сравнение и логика выбора.
Для начала: что этот чип делает в шлюзе?
Bluetooth-модуль шлюза — не обычный Mesh-узел. Он совмещает несколько ролей:
- Provisioner: добавляет в сеть новые устройства, назначает адреса, раздаёт и привязывает ключи.
- Controller: отправляет команды включения и выключения, диммирования и смены цвета, принимает отчёты о состоянии.
- Постоянно включённый узел: ретранслирует сообщения для более удалённых устройств.
- Сопроцессор: принимает команды от Linux-хоста по UART и передаёт ему входящие сообщения.
Поэтому сравнивать приходится не столько кремний, сколько другое: есть ли у производителя готовая прошивка шлюза и насколько удобен последовательный протокол между хостом и модулем. Именно этот слой определяет, сколько кода понадобится программе шлюза и сможет ли кто-нибудь потом в нём разобраться.
Telink: дешевле всех, прошивка в комплекте, но протокол закрытый
Telink доминирует на китайском рынке освещения и выключателей, и в наших устройствах уже стояли его чипы. SIG Mesh SDK открыт на GitHub и включает готовую прошивку шлюза mesh_gw.
Устроена mesh_gw примерно так:
| Слой | Содержимое | Можно менять? |
|---|---|---|
| Bluetooth-стек и Mesh-стек | Шифрование, сетевой и транспортный уровни | Закрытый код, только библиотеки |
| Прикладной уровень шлюза | Обработка команд по serial, процедура provisioning, отчёты о состоянии | Открытый код |
| Интерфейс с хостом | UART (новый TL321X поддерживает только UART) | Собственный протокол Telink |
Плюсы очевидны:
- Дешёвые чипы: при больших партиях — несколько юаней за штуку.
- Готовая прошивка шлюза и отладочный инструмент для Windows.
- Тот же производитель, что и у устройств, поэтому vendor-модели Telink на устройствах понятны сразу.
Проблема — в последовательном протоколе. Telink придумала его сама, документации мало, и многие детали проясняются только при чтении исходников SDK. Команды называются HCI_CMD_GATEWAY_..., что наводит на мысль о стандартном Bluetooth HCI, но это не он. Да и с кадрами всё нестандартно: кадры от хоста к модулю не имеют заголовка длины и разделяются по паузе на UART, а кадры от модуля к хосту длину содержат.
Есть и ограничение по ёмкости: mesh_gw по умолчанию хранит не более 200 узлов, а при удалённом provisioning — 110, потому что данные узлов лежат в одном секторе flash. Для дома хватает, а для коммерческого применения придётся менять схему хранения в SDK.
Наш первый прототип был написан под этот протокол, вместе с эмулятором модуля для тестов. Работало, но каждая новая функция снова означала раскопки в исходниках, и уверенности это не добавляло.
Nordic: лучшие инструменты и документация, но прошивку шлюза пишешь сам
Nordic nRF52840 и nRF5340 у Bluetooth-разработчиков пользуются заслуженным уважением. Документация, снифферы и мобильные приложения — одни из лучших в отрасли, а nRF52840 Dongle стоит около десяти долларов и просто втыкается в USB.
Но у Nordic есть принципиальный пробел: в актуальном nRF Connect SDK нет официальной прошивки шлюза с serial-интерфейсом. В старом nRF5 SDK for Mesh она была, но больше не поддерживается. Со стороны шлюза остаются три варианта:
| Подход | На модуле | На хосте | Вердикт |
|---|---|---|---|
| Писать свою прошивку шлюза | Provisioner и клиентские модели Mesh из Zephyr плюс собственный serial-протокол | Только трансляция | Самая чистая архитектура, но придётся написать тысячу-две строк на C |
| Модуль как обычный Bluetooth-контроллер | Стандартная HCI-прошивка Zephyr | Mesh-демон BlueZ на Linux или собственный стек | Прошивка готова, но под Windows разработки нет |
| Zephyr Mesh Shell | Встроенная командная строка | Текстовые команды | Только для отладки |
По ёмкости: стек Zephyr можно настроить на 4096 узлов, реалистично с учётом памяти — одна-две тысячи. Но по умолчанию там всего 8 узлов, а список защиты от повторов — на 10 записей. Если ничего не менять, сообщения 11-го устройства начнут теряться. Это классическая ловушка при построении шлюза на Zephyr.
Nordic подходит в двух случаях: если нужен полный контроль над Mesh-уровнем шлюза или если один шлюз должен обслуживать несколько сотен устройств и больше. Нас не касалось ни то, ни другое, а модули заметно дороже, так что мы отказались.
Silicon Labs: документированный serial-протокол — и это решило дело
Silicon Labs идёт тем же путём, что и Telink: «модуль крутит стек, хост шлёт команды». Официально это называется режимом NCP (network co-processor). Разница в том, что его serial-протокол BGAPI описан как следует:
- Все команды, ответы и события задокументированы, есть официальные хост-библиотеки на C и Python.
- Покрыт почти весь Mesh API: provisioning, конфигурация, стандартные модели, обновление ключей и прошивки.
- В SDK есть пример provisioner’а на стороне хоста (application note AN1371), и нашу реализацию на Rust можно строить по его логике.
- Графический инструмент NCP Commander позволяет добавлять устройства и переключать свет вообще без кода.
Формат кадра BGAPI прост: 4-байтовый заголовок и до 255 байт полезной нагрузки.
[hdr0][len_lo][class][cmd][payload 0–255 bytes]
hdr0: bit7 команда/событие, биты 6–3 тип устройства, биты 2–0 старшие биты длиныОдна оговорка: в BGAPI на последовательной линии нет контрольной суммы. Кадры разделяются только по длине, поэтому, чтобы не терять байты, нужно обязательно включать аппаратное управление потоком RTS/CTS. При выборе главного процессора проверьте, что его UART умеет flow control.
По цене: EFR32BG24, который используется в шлюзах, на сайте Silicon Labs стоит около 2,70–3,70 доллара за чип при партии в 1000 штук — дороже, чем Telink. В пересчёте на шлюз это примерно 2 доллара сверху.
Все трое в одной таблице
| Telink | Nordic | Silicon Labs | |
|---|---|---|---|
| Прошивка шлюза | Готова (mesh_gw) |
Писать самому или стандартная HCI | Готова (примеры NCP) |
| Serial-протокол | Закрытый, мало документации | Свой или стандартный HCI | BGAPI, документирован, есть хост-библиотеки |
| Инструменты отладки | Есть | Лучшие | Хорошие |
| Ёмкость по умолчанию | 200 узлов (110 при удалённом provisioning) | 8, нужно увеличивать, до 4096 | Задаётся конфигурацией NCP-прошивки |
| Стоимость чипа | Самая низкая | Выше | Средняя |
| Китайская цепочка поставок | Самая зрелая | Средняя | Хорошая |
Наш выбор: Silicon Labs в шлюзе, Telink в устройствах
Итоговая комбинация:
- Шлюз: модуль Silicon Labs серии BG24 с NCP-прошивкой.
- Устройства: по-прежнему Telink, на SIG Mesh SDK от Telink.
В шлюзе стоит один модуль, поэтому пара лишних долларов покупает документированный serial-протокол, полный Mesh API и официальные примеры, а поддерживать всё это намного проще. С устройствами иначе: выключатели и светильники идут большими партиями, небольшая разница в цене чипа быстро складывается в приличную сумму, и по стоимости и местной экосистеме Telink подходит лучше.
Два производителя уживаются в одной сети благодаря стандартным моделям SIG из прошлой статьи. Пока устройства используют стандартные модели вроде Generic OnOff, Light Lightness и CTL, вендор шлюза не имеет значения. Если же устройство использует vendor-модели Telink, придётся либо перейти на стандартные, либо реализовать соответствующую vendor-модель на шлюзе.
После отказа от протокола Telink переписывать нужно только слой serial-протокола в программе шлюза; Matter, таблица устройств и слой маппинга остаются нетронутыми. Это и есть та самая слоистая архитектура из первой статьи, которая окупается.
Что ещё предстоит проверить
Пока все эти выводы существуют только на бумаге. Когда придут платы, первыми будут три проверки:
- Действительно ли шлюз на Silicon Labs и устройства Telink работают вместе? Прежде чем писать код, через NCP Commander добавим плату с light-прошивкой Telink и включим её.
- Может ли UART главного процессора работать с аппаратным flow control? Прогоним длительные стресс-тесты и посмотрим, не теряются ли кадры.
- Сколько устройств один шлюз тянет стабильно? Подберём число узлов и размер списка защиты от повторов в NCP-прошивке под реальные нужды.
Результаты выйдут отдельной статьёй.
Напоследок
Выбирая Bluetooth-чип для шлюза, легко зациклиться на цене и характеристиках. Но разработку и поддержку на деле чаще определяет невидимая часть — serial-протокол: описан ли он, можно ли его отлаживать и можно ли выяснить, почему что-то сломалось.
Если вы выбираете чип для Bluetooth Mesh-шлюза или работаете с BGAPI от Silicon Labs или mesh_gw от Telink, буду рад пообщаться: linktr.ee/weiyii