Retromódulos S88 con Arduino

Bueno, pues visto lo visto, parece ser que solo me ha ocurrido a mi lo del parpadeo.
Como ya lo tengo solucionado, pasemos a otra cosa.
Gracias a todos los que habéis aportado en este hilo.

Las diferencias de comportamiento del pin 13 entre arduinos se deben a que hay varias implenentaciones del mismo a nivel hardware, mientras wue en algunos modelos simplemente esta conectado a la salida del pin con su correspondiente resistencia (y dan el problema) en otros se activa mediante un operacional que evita las caidas de tension y no dan el problema.

Respecto al parpadeo no recuerdo haberlo tenido con este sketch y parecidos y era siempre por problema en la deteccion (malis contactos). La verdad es que lo use poco tiempo pues he preferido hacer la retriseñalizacion por LocoNet/arduino (tengo una Z21 y asi no necesito ningun interface).

Alguien que haya montado el circuito y lo tenga funcionando, ¿podría poner las formas de onda obtenidas en los puntos que indico en el esquema?

Gracias y saludos.

Bueno, pues hoy ha caído en mis manos un osciloscopio y he podido ver cual era el problema ....

Las pruebas las estaba haciendo con mi central Digikeijs DR-5000 y tenía activada la opción "Generate RailCom cut-out" y esto provoca unos cortes en la tensión suministrada a la vía de 480us cada cierto tiempo y eran esos cortes lo que hacía oscilar la señal del sensor.
Una vez eliminada esa opción, la señal aplicada a la vía carece de cortes y la señalización permanece fija, sin fluctuación alguna.

Pido disculpas a los autores del sketch y diseñadores del circuito, porque todo funciona a la perfección.

Adjunto las dos formas de onda, con y sin cut-out.

Saludos.

¿que valor tenía el condensador? pienso que aumentándolo un poco podrías dejar los Cut-Out de RailCom y no te daría problemas

un saludo

El condensador es de 100nF, pero llegué a poner 2 y 3 en paralelo y empeoraba la fluctuación.
De todos modos, con RocRail se solucionaba, dejando el RailCom en la central, temporizando la detección con 100ms.

Ahora que sabemos lo que pasaba, podemos poner una solución.
Pero no podré probarlo yo, pues no tengo una central de esas.

Se tratará, por ejemplo, de acumular los estados leídos durante 4 ó 5 vueltas completas del bus S88 y, si en cualquiera de ellas se detecta consumo, pues mantener la señal activa durante las 4 ó 5 rondas siguientes. Se introduciría un retraso inapreciable en la transmisión de la información pero se evitará el problema del Railcom...

¿Alguna idea mejor?

Pecetero escribió:

Pido disculpas a los autores del sketch y diseñadores del circuito, porque todo funciona a la perfección.

No había por qué pedir disculpas. No hemos causado ningún daño del que debamos responder
Ni somos fabricantes, ni damos garantía de nada. Lo que sabemos lo contamos, lo que tenemos lo compartimos, lo que podemos aportar pues ahí va sin esperar nada a cambio. Así han hecho mis maestros Germán Trinidad y Paco Cañada y así quisiera poder seguir por muchos años. Y que colaboremos todos.

Norber escribió:

Ahora que sabemos lo que pasaba, podemos poner una solución.
Pero no podré probarlo yo, pues no tengo una central de esas.

Se tratará, por ejemplo, de acumular los estados leídos durante 4 ó 5 vueltas completas del bus S88 y, si en cualquiera de ellas se detecta consumo, pues mantener la señal activa durante las 4 ó 5 rondas siguientes. Se introduciría un retraso inapreciable en la transmisión de la información pero se evitará el problema del Railcom...

¿Alguna idea mejor?

Aunque poco puedo aportar a ese nivel, si que me ofrezco para probar lo que necesites con esta central.

Bueno, el tema me parece similar al problema del rebote de un contacto al que ya se han enfrentado los diseñadores de teclados, (los primeros ordenadores personales, estoy hablando de unas Tandy TRS-80 venían con una utilidad para evitar ese rebote) y básicamente es no cambiar de estado de detección por cambio de estado del pin, sino, como dice Norber por una cantidad N de lecturas consecutivas con el nuevo estado.

Es decir, supongamos que estamos en el estado "detectado consumo", tenemos un contador de estado a N. Si en una comprobación nos da "No detectado consumo" decrementamos N. Si al volver a leerlo nos da "detectado consumo" lo volvemos a poner a N, pero si nos vuelve a dar "No detectado consumo" volvemos a decrementar.

Cada vez que decrementamos el contador miramos a ver si el contador ha llegado a 0, si ha llegado a cero, marcamos el sector como "sin consumo", ponemos el contador a N y ahora lo decrementamos o volvemos a poner a N según nos dé "con consumo" o "sin consumo".

Como bien dice Norber, ajustando N podemos evitar oscilaciones falsas es decir "rebotes", y no sólo soslayaremos el tema de los cortes del RailCom, también posibles falsas detecciones por malos contactos.

Por cierto, los valores N que he puesto pueden ser distintos cuando estamos en el estado "no detectamos" a "detectamos", en el primer caso N puede valer 1, es decir, la primera lectura que nos dé consumo ya marcamos como ocupado.

Un saludo

Norber escribió:

Pecetero escribió:

Pido disculpas a los autores del sketch y diseñadores del circuito, porque todo funciona a la perfección.

No había por qué pedir disculpas. No hemos causado ningún daño del que debamos responder
Ni somos fabricantes, ni damos garantía de nada. Lo que sabemos lo contamos, lo que tenemos lo compartimos, lo que podemos aportar pues ahí va sin esperar nada a cambio. Así han hecho mis maestros Germán Trinidad y Paco Cañada y así quisiera poder seguir por muchos años. Y que colaboremos todos.

Pido disculpas por haber afirmado que era problema del sketch sin tener la certeza y solo por intuición y reconocer los errores es una de mis características, a pesar de que soy muy cabezón

Gracias por compartir todo esto que es lo que me entretiene y hace disfrutar en mi época de jubilado, ya que mis conocimientos para programar son casi nulos.

El Matao escribió:

Bueno, el tema me parece similar al problema del rebote de un contacto al que ya se han enfrentado los diseñadores de teclados, (los primeros ordenadores personales, estoy hablando de unas Tandy TRS-80 venían con una utilidad para evitar ese rebote) y básicamente es no cambiar de estado de detección por cambio de estado del pin, sino, como dice Norber por una cantidad N de lecturas consecutivas con el nuevo estado.

Es decir, supongamos que estamos en el estado "detectado consumo", tenemos un contador de estado a N. Si en una comprobación nos da "No detectado consumo" decrementamos N. Si al volver a leerlo nos da "detectado consumo" lo volvemos a poner a N, pero si nos vuelve a dar "No detectado consumo" volvemos a decrementar.

Cada vez que decrementamos el contador miramos a ver si el contador ha llegado a 0, si ha llegado a cero, marcamos el sector como "sin consumo", ponemos el contador a N y ahora lo decrementamos o volvemos a poner a N según nos dé "con consumo" o "sin consumo".

Como bien dice Norber, ajustando N podemos evitar oscilaciones falsas es decir "rebotes", y no sólo soslayaremos el tema de los cortes del RailCom, también posibles falsas detecciones por malos contactos.

Por cierto, los valores N que he puesto pueden ser distintos cuando estamos en el estado "no detectamos" a "detectamos", en el primer caso N puede valer 1, es decir, la primera lectura que nos dé consumo ya marcamos como ocupado.

Un saludo

Pues me parece estupendo .... quedo a la espera ...

Hola a todos, primero agradecer y aplaudir vuestro esfuerzo y trabajo que habéis compartido!!

Me uno a este hilo ya que he montado la misma placa que Pecetero. En mi caso de momento solo tengo la central DCC de Arduino y de momento estoy estudiando como va con la idea de integrarlo todo en una central hecha con Arduino.

He estado revisando el esquema del circuito y no termino de ver el sentido a ese condensador. Hay que tener en cuenta que si la idea era "aplanar" un poco los pulsos del DCC para que la señal sea más estable en la entrada del optoacoplador, hay que tener en cuenta que en los extremos de los diodos, que es donde conectamos el optoacoplador tenemos trenes de pulsos positivos y negativos, vamos como semiciclos positivos y negativos ya que no está rectificada la señal, de esta forma cuando llega un semiciclo "positivo" no parte de 0 sino de la tensión del semiciclo negativo que será aproximadamente los 1,2v que caen en los diodos, por lo que en mi opinión, en este tipo de configuración, el condensador sobra, y aquí unas señales que he medido con el osciloscopio que vienen a confirmar lo que digo:

Señal medida en la entrada del optoacoplador con condensador

Señal medida en la entrada del optoacoplador sin condensador

Como se puede apreciar, el condensador "se come" parte de la señal curvándola y perdiendo una parte de la misma, si aumentamos la capacidad esa curva será cada vez más pronunciada hasta que directamente se aplane toda la señal. Es una reactancia capacitiva y se comporta como una resistencia en corriente alterna, que en realidad es lo que estamos aplicando y de ahí que en este sentido creo que es contraproducente que lleve un condensador, salvo quizá por desacople de ruidos en la señal, en cuyo caso lo normal es usar 10nF, pero como lo único que ataca es un diodo IR de un optoacoplador, que haya un poco más o menos de ruido, dudo que le afecte.

Respecto al problema que genera el cut-out de RailCom, creo que se puede solucionar de diferentes formas. Quizá la más "sencilla" sea modificando el sketch. En mi opinión casi lo mejor sería quitar la lectura de los puertos de la interrupción y en el main hacer que lea continuamente los puertos pero solo actualizar la variable global que contiene todos los bits correspondientes a los sensores si ha habido un cambio, y que dicho cambio solo se valide si tras varios muestreos, suficientes para superar el hueco del RailCom se confirma dicho cambio, vamos, como han comentado algo igual que se hace con la supresión de rebotes.

Otra opción un poco más complicada sería el equivalente a disparar justo en el blanco, que sería tomar la muestra solo cuando sabemos que vamos a obtener un resultado correcto, para esto lo podríamos hacer con el flanco de subida de otra interrupción del arduino, de esta forma, nunca vamos a medir en los huecos del RailCom ya que no se dispararía nuestra medición sino que solo se haría cuando la señal polariza en directo el diodo del optoacoplador. Así el código y lectura estarían optimizadas al máximo (creo).

Claro que para hacerlo lo más fino posible, lo ideal sería utilizar otro tipo de optoacoplador, usar optoacopladores con entrada AC, vamos que llevan dos diodos de infrarrojos contrapuestos de tal forma que se activan en ambos ciclos, esta en principio sería la mejor solución ya que medimos la carga siempre, y aquí si se podría poner un condensador a la salida del optoacoplador para mantener el nivel durante un tiempo.
https://www.vishay.com/docs/83641/il755.pdf

Por otra parte, permitidme que de una última vuelta de tuerca sobre el circuito ya que con tan baja tensión y poco probable que entren transitorios peligrosos, ¿no sería una buena opción prescindir de los optoacopladores y atacar directamente al arduino con solo unos transistores contrapuestos para ambos semiciclos? los transistores son económicos y ocupan poco espacio, más sin son smd, pudiendo reducir el PCB y costes. Claro que lo mismo es marear mucho el tema para una cosa de hobby que tampoco es que lo vayamos a producir en masa, pero por tener vuestra opinión.

En fin, si puedo ir aportando algo lo haré, estoy un poco oxidado con el tema de la programación, aunque espero ir cogiendo más soltura.

Saludos!

Mis detectores no llevan condensador y funcionan sin problemas. Respecto al problema con el RailCon no veo necesario modificar nada, en la mayoria de los casis los detectores son para usarlos con software y este ya permite tratar la señal para que no le afecte el problema, de hecho es necesario hacerlo para evitar priblemas por malos conractos de las locomotoras.
Cambiar optos por transistores, no creo que hubiera problema, al fin y al cabo lo unico que se necesita es un "interruptor" que ponga el pin a nivel bajo. Los optos de alterna se puden usar sin problemas, salvo que son algo mas caros, de hecho los he utilizado para usar detectores de ocupacion en analogico, donde, paradojicamente, es forzoso usarlos pues si no solo detectan en un sentido.

renfe276 escribió:

Mis detectores no llevan condensador y funcionan sin problemas. Respecto al problema con el RailCon no veo necesario modificar nada, en la mayoria de los casis los detectores son para usarlos con software y este ya permite tratar la señal para que no le afecte el problema, de hecho es necesario hacerlo para evitar priblemas por malos conractos de las locomotoras.
Cambiar optos por transistores, no creo que hubiera problema, al fin y al cabo lo unico que se necesita es un "interruptor" que ponga el pin a nivel bajo. Los optos de alterna se puden usar sin problemas, salvo que son algo mas caros, de hecho los he utilizado para usar detectores de ocupacion en analogico, donde, paradojicamente, es forzoso usarlos pues si no solo detectan en un sentido.

Yo si veo adecuado modificar el sketch, como se ha dicho en post anteriores, para evitar el tener que depender de que el software usado tenga o no la posibilidad de temporizar la señal.

Si pero todos los "principales" Rocrail, iTrain, Windigipet y TrainController, lo tienen y dudo que slguno no lo tenga, el poder añadir una temporizacion a la deteccion es necesario, pues si no cualquier pewueño fallo en la deteccion produciria una falsa liberacion del canton con los consecuentes problemas.
De todas formas el que le interese hacerlo puede, esa es una de las ventajas de Arduino.

Buenas a todos!

Le he estado dando algunas vueltas al asunto respecto a la optimización y mejora del circuito. En principio he descartado el uso de transistores ya que hay un problema con la masa o punto de referencia del transistor y del Arduino. La verdad es que los optoacopladores son una excelente solución y lo único que me ha hecho darle vueltas a su sustitución sobre todo es por ganar espacio en el PCB y reducirlo de tamaño.

Respecto a los condensadores, ciertamente los del diseño original del DETECT-4 más que ayudar son contraproducentes para el funcionamiento del circuito, especialmente el electrolítico, aunque el otro de 100nF también tiene un efecto negativo como ya mostré en el post anterior con las capturas de las mediciones con el osciloscopio. No obstante si nos fijamos en el circuito sí que podríamos mejorar la respuesta y estabilidad del circuito con un condensador:

De esta forma lo que hacemos es estabilizar la entrada del arduino con una señal mucho más estable, ahora sí tenemos un efecto como la supresión de rebotes de los pulsadores por hardware, eso sí, hay que tener en cuenta que se puede poner el condensador sin una resistencia adicional en serie para valores bastante bajos del condensador, pero si lo subimos, habrá que poner una resistencia para limitar la corriente de descarga:

Así limitamos la corriente máxima que circula por el transistor del optoacoplador en el proceso de descarga del condensador.

Y aquí las mediciones:

Salida del optoacoplador SIN condensador

Salida del optoacoplador CON condensador

Se aprecia la diferencia en la estabilización de la señal, incluso ahora cabe la posibilidad de que sea suficiente para "omitir" el punto muerto del RailCom (a ver si Pecetero puede hacer la prueba).

Pues colocado el condensador de 100nF, entre el colector del optoacoplador y masa, desaparece la fluctuación del sensor.

La central tiene activada la función de RailCom con su "cut-out" y no se ha temporizado su respuesta con RocRail, con lo cual, puede ser una solución

Norber escribió:

Probad alguno con este código, por favor, a ver si se enciende 2 s el led al iniciar, y luego si es sensible a las detecciones (debería lucir cuando alguno de los 12 detectores de consumo vea algo, y apagarse si están todos sin consumo). No lo he compilado ni probado. Avisad de lo que esté mal y se intenta arreglar. Gracias.

Edito este post porque tenía estropeado el Arduino Nano y no funcionaba correctamente y una vez cambiado ...

He probado este Sketch y funciona correctamente, como describes en tu comentario

Una vez comprobado que todo funciona correctamente, voy a diseñarme una nueva tarjeta, intentando reducir su tamaño e incorporarle el diodo led, por lo que esta primera tarjeta, totalmente montada y probada la pondré a la venta en el mercadillo por algo menos de lo que me ha costado, por si a alguno le interesa.