Mi Tren » Rocrail

Nueva locomotora HAMO e interfaz loconet

Manolo — Sat, 29 Oct 2011 10:51:24 +0000

Recientemente he incorporado a la colección una locomotora HAMO (BR012) y un interfaz para una mobile station.

La idea es convertir la locomotora a sistema marklin, usar el interfaz para comunicar con rocrail por loconet y dejar la mobile station como un control más.
Lo segundo aún no tengo muy claro si se puede hacer. El interfaz estaba pensado para una central intellibox. Así que tengo que investigar un poco más.
Para la conversión a digital en tres carriles la cosas es más sencill. No tengo ni que instalar el imán. la conversión es casi directa sólo me surge una duda: ¿para qué sirve el pequeño tornillo de la foto?

Función SpeedCurve en Rocrail no aprobada

Manolo — Tue, 07 Jun 2011 21:56:49 +0000

~~Aún no sé porque – no me han dado ninguna explicación – pero~~ la contribución del speedcurve no ha sido aceptada por el administrador de Rocrail.
~~A la espera de más información – al menos me gustaría que me dijeran porqué la rechazan –~~ he compilado un paquete basado en la rev 2631:

rocrail-setup-2.0.0-SpeedCurve-rev2631-win32.

Esta solución debería solucionar el problema de pérdida de memoria que describía en el anterior post. Los nuevos ficheros fuente (speedr).

La contribución no se va a incluir en la distribución oficial porque “sólo es útil para decoders de bajo coste que se pueden substituir por poco dinero” . Yo seguiré actualizando esta versión para uso propio, así que si alguien la quiere, sólo tiene que pedirla .

Función Speedcurve en Rocrail

Manolo — Sun, 05 Jun 2011 20:04:50 +0000

Este fin de semana he mandado a la gente de Rocrail una contribución para añadir una funcionalidad a Rocrail. Se trata de la capacidad de tener una curva de velocidad que se gestiona desde el ordenador.

La documentación está en Inglés:

Finally I have had some time to implement the functionality I was requesting. I am attaching an explanation on what the motivation was, and how it can be used.
Since I am not at all an expert on C, neither on the rocrail code, it has taken me longer than expected. Moreover, there is still a problem with the code – a memory leak – I have not been able to solve. I think it is in the way I am attaching the speedcurve parameters to the loc command (loc.c file)… but I am not sure – any help, correction and suggestion for improvement is very welcome.
Basically I have modified the wrapper description file to include a new property to the loc (speedcurve). Then I have modified the loc.c file to explore if a locomotive has this property and include them in the commands sent to the stations. Finally, in DDX, this parameter is treated in MM locomotives.
The reason to address only MM is basically because DCC decoders use to have an actual speedcurve functionality. In any case, since the information is transmitted to any station, anyone could make use of it to implement the speedcurve as I have made for DDX MM.
Hope this new feature to be of interest. It needs still some refinement for the memory leak.. but hopefully someone could give me a hint on how to solve it, so it can be included in a stable release – if it is of interest of course.
I am attaching the three source code files modified, a plan example and the explanation of the functionality.

Description and motivation

A speed curve is a well-known feature of new decoders, and especially it is a feature extensively used in DCC hardware. The solution is normally based on a number of CV that grants the user with the possibility to specify non-linear speed curves, which are closer to reality. The speed can be set per engine step and in addition it is also possible to define the acceleration and deceleration time.

Older decoders, and especially some low-cost solutions designed to work with the motorola format, cannot access such rich feature. In the best scenario it is possible to adjust the acceleration and deceleration time, but never to define different parameters per engine step. This handicap can be easily overcome by software with Rocrail, introducing predefined speed profiles per engine step that can be interpreted by DDX.

The speed curves by software, or speed profiles, are based in the definition of the time each step needs to be hold before going to the next/previous one. It is noteworthy to clarify that the functionality provided by a hardware speed curve is not exactly the same, since a speed profile will not affect the speed magnitude, but the acceleration/deceleration time between steps.

In this way, it is easy to code curves forcing long pauses to accelerate for the lower steps and short pauses for the higher steps, or long pauses to decelerate in higher steps and low pauses in the lower steps.

ACCELERATION CURVE 1

DECELERATION CURVE 1

Furthermore, speed profiles have been proved especially useful in some decoders that, in addition to the lack of a speed curve, have some particular time constraints to achieve an efficient behavior:

Märklin DIGITAL 146871 PIC-Decoder 1. This low-cost decoder needs some pause after any speed change request to actually reach the new speed. This is important when two consecutive commands are sent, and especially critical if a change of direction is requested. In those cases, the decoder needs to stop before implementing the change of direction. Without the mandatory pause, the engine does not “accept” the request, and the change of direction is never achieved.
TAMS LD_W_3. This decoder needs an update on the speed after a change of direction request. Otherwise, the delay in accepting the order depends on the loco stack of commands and active protocols in DDX – worst scenario up to 18 seconds of delay with MM, MMLP and DCC active.
Motorola format I. This protocol forces a stop whenever a change of direction is requested. The behavior can be improved by implementing speed profiles, which may help considering the speed when
the change of direction is requested as a persistent variable. In this way, after the change of direction is implemented, the speed is recovered and the loco does not stop.

How it works

The speed profiles are implemented as a new feature for DDX working on Motorola protocol locomotives. The user needs to define per each step (14 or 28 steps) the delay until the next or previous step. As an example, the accelerating curve in previous section is defined by:

Step	Delay to next step (ms)	Next step
0	1500	1
1	1000	2
2	900	3
3	800	4
4	700	5
5	600	6
6	500	7
7	400	8
8	300	9
9	200	10
10	200	11
11	175	12
12	150	13
13	125	14
14	100	NA

The curve can be extended to 28 steps. In any case, as expected, the last parameter – i.e. ms to go beyond the maximum step – is never used.

IMPORTANT: a minimum delay of 10ms between steps should be respected (100ms recommended value). Otherwise, depending on the platform, the rocrail serveray collapse.

In a similar way, the deceleration file is defined by:

Step	Delay to previous step (ms)	Next step
14	2000	13
13	1800	12
12	1200	11
11	1000	10
10	600	9
9	600	8
8	500	7
7	400	6
6	300	5
5	200	4
4	175	3
3	150	2
2	125	1
1	100	0
0	200	*Pause before sending a refresh in a change direction request

In this case, the last parameter, which was not used in the speed profile definition, has been used to code a pause if a refresh message wants to be sent at the end of the sequence when a change direction is requested – 0ms =non refresh.

In reaction to a speed change request, a sequence is initiated to reach the new speed going through the curve. In this way going from v=4 to v=9 would trigger the following sequence:

· Wait 700 ms and V=5

· Wait 600 ms and V=6

· Wait 500 ms and V=7

· Wait 400 ms and V=8

· Wait 300 ms and V=9

In the same way a change of direction in v=4 would trigger the following sequence:

· Wait 175 ms and V=3 reverse

· Wait 150 ms and V=2

· Wait 125 ms and V=1

· Wait 100 ms and V=0

· Wait 1500 ms and V=1 forward

· Wait 1000 ms and V=2

· Wait 900 ms and V=3

· Wait 800 ms and V=4

In the case of having any delay defined for v=0 – for instance 200ms-, at the decelerating curve, a last message would be sent:

· Wait 200 ms and V=4

The decelerating curve would be used in a similar way to go from v=9 to v=4.

Configuration

The configuration of any speed profile is done at the XML file describing the layout.

As a new parameter describing a loco, now it is possible to include a “speedcurvestep”:

For each step the ms to wait until the next and previous steps need to be set.

If a step is not defined, or if it is defined with a 0ms wait, it will not be considered in the acceleration, or deceleration profile. Thus, a speedprofile as the one above will produce the following curve:

ACCELERATION CURVE 2 (wait in v=0 3000 ms)

DECELERATION CURVE 2

The sequences presented(v=4 to V=9) before would become:

· Wait 0 ms and V=9

Delays equal to zero are not considered.

And V=4 change direction would become:

· Wait 100 ms and V=3 forward

· Wait 2000ms and V=2 forward

· Wait 1000 ms and V=1 forward

· Wait 1500 ms and V=0 forward

· Wait 3000ms and v=4 reverse

Examples

The attached file (speedr) presents the modified source files and four examples :

· One typical speed profile (curve 1, Firemen)

· One low cost (curve 2, 130TB)

· One motorola I (curve 3, BR44)

· One tams (curve 4, V160)

The rest of the locomotives are just included to test that the speedcurve does not affect other decoders.

ACCELERATION CURVE 3(no delay)

DECELERATION CURVE 3

ACCELERATION CURVE 4 (no delay)

DECELERATION CURVE 4 (repeat chdir)

Solución definitiva al problema del coche grúa en Rocrail

Manolo — Sat, 02 Jan 2010 22:45:05 +0000

Finalmente han introducido una opción de configuración en Rocrail para permitir una pausa larga entre paquetes Motorola. Esta sencilla solución hace que el vagón grúa funcione ya perfectamente.

Solución 1 (con suerte no la última) al problema del vagón grúa en Rocrail

Manolo — Wed, 30 Dec 2009 13:14:51 +0000

El vagón grúa me ha dado muchos problemas para funcionar en rocrail. Tras varios meses mirando el problema e intercambiando información en el foro, parece que por fin he encontrado una solución. Por comodidad la he documentado en inglés, pero si alguien necesita traducción sólo tiene que contactarme.

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.

[1] A complete description of the Märklin Motorola format is provided by Andrea Scorzoni at http://www.diei.unipg.it/STAFF/scorzoni_file/personale/hobby/motorola.htm

Estudiando un nuevo esquema ecléctrico

Manolo — Sun, 06 Sep 2009 10:16:20 +0000

En los últimos días estoy estudiando abandonar el planeado uso dl bus s88, y sustituirlo por loconet. Parece que en rocrail es la opción que da mejores resultados.

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.

Estación subterránea (II)

Manolo — Mon, 18 Aug 2008 22:40:14 +0000

Tras más de dos años sin trabajar en los aspectos mecánicos de la maqueta (carpintería), este verano me he decidido a avanzar un poco más con la estación subterránea.

A falta de terminar mi booster casero, los detectores infrarrojos y de hacer más copias de mi decoder de accesorios; me he puesto a construir la rampa de acceso a la estación subterránea. Además he incluido las modificaciones al diseño que ya presenté en un artículo anterior.

Tras dar inclinación a las vías, me ha parecido que era hora de clavarlas, y evitar así que se vicien y adquieran deformaciones. Para ello además de la capa de chapa de madera sobre la que se sujetan, he provisto el trazado de una cama de corcho que amortigua y da homogeneidad al recorrido.

Finalmente he pasado todos los cables ya a la cara inferior, dejando despejado el nivel de las vías.

La segunda gran novedad ha sido la inclusión del ordenador que correrá rocrail para controlar la maqueta.

Lo he instalado junto a la rampa, en una zona muy despejada de vías y cercana a los enchufes de la casa. Para albergarlo lo he alojado en una pequeña caja de metacrilato. En realidad, no se pude considerar una caja ya que, a fin de poder acceder a él y manipularlo desde abajo (cuando la maqueta esté terminada el acceso desde arriba será imposible), lo que he hecho ha sido fabricar tres paredes de metacrilado (arriba, abajo e izquierda) que se puedes desmontar para liberar el ordenador. La ventilación se garantiza por una de las paredes y con la inclusión de ventiladores. En la zona de ventilación se incluirá también el booster principal.