This is version 2.14 of a 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 feedbacks 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@area.bo.cnr.it
home page (office): http://bolam5.lamel.bo.cnr.it/~scorzoni/
Many thanks are due to Stefano Chiti-Batelli and other friends for testing and verification of the format described in this document.
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
-------
-
12345678
-
-------
12345678
------- -------
- -
1234567812345678
- -
------- -------
1234567812345678
------- -
- -------
1234567812345678
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.
-> 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".
-2 1st trit = 1
-- 2nd trit = open
5- 3rd trit = 0
7- 4th trit = 0
Please note that the trinary address "0000" is defined as "80"
in the Märklin Motorola protocol and vice versa,
the address "open open open open" of locos and function decoders is
not used in the Märklin Motorola protocol.
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*1The 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
- 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.
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 0 | 1
0 0 0 0 | 0
Table 2
Note that the code "0 0 0 1" is missing, since it is no longer needed in the
new format (it's obsolete!). 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.
The only thing that changes in the sequences of double packets
described above is the content of EFGH.
1) 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,
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:
| 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".
A B C D
E F G H
1 1 1 1 0 0 0 0
which is the old operating level "2".
| f1 OFF | f1 ON |
---------------------
| E F G H | E F G H |
-------------------------------------
standard values | 1 1 0 0 | 1 1 0 1 |
-------------------------------------
operat. 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 |
-------------------------------------
operat. 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 |
-------------------------------------
operat. 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 |
-------------------------------------
operat. 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.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 1etc.
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 OFFWith "4x" I mean "twice a double packet"
--- --- --- --- ---
#3 OFF -- ------- -- ----------
t1 t2 t1 t3
--- --- --- ---
#3 ON -- - -- -
t1 t2
t1, t2 and t3 are pauses between packets.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.64 + 3.75 + 4.24) ms = 13.38 ms (long pauses, DIP #3 OFF,
only t1 and t2 considered)
(3.75 + 1.64 + 3.75 + 6.1) ms = 15.24 ms (long pauses, DIP #3 OFF,
only t1 and t3 considered)
(3.75 + 1.66 + 3.75 + 1.17) ms = 10.33 ms (short pauses, DIP #3 ON)
One 2x double packet lasts:
(13.38 + 15.24) ms = 28.62 ms (long pauses, DIP #3 OFF)
(10.33 * 2) ms = 20.66 ms (short pauses, DIP #3 ON)
A complete information for one loco lasts:
(28.62 * 8) ms = 228.96 ms (long pauses, DIP #3 OFF)
(20.66 * 8) ms = 165.28 ms (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.65 ms) is still
compatible with the 145026 directives (but on the edge of incompatibility).
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 swich 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 locs, 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 locs 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 locdecoders 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
loc 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 is sent together with the new absolute direction information.
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 loco's 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 minumum "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 bot 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.
--- end of text ---