Protocolo serial asíncrono de ingeniería inversa para el calentador de agua sin tanque EcoSmart

Estoy tratando de aplicar ingeniería inversa al protocolo de control remoto para mi calentador de agua sin tanque EcoSmart .

Desafortunadamente, el dispositivo de control remoto ya no está disponible para la compra y el fabricante no tiene información sobre el protocolo utilizado. Quiero intentar conectar el calentador directamente a un Arduino para poder monitorearlo/controlarlo a través de Ethernet.

El calentador tiene un conector de 4 pines para el control remoto y está conectado a la MCU como se muestra aquí:

esquemático

simular este circuito : esquema creado con CircuitLab

La unidad envía datos en los siguientes escenarios:

  • Cambio de temperatura girando la perilla de control
  • Unidad encendida/apagada presionando la perilla de control
  • Calentador activado/desactivado (inicio/parada del flujo de agua)

Mi osciloscopio tiene decodificación RS-232 incorporada, y parece decodificar algunos datos a 1200 bps, pero no estoy seguro de que realmente esté tratando con datos RS-232/UART aquí. Mi pregunta para usted es: ¿qué tipo de datos le parece esto?

Aquí hay parte de la salida de una operación de "ENCENDIDO" (es decir, presione el botón para encender el calentador): http://is.am/fx

Para mí, esto parece demasiadas transiciones altas/bajas para UART... Me inclino por un pulso de ancho variable para indicar 0/1. En el diagrama de tiempo anterior, puede ver mi interpretación tanto de RS-232 como de "Otro", lo que indica un protocolo desconocido, que tendría un '0' digital como un pulso alto de 720uS y un '1' digital como un pulso alto de 24mS. .

Agradecería cualquier información sobre el protocolo utilizado aquí. Si necesita aclaraciones, haré lo mejor que pueda.

Referencia RS-232/UART: https://electronics.stackexchange.com/a/227414/16378

Actualización: después de grabar y transcribir muchas formas de onda de diferentes eventos, descubrí parte del protocolo.

  1. Hay un comando de 'Inicio' al principio de cada secuencia. Consiste en una lógica Baja durante al menos 4 ms, luego Alta durante 7 ms, luego Baja durante 4 ms.

  2. Después del comando 'Inicio', los pulsos cortos (720uS) representan el cero lógico y los pulsos largos (2,4 ms) representan el uno lógico. Los espacios entre pulsos son todos de aproximadamente 840uS.

  3. Todas las secuencias tienen una longitud de 5 bytes y se transmiten 6 veces.

  4. Los primeros 2 bytes son siempre los mismos: 00:FF:0F:F0

  5. El tercer byte parece ser el identificador de comando/evento:

    • Evento de cambio de ajuste de temperatura (rueda girada): 00:70
    • Comando ON (botón presionado): 00:00
    • Comando APAGADO (botón presionado): 00:70 (igual que el ajuste de temperatura)
    • Evento de inicio de flujo: 02:70
    • Evento de parada de flujo: 00:70 (igual que la configuración de temperatura y el comando de apagado)

  6. El cuarto byte es la temperatura en Fahrenheit, MSB a LSB (80 a 140)

  7. El quinto byte es la temperatura en Celsius, MSB a LSB (26 a 60)

Así que ahora tengo que determinar si puedo enviar estas mismas secuencias a la línea RX para cambiar las temperaturas y habilitar/deshabilitar el calentador de forma remota. Me pregunto si se utiliza una dirección diferente

ACTUALIZACIÓN #2: ¡Éxito! ¡Resulta que enviar las mismas secuencias al pin RX se puede usar para ajustar la temperatura y encender y apagar la unidad! Fue bastante fácil modificar el protocolo con un Arduino Uno, y el calentador responde a los ajustes de temperatura alterando directamente la temperatura de salida (no es necesario subir o bajar un grado a la vez). Planeo publicar la guía de interfaz completa junto con el código fuente tanto para la entrada como para la salida cuando esté completa.

¡Gracias a todos los que ofrecieron sugerencias!

ACTUALIZACIÓN #3: Repositorio de Github creado: https://github.com/ryangriggs/EcoSmartLib

ACTUALIZACIÓN n.º 4: consulte el repositorio de github de Phil para obtener más información: https://github.com/PhilRW/ecosmart-remote

¿Estás seguro de que no hay etiquetas en la MCU? El enlace que proporcionó muestra una imagen del tablero de control, ¿es eso lo que tiene?
@DmitryGrigoryev Sí, esa es la placa de control exacta. Sin embargo, la MCU principal no tiene ningún grabado. Lo he limpiado, usado una lupa, etc, pero no tiene nada impreso. Es un paquete SOP28 de 28 pines.
Podría ser más reconocible si su forma de onda de tiempo tuviera un eje de tiempo constante. Tal como está, es difícil tener una idea del tiempo relativo con solo mirarlo.
¿Alguna idea de qué año es este dispositivo? ¿Tal vez un sello de fecha en otro chip o en la PCB? SI ya no se fabrica y es antiguo, eso limitaría las interfaces disponibles para verificar.
@Wojciech Supongo que este dispositivo se fabricó alrededor de 2014, y este modelo todavía se fabrica/vende activamente. Desafortunadamente, ya lo volví a armar y odio desarmar todo para verificar el código de fecha. :)
sbprojects.com/knowledge/ir/index.php es otro buen recurso para los protocolos de infrarrojos.
@dwelch después de revisar esos protocolos, creo que este se parece más al protocolo JVC... excepto que hay 5 bytes de datos en lugar de los 2 típicos. ¿Suena razonable? Supongo que el calentador envía el punto de ajuste de temperatura actual para sincronizar los controles remotos que también tenían pantallas LED.
¿Cómo se codificaría la temperatura, en su experiencia previa? ¿Como un valor Celsius? Voy a intentar capturar más formas de onda a diferentes temperaturas para ver qué está cambiando.
Ryan, ¿terminaste esto? Estaba planeando publicar la guía de interfaz completa junto con el código fuente tanto para la entrada como para la salida cuando esté completa. Quería probar la interfaz con mi calentador de agua sin tanque EcoSmart.
@Ben Ahora configuré un repositorio de GitHub para este proyecto. Todavía no he escrito funciones de "lectura", pero la funcionalidad de escritura debería ser completamente funcional. github.com/ryangriggs/EcoSmartLib

Respuestas (1)

El protocolo de datos que mostró en el documento vinculado se parece a la forma de onda de modulación común a algunos controles remotos IR. Es posible que la configuración por cable que usted describe pueda diseñarse de manera que el enlace del control remoto también funcione si se conecta un módulo receptor IR en el cabezal remoto. (Sin embargo, las comunicaciones serían de una manera).

En este documento se describen varios protocolos IR comunes .

Me aventuraría a adivinar que los dos tiempos más largos (7mseg/4mseg) son la sincronización de inicio para la transmisión. Después del tiempo de sincronización, los datos parecen estar codificados en celdas de bits que tienen un ancho de codificación de 1440 usec como modulación Manchester. Un nivel de datos es 720usec alto al comienzo de la celda y 720usec bajo en la segunda mitad de la celda. El nivel de datos opuesto está representado por la línea de datos baja para 720usec al comienzo de la celda y alta en la segunda mitad de la celda de bits.

Este definitivamente no es un formato asíncrono utilizado por un protocolo UART típico.

¡GUAU, esa fue una respuesta rápida! Gracias Michael, estoy investigando la codificación de modulación de Manchester ahora. ¡Realmente aprecio tu aporte!
En la codificación Manchester, la muestra más larga debe ser el doble que la corta. Aquí puedo ver periodos de 24mS, 7ms, 4ms y 720uS, ninguno cumple esa condición. ¿Dónde has visto 1440us?
dos tiempos de 720 us que se muestran cerca del frente de la forma de onda de "datos".
eso parece una forma de onda IR, no importa con qué protocolo se alinee, tiene al menos algunos controles y tiene un alcance o algo con lo que ya ha capturado esto. El largo/ordenado al frente se ve como el patrón de sincronización, y luego considere los cortos, del mismo tamaño que los mínimos para ser ceros y los máximos más largos para ser unos.
lo ideal es que desee que el led y la frecuencia portadora coincidan correctamente, pero puede sacrificar la distancia y usar 40K o 38K. Sin embargo, lo primero que haría es mientras monitorea esta interfaz, tome cualquier control remoto IR que tenga y apúntelo a la cosa, si genera formas de onda en esta interfaz, entonces ahí lo tiene, es simplemente tonto y los pasa, y " todo lo que necesita hacer" es generar la señal ir correcta.
si desea conectarse directamente, entonces eso es lo más fácil, simplemente genere las formas de onda que ha grabado.
@dwelch ¡Gracias por tu percepción! También estaba pensando que el patrón H/L corto parecía un '0' y el alto largo/bajo bajo parecía un '1'. (o tal vez están invertidos) Los traduje y obtuve 00 FF 0F F0 00 00 18 01 02 10. Aparentemente, todos los mensajes tienen 5 bytes, si esta es la codificación correcta. También parece que los mensajes se repiten al menos una vez.
Con respecto a la captura de la forma de onda, utilicé mi alcance, pero no tengo una buena manera de guardar la forma de onda completa y publicarla. Intenté guardar un archivo CSV, pero es demasiado grande (más de 200 MB) al descargar toda la memoria y demasiado inexacto al descargar solo la pantalla. (Es un osciloscopio Rigol 1054z) Así que fui a la "vieja escuela" y me desplacé por la forma de onda una pantalla a la vez, registrando los resultados en una hoja de papel como código Morse. Eso también elimina todo el ruido de la señal, lo que facilita la reproducción de los datos reales más adelante. :) ¡Definitivamente estoy abierto a sugerencias para una captura más fácil!
conecte con cuidado un arduino u otra entrada a esta señal (suponiendo que sea 5V o 3.3) y escriba una pequeña cantidad de software para buscar el patrón y decodificar los bits, e imprimirlos en los microcontroladores uart en hexadecimal o lo que sea...
exactamente lo mismo que uno haría si decodificara IR de un módulo receptor...
el que vinculaste arriba me parece 0x0F3C006124 y ese último pulso es un poco extraño, así que tal vez sea un pulso de parada o algo así o una repetición.
si no desea decodificar completamente con un microcontrolador, busque el pulso de inicio y mida el tiempo entre los cambios de estado (usando un temporizador en el mcu) e imprima esos deltas de tiempo, cuando alcance un tiempo que sea más largo que un pulso de inicio , luego vuelva a esperar un pulso de inicio.
no hay regla de que tenga que ajustarse a un protocolo IR si sucede, genial, de cualquier manera, ya que puede causar estas señales y tiene un arduino, entonces debería poder usar el arduino con unas pocas (docenas) líneas de código para contar la duración de los pulsos. y luego eventualmente decodificar.
Protocolo serial asíncrono de ingeniería inversa para el calentador de agua sin tanque EcoSmart
RespuestasAquíPolítica de privacidad1y, 0v