Juntando esta idea y la de Albert Gonzalez, creo tengo la solución. Gracias
"pepitof" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de... | Los esclavos cuando quieran enviar datos podrían inyectar una frecuencia | claramente más alta que la que está utilizando el master. | | -- | | Saludos de José Manuel García | snipped-for-privacy@terra.es | http://213.97.130.124 | | | "CRAM" escribió en el mensaje | news: snipped-for-privacy@uni-berlin.de... | > Verás, que no me he explicado bien. | > El problema es físico. Tengo un espacio muy muy pequeño, y no tengo claro | el | > hard que me hará falta. | > En el master se utiliza un puente en 'H' (o un driver de motores), y | envias | > siempre la señal simétrica. En el esclavo, rectificas, y tienes una | > continua. Pones un solo diodo, y tienes los datos. | > Pero responder no es tan sencillo (o tan pequeño). | > A nivel de soft no hay problema, no necesito velocidad. Lo que necesito es | > el DCC bidireccional. | >
| >
| > "KT88" escribió en el mensaje | > news: snipped-for-privacy@uni-berlin.de... | > | > Yo diseñé hace 9 años un sistema como ese, para una marca comercial, | que | > | > todavía está en venta. Se basa en lo que decía al principio del post, | al | > | > igual que el sistema marklin. | > | > Pero no se me ocurre cómo hacer que respondan. Y máxime cuando tengo | > | muchos | > | > problemas de espacio en los esclavos. | > | | > | No se a que te refieres, cuando dices, que no sabes como hacer que | > | respondan. | > | | > | A efectos eléctricos, para evitar colisiones, que alteren y distorsionen | > las | > | señales del bus, imponiendo unas reglas básicas, que impidan el caos. | Por | > | ejemplo, solo el master interroga, el esclavo debe responder al master | en | > un | > | periodo de tiempo mínimo estipulado, si no, habla de nuevo el master. | > | | > | A efectos lógicos y de programación, contemplando a los esclavos, como | si | > | fueran masters, cada uno con su dirección, cada uno respondiendo cuando | el | > | master le pregunte, y siempre dentro de un plazo de tiempo estipulado, | > para | > | evitar de nuevo las colisiones. | > | | > | DCC, contempla la alimentación de las máquinas y vagones, amén del envío | > de | > | datos en la misma trama, solo que es unidireccional, los esclavos nunca | > | responden, solo reciben las ordenes, para variar la velocidad de las | > | máquinas, encender luces, activar dispositivos de sonido, humo, señales | > | ópticas, desvíos etc... , pero me consta, porque lo he leido en alguna | > | revista, como "Paso a nivel" o "Más tren", que el DCC bidireccional, o | > algo | > | similar, se viene planteando desde hace mucho tiempo, por ejemplo, para | > que | > | las locomotoras se identifiquen por si solas, para tener constancia de | la | > | ubicación física de cada unidad dentro del circuito, para programar las | > | rutas en función de la ubicación de cada convoy etc... | > | | > | Yo no lo veo, muy complejo, al fin y al cabo, CAN es un bus | bidireccional, | > a | > | efectos de comunicación, y debe funcionar con una lógica similar, aparte | > de | > | que pueda implementar algun sistema para detectar colisiones. La ECU, | > | interroga y recibe constantemente datos de los sensores del automovil, | > para | > | detectar problemas, o realizar ajustes en tiempo real. Tal vez | estudiando | > un | > | poco este bus, y la parte eléctrica del DCC, puedas encontrar una | solución | > | válida. | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | >
| >
| |