Decodificador de sensor RF Arduino: 5 pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:42

Mi casa anterior venía con un sistema de seguridad preinstalado que tenía sensores de puerta, un sensor de movimiento y un panel de control. Todo estaba conectado a una gran caja de electrónica en un armario y había instrucciones para cablear un teléfono fijo para marcar automáticamente en caso de alarma. Cuando intenté jugar con él, descubrí que uno de los sensores de la puerta estaba instalado de forma incompleta y otro era intermitente debido a una alineación incorrecta. Hasta aquí la instalación profesional promocionada en la tarjeta de presentación de la empresa de seguridad. Mi solución en ese momento fue comprar un par de cámaras de seguridad de Internet y una alarma de seguridad inalámbrica barata.

Avance rápido hasta hoy y esa alarma inalámbrica está en una caja en mi sótano. Después de adquirir un receptor de RF barato, decidí ver si podía decodificar los mensajes transmitidos por la variedad de sensores de alarma y controles remotos que tengo. Supuse que, dado que todos trabajaban con la caja de alarma barata, todos debían usar el mismo formato de mensaje con una identificación diferente. Pronto descubrí que son similares solo en la estructura general de los mensajes. Así que el proyecto pasó rápidamente de trivial a muy interesante.

Paso 1: Módulos de sensor

Como puede ver en las imágenes de arriba, los transmisores incluyen sensores de puerta abierta, detectores de movimiento, controles remotos de armado y un teclado inalámbrico que se usa para programar la caja de alarma. Resulta que no hay dos de estos dispositivos que utilicen la misma longitud de sincronización o duración de bits. El único punto en común, además de la longitud del mensaje, es el formato básico de los bits. Cada bit ocupa un período de tiempo fijo, siendo la diferencia entre un cero y uno el ciclo de trabajo de las porciones alta / baja.

La bonita forma de onda que se muestra arriba NO es lo que recibí por primera vez. Debido a que hay tanto tráfico en la banda de frecuencia de 433 MHz, tuve que asegurarme de activar el sensor justo antes de configurar el osciloscopio para hacer un solo disparo. Afortunadamente, los sensores emiten varias copias del mensaje de datos cuando se activan y los controles remotos y el teclado continúan enviando mensajes mientras se presione una tecla. Al usar el alcance, pude determinar la longitud de sincronización y la duración de los bits de datos para cada elemento. Como se mencionó anteriormente, los tiempos de sincronización son diferentes y los tiempos de bits son diferentes, pero todos los formatos de mensaje tienen una sincronización de bajo nivel seguida de 24 bits de datos y un bit de parada. Eso fue suficiente para poder construir un decodificador genérico en software sin tener que codificar todos los detalles diferentes para cada dispositivo.

Paso 2: hardware

Originalmente construí un decodificador de sensor usando un microcontrolador PIC y lenguaje ensamblador. He estado jugando con variantes de Arduino recientemente, así que pensé en ver si podía replicarlo. El esquema simple se muestra arriba y también hay una imagen de mi prototipo. Todo lo que hice fue usar tres cables de puente comunes para ir del Arduino Nano a la placa del receptor de RF. Todo lo que se necesita es energía y una sola línea de datos.

Si lee mi Instructable en la “Pantalla de tiempo y clima 3 en 1”, verá que utilizo un receptor RXB6 común de 433 MHz. Es posible que pueda hacer que los receptores realmente baratos funcionen en el corto alcance necesario para este proyecto, pero aún así recomiendo usar un receptor superheterodino.

Paso 3: software

El software convierte los bits recibidos en caracteres ASCII visualizables. Emite el valor de la longitud de sincronización y las longitudes de los bits 1 y 0. Como ya conocía las longitudes de sincronización y los formatos de bits, podría haber escrito el software específicamente para ellos. En su lugar, decidí ver si podía escribirlo para ordenar las longitudes de sincronización y calcular automáticamente los bits de datos. Eso debería facilitar la modificación en caso de que quiera intentar detectar otros formatos en algún momento. Es importante notar que el software no sabe si el primer bit de un mensaje es un 1 o un 0. Asume que es un 1 pero, si se da cuenta de que debería haber sido un cero, invertirá el bits en el mensaje completo antes de enviarlo por el puerto serie.

Los tiempos del pulso de sincronización y los bits de datos se determinan utilizando la entrada de interrupción externa INT0 para activar un manejador de interrupciones. INT0 puede dispararse al subir, bajar o en ambos flancos, o en un nivel bajo constante. El software se interrumpe en ambos bordes y mide la cantidad de tiempo que el pulso permanece bajo. Eso simplifica las cosas porque el inicio / sincronización del mensaje es un pulso de bajo nivel y los bits se pueden determinar en función de su tiempo de bajo nivel.

El manejador de interrupciones primero determina si el recuento capturado es lo suficientemente largo como para ser un pulso de inicio / sincronización. Los distintos dispositivos que tengo utilizan pulsos de sincronización de 4, 9, 10 y 14 milisegundos. Las sentencias de definición para los valores de sincronización permitidos mínimo / máximo están al principio del software y actualmente están configuradas para 3 y 16 milisegundos. Los tiempos de bits también varían entre los sensores, por lo que el algoritmo para decodificar bits debe tener eso en cuenta. El tiempo de bit del primer bit se guarda al igual que el tiempo de un bit posterior que tiene una diferencia significativa con el primer bit. No es posible una comparación directa de los tiempos de bit posteriores, por lo que se utiliza una definición de "factor de modificación" ("Variación"). La decodificación de bits comienza asumiendo que el primer bit de datos siempre se registra como un 1 lógico. Ese valor se guarda y luego se usa para probar los bits siguientes. Si un recuento de bits de datos posterior está dentro de la ventana de variación del valor guardado, también se registra como un 1 lógico. Si está fuera de la ventana de variación del valor guardado, se registra como un 0 lógico. Si el 0 lógico El tiempo de bit es más corto que el primer tiempo de bit, entonces se establece una bandera para indicarle al software que los bytes deben invertirse antes de mostrarse. El único caso en el que este algoritmo falla es cuando los bits de un mensaje son todos ceros. Podemos aceptar esa limitación porque ese tipo de mensaje no tiene sentido.

Todos los sensores que me interesan tienen una longitud de mensaje de 24 bits de datos, pero el software no se limita a esa longitud. Hay un búfer de hasta siete bytes (se podrían agregar más) y define la longitud mínima y máxima del mensaje en bytes. El software está configurado para recopilar los bits, convertirlos en bytes, almacenarlos temporalmente y luego enviarlos en formato ASCII a través del puerto serie. El evento que activa la salida del mensaje es la recepción de un nuevo pulso de inicio / sincronización.

Paso 4: registro de datos

El software está configurado para generar los datos convertidos como caracteres ASCII a través de la salida en serie (TX) del Arduino. Cuando hice la versión PIC, necesitaba conectarme a un programa de terminal en la PC para mostrar los datos. Una ventaja del Arduino IDE es que tiene una función de monitor en serie incorporada. Establezco la velocidad del puerto en serie en 115.2k y luego configuro la ventana del monitor en serie a la misma velocidad. La captura de pantalla aquí muestra una pantalla típica con salidas de una variedad de sensores que tengo. Como puede ver, los datos a veces no son perfectos, pero puede determinar fácilmente cuál debería ser el valor real de cada sensor.

Paso 5: software del receptor de muestra

He incluido una lista de software de muestra que muestra cómo puede utilizar la información recopilada para recibir un conjunto específico de códigos para su aplicación. Este ejemplo está configurado para emular uno de mis puntos de venta remotos de Etekcity. Un comando enciende el LED integrado en el Nano (D13) y el otro comando apaga el LED. Si no tiene un LED integrado en su Arduino, agregue la resistencia y el LED como se muestra en el diagrama. En una aplicación real, esta función encendería / apagaría la alimentación de una toma de corriente (mediante un relé o un triac). Los tiempos de sincronización, los tiempos de bits y los bytes de datos esperados se definen desde el principio para facilitar la modificación. Puede usar cualquiera de las líneas de datos restantes para encender / apagar, etc. para su aplicación específica. Simplemente agregue el código de comando aplicable que defina y reemplace la lógica de encendido / apagado del LED en "bucle" para satisfacer sus necesidades.