Hola Xavi,
te comento, por lo que me dices de que es posible que el bus RS no sirva para enviar la información de RailComm, estoy de acuerdo, es posible que así sea. También he leído en otro hilo un intercambio de ideas entre Norber y Paco Cañadas en el que, si lo he entendido bien, comentaba Paco que XpressNet no funciona (o no está pensado) para enviar la información de RailComm desde el retromódulo a la central y que Roco consigue enviar esta información desde el retromódulo al ordenador usando un truco por el que genera paquetes que van por la XpressNet, pero que la central ignora, por estar mal formados, y que el módulo de comunicaciones con el ordenador si que los recoge y acaba enviando al ordenador. En fin, con todo esto lo que te quiero decir, es que da la sensación que RailComm sea un protocolo al que le falta un soporte para que la información que consigue de los decos fluya por todo el sistema digital y que en definitiva llegue a donde se necesita, que es el ordenador.
Al final, si no he entendido mal las pruebas de Salus y el manual del DR8055, el DR8055 actúa como retromódulo y además proporciona las comunicaciones RailComm, luego, la información de RailComm se envía a la central por LocoNet (parece que LocoNet si que está pensado para poder hacer una comunicación bidireccional en todo el bus) y finalmente la central envía esos datos al ordenador con el que tiene la conexión directa (si bien, por lo que comenta Salus, la conexión de Loconet debe hacerse por USB, ya que no funciona por ethernet).
Al final, me da la sensación de que todo el sistema digital que usamos para el control de las maquetas está basado en una serie de protocolos que por separado funcionan muy bien, pero que tienen dificultades para integrarse unos con otros, o quizá más bien para complementarse y que juntos den un control centralizado más global.
Creo que para lograr lo que persigues de usar el RailComm en el control de tu maqueta, hoy por hoy la mejor opción sería usar el DR5088 como detector de presencia de los trenes (retromódulos) y comunicación RailComm en conjunción con una central que permita la comunicación LocoNet. Con eso bastaría para conseguir tu objetivo de usar el RailComm, de forma que se simplifique al máximo todo el sistema.
Con la DR5000 se podría compaginar la comunicación RS con los retromódulos que ya tienes y la RailComm con los DR5088, pero da lugar a una redundancia, porque por RS obtienes la ocupación de un tramo por la K y con los DR obtienes las ocupación de un tramo por la J, además de obtener la información RailComm. Al final, esa redundancia se puede usar de varias maneras: una sería que no nos fiemos por completo de la detección por la J (por el motivo que sea) y que dupliquemos por completo las detecciones, otra sería que por cada varios detectores K tengamos 1 J, esto es, imaginemos que tenemos un tramo de vía que hace un cantón en el que tenemos dividida la vía en tres tramos que actúan como detección - frenada y detención, estos se podrían gestionar por la K y estar "asociados" a un único tramo de detección J que sea el que nos diga qué tren hay en ese cantón. Este sistema es precisamente el esquema del manual del retromódulo DR8055 que me comentabas:
- Esquema de combinación de detección J y K
Al final, lo más simple sería el uso de los módulos DR8055 tanto para la detección de trenes como para su identificación por RailComm, simplificando el esquema de lo que hay que montar en la maqueta, el uso de protocolos y los buses por lo que circula la información. Cosa que no es desdeñable, porque suele pasar que las cosas simples tienen un funcionamiento más fiable.
En fin, estas son mis reflexiones sobre lo que estamos comentando, disculpadme si me he ido un poco del tema del hilo, que es la central DR5000, pero al final, esta es hoy en día la central que soporta todos los protocolos que comento en mis reflexiones.
Saludos,
Raúl.
.
