Go Down

Topic: Información sobre la placa de salida de relés Ademco 4204 (Read 1 time) previous topic - next topic

surbyte

Si hicieras una rutina basada en RCSwitch podrias decodificar eso, porque veo que si tomas el pulso mas corto como indicador de bit, pareciera leerse algo ahi. Es mas solo hay que sincronizarlo para descartar lo anterior.

Qué opinas?

Anilandro

Sí, es una buena idea, Surbyte, utilizar las señales más cortas como referencia de pasos de reloj y averiguar cuantos bits contiene la "palabra" significativa, pero antes debo "limpiar" esta secuencia de señales, que presuntamente procede de la placa principal, de las que puedan intercalar los otros módulos, que además es necesario que estén conectados a los dos buses porque si no no tengo manera de disparar el evento de alarma ni luego de detenerlo. Además está la incógnita de las señales distintas pero que hacen lo mismo... eso es lo que menos me cuadra... no es lógico.

...Cuando tenga claros estos temas podré realizar más pruebas, porque tengo 18 emisores (101-118) y de 5 módulos de relé 4204, con lo cual, supongo, dispondré de suficientes ejemplos para poder identificar las direcciones y las órdenes básicas...

Saludos

Llorens

surbyte

Si, esta claro, yo hablo solo sobre lo que has marcado pero hay que SEPARAR todo lo que ahora parece basura que no lo es.


Anilandro

He seguido trabajando en el tema del análisis de datos Ademco y he construido algunos circuitos para ayudar a controlar el flujo en buses comunes...

El primero es la idea de utilizar una pequeña resistencia entre cada pin del módulo y el bus común entre ellos. El pin va además a la entrada  + de un operacional LM324, y el - va al bus común... entonces, port la caída que provoca la resistencia, si la salida procede del pin siempre tendrá una tensión algo mayor que si procede del bus, y la salida del operacional sera a un 1, y si es al revés será un 0...

El circuito básico está cuadruplicado y por tanto puede procesar las señales de una línea de bus y cuatro módulos de manera simultánea...



Enlace directo a la imagen a tamaño normal

...Acabé el circuito, lo puse en marcha conectando el - común a la línea de "salida de datos" y los + a los pines de igual nombre de los cuatro módulos: central, 4204, receptor y consola, y la sorpresa fue que no parecía hacer nada, el canal Saleae 0 correspondiente a la placa Central siempre estaba alto y los restantes siempre bajos. Las salidas del operacional no respondían además a los datos digitales...

Pensando un poco llegué a la conclusión que era normal que no salieran las señales digitales en la salida de los operacionales, puesto que sea cual sea el módulo que genera una señal hacia el bus, la tensión de la entrada + siempre será proporcionalmente mayor a la - ...Entonces, el hecho que el resultado del pin de salida de datos de la Central siempre estuviera a 1 podía indicar que era un bus direccional, en que estas placa habla y el resto de módulos escuchan, algo similar al MOSI del protocolo SPI, aunque en este caso asíncrono...

Para certificar si estas suposiciones eran acertadas o era un mal funcionamiento imprevisto del circuito, construí otro más sencillo, sin operacionales, sólo con diodos y algunas resistencias de descarga...



Enlace directo a la imagen a tamaño normal

Si los buses eran realmente unidireccionales, los diodos deberían poder discernir y separar los datos de cada módulo, y por tanto analizar el destino de las órdenes, su respuesta por el bus "entrada de datos" y la acción externa que el módulo realice...

En la siguiente imagen se observan más detalles sobre este nuevo circuito, que de certificar lo que pienso aún podrá reducirse más... Las resistencias de 1 K son para evitar que si la entrada de un módulo es de alta impedancia o tipo MOS, el diodo cargue el "condensador" impidiendo que este regrese a valores de señal 0, con lo cual el módulo dejará de responder...



Enlace directo a la imagen a tamaño normal

Pues bien, ayer noche realicé las primeras pruebas y el resultado coincide con lo que pensaba. El bus "salida de datos" sólo es de envío de señales desde la placa Central al resto de módulos, los cuales contestan todos ellos a través del bus "entrada de datos", son en efecto buses direccionales. De tal manera que enviando al canal Saleae 0 la "salida de datos" y al Saleae 1, 2 y 3, las "entradas de datos" correspondientes al receptor, a la consola y a la placa de relés 4204, puede diferenciarse perfectamente el tráfico de órdenes-respuestas...

He podido ver las órdenes de interrogación del receptor, el intercambio de datos entre la Central y la consola, y entre la central y el módulo de relés... De todas formas, no todos los tipos de pregunta-respuesta están demasiado claros, de vez en cuando hay intercambios que no coinciden con eventos externos, cuyo sentido también deberá resolverse...

Continuará...

Saludos a todos

Llorens


Anilandro

Con los datos obtenidos a partir de los dos circuitos anteriores, he montado un tercero que supongo será definitivo. De hecho es más sencillo, ya que consta de tan sólo tres diodos y unas pocas resistencias adaptadoras de nivel.

Una vez constatado que los buses son unidireccionales, como los MOSI y MISO del protocolo SPI, aunque sin línea de reloj ni de CS, el denominado "Salida de datos", equivalente al MOSI (Master Output Slave Input) estará conectado directamente al resto de los módulos, ya que la señal sólo puede provenir de "master", es decir, de la placa de la centralita...





...En cambio los "retornos" del resto de módulos hacia la línea "Entrada de datos" de la Centralita van a una OR formada por tres diodos, y por tanto en cada ánodo tenemos exclusivamente la señal procedente de cada módulo: el receptor, la consola o la placa de relés.

Así el analizador lógico Saleae puede grabar simultáneamente las señales digitales de cinco canales distintos:

- MOSI de la Centralita hacia el resto de módulos (Salida de datos)
- MISO "retorno" general del resto de módulos (Entrada de datos)
- MISO sólo del Receptor
- MISO sólo de la Consola
- MISO sólo del módulo de salida de relés 4204
- Activación de un relé determinado del 4204

El Saleae conectado al circuito...



...Y todo el conjunto conectado a los módulos...



Los datos obtenidos se identifican muy bien, pero intentar averiguar los códigos binarios a partir de la imagen del Saleae en muy tedioso y es fácil equivocarse. Para intentar simplificarlo me he hecho una imagen en forma de plantilla gráfica con columnas semitransparentes que puede ser superpuesta a la imagen de la señal a analizar través del Photoshop y que a igual resolución marca los tiempos cada 0,21 mS, que corresponde más o menos al impulso de reloj que he detectado visualmente en las señales Ademco, pero al final resulta igualmente engorroso, por este motivo he pensado en un sistema automático a partir de hardware-sofware para decodificarlas y también poder reproducirlas y enviarlas a los módulos...

El Saleae también puede exportar los datos gráficos en formato numérico "cvs" (datos separados por comas), que pueden ser abiertos con el Excel o incluso con el block de notas. En estos datos se basan en los cambios de nivel de la señal y contienen los valores de tiempo en segundos con 6 decimales, contados desde el inicio de la grabación o bien desde un fragmento acotado por marcadores, y la transición que ocurre en cada uno de ellos, si es un 0 o un 1.

...Mi idea es enviar estos datos al Arduino vía serie mediante un programa de Visual Basic (que ya tengo a medio hacer) y que el programa de Arduino genere luego el "frame" digital correspondiente con una resolución de pulsos de al menos 0,01 mS, utilizando para ello la reprogramación de los temporizadores internos. Luego sólo hará falta cambiar los niveles de TTL 0-5 V a 0-12 Volts e insertar tales señales en los módulos a controlar para ver cómo responden...

...Así que es éstas estoy...

Continuará...

Saludos a todos

Llorens

 


Anilandro

Ya tengo funcionando un programita de Visual Basic que me captura los datos en csv provenientes del analizador lógico Saleae, me los regulariza acortando los decimales a 6, una resolución teórica de 1 uS para señales que las más cortas son de 0,21 mS, y me los envía al Arduino vía puerto serie...



Estas señales puedo configurarlas como de lógica positiva o negativa, para que el Arduino las pueda generar de las dos formas. En caso de señales de la central Ademco son de lógica negativa, en cambio la respuesta de los módulos es positiva...

Estos datos están estructurados de forma muy sencilla, ya que indican el tiempo en segundos en que la señal presenta un flanco, indicando tras la coma el sentido de este flanco, si el valor lógico cae a cero o a uno. Por la propia estructura los flancos 0 y 1 son alternativos, por lo cual no es necesario enviar las comas y los valores que hay tras ellas. Basta con enviar el valor lógico del primer flanco...

El programa es experimental pero ya funciona... mañana me meteré con el programa de Arduino, que también tengo casi hecho, ya que recibe los datos y los guarda. Sólo faltará añadir la rutina de generación del frame TTL 0-5 Volts, que con un simple transistor subiré a lógica 0-12 Volts...

Continuará...

Saludos a todos

Llorens

Anilandro

Estos días de reclusión forzosa por el tema del coronavirus los he aprovechado en casa para seguir con el proyecto del manejo de los módulos Ademco. Anteriormente ya mostré un primer programa de Visual Basic que aceptaba datos en csv (datos separados por comas) procedentes del analizador lógico Saleae, y tras procesarlos debería enviarlos a una placa Arduino para que sintetizara una señal idéntica con que atacar los módulos Ademco...

Pues bien, de esta primera versión "servidor" y de su correspondiente "cliente" en Arduino vinieron otras porque he tenido muchos problemas con la transmisión de datos serie, tal vez por un asunto de bufferes llenos, o por cierta desincronización entre lo que un módulo escribe y el otro lee... no lo sé. Cuando eran pocos datos la cosa iba bien, pero cuando superaban un cierto número comenzaba a estropearse, perdiéndose bytes por el camino...

...Al final lo arreglé aumentando la velocidad serie a 57.600, pero sigo sin saber exactamente que ocurría, ya que llegué a pausar muchísimo la tasa de transferencia para que no hubiera solapamientos, y ni así conseguía que funcionase sin errores...

Vale, el VB me acepta los datos csv, me los traduce a una cadena y los envía al Arduino. Esta cadena está formada por octetos de bytes, es decir, por series de números enteros de 8 cifras que contienen los microsegundos de tiempo (siempre referentes al inicio) en que ocurren las transiciones de las señales digitales, cuando los flancos pasan de 0 a 1 o viceversa. También envía la referencia de la lógica, si es positiva o negativa (como ocurre en este caso del Ademco)

El Arduino los recibe, recupera los valores numéricos de los octetos (ya que se transmiten en código ASCII) y los guarda en un array, luego otra función convierte estos tiempos absolutos en relativos, al obtener las diferencias de tiempo entre transiciones, lo que equivale a la duración de las marcas y espacios de las señales digitales. Finalmente, otra función sintetiza de nuevo la señal digital, que ahora envío al Saleae para comparar su integridad con la señal original, pero cuyo destino será enviarla a los módulos de relé Ademco para ver como responden.

Pues tras muchos cambios en el software y de corregir algunos bugs, ayer noche conseguí que funcionara sin errores, con una resolución de señal de salida de 4 uS, lo cual es excelente para señales cuya menor duración es de 210 uS. Hoy me gustaría construir un pequeño circuito adaptador de nivel TTL 5-12 V y probarlo con uno de los módulos Ademco 4204, a ver si consigo lo que era la idea inicial de este proyecto, activar y desactivar los relés de salida...

También veo posibilidades de modificación al programa Visual Basic, como que además de procesar los datos csv procedentes del Saleae, pueda decodificar dichas señales a forma binaria, como por ejemplo 100110011101, y también acepte datos directos, tanto de diferencias de tiempo, como poder escribir señales digitales, especificando además la frecuencia o el período de reloj.

...Si todo este trabajo lo realiza el Visual Basic, la secuencia de Arduino será aún más simple que ahora, ya que al recibir directamente las diferencias de tiempos, se limitará a la síntesis de señal...

Continuará

Saludos a todos

Llorens

Go Up