ZIMO MX10 Manual Download

Page: 23 / 44

INSTRUCTION MANUAL CENTRAL COMMAND STATION MX10, MX10EC Page23

Track signal, Feedback, Database

DCC and MOTOROLA (MM) form the basic eqquipment of the MX10. Nevertheless, hardware and soft-
ware are open for expansion to other protocols, especially mfx (with RDS-feedback) and Selectrix, if
demanded. It would also possible to expand to new, more efficient methods (as the currently existing
formats) of data transmission on the tracks.

RailCom

and ZIMO loco number identification:

The “bi-directional communication” corresponding to “RailCom

“ is an essential component of all rele-

vant devices of the ZIMO system (of the generation MX10 / MX32 / StEin).

The MX10 is equipped with two

„RailCom

-precision global detectors

“, i.e. one detector per track

output.

“Global” is a term of the RailCom

standard (already since the NMRA) and means that it receives Rail-

Com

notifications independent of the locos position (=track section), e.g. feedback about speed, cur-

rent consumption, alarms, turnout positions, CV values, etc.

“Precision” means that RailCom

notifications are not acknowledged by the standardised thresholds,

but that the RailCom

signal is digitalised first and then analysed, to be able to read very low and muti-

lated notifications and also, to be relatively insensible towards influences as they occur in almost every
extensive layout, especially by the consumption of a big part of the RailCom

signal by illuminated wag-

ons.

“local detectors” on the other hand identify the vehicles on the single track sections; within the ZIMO system this task

is done by the “StEin” modules (stationary equipment modules); but those are not only simple local detectors, but also
read global notifications (and forward them to the MX10), because on a big layout, the receiving quality can be much
better on a single track section than on the command station’s position.

The central command station MX10 also reads the “loco number impulses” of the decoders, because
they are used in addition to RailCom

as acknowledgement for the reception of DCC packets, also of

decoders which were produced before 2005 when RailCom

did not yet exist, but only loco number

identification as feedback from the decoders.

RailCom

is a registered trademark of Lenz Elektronik GmbH

Organising data transmission via track signal (DCC or MM)

(in many documents also called “transmission cycle”):

Additionally to supplying the layout with traction current, a digital command station has to assume the
relevant information for the vehicles and accessory decoders from the input devices (controller, com-
puter, ...) and forward them efficiently, i.e. with the least possible delay and highest possible reliability
to the decoders.

Thereby the vulnerability of the data canal due to the contact disruptions between track and vehicle
has to be taken into account, which is a common factor in the model railway world.

This is why a complex priority schema is used, which decides how the available transmission time is
distributed to the different current data packages. The following levels are differentiated; high priority
(order 0, 1, 2, ..) means more frequent
transmission:

0.  Protocol requirements (Request-for-Service-Slots, time synchronisation for decoders, etc.)
1.  Changing data contents (new velocity, functions, etc.) by controller, computer, or others.
2.  Data for addresses in the controller’s foreground,
3.  Data for addresses of “secondary objects” of the addresses in the foreground, e.g. consist,
4.  Data for addresses of computer controllers (ESTWGJ, STP, TrainController, etc.),
5.  Data for addresses in the controller’s LoR, or the favourits in the computer,
6.  Data for addresses in the system database (which is not one of the higher priorities)
7.  Scan cycle, to find not reported addresses.