loraE22

lorae22

Una clase de micryphon para los módulos Lora de la serie Ebyte E22

Los módulos EByte E22 compatibles se basan en los conjuntos de chips Semtech SX1262/SX1286 y están disponibles para los rangos de frecuencia de 400 MHz (410.125 ... 493.125) y 900 MHz (850.125 ... 930.125) y proporcionan 22 dBM MAX. TX Power.

Se utiliza una interfaz UART simple para controlar el dispositivo.

Hojas de datos de ebyte:
E22-900T22D
E22-400T22D

La clase Lorae22 se basa en la clase Lorae32 por Effevee: https://github.com/effevee/lorae32

Advertencias

¡Conecte la antena adecuada antes de transmitir!

Antes de usar, consulte sus regulaciones locales para usar este rango de frecuencia. ¡Por ejemplo, en la mayor parte de Europa, la potencia TX máxima permitida está por debajo del valor predeterminado de 22 dBm! ¡También puede haber restricciones adicionales, por ejemplo, restricciones en el ciclo de trabajo de sus transmisiones (es decir, la fracción del tiempo del aire hasta el tiempo total abarcado durante un período de uso del dispositivo)!

Notas

1. El E22 y E32 son diferentes en muchos detalles -
   • comandos
   • Diseño de registro
   • control de modo
   • Tiempo de señal Aux (en el modo de configuración, Aux no se puede usar para detectar la finalización de la secuencia de comando/respuesta)
2. Los módulos E22 o E32 no parecen ser adecuados para la comunicación de Lorawan (por ejemplo, la red Things)
3. Consulte el número 6 para problemas de compatibilidad con los módulos E22 nuevos (v2.1)

Configuración mínima de hardware nodemcu-sp32

Consulte el código para la configuración de PIN.

Código de prueba

Notas: ¡El código de prueba Lorae22 difiere del código de prueba E32 en términos de PIN UART y AUX usado! Además, Lorae22 usa 'modo normal', mientras que Lorae32 usa 'modo de atención' en sendMessage () .

Modo de transmisión	TX (ADDR - CH)	RX (ADDR - CH)	MSG (ADDR - CH)	Código transmisor	Código receptor
transparente	0x0001 - 0x02	0x0001 - 0x02	0x0001 - 0x02	testSende22_transparent.py	testRecve22_transparent.py
P2P fijo	0x0001 - 0x02	0x0003 - 0x04	0x0003 - 0x04	testSende22_p2p.py	testRecve22_p2p.py
transmisión fija	0x0001 - 0x02	0x0003 - 0x04	0xffff - 0x04	testSende22_broadcast.py	testRecve22_broadcast.py
monitor fijo	0x0001 - 0x02	0xffff - 0x04	0x0003 - 0x04	testSende22_monitor.py	testrecve22_monitor.py

Ejemplo: transmisión bidireccional entre dos nodos

Cada nodo envía un mensaje a un intervalo fijo que contiene un valor de control LED de acuerdo con el estado de un botón Push.

Luego verifica los mensajes recibidos. Si hay un mensaje con el valor de control del LED disponible, el LED se cambia en consecuencia.

El modo de transmisión (configuración de dirección/canal) para el nodo local y el nodo par se puede establecer como se desea en las matrices ADDR y Chan .

El código de node0.py y node1.py es idéntico, excepto la configuración de las variables yo y el par .

Nodo0	Nodo1
nodo0.py	nodo1.py

Configuración de prueba de rango

El transmisor Lora envía una cadena que contiene su ID de chip y un número de secuencia de mensaje a un intervalo fijo.

El receptor de Lora imprime/registra <Timestamp>, <Tlatitude>, <Longitude>, <altitude>, <RSSI> en un intervalo predefinido.

La posición del receptor y una marca de tiempo se decodifican de los mensajes NMEA recibidos a través de UART de un receptor GPS. Para este propósito, se usa MicropyGPS.

Si está disponible, se reciben mensajes de Lora entrantes del módulo transceptor EBYTEE22 Lora a través de otro UART. Si los mensajes esperados del transmisor Lora no pudieran recibirse por cierto tiempo, se supone un valor RSSI de -255 dBm, lo que indica la pérdida del enlace de radio Lora.

La tuple <Timestamp>, <Latitude>, <Rongitude>, <Altitude>, <RSSI> se imprime y opcionalmente se escribe en un archivo de registro solo si hay una posición válida disponible.

Si el registro está habilitado, un nombre de archivo en el formato log_ <8_random_hex_digits _>. CSV se crea después de encender o reiniciar. Los archivos de registro se escriben en el sistema de archivos interno de Micopython. El registro debe detenerse explícitamente presionando una tecla, de lo contrario, el archivo no se puede cerrar correctamente y estará corrupto/vacío.

Dos LED indican el estado de la solución GPS y el enlace Lora, respectivamente.

Nodo transmisor	Nodo receptor
lora_tx.py	lora_rssi_logger.py

Los archivos de registro se pueden convertir de CSV -formato a un formato adecuado, como GPX o KML, en el host más adelante. Consulte RSSI_CSV_TO_KML.PY: el archivo de salida KML proporciona el valor RSSI como datos extendidos que se mostrarán con el gráfico de elevación en GoogleEarth. (Uso: rssi_csv_to_kml.py log_deadbeef.csv >log_deadbeef.kml )

Nota: El gráfico simplemente sirve como ejemplo: el intervalo de registro debería haber sido más corto y la estrategia de registro se ha modificado después.