Creamos un puente entre Wi-Fi y LoRa para UDP
Tenía un sueño de infancia: darle a cada dispositivo "sin Wi-Fi" un boleto a la red, es decir, una dirección IP y un puerto. Después de un tiempo, comprendí que no debía posponerlo. Debía actuar y hacerlo.
Especificaciones técnicas
Hacer un puente con M5Stack que tenga el Módulo LoRa instalado (ver figura 1). El puente se conectará a una red Wi-Fi, donde obtendrá una dirección IP local por DHCP. El puente transmitirá periódicamente en el "aire LoRa" su nombre (análogamente al SSID para Wi-Fi) y el rango de puertos permitidos, para que otros dispositivos sepan que hay una red disponible a la que pueden conectarse y en qué rango pueden elegir un puerto libre. Dado que esto será un prototipo, la autenticación no se realizará en esta ocasión. Los nuevos dispositivos clientes encontrarán la red LoRa disponible y le transmitirán el puerto elegido. Una vez que el puente reciba el puerto del nuevo cliente, verificará si está libre, y si es así, registrará el nuevo cliente y comenzará a escuchar en dicho puerto en su propio servidor UDP asincrónico. Tras el registro, el cliente recibirá la aprobación o el rechazo para usar el puerto solicitado. El funcionamiento se muestra en la tabla 1.
Figura 1
Tabla 1
lado
dirección y datos
lado
sesión
[ cliente ]
<— señal-faro —
[ puente ]
0xA1
[ cliente ]
— puerto elegido —>
[ puente ]
0xB1
[ cliente ]
<— aprobación o rechazo —
[ puente ]
0xA2
[ cliente ]
— paquete UPD —>
[ puente ]
0xB2
[ cliente ]
<— paquete UPD —
[ puente ]
0xA3
[ red ]
<— paquete UPD —
[ puente ]
0xC1
Ante mí en la mesa hay varios Módulos para M5Stack que están aburridos. Vamos a tomar LoRa y divertirnos con ella. ¡El concepto mismo de los módulos es maravilloso! ¿Qué más puedo decir? Pero, los módulos que tengo son de la primera revisión, en la que la terrible antena integrada está hecha de una placa de circuito flexible y pegada al lado del cuerpo. Una vez realicé pruebas de campo con tales módulos (se puede ver en un canal de YouTube en ruso):
Naturalmente, tuve que quitar esos restos y soldar antenas espirales estándar que vienen con Ra-01. Después de esta personalización, la distancia de comunicación mejoró notablemente, pero surgió un efecto secundario: la antena tiene un diámetro mayor que la distancia permitida entre los módulos. Tuve que renunciar al Módulo Final por el tiempo del proyecto.
Las primeras dificultades de la tensión sincrónica
Aparentemente, solo hay que tomar la biblioteca WiFiUdp.h, donde todo está disponible para el funcionamiento cómodo de un servidor UDP, pero no. La biblioteca está diseñada para levantar un servidor sincrónico que, lamentablemente, no puede atender múltiples conexiones en un solo hilo. Esta biblioteca no es adecuada para la tarea actual. Tuve que tomar muchas tazas de té y buscar una biblioteca que permitiera levantar un servidor UDP asíncrono capaz de soportar múltiples conexiones simultáneamente. Esta biblioteca fue encontrada — AsyncUDP.h. ¿Cuál es la diferencia entre un servidor sincrónico y uno asíncrono? Vamos a analizar seis episodios en la figura 2, donde se muestran trivialmente las variaciones de funcionamiento de los sockets.
Figura 2
En los papeles principales:
Hombre en el papel de Socket;
Paloma en el papel de Conexiones;
Carta en el papel de Datos.
Episodio A. Socket sincrónico sin tiempo de espera
El Hombre permanecerá allí hasta que la Paloma le entregue la Carta.
Episodio B. Socket sincrónico con tiempo de espera
El Hombre espera el tiempo acordado con la Paloma y, si ésta no llega a tiempo, el Hombre se marchará.
Episodio C. Socket sincrónico con multihilo
El Hombre está ocioso y observa cómo las Palomas entregan solas las Cartas.
Episodio D. Socket asíncrono (cuando no hay nada que recibir)
El Hombre está dedicado a sus cosas favoritas, pero no se olvida de las Palomas.
Episodio E. Socket asíncrono (cuando hay algo que recibir)
El Hombre se distrae brevemente de sus asuntos para recibir la carta de la Paloma.
Episodio F. Socket asíncrono con multihilo
El Hombre está ocupado con sus cosas y observa cómo las Palomas entregan solas las Cartas.
Si han estado atentos, seguramente habrán notado que los collares en las Palomas en cada episodio tienen un color específico. Y esto no es por casualidad. En el episodio A y B solo un socket está funcionando en el servidor. En el episodio C ya funcionan dos sockets. En los episodios D, E y F ya hay tres sockets. "¿Por qué allí hay dos y aquí tres?" — preguntarán. Esto es condicionalmente 2 y 3, en realidad en lugar de 2 pueden ser 20, y en lugar de tres 200. La tarea es mostrar que los sockets asíncronos no sobrecargan tanto el hardware como los sincrónicos.
¿Cuánto cabe dónde?
Veamos la tabla 1, que presenta la estructura del paquete UDP y pensemos en lo que se puede hacer con esto.
Tabla 1. Estructura del paquete UDP
Bits
0 — 15
16 — 31
0-31
Puerto de origen (Source port)
Puerto de destino (Destination port)
32-63
Longitud del datagrama (Length)
Suma de verificación (Checksum)
64-…
Datos (Data)
Agregaremos un campo más al principio de esta tabla. Sesión (1 Byte). Esto es suficiente para este proyecto. Según la sesión, el dispositivo sabrá cómo proceder con el paquete. Ahora inventaremos códigos para las sesiones y los registraremos en la tabla 2.
Tabla 2. Explicación de las sesiones
Código
Nombre
Explicación
0xA1
Faro
El gateway transmite el nombre de la red LoRa y el rango de puertos permitidos con cierta periodicidad. Esto es necesario para que nuevos clientes puedan ver la red disponible, y para que los clientes actuales, cuando no hay transmisiones, puedan determinar el nivel de señal.
0xB1
Solicitud
Cuando el cliente detecta la red, envía el puerto preferido.
0xA2
Aceptación o rechazo
Si el puerto solicitado por el cliente está libre, el servidor responde con aceptación, y en caso contrario con rechazo.
0xB2
Up-link
Cuando el cliente envía un paquete UDP al gateway.
0xA3
Down-link
Cuando el gateway envía un paquete UDP al cliente.
0xC1
Continuación del Up-link
Cuando el gateway envía un paquete UDP a la red local.
Bien. Ahora vamos a discutir la composición de las sesiones en la tabla 3.
Tabla 3. Sesiones
Nombre de la sesión
Composición
Faro
Código de sesión (1 Byte) + Nombre de la red LoRa (4 Bytes) + Puerto inicial (2 Bytes) + Puerto final (2 Bytes)
Solicitud
Código de transmisión (1 Byte) + Nombre de la red LoRa (4 Bytes) + Puerto preferido (2 Bytes)
Aceptación o rechazo
Código de transmisión (1 Byte) + Nombre de la red LoRa (4 Bytes) + Puerto preferido (2 Bytes) + Resultado (1 Byte)
Up-link
Código de transmisión (1 Byte) + Nombre de la red LoRa (4 Bytes) + Dirección IP remota (4 Bytes) + Puerto remoto (2 Bytes) + Dirección IP local (4 Bytes) + Puerto local (2 Bytes) + Tamaño de datos (2 Bytes) + Datos
Down-link
Código de transmisión (1 Byte) + Nombre de la red LoRa (4 Bytes) + Dirección IP remota (4 Bytes) + Puerto remoto (2 Bytes) + Dirección IP local (4 Bytes) + Puerto local (2 Bytes) + Tamaño de datos (2 Bytes) + Datos
Continuación del Up-link
Dirección IP remota (4 Bytes) + Puerto remoto (2 Bytes) + Tamaño de datos (2 Bytes) + Datos
He escrito dos clientes para Arduino y para M5Stack. En puedes ver cómo funciona. No hay problemas dentro del apartamento, aún no he realizado pruebas de campo.
El código fuente está disponible en GitHub en
Puedes aprender más sobre el dispositivo M5Stack y comprarlo
Puedes elegir módulos inalámbricos LoRa para el dispositivo básico
Me alegrará si este proyecto te resulta útil. ¡Muchas gracias por tu tiempo!
Lista de referencias y/o fuentes:
Fuente: habr.com
