Railcom (1ª parte) ¿Qué es y para qué sirve?

Ya hace varios años que oímos hablar de “Railcom”. Hay algunos decoders que soportan Railcom, otros que no. Hay centrales que soportan Railcom, pero otras que no. Hay también en relación a Railcom muchos tópicos equivocados, concepciones erróneas, y cierto desconocimiento generalizado que no nos permiten sacarle partido a esta interesante tecnología, o en el peor de los casos orientan nuestras adquisiciones y compras en un sentido que quizás nos limite o nos cierre puertas en el futuro.

Hay quien piensa que Railcom sólo sirve para que sepamos qué locomotora está en un tramo de vía determinado, ya que los decoders con Railcom tienen la capacidad de emitir su dirección. Esto no es falso, pero es una caricatura de esta tecnología que no hace justicia a todas sus potencialidades.

Por un lado, en una maqueta digital convencional, los comando o órdenes sólo circulan en un sentido: desde la central hacia el decodificador, esté éste en una locomotora, vagón, o controlando accesorios. Pero no hay manera de obtener información de los decoders, a menos que los pongamos en la vía de programación con la que algunas centrales (no todas) están equipadas.

railcom-logo

 

Sin embargo, en un entorno Railcom la comunicación es bidireccional. No sólo es la central la que habla y el decodificador el que escucha, sino que la central además puede preguntar y escuchar al decodificador, esté donde esté. En consecuencia, en un entorno Railcom, podemos obtener datos de los decodificadores mientras éstos están en funcionamiento, sin interrumpir la marcha del juego ni reconectar nada de manera diferente.

La tecnología Railcom fue inventada por Lenz, que la patentó en 2006. Anteriormente, había habido otras tecnologías propietarias para conseguir comunicación bidireccional con los decoders: el “transponding” de Digitrax en 1999 y el “reconocimiento de número de tren” de ZIMO -atención- en 1987 (!).

Durante un tiempo Lenz se reservó el conocimiento de las características de la tecnología, más tarde (a finales del 2007) se recogieron en una “Práctica Recomendada” de la NMRA, la RP 9.3.1. Posteriormente, en 2011 ya adquirió el estatus de Standard de la NMRA, el S 9.3.2.

En un post futuro analizaremos cómo funciona Railcom.