Raspberry Pi SX1262 LoRa HAT multibanda con UART

Análisis general del producto

Mi valoración es que este HAT está orientado a proyectos de telemetría y comunicación entre nodos, no a sustituir una conexión Wi-Fi ni a transportar grandes volúmenes de datos. LoRa prioriza el alcance y la robustez del enlace frente a la velocidad; el rango de radio configurable, de 0,3 a 62,5 kbps, encaja con lecturas de sensores, alarmas y mensajes de control. El límite de 240 bytes por paquete obliga a diseñar mensajes compactos y a fragmentar los datos mayores.

Un detalle importante es que la UART y la radio son dos enlaces distintos. La UART, ajustable entre 1200 y 115200 bps, conecta la Raspberry Pi con el módulo; la velocidad LoRa determina cómo se transmite por el aire. Subir el baud rate de la UART no acelera por sí mismo el enlace inalámbrico. El SX1262, además, es un transceptor de radio; el rendimiento extremo a extremo dependerá también del firmware, el formato de paquetes, la antena y la configuración del nodo receptor. Las cifras del chip de radio no permiten deducir por sí solas una distancia fiable: Semtech también señala que las condiciones de enlace y configuración influyen en el resultado.

Calidad de construcción y materiales

La información técnica disponible no permite juzgar el grosor de la placa, la calidad de las soldaduras, el sistema de fijación ni la disipación térmica del HAT concreto. Sí permite valorar la conectividad prevista: disponer de SMA e IPEX facilita elegir entre una antena externa con conexión directa o una antena compacta mediante cable, siempre que la variante adquirida incorpore el conector correspondiente. Conviene evitar tensiones sobre el cable y no manipular el conector IPEX tirando del propio coaxial, ya que es pequeño y delicado.

La alimentación indicada es de 5 V, pero eso no significa que deban aplicarse 5 V a cualquier pin de señal. La Raspberry Pi trabaja con GPIO de lógica de 3,3 V; antes de conectar la UART hay que confirmar los niveles reales de TX y RX de la placa y el pinout del HAT. Un dispositivo que admita alimentación de 5 V no necesariamente entrega señales compatibles con GPIO de 3,3 V.

Compatibilidad y rendimiento

La UART TTL hace que el módulo pueda integrarse en un sistema Linux con herramientas habituales de puerto serie, pero la compatibilidad física no está garantizada solo por llamarse HAT. Revisaría el modelo de Raspberry Pi, la orientación de los pines, la disponibilidad de una UART libre y si la consola del sistema operativo está ocupando ese puerto. En una instalación de sensores, por ejemplo, reservaría la UART para el HAT y registraría los mensajes recibidos en un servicio que gestione reintentos y errores, en lugar de depender de lecturas manuales desde una terminal.

En un escenario cotidiano —una Pi en casa que recibe temperatura y estado de sensores instalados en un cobertizo— la baja tasa de datos es suficiente, pero la ubicación de la antena puede importar más que la potencia máxima. Separarla de fuentes de ruido, mantenerla despejada y probar el enlace con los nodos en su posición definitiva suele ser más útil que aumentar la potencia sin medir.

La autonomía también requiere cálculo con el patrón de uso real. El consumo indicado durante transmisión, 110 mA para SX1268 o 133 mA para SX1262, contrasta con los 2 µA declarados en reposo; por tanto, no dimensionaría una batería usando únicamente la cifra de reposo. La duración de cada transmisión, la frecuencia de envío y el consumo del resto del montaje son determinantes.

En España, elegir 868 MHz no basta para asegurar que cualquier ajuste sea válido. La normativa aplicable depende de la subbanda, la potencia radiada, el ciclo de trabajo y las condiciones de acceso al canal; por ejemplo, en 868,0–868,6 MHz se establece un máximo de 25 mW de potencia radiada aparente y condiciones de ocupación específicas. Los 22 dBm programables del módulo no equivalen automáticamente a una potencia legal de emisión. Verificaría la subbanda y los límites aplicables al caso de uso antes de transmitir.

Puntos fuertes y aspectos mejorables

• A favor: comunicación LoRa configurable, interfaz UART sencilla y consumo de reposo muy bajo según las cifras indicadas.
• A favor: potencia seleccionable y paquetes de hasta 240 bytes, adecuados para telemetría y órdenes breves.
• A mejorar: faltan datos concretos sobre el pinout, la variante exacta del chip, el firmware y el protocolo de intercambio. Sin ellos, la puesta en marcha puede requerir más comprobaciones que con un módulo acompañado de documentación completa.
• A mejorar: la selección entre 433, 470, 868 y 915 MHz exige que todos los nodos compartan una configuración compatible; no son bandas intercambiables por software si la variante física no corresponde.
• A tener en cuenta: LoRa no implica compatibilidad con LoRaWAN. Confirmaría expresamente el protocolo soportado si el objetivo es conectar el módulo a una red LoRaWAN existente.

Veredicto del experto

Lo considero una opción razonable para prototipos con mensajes breves, sensores remotos y telemetría, especialmente si se busca una interfaz serie directa en lugar de desarrollar desde cero el control del transceptor. No lo elegiría sin comprobar antes la variante de frecuencia, el chip montado, el pinout, los niveles lógicos y la documentación del firmware. Para un proyecto alimentado por batería, mediría el consumo en transmisión real; para una instalación en España, ajustaría potencia y frecuencia a la normativa aplicable, no al máximo que permita el módulo.