Bueno, por fin, tras casi un año en el dique seco, he completado el montaje de mis primeros dos decoders para accesorios.
Me decidí por un diseño bajo protocolo DCC por la gran cantidad de material que hay en la red y la facilidad de montaje del circuito base. Además, los componentes necesarios para el montaje son bastante comunes y fáciles de encontrar.
Por el contrario, la información para un Decoder Motorota/Märklin, no era tan abundante ni tampoco me era fácil localizar alguno de los componentes necesarios aquí en Valencia. Por supuesto, estaban los diseños del Dr. König y alguno más que conseguí localizar en Internet, pero, teniendo en mente que al final el control iba a ser por ordenador y que en cualquier caso iba a estar usando un sistema multiprotocolo, la opción más lógica era DCC.
Por su simplicidad me base 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. La versión que he implementado (DCCDecoderManolo v2.0) tan sólo toma prestado el diseño de la fuente de alimentación para el PIC. Sin embargo, para la próxima versión (3.0) he decidido adoptar también la entrada de datos optoacoplada para poder usar un trafo independiente. En realidad, planeo utilizar directamente los 12v en continua que ofrece la fuente de alimentación del ordenador, con lo que mi diseño simplifica un poco la fuente de alimentación para el PIC.
La solución optoacoplada también la contempla el ORA-1, con lo que en lugar de utilizar la solución de Paco Cañadas, que incluye un pulsador para controlar la programación del decoder, me he basado en la de Rocrail. Yo de momento no creo que vaya a necesitar el pulsador, aunque ya veremos si más adelante me planteo incluirlo.
Por ahora el siguiente paso sería construir un prototipo de la versión 3 para comprobar que efectivamente se puede utilizar la fuente de alimentación del ordenador para controlar los desvíos. He hecho pruebas en modo «analógico», es decir ofreciéndole alimentación a un desvío aislado desde el ordenador simulando un impulso a mano, y parece que funciona.
Pero bueno, centrémonos en la versión 2 que es la que ya he podido probar. El circuito electrónico no tiene mucha historia. De la misma entrada de datos digitales, se toma la alimentación para los solenoides – o luces – y el PIC. Se rectifica por un puente de diodos y se estabiliza a 5v para el microcontrolador. 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.
La inteligencia viene, obviamente, con el programa que se carga en el PIC. En mi caso tomé la versión original de MERG y simplemente configuré el programa con las entradas y salidas adecuadas conforme al diseño de LMDD. De hecho, buena parte en el retraso para completar este decoder viene de los problemas que tuve para hacer funcionar de forma correcta el sofware. El diseño de LMDD no incluía el código fuente, sólo la versión compilada, y no conseguía que me permitiera programar el decoder. Intenté durante bastante tiempo decompilar el programa e identificar el error… al final la solución fue volver al origen (MERG).
En cuanto al 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 fue 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. Yo he probado con Rocrail y una conexión casera al puerto serie utilizando una estación delta como booster y el funcionamiento es perfecto, el LED de programación parpadea para informar que se ha completado el proceso.
En conclusión, un diseño muy sencillo y fácil de realizar, aunque en estos momentos mis ojos están puestos en la versión 3… y no tengo muy claro que haré con los dos prototipos construidos de la versión 2 (más una tercera placa aún no soldada).
Dejo los esquemáticos y diseño de placa para la versión 2 y 3 de mis decoders. También dejo el código para el PIC, código fuente y versión compilada.
DCCDecoderManolo v2.0
DCCDecoderManolo v3.0
DCCDecoderManolo software
Hola
Están muy bien tus diseños y proyectos.Yo quiero empezar al digital ahora.¿Que central CPU y booster te has construido con tanto éxito ? En internet hay algunas pero interesa saber de tu experiencia para ir más seguro.
Saludos
Juan
Mi correo barteses@yahoo.es
Comentario por Juan — 1 junio 2010 @ 0:04
Hola Juan,
La información la tienes también en l apágina:
– CPU usada
– Booster
Como ves la CPU es un PC viejo, lo único crítico es que tenga un puerto serie.
El Booster que he construído ahora mismo es más bien un primer driver de laimentación. Coge la señan del puerto serie y la amplifica – hace más cosas, pero lo básico es esto.
Para generar las señales yo utilizo Rocrail.
Comentario por Manolo — 1 junio 2010 @ 21:48
Hola quiero usar tus decos para activar cemaforos y otras cosas con RocRail pero no encuentro las direcciones; para deco 1 y salida 1 por ejemplo. muchas gracias por tu aporte son de gran utilidad.
Saludos
Comentario por Adrian Leal — 11 abril 2015 @ 16:57
Hola,
Si el deco está bienprogramado, deco 1 y salida 1, están justo en la dirección 1 puerto 1.
No deberías tener más problemas. Una forma de saber si hay algún problema a nivel HW es con Rocrail usar el menu de accesorios y probar rápidamente las primeras direcciones.
Saludos,
Comentario por Manolo — 11 abril 2015 @ 17:18