Go Down

Topic: Comunicacion bus datos desconocido a arduino. (Read 484 times) previous topic - next topic

doctordelpino

Buenas.
Lo que quiero hacer es comunicar un arduino con una instalacion de aire acondicionado  que usa un bus de datos de un cable. La marca del aparato es Hiyasu (submarca de Fujitsu). La instalacion es por conductos y dispongo de un termostato con tres cables (GND, VCC y data). Aparte he comprado otro termostato para hacer pruebas, el cual tengo conectado al bus en modo "slave".
Hasta ahora he hecho lecturas del bus con un analizador lógico chino, en diferentes estados (OFF, 18º, 30º, fan 4....) Tengo registradas las lecturas y las he traducido a ceros y unos. Pero no se interpretarlas, no se que protocolo usa fujistu ni hay documentacion sobre ella. Hay muchas cosas sobre infrarrojos pero no sobre el protocolo del bus por cable, no se si se comportan igual.
He visto que hay otras personas trabajando en ello, con  mas conocimientos que yo (hackaday.io/project/19473), pero no he encontrado nada que me ayude y llevo un mes parado con esto. (Este ultimo link es practicamente mi situacion concreta).  No suelo pedir ayuda, pero esto me sobrepasa y no se por donde seguir.... necesito una orientacion.

Dispongo del mando termostato original 
y una copia que compre para pruebas. Conozco los modelos de chips que llevan dichos mandos y la unidad central interna del sistema. Tengo un analizador lógico y un osciloscopio digital. Y tengo pocos conocimientos (pero buena disposicion y ganas), y siento que se abre un gran abanico de escenarios. No se continuar.

No se si es buena idea  probar a utilizar el bus de datos con la biblioteca remoteIR pero directamente al bus, es decir, sin el led y el receptor IR. Intentare copiar las secuencias de bits y reenviarlas al bus.

Me gustaria saber si alguien dispone de documentacion acerca de como interpretar los datos de buses desconocidos, o mas concretamente del protocolo de fujistu. Y de como continuar el tema.
Muchas gracias de antemano

Lucario448

No se si es buena idea  probar a utilizar el bus de datos con la biblioteca remoteIR pero directamente al bus, es decir, sin el led y el receptor IR. Intentare copiar las secuencias de bits y reenviarlas al bus.
Si el ancho de pulsos (y todo el protocolo en sí) no coincide con el original, no va a funcionar. Primero analiza detenidamente.


Me gustaria saber si alguien dispone de documentacion acerca de como interpretar los datos de buses desconocidos, o mas concretamente del protocolo de fujistu.
Si nadie lo tiene, menos yo.

Sin embargo, si has seguido las pautas del que ha hecho el intento; al final verás que dice:
Quote
My first hypothesis was the remote unit worked a lot like an IR remote - every button press sent the complete state to the outdoor unit. If this was the case, it should just be a matter of hooking up a DSO (I have the LabNation SmartScope), copying the signal and replaying it via a microcontroller.
De ser cierto, entonces la comunicación es unidireccional y lo único que hay que hacer es muestrear los trenes de pulsos cada vez que se cambie un parámetro. La clave está en que si el control debe transmitir siempre el valor de todos los paramétros, modificar uno de estos debería alterar la secuencia de bits.

En cada muestreo, lo que haría es cambiar un parámetro (ej.: temperatura, velocidad de ventilador, dirección del viento, etc.) a la vez a todos sus valores posibles; para así fácilmente poder determinar exactamente cuáles bits de la secuencia corresponden a cada uno. Lo difícil es darse cuenta si en la secuencia hay código de detección de errores; que muy probablemente sea un bit de paridad o XOR de 8 bits.

Al ser comunicación serial carente de señal de reloj, me hace pensar que el protocolo utilizado es similar al UART (coloquialmente conocido como "de puerto serial"); donde el tiempo de los pulsos (análogamente "tasa de baudios") se tiene que respetar y evidentemente debe haber un bit de inicio (para notificar al receptor que debe recibir el mensaje entrante) y al menos uno de parada (lapso "de reposo" establecido por protocolo para preparar al receptor ante otra inmediata trama de datos).



Si dicho protocolo se comprueba que no es UART, sigue siendo posible al menos emularlo (bit-bang) por software. El problema es que si el margen de error es muy pequeño, puede que haya que desechar el uso de digitalWrite (tarda 8-10 microsegundos a 16 MHz) y deshabilitar las interrupciones (la que hace posible millis(), micros() y delay() tarda entre 3-8 microsegundos a 16 MHz).

doctordelpino

#2
Apr 01, 2018, 11:38 pm Last Edit: Apr 01, 2018, 11:41 pm by doctordelpino Reason: añadir tag a las fotos
Gracias Lucario448:
Con lo que me cuentas, ya me das pautas para seguir investigando. Voy a sacar todos los estados que pueda para tratar de entender el protocolo. Tendre en cuenta lo de la secuencia de deteccion de errores.
Tratare igualmente de emularlo con lo que me indicas; lo pasare por el analizador logico y a ver si coincide.
Lo que si que he visto, es que cada tren de ondas esta compuesto por tres "vagones" muy similares pero no iguales. El Primer Vagon es "emitido" por la unidad central, el segundo por el termostado que actúa como master, y el tercero por el termostato que compré para pruebas y que esta configurado como Slave. Lo he averiguado colocando una sonda del analizador de datos en el pin Tx de los chips principales de ambos termostatos. Asimismo, la emisión es justo inversa, y hay un amplificador operacional que lo pasa de 5 a 1 voltios e invierte la onda (entre el pin Tx del chip y la linea del bus).
Adjunto foto de la captura del bus, tal como lo estoy haciendo. Se ve cada tren por separado, aunque en la secuencia real van los tres seguidos.



La primera es con todo apagado, la señal en reposo. La segunda es del estado ON, ventilador 4, Modo Calor (las tres primeras si la orden se programa desde el mando Master y las tres segundas desde el mando "slave)
Si alguien ve la necesidad de subir mas fotos y/o esquemas de lo que hago o propuestas de lo que puedo hacer, por favor, que lo indique.
Cuando tenga guardados mas estados, podre un excel como hace el señor de Hackaday. https://hackaday.io/project/19473 a ver que mas se puede hacer. También voy a escribirle a él directamente (Myles Eftos), a ver si ha hecho progresos. Os cuento los avances según vaya pudiendo progresar.
Gracias de antemano por la ayuda.

Lucario448

También voy a escribirle a él directamente (Myles Eftos), a ver si ha hecho progresos.
Hazlo, porque honestamente me tiene confundido el hecho de que el control reciba retroalimentación. De primera impresión hubiera pensado que es para mantener sincronizados los parámetros de la unidad central con los memorizados y mostrados por el control; pero esta afirmación se ve refutada por el hecho de que las secuencias no coinciden aún cuando (creo yo) ambas partes ya están sincronizadas.
Lo del control como "esclavo" tampoco lo entendí.


Según lo que decía Myles Eftos, sólo de tres cosas estamos seguros:
  • El ancho del pulso (bit) es de 2 ms (¿entonces 500 bps?).
  • Tiene bit de inicio y de parada (sólo en eso coincide con UART).
  • La secuencia que el control emite efectivamente se ve alterada por los valores de sus parámetros.

De momento, todo lo demás sería especulación hasta que verdaderamente se haya comprobado...

Go Up