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