ZIMO MS450 Instruction Manual Download Page 44

Page: 44 / 88

Page 44 MS - SOUND decoders MS440 to MS990 and MN - NON-SOUND decoders MN170 to MN340

Denomination

Range

Default

Description

#264

Variable low voltage

(large scale and special

decoders)

10 - 158

15 (= 1.5 V)

Variable (adjustable by CV) low voltage (only large
scale and some special decoders)
= 10 - 158: Low voltage in tenths of a volt (1-15.8 V)

RailCom -

“Bidirectional communication” for DCC

"Bi-directional" means that within the framework of the DCC protocol there is a flow of information not only in the
direction of the decoders, but also in the opposite direction; i.e. not only run commands, function commands, control
commands, etc. to the decoders, but also feedback messages such as reception confirmations, speed measurements,
other status information and CV readouts from the decoders to the digital control centre or "local detectors".

ZIMO decoders of all types (as well as digital command stations and track detectors as receiving devices) were already
equipped with a proprietary form of "bi-directional communication" since the 1990s (long before RailCom) - the

"ZIMO

loco number identification"

. At that time, this was a significant difference to competitor products. In layouts with MX9

track section modules built until 2010, ZIMO loco number identification continues to be used, as

MX9 modules do

NOT work with "RailCom"

(but the subsequent "StEin" modules do).

Since 2005 (shortly after the introduction by Lenz) all ZIMO decoders are equipped for the in the mean-
time

standardised feedback protocol "RailCom"

(RCN-217 at Railcommunity - VHDM - and S-9.3.2

at NMRA). RailCom also replaces the above-mentioned ZIMO train number identification.

The basic mode of operation of RailCom is based on the fact that the otherwise continuous energy and data stream,
i.e. the DCC rail signal, which is applied to the track by the digital control centre, is interrupted by short potential-free
gaps (the "RailCom cutouts", max. 500 microsec); in these gaps, the decoders can send out feedback information (as
"RailCom messages", altogether - both channels together - up to 48 bits long), which are received and evaluated by
"local detectors" (assigned to individual isolated track sections) or by the "global detector" in the digital centre itself,
largely undisturbed.

Relevant CVs for basic RailCom configuration:

Denomination

Range

Default Description

#28

RailCom Configuration

0, 1, 2, 3,

65, 66, 67

resp.

with bit 6,

High cur-

rent

Bit 0 - RailCom Channel 1 (Broadcast)
Bit 1 - RailCom Channel 2 (Data)
Bit 6 - High voltage RailCom (large scale decoders onl.)
for all Bits: 0 = OFF

1 = ON

#29

Basic configuration

Configuration data

0 - 63

14 =

0000

110

Bit 3 = 1

(RailCom

is switched

on)

and

Bits 1,2 = 1

(28 or 128

speed steps,

and autom.

analog mode

Bit 0 - Train direction:

0 = normal, 1 = reversed

Bit 1 - number of speed steps

0 = 14, 1 = 28 speed steps

Bit 2 - automatic change to analog operation
0 = disabled 1 = enabled

Bit 3 -

RailCom („bi-directional communication“)

0 = deactivated

1 = activated

Bit 4 - Selection of speed characteristic:

0 = Three-point char. according to CV #2, #5, #6

1 = free characteristics acc. to CVs #67

– #94

Bit 5 - Decoder address selection (DCC):

0 = primary address as per CV #1

1 = ext. address as per CVs #17 & #18

Denomination

Range

Default Description

#136

Fine adjustment of the

speed feedback

km/h

–

control

number during

calibration run

0 - 255

128

RailCom speed feedback correction factor.

or (see chapter 5.8 in manual for small decoders)

reading out the result of the internally computed speed
after the calibration run.

In ZIMO decoders (now also in most third-party products) the RailCom functions are switched on by
default. If this should not be the case, they are activated by:

CV #29, Bit 3 = 1 AND CV #28 = 3 (or = 67, if large scale decoder),

if the speed feedback (tacho) should not work: CV #158, Bit 2 = 1

or exceptionally (if MX31ZL as command station): = 0

In the first years after the introduction of RailCom, its potential was only used intensively for two pur-
posies: for

address reporting

for isolated track sections (what the ZIMO loco number identification had

previously done), and for

CV programming and reading

in operational mode (also called "PoM" =

"Programming-on-the-Main"). This has changed - roughly since 2015:

DCC decoders without RailCom

are now hardly imaginable.

Briefly summarised, the "RailCom" tasks can be structured like this:

•

All RailCom responses

(initially independent of the content of the message itself) confirm the receipt

of the respective preceding DCC commands, which increases the operational reliability and the "band-
width" of the entire DCC control. The latter is the case because acknowledged DCC commands do
not have to be repeated.

•

"RailCom Channel 2"

(the second - with 36 bit larger part - of each RailCom total message):

Current data from the vehicle

are reported to the "global detector" of the digital control centre via

this channel, each time in response to a DCC command to its own decoder address; this includes, for
example (depending on the design) the "real" (measured) speed, routing and position codes, simu-
lated "fuel stocks", current values of the CVs on request (CV programming and reading in operational
mode or "programming-on-the-main" - PoM).

•

"RailCom Channel 1"

(the first - smaller part with 12 bit): This is used to report (normally nothing else

than) the

own decoder address

, in response to all DCC commands (i.e. especially those that do NOT

address the own vehicle, therefore up to 100 times / sec). Since all decoders send out Channel 1 data
at the same time, these can only be read on isolated track sections by "local detectors", if there is only
one vehicle with a RailCom-activated decoder.

In the "global detector" of the command station, on the other hand, the simultaneous Channel 1 data of the different
decoders overlap and are therefore not readable, which would not make sense anyway, since the addresses are
only of interest locally (on the individual isolated track sections).

The above "short description" of RailCom technology refers only to the "normal" operations; in practice (even in the
standards themselves) there are numerous deviations and exceptions in the channel allocations, etc.