THE MANUAL OF THE

NEW MÄRKLIN-MOTOROLA FORMAT

©Andrea Scorzoni, 1995-2000

FOREWORD

This is version 3.7 of the manual on the "New Motorola format" introduced by Märklin in 1994 with the Control Unit 6021. As you will see, the new format has only a few features in common with the standard trinary Motorola format (145026 format). Moreover, this manual does not describe in detail the old format, since a lot of literature is available on it.

After receiving this document, Märklin Export Directorate told me that they had not time (at least up to now) to publish an official document describing the new Märklin-Motorola format. I hope this document will help both you, reader, and them, Märklin officials.

The format described in this document has been thoroughly verified and tested.

Quite obviously, I'm not responsible for anything that might happen to your rolling stock when using the information contained in this document. This document is likely to contain typing and logical errors. Please check it. I'm waiting for your feedback's and reactions.

Should you use this information in written documents, please refer to the source of it:

Andrea Scorzoni, via Agucchi 169, 40131, Bologna, Italy.

e-mail address (office): scorzoni@diei.unipg.it

home page (office): http://www.diei.unipg.it/STAFF/scorzoni.htm

Many thanks are due to Stefano Chiti-Batelli for extensive testing and verification of the format described in this document. The help of Rob Hamerling is also gratefully acknowledged, for a better understanding of the data stream issued by the 6021. Thanks also to other friends from the Märklin Mailing list. 

CONTENTS

FUNCTION OF THE 4 DIP SWITCHES OF THE 6021:

DIP SW. #1)
[OFF]/[ON] ->[OLD&NEW] /[ONLY-NEW] extended function decoder codes and [OLD&NEW] /[ONLY-NEW] "reverse direction" information.

To keep compatibility with old-fashioned decoders (from Zy to 701.13 through LME) use #1 OFF (see later);
DIP SW. #2)
[OFF]/[ON] ->[OLD]/[NEW] Motorola format; Direction arrows on the Control 80f (6036) turn on.
DIP SW. #3)
Only for new Motorola format. It increases the speed at which info is sent to the track. In other words it decreases the time intervals between series of 18 pulses. Incompatible with some chips before 701.13 (it doesn't work, e.g., with some chips LME03, LME=Lenz Märklin Electronics)
DIP SW. #4)
Voltage stabilization at +/-12 Volt.
If #1 OFF and #2 ON you actually have a mixture between new Motorola format and old function decoder format. The additional functions f1,f2,f3,f4 are working both with old decoders (e.g. digital crane decoder) and new ones (e.g. additional functions of the c95).
Please take into account that the 6021 reads the DIP switches only during the "power on" cycle or after a "reset" ("stop" and "go" pressed at the same time for about half a second). Therefore, changing the position of the DIP switches during normal operation has no effect.
Return to the Table of Contents

DEFINITIONS.

Return to the Table of Contents

ABOUT THE TRITS OF A PACKET

A packet is made of 18 binary pulses or 9 trits. Depending on the type of device addressed, the following packets and trit subsets are used: 
locos: A1 A2 A3 A4 F S1 S2 S3 S4  (standard frequency,
                      old and new Maerklin Motorola protocol)
       -> A1 A2 A3 A4 address part (trinary)
       -> F           auxiliary function trit used in binary mode:
                      the function is ON in the case of two long pulses,
                      OFF when two short pulses are used
       -> S1 S2 S3 S4 speed and reverse function in the old Motorola
                      protocol (used in binary mode);
                      speed, direction of travel and status of
                      additional functions f1...f4 in the new
                      Maerklin-Motorola protocol.
                      S1 S2 S3 S4 are no longer binary
                      or trinary (see later).

solenoids: A1 A2 A3 A4 0 D0 D1 D2 S  (double frequency,
                          old and new Maerklin Motorola protocol)
       -> A1 A2 A3 A4 address part (trinary);
       -> "0"         fixed trit;
       -> D2 D1 D0    binary trits used to address the particular port
                      of the k83. Range: 0...7; D2=MSB, D0=LSB.
       -> S           status of the k83: "1"=on, "0"=switch off all
                      the k83, no matter what D2 D1 D0 are.

additional functions decoders: A1 A2 A3 A4 1 F1 F2 F3 F4
                      (double frequency, old Maerklin Motorola protocol)
       -> A1 A2 A3 A4 address part (trinary);
       -> "1"         fixed trit;
       -> F1 F2 F3 F4 binary trits used to switch on and off the
                      4 functions f1...f4, respectively.
Return to the Table of Contents

ADDRESS PART "A1 A2 A3 A4" OF A PACKET

"A1 A2 A3 A4" are trits, i.e. they are used as trinary bits. 3^4=81 addresses are possible. Only 80 addresses are actually used for locos and old function decoders and only 64 addresses are used for solenoid devices.
The trinary addresses can be recognized in the DIP switch setting of locomotives that is enclosed in all Märklin Digital publications. There are 8 DIP switches, numbered from 1 to 8. 
-> 1,3,5,7 are connection to ground of the 4 address
           inputs of the decoders;
-> 2,4,6,8 are connection to Vcc of the 4 address
           inputs of the decoders;
If these address inputs are left unconnected, the decoders interpret this as an "open".
For example, -2--5-7- means: 
      -2  1st trit   = 1
      --  2nd trit = open
      5-  3rd trit   = 0
      7-  4th trit   = 0
Please note that in the Märklin Motorola protocol the trinary address "0000" is defined as "80" while the address "open open open open" of locos and function decoders is used to transmit the "idle state" packets (see next section). 
Example: address 34:
34:3=11      remainder: 1
11:3= 3      remainder: 2
 3:3= 1      remainder: 0
 1:3= 0      remainder: 1

Then: 34=1*27+0*9+2*3+1*1
The trinary format of 34 is 1021, i.e. "1" "0" "open" "1". In the Motorola format they are actually sent with a reversed sequence, i.e.: 
"1" "open" "0" "1" (trits) or
11 10 00 11 (bits)
-2 -- 5- -8 (Maerklin DIP switch)
A1 A2 A3 A4
Return to the Table of Contents

IDLE STATE

The idle state is forced on power-on or after a reset.
In the old Motorola protocol the idle state forces a continuous negative voltage on the track (red socket negative with respect to brown socket).
In the new Märklin-Motorola protocol the idle state causes a continuous transmission of packets in which the address part is the non-used address of the Märklin Digital, i.e. four "open" trits, and the data part is 5 "zero" trits.
Please note that this address is actually an "80" in trinary code, while the address "80" of locos and function decoders is coded with a sequence of 4 "zero" trits.
The idle mode ends as soon as the first "true" packet for locos is sent.
Return to the Table of Contents

BITS FOR LOCOMOTIVES IN THE NEW MOTOROLA FORMAT

When DIP switch No.2 in the Control Unit is ON, the new Motorola format appears on the tracks.
In the new Motorola format: Summarizing, the first 10 binary pulses of the new "Motorola" format are exactly the same as for the old one. For example, two long binary pulses at 9th and 10th place (5th trinary pulse = 1) mean "function on". Only the last 8 binary pulses are different in the new protocol.
Return to the Table of Contents

DESCRIPTION OF THE SEQUENCE OF PACKETS

The new format sends the following sequence FOR ONE LOCO: 
- 2x double packet specifying speed and direction;   (*)
- 2x double packet specifying status of additional function f1;
- 2x double packet specifying speed and direction;   [same as (*)]
- 2x double packet specifying status of additional function f2;
- 2x double packet specifying speed and direction;   [same as (*)]
- 2x double packet specifying status of additional function f3;
- 2x double packet specifying speed and direction;   [same as (*)]
- 2x double packet specifying status of additional function f4;
In case of TWO LOCOS the format is: 
- 2x double packet specifying speed and direction;   (1st loco)
- 2x double packet specifying status of additional function f1; (1st loco)
- 2x double packet specifying speed and direction;   (2nd loco)
- 2x double packet specifying status of additional function f1; (2nd loco)
- 2x double packet specifying speed and direction;   (1st loco)
- 2x double packet specifying status of additional function f2; (1st loco)
- 2x double packet specifying speed and direction;   (2nd loco)
- 2x double packet specifying status of additional function f2; (2nd loco)
...
and so on.
The reason why more than one packet is issued for the same information is the electrical noise always present when an electrical signal is picked-up by a rotating wheel. For error control, a decoder reacts only when it detects two identical packets. The decoder is very lucky in case it is able to understand two consecutive packets. Usually it needs more than two packets, typically 4 or even more.
There is no limit to the number of locomotives in the refresh cycle. This means that up to 80 locomotives can be refreshed at the same time. When DIP switch #1 and #2 are ON the refresh cycle is very time consuming (see also section FUNCTION OF DIP SWITCH No.3). When DIP switch #1 and #2 are OFF, since in this situation there are only 4 packets per locomotive, a complete cycle for all 80 locos takes much less time (slightly over 2 seconds).
The refresh cycle is in reverse sequence: when activating addresses in the sequence 1,2,3,4,5 the repeat cycle shows: 5,4,3,2,1.

Let us have a look at the data stream issued by the 6021 as a consequence of a particular command. The following paragraphs have been compiled with the help of a "sniffer" program written by Rob Hamerling. For more information please refer to Rob's home page
When changing the speed of a loco, the 6021 sends 16 identical packets (8 double packets) with the new information and then resumes the refresh cycle.
When sending "reverse direction" information, the 6021 (with DIP switch #2 ON) issues 16 "change direction" packets of the new type (8 double packets). When DIP switch #1 is OFF it also issues 12 "change direction" packets of the old type (6 double packets).
When pushing the FX (F1...F4) button the 6021 interrupts its packet refresh cycle and sends 12 identical packets (6 double packets) with the FX ON code to the selected locomotive decoder before resuming the normal refresh cycle.
Return to the Table of Contents

DETAILS ON THE LAST 8 BINARY PULSES OF A PACKET.

In the following I'll discuss only the last 8 binary pulses. Previously they were interpreted as 4 trinary pulses, but only "0" and "1" values were considered, so that they were actually 4 binary digits, giving rise to the 16 (2^4) operational levels of the Märklin Digital system. From now on I'll consider them as 8 binary pulses (2^8=256 possible combinations).

Let's call them: A E B F C G D H

In the old Motorola format these bits were actually AABBCCDD (E=A, F=B, G=C, D=H, 16 combinations) and, thinking about trits
 

reversed -> D C B A
operat. level
1 1 1 1
14
1 1 1 0
13
...
...
0 0 1 1
2
0 0 1 0
1
0 0 0 1
reverse
0 0 0 0
stop

Table 1

To better analyze the new Märklin-Motorola format, let's split these bits as follows: 

                     A   B   C   D
                       E   F   G   H
The operating level is always present in the A B C D pulses, and it is compatible with the old format
 

reversed -> D C B A
operat. level
1 1 1 1
14
1 1 1 0
13
...
...
0 0 1 1
2
0 0 1 0
1
(0 0 0 1)
(reverse)
0 0 0 0
stop

Table 2

Note that, from the theoretical point of view, the code "0 0 0 1" is not needed, in the new format (it's obsolete!). However, for backwards compatibility, when DIP switch #2 is ON the 6021 issues 16 packets with a mixture of "old reverse information (DCBA=0001) and absolute direction information (HGFE different from DCBA). Moreover, when DIP switch #2 is ON and DIP switch #1 is OFF ("New Motorola Format" WITH backwards compatibility with LME decoders), before the 16 packets just described the 6021 issues 12 old Motorola "11 00 00 00" packets (reverse direction).

The only thing that changes in the sequences of double packets described above is the content of EFGH.

CASE OF A DOUBLE PACKET SPECIFYING SPEED AND DIRECTION

In the case of double packet specifying speed and direction, the values of EFGH depend on the operating level
 

operating level
E F G H
-14 to -7
1 0 1 0
-6 to -0
1 0 1 1
+0 to +6
0 1 0 1
+7 to +14
0 1 0 0

Table 3

Note that "+0" means speed=0 and forward direction, "-0" means speed=0 and reverse direction. "-6 to -0" and "+6 to +0" include the reverse direction code "0 0 0 1".
Moreover, following these settings the last 8 bits of a packet cannot be confused with the same bits of the old protocol. In fact it is impossible to have a sequence AABBCCDD since the relationship between H and the most significant bit of the speed set (D) is always such that:

H = NOT(D)

The total number of combinations used for sending information on speed and direction is 32, i.e. the total number of speeds from -14 to +14 plus 2 combinations for reversing direction of travel, still used for compatibility with Märklin decoders conforming to the old protocol.
 

CASE OF A DOUBLE PACKET SPECIFYING SPEED AND STATUS OF F1...F4

Standard values
 

f1
f2
f3
f4
E F G H
E F G H
E F G H
E F G H
standard values
1 1 0 f
0 0 1 f
0 1 1 f
1 1 1 f

Table 4a

The value of the variable "f" in the last bit (H) of all columns is dependent on the status of the additional function: OFF: f="0"; ON: f="1".
Please note that only 6 possible combinations of the three bits EFG are used when joining Table 3 AND Table 4a.
On the other hand, since the bit "f" can be both "0" and "1" depending on the status of the extended function, it is not possible to assure that the resulting combination AEBFCGDH does not conflict with the case AABBCCDD (old Motorola protocol).
For this reason some exceptions can be found to the format of Table 4a. These exceptions are for compatibility with the old format. In fact, e.g., in the case of operating level 2 and additional function f1, with EFGH=1100 we could have: 

    A   B   C   D
      E   F   G   H
    1 1 1 1 0 0 0 0
which is the old operating level "2".
The exceptions are shown in Table 4b.
 
f1 OFF
f1 ON
E F G H
E F G H
standard values
1 1 0 0
1 1 0 1
operating level
2
1 0 1 0
normal
10
normal
0 1 0 1

 
f2 OFF
f2 ON
E F G H
E F G H
standard values
0 0 1 0
0 0 1 1
operating level
3
1 0 1 0
normal
11
normal
0 1 0 1

 
f3 OFF
f3 ON
E F G H
E F G H
standard values
0 1 1 0
0 1 1 1
operating level
5
1 0 1 0
normal
13
normal
0 1 0 1

 
f4 OFF
f4 ON
E F G H
E F G H
standard values
1 1 1 0
1 1 1 1
operating level
6
1 0 1 0
normal
14
normal
0 1 0 1

Table 4b

Please note that the EFGH combinations 1010 and 0101 are normally used to indicate the direction of travel in the packet that specify speed and direction. However, the normal meaning of EFGH=1010 is "negative direction of travel, speed between -14 and -7", while in the case of Table 4b it is used for speeds 2,3,5,6. Similarly, EFGH=0101 normally means "positive direction, speed between 0 and 6", but in Table 4b it is used for the operating levels 10,11,13,14. For these reasons the Märklin-Motorola protocol is completely consistent.
The total number of combinations of 8 bits used for sending information on the status of the extended functions is:
(No. of functions) x (No. of operating levels) x (ON/OFF) = 4 x 16 x 2 = 128
In this computations I also included as operating levels the ABCD binary value used for reversing direction of travel. This is for compatibility with Märklin decoders conforming to the old protocol.

EXAMPLE

Loco #34, function ON, speed -4, aux. function f1 ON and f2,f3,f4 OFF. 
Address part: 11 10 00 11
Function: 11

1st packet has:
Speed (from Table 2):     A   B   C   D         1   0   1   0
from Table 3:               E   F   G   H         1   0   1   1

2nd packet has:
Speed (from Table 2):     A   B   C   D         1   0   1   0
from Table 4:               E   F   G   H         1   1   0   1
etc.

The complete set of packets for loco #34 is: 

4x  [11 10 00 11 11 11 00 11 01]  speed
4x  [11 10 00 11 11 11 01 10 01]  speed & f1 ON
4x  [11 10 00 11 11 11 00 11 01]  speed
4x  [11 10 00 11 11 10 00 11 00]  speed & f2 OFF
4x  [11 10 00 11 11 11 00 11 01]  speed
4x  [11 10 00 11 11 10 01 11 00]  speed & f3 OFF
4x  [11 10 00 11 11 11 00 11 01]  speed
4x  [11 10 00 11 11 11 01 11 00]  speed & f4 OFF
With "4x" I mean "twice a double packet"
Return to the Table of Contents

FUNCTION OF DIP SWITCH No.3 - PAUSES BETWEEN PACKETS

2x double packet 
                  ---  ---       ---  ---          ---
#3 OFF  ----------   --   -------   --   ----------   ...
           t3        t1     t2      t1       t3
         ---  --- ---  ---
#3 ON   -   --   -   --   -...
       t2   t1   t2  t1  t2
t1, t2 and t3 are pauses between packets.

Case of 6021
If DIP switch No.3 is OFF, t1=1525 us, t2=4025 us and t3=6025 us
If DIP switch No.3 is ON, t1=1525 us and t2=1025 us
When #3=OFF then t1 < t2 and t1 < t3; when #3=ON then t1 > t2. In the latter case, the average voltage on the track is nearer to zero than in the former. An average voltage near to zero is good for 2-rail systems, since if the loco-decoder is standard-mounted (common of the lamps connected to the brown wire of the decoder), reversing the loco on the track doesn't change that much the light intensity. With "reversing" I mean "take the loco off the track with your hands, swap left and right side and place the loco back on the track".
Note: C80/81 decoders equipped with LME03 chips do not work with DIP No.3 ON. Moreover, they do not work with t1=1525 us, t2=t3=4025 us.

Case of 6022 (old Control Units with internal 145026 encoder)
t1=1.25 ms and t2 alternates between about 4 ms and 6 ms.

Let's calculate the total duration of a double packet in a 6021, including pauses. 

The 1st repetition of 18 bits lasts:
(1/38400 * 8 clocks * 2 bits * 9 trits) s = 3.75 ms

One double packet lasts:
(3.75 + 1.525 + 3.75 + 4.025) ms = 13.05 ms (long  pauses, DIP #3 OFF,
                                            only t1 and t2 considered)
(3.75 + 1.525 + 3.75 + 6.025) ms = 15.05 ms (long  pauses, DIP #3 OFF,
                                            only t1 and t3 considered)
(3.75 + 1.525 + 3.75 + 1.025) ms = 10.05 ms (short pauses, DIP #3 ON)

One 2x double packet lasts:
(13.05 + 15.05) ms = 28.1 ms (long  pauses, DIP #3 OFF)
(10.05 * 2) ms     = 20.1 ms (short pauses, DIP #3 ON)

A complete information for one loco lasts:
(28.1 * 8) ms = 224.8 ms (long  pauses, DIP #3 OFF)
(20.1 * 8) ms = 160.8 ms (short pauses, DIP #3 ON)

A complete information for 80 locos lasts:
(224.8 * 80) ms = 17.98 s (long  pauses, DIP #3 OFF)
(160.8 * 80) ms = 12.86 s (short pauses, DIP #3 ON)
And now let's try to justify the different t1 and t2 (and t3) values. The Motorola encoder 145026 standardized t1 to 3 trit times, i.e. 1248 us. This should be the "regular" t1, as issued by the old 6020 and 6022. On the other hand, the data sheet of the 145026 sets the "dead time discriminator" of the chip (the maximum value of our "t1") to slightly more than 4 trit times (1742 us against the exact "4 trit times" of 1664 us). Old Central Units (6020 and 6022) have t1=1.25 ms and follow the directives of the 145026 data sheet. On the other hand, the pause t1 of the 6021 (about 1.5 ms) is still compatible with the 145026 directives (but on the edge of incompatibility).
Return to the Table of Contents

QUESTIONS AND ANSWERS

Question #1:
If I understand you correctly the LENZ and Märklin system are not compatible. e.g. a LENZ extended function decoder does not work with the Märklin Motorola system?
Answer:
That's it. Lenz function decoders only work with the Lenz protocol, while "Motorola" function decoders only work with the Motorola format. The problem is further complicated by the fact that there are now TWO Motorola function decoders!
(I'm just waiting for the moment in which a loco/function decoder will understand both Märklin and Lenz protocols. It's possible with the Ultra Large Scale Integration!)
1) the former type of extended function decoder was mounted in some Digital coaches and in the Digital crane from Märklin. It works ONLY if the new Control Unit has Dip switch No.1 OFF. It works exactly with the format and "double frequency" of the k83 (6083), but one "trit" (or, better, pulse pair) is different. Moreover it has latches to store the info, which is not sent continuously, but only when a f1...f4 key is pressed (or when a command comes from the Interface). Märklin does not sell this type of decoders (but it is going to sell function decoders in the New Motorola Format). You can purchase this type of decoders for example from Modeltreno, via Cipriani 6, 40131 Bologna, Italy, fax: +39-51-524114. (but they are not miniaturized and can only fit in coaches)
2) The new format is sent by the new Control Unit when dip switch No.2 is ON. Presently, it only works with the 701.17 chips mounted on the c95 (6095). The on/off status of the extended functions is continuously sent with this new Motorola protocol. It's likely that this will be the future standard protocol and that next miniaturized c90s will have the possibility to use the 4 additional functions.

Question #2:
Is the new protocol only used for locos, or does it also apply to the switches (k83) (or put in another way: can I use my Elektor decoders with the new protocol)?
Answer:
The new protocol is used only for locos and function decoders, Märklin keeps compatibility with the thousands of k83 they sold up to now. So you can use the Elektor decoders or whatever compatible you want (see Modeltreno 66001 decoders)

Question #3:
What locodecoders have the implementation of the new protocol, are the Delta decoders compatible with the new protocol?
Answer:
All the decoders with Zymos, LME03, 701.13 and 701.17 chips are compatible with the new protocol. This is due to the fact that they actually interpret only the 1st pulse of the 4 couples that give the info on the speed/reverse. (you know that with the old Motorola protocol the couples are composed by two equal pulses, two long or two short pulses). Even the 1st type of decoders (non surface mount) work properly with the new protocol). Anyway, please note that for these decoders the change of direction needs a packet of the old protocol (AABBCCDD=11000000).
New Delta and c95 decoders have a 701.17 chip and old Delta have a 701.13. Then, presently only new Delta, c95s and new 6090x decoders correctly interpret the information on the absolute direction of travel (new c90s issued in 1998 have the 701.17 chip on board).

Question #4:
Do you need 2 decoder chips to control 4 extra functions AND control the loco speed, or have the new chips implementation for both (as in the I-Gauge decoders).
Answer:
I partially answered this question above. In the new format no need of two decoder chips. Only a problem of room (c95 are quite big!). Anyway, the 701.17 has the implementation for both and will be mounted on next version of c90. It is likely that the next c90 will have at least f1 and f2 capability. In the old protocol you need two different decoders.

Question #5:
What about old central units?
Answer:
The old Central Units are not able to drive the four functions of a c95

Question #6:
How can I use old and new function decoders together?
Answer:
Use DIP switches #1=OFF, #2=ON

Question #7:
How can I use old and new locodecoders together?
Answer:
Same as before: use DIP switches #1=OFF, #2=ON. This causes a "mixed-mode" protocol. When reversing the direction of travel, the packet for reversing the direction in the old Motorola format ("11000000") is sent before the new absolute direction information in mixed-mode ("1E0F0G0H0"). Hence all types of decoders are able to change their direction.
For those who want to build their own controller, please notice that when a reverse information ("0 0 0 1") is issued and at the same time the information on the absolute direction does not change (this is nonsense for a 6021), then the new decoders (701.17 chip) don't change direction and the old ones do change their direction.

Question #8:
has anyone tested the new MKL-Format (switch 1 and 2 at Control 80f ON) in a computer controlled layout with a lot of locos in action?
Answer:
yes, everything works fine, much better than in the case of the old 6020, which had no "refresh" sequence. I commonly use DIGIPET 4.01 and its timetable system. The "refresh" cycle is also useful in case you forgot to install the 1.5 kOhm resistor in the sectioned track of a semaphore (provided the loco wakes up in the correct direction, in the case of a decoder based on a Märklin chip older than 701.17)

Question #9:
Has anyone tested a double traction via computer with this format? I think there should be some troubles when there are more than 3 trains (the more trains the trouble should happen) in action and the computer tries to stop many of them. "Parallel" action to many trains can be a problem!
Answer:
I think you are referring to the possible delay between one loco and the other of the double traction. Please take into account that whenever you send a command with the Interface or a Control 80, the same command is "immediately" issued on the track without waiting for the turn of that loco. In other words, the normal "refresh" sequence issued by the Control Unit is stopped when a new command is entered. Just after the new command is executed, the "refresh" sequence starts again.

Question #10:
When switch 2 is on, what does actually "understand" a loco decoder? Is it the simple double packet or does the decoder need to wait for a complete information refresh cycle in order to change its settings?
Answer:
The minimum "atomic" component which is understood by a decoder is one double packet and not a complete refresh block. This due to the fact that the 6021 must be compatible with the old decoders (with the ZyMOS chip) and, conversely, the new decoders must also be compatible with the very first 6020. In a self made system, after each double packet one could send any "double packet" type, even with a different address.

Question #11:
What is not mentioned in the manual is the way how the new protocol is controlled from the computer via an Interface. Can one use the 'old' Interface?
Answer:
yes, of course, but the "new" 6051 Interface is exactly identical to the 6050 (excluding the cable and the diskette)

Question #12:
Again on the Interface 6050/51. I assume speed control has not changed, but how about reverse direction command? Do I still have to send a '15' command to instruct the Control Unit to change direction?
Answer:
unfortunately yes! The standard 6050 protocol does not include any "absolute direction" command.

Question #13:
You write: "However, for backwards compatibility, when DIP switch #2 is ON ("New Motorola Format"), the 6021 issues some old Motorola "0 0 0 1" packets (reverse direction) in addition to the information of the new format, even in the case of DIP switch #1 ON." But, with my LME03 decoder the loco does not change direction with both DIP switch #1 and #2 ON. Why?
Answer:
Let's start from some definitions. Märklin produced different types of decoders. Let's indicate them with the relative decoder chip.

Let's suppose to switch DIP#1 ON and DIP#2 ON (both ON) in the 6021. The decoders behave differently. In particular Now let's make the following experiment Results of the experiment Solution of the problem.
When DIP#1 is OFF the 6021 issues 6 "standard reverse direction" double packets in the old Motorola format and 8 "reverse direction" double packets of the new type (a mixture between "speed = reverse" in the old format and "direction = EFGH" in the new format). When DIP#1 is ON the "reverse direction" packets are only of the new type. The explanation of the different behaviour (when DIP#1 is ON) of Zy and 701.13 on one side and LME on the other side is that LME decoders decode both bits of each trit, while Zy and 701.13 decode only the first bit. Therefore the LME decoders are not able to decode the "direction = EFGH" packet in the new format. This could look like a bug of the LME decoders. Actually, it is not a real bug, since at that time the "New Motorola Format" was not known. And this is the reason why Märklin's advice is to keep DIP#1 OFF for H0 models (backwards compatibility above all!!!).

Question #14:
Why are my decoders reacting on a Function decoder command from a 6050/51 Interface with a delay of some seconds? Why doesn't this occur when pressing the f1...f4 keys on a 6021?
Answer:
This refers to the behaviour of the 6021 when receiving a function-decoder command via the Interface: the 6021 accepts the new function setting but does not interrupt the repeat cycle and does not transmit the "normal" 6 double packets as when pushing an Fx (x=1...4) button (don't ask me why). Therefore in the worst case of 80 locomotives in the refresh cycle one could wait 18.3 seconds before having Fx switched ON!

Return to the Table of Contents

A beginner's guide on Digital systems

--- end of text ---