Los decoders para accesorios que se utilizan en mi tren funcionan bajo protocolo DCC, del que se dispone de una gran cantidad de material en la red y facilita el montaje del circuito base. Además, los componentes necesarios para el circuito son bastante comunes y fáciles de encontrar.
Por el contrario, la información para un Decoder Motorota/Märklin, no es tan abundante ni tampoco es fácil localizar alguno de los componentes necesarios aquí en Valencia. Por supuesto, estan los diseños del Dr. König, pero, teniendo en mente que al final el control es por ordenador y que se va a usar estar usando un sistema multiprotocolo, la opción más lógica es DCC.
Por su simplicidad me baso en el cirucito de «Le monde du DCC» (LMDD) que como casi todos está a su vez basado en los diseños del grupo MERG.
Los chicos de Rocrail también tienen su propio diseño, el ORA-1, muy interesante ya que es fácilmente ampliable para soportar el control de motores en lugar de solenoides. El problema de su circuito es que no utilizan un PIC Microchip como cerebro del sistema, y de nuevo me veo con problemas para conseguir el Atmel utilizado.
Mis decoders, partiendo del circuito base de LMDD también toman cosas prestados de otro diseño de referencia, el de Paco Cañadas en su página POW.
El circuito electrónico no tiene mucha historia. La entrada de datos digitales está optoacoplada, y la alimentación viene de un trafo externo, lo cual evita el parpadeo de la alimentación digital, y el pico de consumo cuando se activa un relé no afecta al resto de elementos, es decir que no disminuye el brillo de ninguna lámpara.
Las salidas hacia los solenoides pasan por un driver de corriente que garantiza 500 mA.. Contamos también con un LED que sirve para confirmar la entrada de datos cuando el decoder es programado.
En un principio la fuente de alimentación externa que iba a utilizar era la propia del ordenador, sin embargo, tras hacer varias pruebas utilizo una fuente de continua de 18V y 3,5 A. También probé con una vieja fuente de un portatil que da 20V y 6A, pero la corriente puede ser excesiva para algunos elementos.
Para aislar completamente la alimentación digital de la alimentación del ordenador se debe aislar la bombillita que se usa en los desvíos. Las opciones son:
- Eliminar la bombilla
- Aislar la bombilla. No parece una opción fácil
- Sustituir la bombilla por un LED
La inteligencia viene, obviamente, con el programa que se carga en el PIC.
El código es bastante fácil de entender, la gente que ha ido trabajando en él se ha molestado en dejarlo todo perfectamente comentado, con lo que es fácil encontrar donde modificarlo.
Las variables de configuración (CV) típicas de DCC se pueden tocar directamente al programar el PIC, o más tarde mediante los comandos de programación del decoder.
Se soportan las siguientes CV:
• 513: que contiene los 6 bits de menor peso de la dirección del decoder.
Por defecto 0
• 521: que contiene los 3 bits de mayor peso de la dirección del decoder.
Por defecto 0
Con lo que la dirección por defecto es 0.
• 514: que especifica que puertas estarán operativas y cuales no, 7 bits, 0 inactiva 1 activa.
Por defecto todas activas: 255
• 515: Tiempo de activación para las puertas 1 y 2 (solenoide 1).
• 516: Tiempo de activación para las puertas 3 y 4 (solenoide 2).
• 517: Tiempo de activación para las puertas 5 y 6 (solenoide 3).
• 518: Tiempo de activación para las puertas 7 y 8 (solenoide 4).
Por defecto todos a 10
Los tiempos de activación se codifican en pasos de 10ms con un byte. Con lo que el tiempo de activación por defecto es de 100ms. Para una activación continua, en el caso de querer usar los decoders para gestionar luces en lugar de solenoides, se indica con un tiempo de activación igual a cero.
Como digo, se pueden modificar las CV al compilar el programa, o directamente configurándolas desde una central digital, el LED de programación parpadea para informar que se ha completado el proceso.
Las modificaciones que he introducido al software original de MERG permiten almacenar las últimas salidas activas. De esta forma, cuando se reinicia volvemos al último estado guardado, lo que es imprescindible en el control de luces – incluyendo semáforos sin relés – ya que de otra forma cada vez que se iniciara la maqueta sería necesario refrescar el decoder manualmente con las instrucciones para volver al último estado antes del apagado (luces encendidas o apagadas, semáforos en rojo o verde)
Como ventaja adicional al iniciar también actualiza las salidas a elementos conmutados, refrescando su posición. En una situación normal el resultado será un pequeño impulso que no modificará el desvío, pero si éste hubiera sido modificado manualmente, el reset del decoder se encargaría de devolverlo al estado deseado.
Otra solución alternativa al refresco de la última posición desde los decodificadores, sería actualizar las salidas desde el control por PC.