MS-SOUND-decoders MS440 to MS990 Page 41
CV
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)
4
3B
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 di-
rection 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 measure-
ments, 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 al-
ready 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 mod-
ules 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
meantime
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:
CV
Denomination
Range
Default Description
#28
RailCom Configuration 0, 1, 2, 3,
65, 66, 67
3
resp.
67
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
1
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
#136
Fine adjustment of the
speed feedback
0 - 255
128
RailCom speed feedback correction factor.
or (see chapter 5.8 in manual for small decoders)
CV
Denomination
Range
Default Description
or
km/h –
control
number during
calibration run
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 Rail-
Com 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 re-
ceipt of the respective preceding DCC commands, which increases the operational reliability and the
"bandwidth" of the entire DCC control. The latter is the case because acknowledged DCC com-
mands 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, sim-
ulated "fuel stocks", current values of the CVs on request (CV programming and reading in opera-
tional 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 detec-
tors", 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 differ-
ent 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.
Constant further development of RailCom use:
Since
new RailCom applications are constantly being created
and implemented in decoders and
digital equipment, with ZIMO often taking a pioneering role, instruction manuals cannot always be kept
up to date in this respect.
Therefore, here is only a short list of applications that have either already been realised, are currently
in progress, or may be realised in the near future (in ZIMO decoders and systems):
Classic applications:
Address messaging (display on digit displays or computer interlocking), CV-programming and –read-
ing, speed messages (to be displayed on the speedometer on the control unit), directional status mes-
sages (to be displayed forwards/backwards and east-west on the controller and automatic control in-
terventions).
