[Solved] Problems configuring a crane car

Moderator: Moderators

Postby mserrano » 15.09.2009, 22:32

Thanks Volker,

I have tested a minimal configuration with no results. Actually, I have notice different behaviours depending on the OS:

Under Linux, after getting the minimum configuration, the results were exactly the same as before :(

Under Windows, it has been impossible to turn off the checkTX and fastCVget... the computer nearly collapsed. Anyway, leaving only the MM protocol active, the results are still negative. I am attaching new traces and the plan used.

I am going to be out the rest of the week. On the weekend I will test with another computer... and hopefully I will receive the parts to build my ORD-2... after that, I will not know what else to try.

Maybe, if you can send me the plan you used I can try to see if the traces I produce with it are still weird.

Thanks again,

You do not have the required permissions to view the files attached to this post.

Postby ViktorHotel » 27.09.2009, 16:25

Hi Manolo,

If you use linux can you please post the output (console/terminal window) of:
dmesg | grep tty
Maybe it is the uart type of your computer, not every usb-serial converter works with DDX (see Wiki)
On my computer DDX is working on ttyS0, a "real" serial port with 16550a uart.
volker@Bahn:~$ dmesg | grep tty
[ 22.317722] console [tty0] enabled
[ 24.093608] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 24.094195] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 33.660909] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 33.660987] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
[ 39.359079] audit(1254063781.418:2): type=1503 operation="inode_permission" requested_mask="a::" denied_mask="a::" name="/dev/tty" pid=4857 profile="/usr/sbin/cupsd" namespace="default"

maybe another option to test is "chmod 666 /dev/ttyS0"

rocrailing with:
Ubuntu 16.04 LTS, MDRRC-II mit BMB Booster-B5 (Fahren), HSI88(Rückmelden), Sprog3 (Weichen und Signale), DMX-Artnetnode (Wetter und Licht)

Postby mserrano » 27.09.2009, 22:54

Hi volker,

Herafter the results of the command in linux:

[ 0.004000] console [tty0] enabled
[ 1.863515] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.863602] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 1.863923] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.864081] 00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 10.939132] usb 1-1: pl2303 converter now attached to ttyUSB0
[ 353.618964] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 353.947421] usb 1-1: pl2303 converter now attached to ttyUSB0

On Linux I am running rocrail in ttys0 (real com port)

Since my last post I have made more tests:

1. Tests on a different computer: same results
2. Test with a mgv-105 (similar to ord-2) as booster: same results.

At this point I am pretty sure it is not a problem of HW. I have been trying to find more about the decoder used by the crane car... but no news so far.

During this month I will try to check the output with an oscilloscope at work... at least to see if the quality of the signal is OK.

As I said, since everything else is working, and the results on other computers or other boosters are consistent... it seems that the problem is on the SW, not producing the signals required by the car.

Any help is still welcome, but I think next step will be to check the quality of the signal and try to sniffer the output of a Mobile station- where the crane worked- and the output of ddx... to compare both.



Postby mserrano » 15.11.2009, 21:33

Hi there,

I have finally made some progress with the issue of the märklin crane… Well maybe I shouldn’t be so optimistic… there is not actually “progress” since I still don0t have my crane running. However, I have found some information that may be relevant to find a solution.

Checking the Internet I came across these two sites with information on problems the Intellibox has to interface with the Märklin crane 46715:

http://stummi.foren-city.de/topic,7319, ... libox.html

Since I do not speak German – not at all- I had to trust on the google translator service to get to know something like this:

Problems with the Marklin Crane 46,715
Problem / Question:
With the Intellibox it is not possible to control the crane to Marklin
Special Options 902 = 16 (factory setting: 12) Special Options 914 = 40 (factory setting: 18) In a similar setting is the measurement vehicle operated. See also FAQ-test van.
The Marklin Crane has internal controls a decoder that simultaneously the piezoelectric actuators. This decoder responds only when certain break times are guaranteed in the digital signal

Original source in german here:
http://www.uhlenbrock.de/germany/Servic ... Name=GAMMA

I assume that if the IB has problems to control the crane, DDX could have also some issues with it. I have been trying to find out this weekend how the solution for the IB works –i.e. what the SO 902 and 914 make. But I do not have an IB, and there is not so much information in English on the web site.
Any help on this issue would be great.

In the meantime, I am planning to take my MGV-105 with DDX and the mobile station to an oscilloscope to see if I can find out more about the “break times” that makes the crane run.

Worst scenario, “easy solution”: replace the decoder on the crane… I have been playing with a design from Paco Cañadas… but so far, I have not been able to make the decoder react…. So, not even considering controlling three “piezoelectric actuators”.

Best scenario, complex solution: get to know what the SO on the IB make, and see if it can be translated to the DDX ?

I will keep you all informed, if I make more “progress”.
Best regards,

Postby Besra » 15.11.2009, 23:16

Hi Manolo,

you can trust the google translator in this case (translation of Uhlenbrock site). It is stated there the decoder of the crane car depends on correct (or better to say: special) timing in the MM protocol.
In the Stummi-Forum you quoted it was speculated the IB does use some "unused" time slots in the MM protocol to interleave other commands (from other protocols, e.g.) in order to speed up communication. This could hamper communication with the crane car (due to its special decoder). The Special Options 902 and 914 will lengthen these time slots (or breaks) if I understood correctly.
Following the Stummi-Page the crane car is working under MM2 only, MM1 will not work. On the other hand you have to set the address of the crane car (or adr. 80) to MM1 (!) on the IB if you want to set the decoder address (that's a special case for the IB because of some special timings needed to access programming mode of "modern" Marklin-decoders which will work under MM1 only).

In conclusion the decoder of the crane car relies on special or strict timing (same or similar applies to the Marklin measurement car).

Best regards
Maerklin H0, DCC and MM, Intellibox (I) via ULNI, Booster Tams B4, Throttle Digitrax UT4, LocoNet.
Loco decoders: Zimo, Uhlenbrock, Maerklin & ESU.
Rocweb, Win10 32bit & 64bit

Postby mserrano » 30.12.2009, 14:48

Finally I found a first solution to the problem with the crane.

The complete explanation is in the attached pdf (published at my website). It may be useful in the future to debug other problems with new decoders and other hardware. In any case, a reference is always needed to analyse the signal and packet content that makes the decoder works. With this information, it is possible to compare it to the output from DDX, and see if it is possible to provide the decoder with the signal it needs.

In short, the problem in the case of the crane was with the pause between packets (between double-packets). The MS force a pause of more than 6000us, and DDX is around 2000us.

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 used in matlab to analised the signals 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.
I do understand that this new feature is only affecting me… so it is a minor improvement. However, I think that solving this problem can provide a new feature to DDX – supporting märklin cranes –similar to the one the intellibox or the 6021 offers.

Before continuing, and since I do not like to mesh with someone else’s code, I would like to ask Rob and the developers involved in the support of DDX their opinion.

Despite my technical background, I have not gone deep into coding for years… I think I have a clear idea on how to declare a new MM format, which I think is the cleanest solution – less flickering, reduced impact on the delays, etc. I will give it a try during the weekend. If the results are not positive, I think I am not so confident on my capabilities to modify the dialogues in rocview… and I would need help :(.

May I proceed? As I said, I prefer to get permission from whoever takes care of DDX. :D

BTW: I am working on windows… is there an easy way to compile only the ddx.dll library?.
You do not have the required permissions to view the files attached to this post.

Postby rjversluis » 30.12.2009, 17:00


I can give you some help with merging and dialogs.
If this option works for all MM version I would not introduce a new MM6 but add the longer pause as new option for all.

If you only want to build the ddx library just change the working directory to digints and issue the make file for windows.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
Site Admin

Postby rjversluis » 30.12.2009, 18:13


I added the "long pause" option in revision 1141. Default is no long pause to be backwards compatible.
Also the dialog has became this option.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
Site Admin

Postby mserrano » 02.01.2010, 19:46

Thanks Rob!
I did the test with a new MM6 before reading your message.
I suppose the timing is better – I did not measure this time, but theoretically the pauses are just sent with the MM6 protocol. In any case, I cannot perceive the extra pauses, so I am completely happy with your solution.
I agree that creating a new MM protocol could be worst – the MM code seems already quite confusing – at least for me.

Thanks again,



Return to ddx