Cómo elegir el chip de una pasarela Bluetooth Mesh: ¿Telink, Silicon Labs o Nordic?
Comparamos Telink mesh_gw, Nordic Zephyr y Silicon Labs NCP/BGAPI para una pasarela Bluetooth Mesh: firmware, protocolo serie, capacidad de nodos, coste y nuestra elección.
El artículo anterior dejó dos cosas claras: los dispositivos y el gateway hablan SIG Mesh, y en el gateway la pila Mesh vive en un módulo Bluetooth independiente al que el programa de Linux controla por el puerto serie.
Eso nos deja una pregunta muy concreta: ¿qué chip Bluetooth usamos?
Comparamos tres fabricantes: Telink, Silicon Labs y Nordic. Cambiamos de opinión una vez por el camino y terminamos con Silicon Labs en el gateway y Telink en los dispositivos. Este artículo expone la comparación y el razonamiento.
Primero, ¿qué hace este chip en el gateway?
El módulo Bluetooth del gateway no es un nodo Mesh cualquiera. Cumple varios papeles:
- Provisioner: da de alta dispositivos nuevos, asigna direcciones, distribuye y vincula claves.
- Controlador: envía comandos de encendido/apagado, atenuación y color, y recibe los informes de estado.
- Nodo siempre activo: retransmite mensajes para los dispositivos más alejados.
- Coprocesador: recibe órdenes del host Linux por UART y le devuelve los mensajes entrantes.
Así que la comparación no va realmente del silicio. Importa más si el fabricante entrega firmware de gateway ya hecho y qué tan manejable es el protocolo serie entre el host y el módulo. Esa capa decide cuánto código necesita el programa del gateway y si alguien podrá depurarlo después.
Telink: lo más barato, con firmware incluido, pero con protocolo propietario
Telink domina el mercado chino de iluminación e interruptores, y nuestros dispositivos ya usaban sus chips. Su SDK de SIG Mesh es abierto en GitHub e incluye un firmware de gateway precompilado, mesh_gw.
A grandes rasgos, mesh_gw se ve así:
| Capa | Contenido | ¿Modificable? |
|---|---|---|
| Pila Bluetooth y pila Mesh | Cifrado, capas de red y de transporte | Código cerrado, solo bibliotecas |
| Capa de aplicación del gateway | Gestión de comandos serie, flujo de provisioning, informes de estado | Código abierto |
| Interfaz con el host | UART (el nuevo TL321X solo admite UART) | Protocolo propio de Telink |
Las ventajas son evidentes:
- Chips baratos: unos pocos yuanes por unidad en volumen.
- Firmware de gateway listo para usar, además de una herramienta de depuración para Windows.
- Mismo fabricante que los dispositivos, así que cualquier modelo de fabricante de Telink en los dispositivos se entiende directamente.
El problema es el protocolo serie. Telink lo definió por su cuenta, la documentación es escasa y muchos detalles solo se aclaran leyendo el código fuente del SDK. Los comandos se llaman HCI_CMD_GATEWAY_..., lo que sugiere el HCI estándar de Bluetooth, pero no lo son, y el entramado de las tramas también es distinto: las tramas del host al módulo no llevan cabecera de longitud y se separan por el tiempo de inactividad de la UART, mientras que las que vuelven del módulo sí la llevan.
Hay además un límite de capacidad: mesh_gw almacena como máximo 200 nodos por defecto, o 110 con provisioning remoto, porque los datos de los nodos viven en un único sector de flash. Para una casa basta; para uso comercial habría que cambiar la distribución del almacenamiento del SDK.
Nuestro primer prototipo se escribió contra este protocolo, junto con un módulo simulado para las pruebas. Funcionaba, pero cada función nueva implicaba volver a bucear en el código fuente, y nunca nos dio sensación de solidez.
Nordic: las mejores herramientas y documentación, pero el firmware del gateway lo escribes tú
El nRF52840 y el nRF5340 de Nordic gozan de muy buena fama entre los desarrolladores de Bluetooth. La documentación, las herramientas de sniffing y las apps para el móvil figuran entre lo mejor del sector, y el nRF52840 Dongle cuesta unos diez dólares y se conecta directamente a un puerto USB.
Pero Nordic tiene una carencia clave: el nRF Connect SDK actual no incluye firmware oficial de gateway serie. El antiguo nRF5 SDK for Mesh sí lo tenía, pero ya no se mantiene. Quedan tres opciones del lado del gateway:
| Enfoque | En el módulo | En el host | Valoración |
|---|---|---|---|
| Escribir tu propio firmware de gateway | El provisioner y los modelos cliente de Mesh de Zephyr, más un protocolo serie propio | Solo traducción | La arquitectura más limpia, pero hay que escribir entre mil y dos mil líneas de C |
| Módulo como simple controlador Bluetooth | Firmware HCI estándar de Zephyr | El demonio Mesh de BlueZ en Linux, o una pila propia | El firmware ya está listo, pero no hay desarrollo en Windows |
| Zephyr Mesh Shell | Línea de comandos integrada | Comandos de texto | Solo para depuración |
En cuanto a capacidad, la pila de Zephyr puede configurarse hasta 4.096 nodos, con entre mil y dos mil como cifra realista según la memoria. Pero por defecto son solo 8 nodos, con una lista de protección contra repetición de 10 entradas. Si no lo tocas, los mensajes del undécimo dispositivo empiezan a fallar, una trampa clásica al montar un gateway sobre Zephyr.
Nordic encaja en dos casos: quieres control total de la capa Mesh del gateway, o un solo gateway debe gestionar varios cientos de dispositivos o más. Ninguno era el nuestro, y los módulos cuestan bastante más, así que lo descartamos.
Silicon Labs: un protocolo serie documentado, y eso decidió
Silicon Labs sigue el mismo enfoque que Telink, «el módulo ejecuta la pila, el host envía comandos», que oficialmente se llama modo NCP (network co-processor). La diferencia es que su protocolo serie, BGAPI, está bien documentado:
- Cada comando, respuesta y evento está documentado, con bibliotecas oficiales para el host en C y Python.
- Cubre casi toda la API de Mesh: provisioning, configuración, modelos estándar, renovación de claves y actualizaciones de firmware.
- El SDK incluye un ejemplo de provisioner del lado del host (nota de aplicación AN1371), de modo que nuestra implementación en Rust puede seguir su flujo.
- NCP Commander, una herramienta gráfica, permite dar de alta dispositivos y encender luces sin escribir una línea de código.
El entramado de BGAPI es sencillo: una cabecera de 4 bytes más hasta 255 bytes de carga útil.
[hdr0][len_lo][class][cmd][payload 0–255 bytes]
hdr0: bit7 comando/evento, bits 6–3 tipo de dispositivo, bits 2–0 bits altos de la longitudUna advertencia: BGAPI no tiene suma de verificación en el enlace serie. Las tramas se separan solo por su longitud, así que hay que activar el control de flujo por hardware RTS/CTS para evitar la pérdida de bytes. Al elegir el procesador principal, comprueba que su UART admita control de flujo.
En precio, el EFR32BG24 que se usa en gateways figura en el sitio de Silicon Labs a unos 2,70–3,70 US$ por chip en lotes de 1.000 unidades, más que Telink. Por gateway, eso supone aproximadamente 2 US$ más.
Los tres, frente a frente
| Telink | Nordic | Silicon Labs | |
|---|---|---|---|
| Firmware de gateway | Listo (mesh_gw) |
Escribirlo tú, o HCI estándar | Listo (ejemplos NCP) |
| Protocolo serie | Propietario, poca documentación | El tuyo, o HCI estándar | BGAPI, documentado, con bibliotecas para el host |
| Herramientas de depuración | Sí | Las mejores | Buenas |
| Capacidad de nodos por defecto | 200 (110 con provisioning remoto) | 8, hay que ampliarla, hasta 4.096 | Según la configuración del firmware NCP |
| Coste del chip | El más bajo | Más alto | Intermedio |
| Cadena de suministro en China | La más madura | Aceptable | Buena |
Nuestra elección: Silicon Labs en el gateway, Telink en los dispositivos
La combinación final:
- Gateway: un módulo de la serie BG24 de Silicon Labs con firmware NCP.
- Dispositivos: siguen siendo Telink, con el SDK de SIG Mesh de Telink.
Un gateway lleva un solo módulo, así que pagar un par de dólares más compra un protocolo serie documentado, una API de Mesh completa y ejemplos oficiales, y hace el mantenimiento mucho más fácil. Con los dispositivos es distinto: interruptores y luces se fabrican en volumen, de modo que una pequeña diferencia por chip se multiplica, y el coste y el ecosistema local de Telink encajan mejor.
Los dos fabricantes conviven en una misma red gracias a los modelos estándar de SIG del artículo anterior. Mientras los dispositivos se ciñan a modelos estándar como Generic OnOff, Light Lightness y CTL, el fabricante del gateway da igual. Si un dispositivo usa modelos de fabricante de Telink, hay que cambiarlos por estándar o implementar el modelo de fabricante equivalente en el gateway.
Al abandonar el protocolo de Telink, solo hay que reescribir la capa de protocolo serie del programa del gateway; Matter, la tabla de dispositivos y la capa de mapeo quedan intactos. Es el diseño por capas del primer artículo dando sus frutos.
Pendiente de verificar
Estas conclusiones siguen en el papel. Cuando lleguen las placas, hay tres cosas que van primero:
- ¿Interoperan de verdad un gateway de Silicon Labs y dispositivos Telink? Antes de escribir código, usar NCP Commander para dar de alta una placa con el firmware de luz de Telink y encenderla.
- ¿Puede la UART del procesador principal funcionar con control de flujo por hardware? Ejecutar pruebas de estrés largas y vigilar si se pierden tramas.
- ¿Cuántos dispositivos puede manejar un gateway de forma fiable? Ajustar el número de nodos y la lista de repetición del firmware NCP a las necesidades reales.
Los resultados tendrán su propio artículo.
Reflexión final
Al elegir el chip Bluetooth de un gateway, es tentador fijarse en el precio y las especificaciones. Lo que de verdad condiciona el desarrollo y el mantenimiento suele ser el protocolo serie, invisible a simple vista: ¿está documentado?, ¿se puede depurar?, ¿puedes averiguar por qué algo falló?
Si estás eligiendo un chip para un gateway de Bluetooth Mesh, o trabajas con BGAPI de Silicon Labs o con el mesh_gw de Telink, me encantará conversar: linktr.ee/weiyii