Control DCC: algunas ideas

Hola,

En este caso voy a empezar la casa por la ventana: en lugar de presentar un circuito de aplicación, me gustaría comentar las distintas posibilidades y aplicaciones que tiene el sistema DCC. En este hilo me gustaría que aportáramos tanto ideas como peticiones de soluciones concretas a propuestas particulares que pudiéramos comentar todos.

Por mi parte estaría dispuesto a tratar de convertir las ideas en circuitos, en la medida en que me sea posible.

Estos circuitos no los he construido porque no tengo maqueta; sólo un circuito de vías para rodar los trenes y probar la circuitería que voy comentando.

El invento del DCC es maravilloso. Según su primera idea: dos hilos para todo, aunque vemos como todo se va “babelizando” a medida que se van aumentando las prestaciones.

Siempre me horrorizó el ver el laberinto que representa, por ejemplo, un panel de control de desvíos: haces de cables para ir, unos a los motores de los desvíos, otros a los LEDs indicadores. A esto además hay que sumar la distancia hasta los puntos de aplicación.

En mi caso empecé por dos veces un panel de control: la primera vez no pasé de hacer los agujeros en la placa; la segunda llegué a empezar a conectar alguno de los LEDs…, y desistí. En su lugar me tiré a la piscina y preparé el panel en la pantalla del PC, empleando paint, y luego “pues_ya_que” estaba en ello di el salto a crear mi propio control total DCC para los ensayos que hago en mis vías. Para los desvíos utilizo servos y los controlo ahora por el puerto serie RS232; inicialmente lo hice con comandos DCC.

Hace ya tiempo, desde que comprobé que no resulta tan complicada la decodificación de la señal DCC, para lo básico, he venido dándole vueltas a las posibilidades de control que nos brinda. En el mundo digital “la imaginación es el límite”, cosa casi cierta.

Todo esto son ideas que aún no he concretado, pero que considero factibles. De manera general pondría dos circuitos decodificadores: el principal, que hace las operaciones deseadas, tan próximo como sea posible al lugar donde aplicarse; y el auxiliar, tan a la vista como deseemos. Tanto uno como otro reciben los comandos a través de la vía; pero sólo los comandos (por medio de optoacopladores). La alimentación correría a cargo de unos hilos generales que supondré proporcionan 12V, 5V y masa (por ejemplo la fuente de un PC, como aconsejan muchos foreros) para no sobrecargar a la central DCC, ya que estos dispositivos son estáticos y no precisan alimentarse de la vía.

Y mediante las funciones disponibles en la central se controlarían los dispositivos implicados, dándoles funcionalidad a medida. Esta funcionalidad puede adaptarse a cada caso mediante las variables de configuración que podemos programar para cada receptor.

Diagrama general.png (26.5 KiB) Visto 5347 veces

Asignamos a cada uno de los receptores (decodificadores) la misma dirección. En el de aplicación diseñamos el circuito apropiado para actuar (encendido de LEDs, control de servos, disparo de electroimanes, control de motor CC…); y en el indicador, LEDs que informen del funcionamiento. Ya sólo queda escribir el programa adecuado en cada uno.

El “pero” de este sistema es que no admite la realimentación del circuito de aplicación al indicador, porque la información sólo viaja desde la central a la vía. No tendrá importancia en los controles manuales porque los dos receptores recibirán la misma información, sin problemas de contactos, pero en funcionamiento automático, el indicador no puede saber en qué momento cambiará el de aplicación (salvo que se realimentara desde uno al otro, cosa que ya complicaría el sistema, perdiendo sencillez). Aunque mediante un solo hilo entre ambos circuitos, sería posible que el de aplicación informara al indicador de su estado.

Iluminación de la estación:

Podemos imaginar varios circuitos:
- andenes
- vestíbulo
- oficinas
- vivienda del jefe de estación (Iluminación doméstica, chimenea, TV…)
- etc.
El circuito de aplicación sería el apropiado para encender LEDs o lámparas, con varias salidas alimentadas por medio de un circuito del tipo ULN2003. Cada circuito podría ser gobernado por una función, y, puestos a programar, se me ocurre, en principio, que el modo de funcionamiento puede ser manual (cada función un circuito) o automático, con un encendido programado por medio de cvs.
El circuito indicador en el panel podría estar formado por LEDs que se enciendan según el circuito actuado.

Estos dos circuitos pueden estar tan distantes como sea necesario. Su conexión viene dada por el hecho de recibir los mismos comandos.

Iluminación de una población:

Similar al anterior:
- Luces “día” y “noche”
- calles
- comercios
- carteles publicitarios
- Oficinas
- Viviendas

Con todas las variantes que admiten otros circuitos en ellos. Por ejemplo los circuitos de fuego, chimenea, iluminación doméstica, simulador de TV, etc., pueden alimentarse desde las salidas del circuito de aplicación. Se podría controlar la intensidad luminosa de cada circuito.
También puede hacerse el funcionamiento manual o automático, incluso casi aleatorio.

Control de desvíos:

Podrían diseñarse circuitos de aplicación para generar las salidas por impulsos (mediante transistores de potencia), para los desvíos basados en solenoides; incluso hacer su funcionamiento “por descarga de condensador” para proteger las bobinas de posibles sobre-corrientes. Podrían ser salidas simples para control de servos, siendo programable mediante cvs las posiciones inicial y final del servo, la velocidad de giro, etc.

El control y la posición de los desvíos podría realizarse con facilidad por medio de las teclas de función de la central; por ejemplo ‘no activada’ = vía directa y ‘activada’ = vía desviada.

Creo que no sería complicado programar itinerarios asignándolos también a funciones.

El indicador dispondría de LEDs para mostrar la posición de cada desvío según las órdenes recibidas. Y la ‘cosmética’ para distribuirlos en el panel ya sería cosa de cada uno. Todos los indicadores podrían agruparse en uno o varios paneles.

Y como el límite es la imaginación, podemos estar abiertos a qué otras funciones se puedan desarrollar para facilitar el control de la maqueta. Se pueden controlar rotondas (desconozco el funcionamiento), motores, sistemas emisor-receptor de infrarrojos para saber la ocupación de zonas; por ejemplo, de vías ocultas y…

Por ahora es lo que se me ha ocurrido. Saludos a todos y os animo a exponer posibilidades para ver si somos capaces de realizarlas. El objetivo: disfrutar también de esta faceta de la afición.

Germán

En efecto, la maraña de cables es el enemigo a batir. Estoy de acuerdo.
También me parece perfecto el planteamiento de usar la señal DCC para todo. No me atrae demasiado tener un bus de datos para accesorios separado. Creo que con DCC en la vía deberíamos tener más que suficiente (1).
También comparto lo de la fuente de PC como potencia auxiliar. Así lo hago en mi maqueta, distribuyendo 5 V y 12 V a tres hilos por todas partes con un resultado impecable.
En breve intentaré señalizar la "posición" de los desvíos que controlaré con servomotores (2). Lo haré mediante un decoder de accesorios (el de los semáforos) en el cuadro de control por pulsadores, al que asignaré la misma dirección que el decoder de servos (el de los desvíos).
Y por si fuera poco, el accionamiento de los desvíos se podrá hacer desde la central, desde el PC (y tablet, iPhone, internet, etc) y desde los pulsadores del cuadro de mandos. Estos últimos tampoco estarán cableados: montaré el circuito XBusTCO de Paco Cañada (POWS) que enviará el comando de cambio a través de las vías.

Si todo sale bien, y es cuestión de tiempo que así sea, podré tener un cuadro de mandos por pulsadores, con indicadores luminosos al estilo tradicional, que solo necesitará tres cables hacia la maqueta: uno hacia las vías para la señal, otro hacia la fuente de 5 V para alimentarse, y otro el del Multimaus que también servirá para el XbusTCO.

De manera que sí, Maestro Germán, tus ideas no sólo son compartidas, sino que incluso hay quien intenta ponerlas en práctica.

____________
Nota 1: La retroseñalización es el problema. Es decir, informar a la central. De momento exige otro bus. Yo uso el S88, pero los hay mejores (Loconet, RS). Los intentos de usar DCC (Railcom por ejemplo) no han triunfado por alguna razón que desconozco. Ahí es donde habría que trabajar en mi opinión.

Nota 2: Pongo "posición" entre comillas porque no se tratará de una auténtica alimentación hacia el sistema DCC de la posición de los desvíos, sino solo de repetir la orden de cambio hacia un decoder de semáforos que iluminará las lucecitas del panel de control. De nuevo es el asunto de la retroalimentación por DCC, que no se ha desarrollado lo suficiente.

El problema (tu problema Norber), no es tal. Todo consisto en realizar un pequeñito hardware (una plaquita de unos veinticinco centímetros cuadrados = 5 X 5) para cada uno de los tramos a detectar. Consistiría en un optoacoplador. Este dejaría (1) o no dejaría (0), pasar la corriente digital a la vía. Al devolver tensión (1) o no (0), al PC (o en tu caso a la central), el ordenador sólo tiene que interpretar ese 1 o ese 0, como que está (1) o no (0) pasando un tren por un punto. La forma de saber de qué tren se trata, es contar (mediante software), el número de impulsos (1) recibidos, entendiendo que cada 1 recibido es el paso de la rueda por el tramo aislado. Siendo éste tramo lo suficientemente pequeño, y a la vez suficientemente grande (una o dos traviesas si el detector es de paso), como para que cada rueda marque ese paso por ese tramo. Entendiendo, claro está, que existen dos tipos de detectores. Los de paso. Y los de consumo.

Es cuestión de software..........

Posiblemente, en la foto que anexo, se vea claramente mi explicación.

Saludos.

Hola Norber,

¡chapeau!; estoy de acuerdo contigo. Realmente con el tema de retroalimentaciones me lío, pero cualquiera de los existentes por hilos independientes de la vía parece válido (como confirman los sistemas comerciales).

Lo del Rail-com me parece un invento endiablado (muy útil), pero pienso (y entiéndase con modestia, porque habla más mi ignorancia) que en ese sentido el sistema DCC nació cojo. Efectivamente por dos raíles que llevan la alimentación a toda la maqueta parece que no cabe realimentación. Cuando supe de este invento genial, comenté con mi amigo Antonio y otros compañeros qué maravilloso era poder tener también comunicación tren-tierra (como en el tren real), suponiendo que los decodificadores incluirían de serie la comunicación con puntos de la vía por medio de infrarrojos..., pero pasó el tiempo y eso no se contempló. Luego vino el sistema Lissy y me pisó la idea .

Si los decodificadores llevaran de serie un emisor-receptor de infrarrojos y en la vía se dispusieran otros, la comunicación sería sencilla y los circuitos más (teóricamente un sólo hilo valdría para informar a la central...). Eso permitiría a la locomotora (a cualquier decoder en general) comunicarse con la central y a ésta tener conocimiento de todos los elementos de la maqueta y su estado. Podría además evitarse lo tedioso de la vía de programación porque alguno de los optoacopladores, o cualquiera incluso, podría establecer un diálogo con la locomotora para confirmar con todo tipo de redundancias ¡incluso su cambio de dirección! y eso no interferiría con el resto de los dispositivos de la maqueta. Cuando más me harvían estas ideas en el coco hice pruebas con distintos formatos de pulsos de infrarrojos y el éxito de funcionamiento fue casi del 100%.

Claro, ya sé que ahora es muy fácil inventar con lo que hay; es como adivinar el pasado. La idea del DCC es genial y parece que nació como un paso de gigante sin prever que evolucionaría de manera asombrosa aumentando las prestaciones a niveles casi de ciencia ficción. Y así ampliar un sistema simple, implica casi siempre complicarlo, llegando a donde estamos.

Y esto da para mucho más. Saludos,

Germán

Rfe7747 escribió:

Hola Norber,

¡chapeau!; estoy de acuerdo contigo. Realmente con el tema de retroalimentaciones me lío, pero cualquiera de los existentes por hilos independientes de la vía parece válido (como confirman los sistemas comerciales).

Lo del Rail-com me parece un invento endiablado (muy útil), pero pienso (y entiéndase con modestia, porque habla más mi ignorancia) que en ese sentido el sistema DCC nació cojo. Efectivamente por dos raíles que llevan la alimentación a toda la maqueta parece que no cabe realimentación. Cuando supe de este invento genial, comenté con mi amigo Antonio y otros compañeros qué maravilloso era poder tener también comunicación tren-tierra (como en el tren real), suponiendo que los decodificadores incluirían de serie la comunicación con puntos de la vía por medio de infrarrojos..., pero pasó el tiempo y eso no se contempló. Luego vino el sistema Lissy y me pisó la idea .

Si los decodificadores llevaran de serie un emisor-receptor de infrarrojos y en la vía se dispusieran otros, la comunicación sería sencilla y los circuitos más (teóricamente un sólo hilo valdría para informar a la central...). Eso permitiría a la locomotora (a cualquier decoder en general) comunicarse con la central y a ésta tener conocimiento de todos los elementos de la maqueta y su estado. Podría además evitarse lo tedioso de la vía de programación porque alguno de los optoacopladores, o cualquiera incluso, podría establecer un diálogo con la locomotora para confirmar con todo tipo de redundancias ¡incluso su cambio de dirección! y eso no interferiría con el resto de los dispositivos de la maqueta. Cuando más me harvían estas ideas en el coco hice pruebas con distintos formatos de pulsos de infrarrojos y el éxito de funcionamiento fue casi del 100%.

Claro, ya sé que ahora es muy fácil inventar con lo que hay; es como adivinar el pasado. La idea del DCC es genial y parece que nació como un paso de gigante sin prever que evolucionaría de manera asombrosa aumentando las prestaciones a niveles casi de ciencia ficción. Y así ampliar un sistema simple, implica casi siempre complicarlo, llegando a donde estamos.

Y esto da para mucho más. Saludos,

Germán

has abierto una puerta.......muy dificil de cerrar!!!!!

astatron escribió:

... al devolver tensión (1) o no (0), al PC (o en tu caso a la central), el ordenador sólo tiene que interpretar ...
Es cuestión de software...

Yo estoy más que satisfecho con el funcionamiento de mis detectores de consumo basados en diodos y la retroalimentación por el bus S88. De manera que no veo necesidad de habilitar otro medio de detección que informe al PC por dos hilos separados. Es la función del S88 y la desempeña 100% bien.

Lo que yo comentaba iba más en el sentido de la comunicación tren-tierra a través del propio DCC de las vías, sin otros hilos separados hacia la central o el Mac.

Rfe7747 escribió:

Lo del Rail-com me parece un invento endiablado (muy útil), pero pienso (y entiéndase con modestia, porque habla más mi ignorancia) que en ese sentido el sistema DCC nació cojo. Efectivamente por dos raíles que llevan la alimentación a toda la maqueta parece que no cabe realimentación.

Pues espero que no tengas razón y que, finalmente, haya un cambio al DCC2 (o como lo llamen) que permita lograr elevada fiabilidad en RailCom o lo que lo sustituya. Entonces tendríamos un montón de posibilidades de juego más. A mi, por ejemplo, me desaparecerían los cables del bus S88 para retroalimentar, y tampoco tendría trenes "fantasma" en el ordenador que controla la maqueta, pues en cuanto pasaran por un tramo con RailCom volverían a quedar identificados. Lo echo de menos, la verdad. También podríamos conocer la posición de los desvíos, retroalimentada por los propios carriles y no por Loconet o RS... En fin, sería el bus perfecto a dos hilos que, además, continuaría llevando potencia a motores y lámparas.

Vale. Estupendo. Me alegro de que te conformes con la supuesta salida al mercado del RailCom. Y de que te gastes la pasta. Yo, por el contrario, para quienes tengan conocimientos para hacerlo, creo que obrarán en mejor medida.

Saludos.

Hola a todos,
En el tema de los retrocontactos y la retroinformacion lo existente por ahora mas conocidos y utilizados como los retromodulos RS o los mas antiguos S88 lo veo como un asunto que ya esta quedando obsoleto y sin posibilidad de continuación y evolución de cara al futuro aunque por ahora los estemos utilizando porque simplemente NO hay nada mejor al alcance de nuestra mano.
Como ofertas casi inmediatas para su sustitución a esto esta el Railcom, ya hay algunas cositas comercializadas pero en plan casi incipiente.
Railcom no termina de despegar no por temas de desarrollo y tecnología si no por grandes problemas de intereses económicos y comerciales.
Aunque el inventor y desarrollador de Railcom fue Lenz, es una gran tarta muy apetitosa para las grandes firmas fabricantes y comercializadoras de todos los temas digitales y hay literalmente una guerra por parte de cada una como posicionarse en un puesto de preferencia y cuota de mercado a la hora de comercializar este producto. Total, que no se ponen de acuerdo en los porcentajes de beneficios y copyright.
Con esta demora de sus guerras particulares no se están dando cuenta que cuando se aclaren y lo comercialicen en masa ya estará obsoleto, ¿Por qué?, pues porque ya se esta moviendo otro sistema mucho mas eficiente y revolucionario que todo esto, “la detección por georeferencia”.
Una intercomunicacion bidireccional de informacion y ordenes entre la locomotora, la central y el Pc "Sin cables en la via", todo un sueño hecho realidad.

La detección y posicionamiento por georeferencia es un sistema puramente basado en la técnica del Gps, ya se pueden adquirir productos completamente probados y comercializados:
http://translate.google.es/translate?hl ... rev=search

https://www.google.es/webhp?sourceid=ch ... mesontrack

Un par de firmas alemanas desconocidas ya tienen productos de estos y basados prácticamente en lo mismo, no pongo aquí sus páginas pues toda la información está en un correcto idioma teutón y es muy difícil de entender con estas altas características técnicas.

Mi visión particular es que por este camino seguirá el futuro de todo el tema de la retroinformacion, es una puerta abierta muy atractiva para seguir investigando y con muchísimas cosas por hacer.

Un saludo, Angel

Hola Ángel,

como siempre tan informado como dispuesto a colaborar; gracias por la información. El sistema, visto por encima y con la traducción de Google, es genial. Pero, es hablar por hablar por mi parte, parecería como lo de matar hormigas a cañonazos porque no sé si es preciso tanta sofisticación cuando lo deseado es conocer la posición y algunos pocos parámetros más de los receptores. Yo comentaba lo de los infrarrojos porque se simula fácilmente la situación del tren real con balizas y/o comunicación tren-tierra. Ahora bien, comprendo que para una empresa sea preferible realizar proyectos que no estén al alcance de los clientes..., para que lo sigan siendo. En mi caso la electrónica es hobby como los trenes, y disfruto más haciendo chapuzas que comprando maravillas.

He leído hace un tiempo sobre el empleo de módulos de radio. Un amigo tiene un sistema de medida de consumo eléctrico en casa basado en parte en arduino y utiliza unos módulos de radio para comunicaciones, con alcance dentro de la casa, del tamaño de la uña del dedo gordo, más o menos, perfectamente encajable en vehículos de escala H0.

También están las etiquetas RFID que contienen un código único y según he leído en el foro "escalan" las hay de tamaño mínimo: allí proponían su uso, en escala N, para activar locuciones en la estación identificando al tren que entra o va salir.

Este campo parece no agotarse.

Saludos,

Germán

Yo, al igual que tú, Rfe7747, he sido investigador (autónomo, particular, privado........) en terreno de software (y algo de hardware) durante más de 30 años (empecé con el Sinclair Spectrum en Assembler por allá, por 193 más o menos). Seuiré animando a la investigación. Desde aquí. Aunque, como tú bien has mentado, hay que seguir que los clientes, lo sigan siendo.

Saludos.

OrBahn escribió:

La detección y posicionamiento por georeferencia es un sistema puramente basado en la técnica del Gps, ya se pueden adquirir productos completamente probados y comercializados:
http://translate.google.es/translate?hl ... rev=search

https://www.google.es/webhp?sourceid=ch ... mesontrack

Desde julio RocRail, el software de control de maquetas DCC que yo uso, ya soporta este tipo de retroalimentación con éxito. No es comunicación a través de un bus extra, aunque tampoco es a través de la vía. Es a través del aire, mediante ondas electromagnéticas. Me fastidia en el fondo, porque sigo pensando que la mejor solución habría de ser transmitir por los carriles toda la información, tanto de ida (tierra-tren) como de vuelta (la retroalimentación tren-tierra).

Y quisiera poner un ejemplo: los modernos contadores de la luz que se están poniendo por toda España reciben la orden de comunicar sus datos a través de los propios cables de la red eléctrica, y luego devuelven la lectura mediante ellos. Es decir, se trata de una solución en la que los propios cables (véase raíles) llevan tanto potencia en un sentido como información en los dos. Pero nuestros raíles sólo llevan potencia e información hacia los trenes, y les falta traerla de vuelta hacia la central desde los sensores y demás...

Será que, en verdad, no interesa desarrollar esta solución por la guerra de marcas y derechos. Y eso fastidia, a mi al menos.

Llevo algunas semanas rastreando qué hacen otros aficionados del extranjero con la señal DCC de los raíles. Básicamente lo que nosotros, me temo, y el despegue del RailCom sigue sin ocurrir. Pero en USA va cobrando fuerza el empleo de Arduino para DCC, y por ahí se debe producir el esperado (por mí al menos) cambio. De momento ya se usan con facilidad las librerías de código para el estándar NMRA y, en consecuencia, comienzan a surgir nuevos decóder de todo tipo basados en Arduino. Para muestra, un decodificador que maneja hasta 17 servos (de un máximo de 19), y los enciende de manera secuencial, para no sobrecargar la central en el arranque:

http://model-railroad-hobbyist.com/node/19446

Entre nosotros ha habido también iniciativas muy interesantes:

Para ir abriendo boca: http://www.forotrenes.com/foro/viewtopic.php?f=7&t=55554&p=447513
Para interaccionar con Train Simulator: http://www.forotrenes.com/foro/viewtopic.php?f=7&t=59281&p=477952
Para iluminar vagones: http://www.forotrenes.com/foro/viewtopic.php?f=7&t=59426&p=477867
Y más que me dejo, sin duda.

Espero que así pueda desarrollarse la comunicación tren-tierra, al margen de guerras de marcas, y que podamos disfrutarla todos pronto.

Hoy he encontrado un retromódulo S88 fabricado con un Arduino de 6 euros...

http://rudysmodelrailway.wordpress.com/2014/10/03/arduino-used-as-an-s88-occupancy-detector-board/

ArdS88.png (112.36 KiB) Visto 4551 veces

Esto significa que ya no es necesario fabricarse uno mismo la placa de los retromódulos, que es uno de los montajes más frecuentes y, en mi opinión, más laboriosos de lograr. Me refiero, por supuesto, al montaje que nos ofrece Paco Cañada en http://usuaris.tinet.cat/fmco/retro_sp.html y que tantos de nosotros estamos utilizando.

Lo que me llama la atención es no encontrar gran cosa referida a incorporar datos RailCom al bus XpressNet. Algo hay en un sitio alemán, pero parece que todo el mundo prefiere el Loconet...

Hola.

Un apunte, le he estado dando un ojo a las páginas que indica Norber y lo que veo es que efectivamente, el Arduino lo que hace es conectarse al bus S88, por otra parte la activación o no es a través de detectores de paso (ampollas, cetectores IR, diodos Hall, etc.) pero no por consumo.
Esto puede interesar o no. Lo comento sólo para tenerlo claro. El aporte de Norber y de su desarrollador (Rudy) me parece muy interesante y leyendo se puede ver una descripción bastante completa del bus S88.

Un saludo.

El autor del programa para el retromódulo S88 sobre arduino especifica en https://rudysmodelrailway.wordpress.com/software/ que

For the sensors anything can be used that pulls an Arduino input to GND, like a reed switch or an optical detector.

Es decir, que cualquier sensor que ponga a potencial cero su salida puede conectarse a este retromódulo. Ese es, justamente, el comportamiento de los detectores de consumo por diodos que también ofrecen Paco Cañada y J. Frutos y que yo uso masivamente, de manera que la conclusión es que también los detectores de consumo por diodos funcionan con este retromódulo tan barato.

Bon dia,sigo este hilo desde su aparición ,la idea de reducir cableado es la que todos tenemos en mente desde siempre como comenta el amigo Norber,las continuas aportaciones del autor de hilo,el compañero Rfe 7747 , de Orbahn y de Norber y los comentarios de Matao y 7700 ,me han permitido adquirir una serie de conocimientos y tomar conciencia de lo apasionante que puede ser el tema de que la central no solo pueda enviar datos sino que sea capaz de recibirlos.
Agradeceros vuestro trabajo y aportacion ,me han sido muy utiles y espero que sigan siendo.


Josep Aleixandre