El trabajo principal ha sido decorar con gravilla el ténder, a modo de carbón. La verdad es que ha quedado incluso mejor que el original (de plástico).

Además he aprovechado para pegar algunos detalles que quedaban pendientes: maquinista, barandilla, etc. Por desgracia hay algunas piezas que en estos años se han perdido, como detalles en el techo de la cabina.

Con todo, el resultado es bastante bueno. Me queda tan sólo comprobar la estabilidad de la máquina en un trazado con curvas. Me da la sensación que el tender se mueve demasiado.

Finally, I have been able to analyse the output of a Mobile Station and compare it to the output of a DDX+MGV105.

After a couple of tests, it was clear, as expected that the signal from the MS (hereafter) was quite different to the signal coming from DDX, especially with regards to the distribution of packets.

The voltage and timing were similar, except for the pause between double packets.

At this point, I needed a logic analyser to check the content of the packets and since I do not have an easy access to an oscilloscope at work, obviously I do not have one at home, and I needed a good set of samples, I decided to ‘build’ something that without having the quality of an oscilloscope, enables the recording of a high number of samples.

With a couple of resistors the voltage coming from a MS or a MGV105, can be reduced to meet the maximum acceptable levels of a sound card (normally between -1V and 1V). In the Internet there are a lot of examples on circuits to adapt the signal that is going to be recorded, protecting the sound card and PC. In my case, and since this solution was prepared ad-hoc to solve the problem with the crane, I simply used a simple voltage divider.

Choosing the resistors is critical, especially if you do not know the circuit in the sound card. As a general rule the second resistor should support only the -1V,1V difference, and the current through the divider should not be high enough to destroy the resistors.

Personally, I do not know if a high impedance in the divider would be better than a low impedance (as I said I do not know the details of the sound card). I have the feeling that a low impedance would be better… but it would require to dissipate a lot of power, and this solution was design to be built with 0,25W resistors. All in all, I used the following schema.

Playing with different values for the second resistor, the best results in my case were with 33k – the limit to saturate my sound card and get voltages close to -1V,1V. Note that a higher resistor can damage a soundcard; actually 33k is already too high… especially for the MGV105.

As explained before, this was just an ad-hoc solution; there are much better circuits to adapt the signals.

The software used to record the signal was wavosour. Any software that can record at the maximum sample rate supported by a sound card is OK. I used the “line in” port of my sound card, but I suppose the microphone port could work too.

The higher the sample rate is, the best (you get more samples to capture the signal). Since the Motorola format has a frequency of ≈38K[1], a sample rate of 44K could be enough (you get a sample each ≈22us and the shortest pulse in the format for locomotives is ≈26us). However, higher sample rates are needed in order to obtain an accurate capture, (pretty important if you want to measure the timings, and not just to capture the levels). In addition, higher sample rates enable the recording of accessory packets, which shorter pulse is ≈13us – out of the scope of this analysis.

I recorded the signals from the MS and DDX+MGV105 (configuring rocrail to work only with MM) using 192K as ample rate – once again I had no idea of what the limits of my sound card were.

The resulting wave files can be opened and treated with Matlab. To that end I wrote a set of functions to prepare the signal (chose the channel in the case of a stereo recording, produce the sampling vector and even adapt the polarity of the signal); decode the trits and measure the distance between packets; decode the bits; and measure the distance between two data cursors in a figure.

The results for idle data in a group of 4 packets in DDX can be found hereafter. Besides the the way the information is distributed in the MS, and not considering the expected differences –i.e. no idle data for DCC in the MS, unknown packets in the MS that could be MMX info – the main differences were on the pause timing between packets, specially the pause between double packets.

The MS is forcing a pause of more than 6000us, whilst DDX is forcing only 2000us (1700us reading the source code, if I am understanding it right).

On the other hand, the timing of an idle packet in DDX is similar to the timing of the MS, though the MS is not producing the expected idle packet -i.e. AAAA00000’trit.

With this first analysis and the results of the different functions in Matlab, the most significant difference seemed to be on the pause between double-packets. Furthermore, the comments on the different configurations for the Intellibox, and the comments on how the 6021 can be also configured to adapt the timing between packets, pointed at the timing as the more probable cause of the problem with the crane.

As a first solution I have modified the end19K value at locpool.c in rocrail sourcecode, 6000us instead of 1700. With this figure, the crane is reacting fine. I have tested the other MM decoders I have (tams LD-W-3, and a MMX decoder) and everything still works. I have also tested if this modification affects to the DCC signal,  and so far I have not detected any problem with my home made DCC accessory decoder and the loksound decoders.

I would expect more flickering in the lights, and of course a longer delay in the response to commands… but it does not seem to be so critical. Obviously, this is just a working solution. At least it would require a dialog in rocview to offer the possibility to change this value or not (as the intellibox or the 6021 do).

I am working now in declaring a new MM format in DDX (MM6) forcing this special pauses of 6000us. As soon as I get results, if any, I would publish them.

The files in matlab as well as the modified locpool.c can be found attached. Sorry but the comments are in Spanish, so if you want to use them and you need translation, please let me know.

En realidad el mecanismo es sólo el juego de bobinas para conmutar los cambios de aguja, la parte de digitalización hay que ponerla aparte a través de un decoder. Mi idea era utilizar las dos placas de decoders v2.0  que hice ya hace algún tiempo. Sin embargo, al hacer las primeras pruebas tuve algunos resultados no previstos y acabé quemando 4 veces la placa, en concreto el microcontrolador y el array de darlingtons.

Tras  volverme loco, probar con diferentes versiones de firmware, con diferentes boosters e incluso probar la placa v3.0, obteniendo siempre resultados extraños (desde más elementos quemados hasta placas que no respondían), finalmente, gracias a un amigo electrónico creo que he conseguido tener alguna idea del porqué de estos comportamientos raros.

Midiendo la resistencia de una bobina tradicional, de las que iban incluidas en las vías M, se tiene un valor de 30 Ohms, mientras que las nuevas bobinas, visiblemente más pequeñas, ofrecen una resistencia de sólo 12 Ohms. Como resultado, además de tener un bobinado más pequeño para mover el mecanismo, y que por lo tanto puede requerir más corriente, para una misma caída de tensión de 18-20V, la corriente que se debe ofrecer al bobinado es mucho mayor.

Como resultados de esta campana de pruebas, si el array Darlington sólo puede dar 0,5A, en las pruebas acababa por quemarse. Solución:

• Evitar el uso de la fuente de 20V, ya que incluso puede ser excesiva para las bobinas tradicionales.
• Soldar un nuevo Darlington encima del que lleva la placa, de forma que puedan drenar 1A.

• Incluir una resistencia en serie antes del bobinado. Hice pruebas con los valores de la tabla, y el máximo valor aceptable era de 8,2 Ohms. Además, y por precaución leí que era conveniente proteger los bobinados en su desactivación mediante un diodo en paralelo, con lo que hice el siguiente montaje:

Para conseguirlo fabriqué una nueva serie de cuatro decoders. Se trata de una versión ligeramente diferente a la 3.0, acomodando los conectores para que sea más sencillo tirar el cable por debajo de la maqueta.

Archivos v4.0.

Quizás la diferencia más importante venga por el microcontrolador utilizado en algunos de los decoders implementados. He comenzado a migrar del viejo pic 16f84A al 16f628A. Buscando en internet no queda claro si el antiguo va a ser discontinuado próximamente, y si el 16f628A es su substituto – de hecho existe un pic de similares características más nuevo todavía, el 16f88. Lo cierto es que a fecha de hoy, el 16f628A es el más barato de los tres, casi dos euros de diferencia con respecto al 16f84A. Multiplicando por 10, son casi 20€ de ahorro.

Por lo demás, el nuevo microcontrolador tiene más capacidades, que yo no voy a utilizar en el diseño de los decoders, y la migración es bastante sencilla, ya que el patillaje es compatible entre ambos pics y lo único que hay que hacer es cambiar el firmware – mover los registros de usuario, la forma de trabajar con la eeprom y desactivar los comparadores. El nuevo firmware, 7.01, es idéntico al utilizado para el 16f84A. Mismas funcionalidades pero con los cambios necesarios para correr sobre el nuevo microcontrolador.

Version 7.01 para pic 16f628A. 

 La verdad es que ya no sé si tras la detección, la información se volcará a un bus s88, a loconet, o si me haré yo algún tipo de solución propietaria para reducir el cableado.

Lo que quería probar primero era cómo hacer un sistema de detección que fuera inmune a la luz ambiente. Esto es, que tuviera mucha sensibilidad para detectar un tren, pero que la vez desestimara los positivos por luz directa, en lugar de por reflexión.

 La solución me la dio opendcc y es bastante sencilla:

1. Con ayuda de un PIC se genera una señal 01010 y se manda al emisor IR.
2. En cada ciclo se mide la tensión en el receptor infrarrojo.
3. Si la tensión viene porque el circuito se activa por la luz ambiente… el circuito se habrá activado siempre: 11111… es decir, evaluando la tensión recibida en el receptor, la suma de tensiones (o su media) en los periodos 0 será mayor que en  los periodos 1
4. Si por el contrario la detección viene por una reflexión, se tendrá: 01010, y la suma de la tensión en los periodos 1 será mayor que en los ceros.

La tensión en receptor se evalúa con un conversor analógico digital puesto que los niveles de detección pueden depender de la cantidad de luz ambiente existente… y por lo tanto es difícil fijar que valor de tensión equivale a 1 y que valor equivale a 0. Éste es un punto en el diseño que aún no he cerrado, De hecho existen una serie de variables que se pueden todavía optimizar para mejorar la detección. 

Por un lado tenemos que en un circuito clásico de detección – como el que sugiere las hojas de catálogo del sensor que utilizo, CNY70 – las dos variables que se manejarían son la resistencia en el emisor, y la resistencia en el receptor.

Con mis conocimientos amateur de electrónica, en general interesa tener una resistencia baja en el emisor y alta en el receptor.

• Rd lo más baja posible en el emisor para que circule toda la corriente posible sin quemar el led: en este caso si el máximo que soporta es 50mA, con lo que da una caída de tensión de 1,25-1,6V. Poniéndonos en el caso peor, y buscando una corriente de 40mA para dar un poco de margen de seguridad, tenemos:

Rd=(Vcc-Vf)/If=85-93Ohms

Para estar en el caso más restrictivo habría que elegir el valor mayor. En mis pruebas, me he ido a una Resistencia de 390 Ohms (lo más bajo que tenía por casa), con lo que la corriente que circulaba variaba entre 8 y 9 mA… obviamente he de hacer pruebas con una resistencia más acorde (100Ohms?). El problema futuro será como alimentar un juego de 8 leds emisores desde una única salida de un PIC, que sólo entrega 5V y 25mA – ni en serie ni en paralelo sería capaz de entregar el voltaje o la corriente suficiente (≈3mA por Led)

• Rt lo más alta posible en el receptor para aumentar la sensibilidad. Por poca corriente que llegue al receptor, se traducirá en una caída de tensión importante. Esto es necesario porque el pic evalúa la tensión en un margen de 0 a 5V (una precisión de ≈0,005V), y lo interesante es tener la mayor diferencia entre la detección del símbolo 0 y la detección del símbolo 1. 
  • Una opción sería modificar la tensión de referencia del conversor A/D en el pic, para que, por ejemplo, se evaluara de 0 a 1,5V… Aún no lo he descartado, pero esta solución implicaría más componentes y perder un pin en el pic (el que se usa para obtener Vref)
  • Otra opción sería usar una resistencia adecuada. Para el cálculo se puede usar la siguiente gráfica y estimar la distancia a la que queremos que se produzca la detección.

  

El problema es que esta gráfica considera unas condiciones muy favorables con una superficie lisa de detección. En cualquier caso sirve de guía, ya que nuestra detección se encuentra en el entrono de los 10mm… Poniéndonos en un caso catastrófico con una corriente de 0.001 mA, una resistencia de 1M, nos daría una caída de 1 V (demasiado poco). Con estas consideraciones comencé a probar 1K, 10k, 100k y 1M. Los resultados, como se esperaba eran mejores cuanto mayor era Rt.

Una característica adicional a considerar es que el sensor sí que recibe reflexiones no provenientes de un vagón detectado, por ejemplo de la vía. Obviamente estas reflexiones (falsos positivos) inducen una caída de tensión menor que la del vagón… y deben ser descartadas. Así que no sólo interesa optimizar Rt para que el valor del símbolo  “1” esté lo más lejos posible del valor del símbolo “0”, también hay que garantizar que el valor del “1” detección, esté lo más lejos posible del valor de “1” falso positivo.

De hecho con con 1M existía siempre una diferencia de casi 3V entre el ambos valores en diferentes condiciones de luz ambiental.

Para evaluar que es un falso positivo he hecho un pequeño programa de calibrado en el pic, que mide 50 veces la señal que se recibe al mandar un 1 al emisor cuando no debería haber reflexión. Esta medida debería hacerse en ausencia de luz, puesto que lo que se quiere medir es la luz que proviene del emisor, y no la ambiental. El máximo captado, es el valor límite que se utilizará para desestimar los falsos positivos. Otra opción  – más potente y a  explorar – sería medir la diferencia de tensión entre “1” y “0” en el falso positivo para desestimarla cuando se tiene una detección real. Esto es más potente porque se mantiene el principio de inmunidad a la luz ambiental. Con luz tenue en el primer caso se podría tener una situación en la la luz ambiental ayuda a superar el umbral, sin saturar, dando un falso positivo… si lo que se desestima es la diferencia de tensión proporcionada por la falsa reflexión, es sistema será más robusto. De momento las pruebas se han hecho con el primer supuesto… con lo que aún hay espacio para mejorar.

 El problema al integrar el PIC en el circuito, se hace más interesante.

 Leyendo el catálogo del pic, la resistencia de carga del conversor AD no debería superar los 10K… de hecho con 1M, aunque como comento da una caída de tensión muy adecuada… el sistema no funciona, el PIC no consigue capturarla. Así que para las pruebas he tenido que rebajar a 100k (aún fuera de especificación). La solución si quiero seguir usando una resistencia alta será usar un seguidor de tensión con un operacional o con un transistor – esta parte he de mirarla en detalle repasando mis apuntes de electrónica. Probablemente un operacional será lo más adecuado… pero veré que tengo por casa para hacer pruebas.

 Y todavía quedan más variables a optimizar:

• El tiempo de refresco entre actualizaciones de estado, que afecta para saber si el vagón será detectado atodas las velocidades. El tiempo de la captura AD es prácticamente despreciable (0,1ms-1 canal; 0,8 ms-8 canales), pero para dar tiempo al que el ciclo 01010 se propague de forma correcta he tenido que poner un retraso de 10ms (50ms por canal, 200 ms en 8 canales). Esto podría traer problemas, pero en las pruebas, cualquier cosa por debajo de 1ms daba problemas. Quizás deba jugar más con eso, en especial si considero 8 canales y luego me decido por un bus s88. Lo primero será hacer una prueba con un vagón en movimiento. Opendcc hace unos cálculos que no termino de entender:

“This evaluation is done every 10ms for a sensor. Assuming a train traveling with 50km/h (scale H0). it will travel 16cm in one sec. Thus, the query interval is 1.6mm.”

• La carencia entre detecciones. Para tener un resultado más estable he introducido un tiempo de espera entre detecciones positivas. La idea es que si el sensor es muy sensible, no deje de detectar el vagón demasiado pronto. No sé muy bien como funcionará esta solución en 8 canales. Por un lado no puede tener el pic parado mucho tiempo – se podría solucionar con contadores o vigilando el reloj. Por otro lado hasta que no pruebe con un tren en movimiento no sabré si realmente hará falta este tiempo de carencia – especial me preocupa que pasa entre, idealmente, el sensor debería ser suficientemente sensible para detectar el enganche.

Resumiendo, antes de pensar omo se volcará la información a un bus, hay que  optimizar a nivel de sensor: Rd, Rt, umbral falsos positivos, tiempo refresco y carencia.

La idea, cómo he comentado en otras ocasiones , es generar las señales de control por el puerto serie de un ordenador mediante algún programa como DDW o Rocrail.

En este caso me he decidido por el prototipo MGV-105 de Peter Giling, miembro del proyecto de Rocrail.

La verdad es que es un diseño muy elegante, y bastante más simple que el original ORD-1. Algunos puntos clave:

• Soporta DDC y Motorola
• Lleva un booster de 3A
• Detecta cortocircuitos
• Proporciona información y control por el bus loconet.

Por el contrario, el diseño deja fuera el módulo s88, ya que está pensado para funcionar en un sistema con loconet como buffer de detección de trenes. También se deja fuera la posibilidad de tener una salida para una vía de programación.

Si tuviera que modificar el diseño probablemente retomaría la idea de la programación, y partiría del ORD-2, que básicamente tiene el mismo diseño que el mgv-105, pero con una salida regulada de mayor calidad.

La construcción ha supuesto mi primera placa a dos caras. La lista de componentes y ficheros (pcb, esquemático y firmware) pueden encontrarse en la página de rocrail.

Yo os dejo algunas fotos del montaje:

Por otro lado mis padres se acordaron de mí en un reciente viaje a Andorra y, cal igual que cuando era pequeño, me trajeron este magnífico set de época I.

 Estoy buscando alguno de estos sets para completarlo: el 43985 o el 43982… muy parecidos

Aunque me temo que el primer set ya no se encuentra a al venta – a no ser que me lo encuentre en alguna tienda – y el otro está un poco caro (130X€ en JCtren).

En el capítulo de compras en eBay, me he hecho con los elemento spara completar el tren de bomberos:

Lamentablemente, a fecha de hoy aún no he conseguido hacer funcionar bajo rocrail o ddw el vagón grúa. Con la Mobile station no hay problemas, pero sacando la señal desde el puerto serie del ordenador no parece funcionar. He de hacer más pruebas, incluido pruebas con un nuevo generador de señal. Si no funcionara vería como solucionarlo, aunque me parece que con lo que he visto los planes de generar un vagón grúa propio parecen pocos viables – la micromecánica utilizada es bastante difícil de controlar.

 También he comprado un par de vagónes para completar el ICE2 procediente del set que märklin ha sacado este año (78056). Es el único que conozco que cuadra con el viejo set delta ice2. En cualquier caso quedo a la espera de incorporar también un vagón comedor y modificar los vagones de forma que al menos dispongan de iluminación.

Finalmente, me he hecho con este par de vagones para completar la serie de vagones 4026, 4052 y 4053  de la que disponía.

De hecho han creado una nueva placa de alimentación muy compacta y sencilla que no incluye el bus s88 y que es capaz de reportar cortos y estado a loconet.

Aún no tengo muy claro como funciona el sistema – me estoy informando en el foro de rocrail – pero la versión simplificada del nuevo esquema debería ser algo así.

Lo único que sé es que los cirtuitos que se emplean son bastante más sencillos de realizar, y que el programa es capaz de gestionar los boosters de manera individual.

Lo que aún no sé cierto es como se conectan los detectores de corriente – y si podré adaptarlos a una detección por infrarrojos – ni como se conectan varios boosters.

Espero aclarar las dudas pronto.

La instalación del fumígeno es una odisea que no ha terminado todavía. He tenido que aislar bien el espacio que la máquina tiene reservado para el fumígeno. Primero intenté poner una pequeña pieza d plástico con una zona de contacto para cerrar el circuito… pero no daba buen contacto.

Al final opté por dejarlo todo bien aislado y soldar directamente el cable al fumígeno. Por desgracia, el fumígeno que tenía disponible – un seuthe 11 – no da la cantidad de humo que me gustaría, así que he decidido encargar un seuthe 10 a JCTREN. La diferencia entre uno y otro, para los que desconocen la marca es que el 11 está pensado para la alimentación desde el decoder y el 10 desde la vía (modo analógico). ESU (loksound) recomienda emplear estos últimos cuando el retorno de corriente se ahce directamente por la vía, como es el caso.

De momento he dejado instalado el nº 11 que algo de humo sí que hace, pero en cunato me llegue le nuevo lo cambio.

 Para el camuflaje del decoder me he decidido a eliminar por completo la placa de conexiones que me hice, soldando directamente el decoder a cada uno de las funciones. El resultado es que el decoder casi cabe con la pieza de simulación de carbón original de la máquina.

 La solución está en camino. De momento he cortado la pieza en tres, y ahora se acopla bastante bien al ténder. La solución final será sustituir una de esas piezas por una nueva casera hecha con gravilla de la que se usa para simular el balasto.