Draft: RCNxxx

Automatic Logon Of DCC Decoders Using DCC/Railcom DCC-A

    Note: German page has been update, this page currently outdated
    Rev:
    0.01 2019-01-22 kw start
    0.02 2019-02-11 kw get info - no tid

Table of contents

1. Preface

Purpose of this Norm / Standard

    This norm/common standard defines an automatic logon process for DCC. With that, user friendliness of controlling modell railroad components and layouts is significantly increased. Ideally the user does not have to bother about digital addressing and function mapping. One intention of this is to have a vehicle register itself automatically with a command station or control panel immediately after placing it on the tracks. When using this specification, you will achieve:
  • Really fast automatic logon - true plug&play. Unpack, put on tracks, use it!
  • Immediate visibility of brand and functions in your throttle
  • Easy firmware update - no opening of the loco, no dedicated programmer from the decoder vendor.
  • Low implementation costs on both command station and decoder

    • This norm is based on packet composition explained in norms/common standards [RCN211] and [RCN217] for DCC and Railcom.

    To help implementation, headers and code snippets are available.

Specifications

    To comply with this norm/common standard it is essential that all commands and data structures described herein are supported. Optional parts are marked separately.

Glossary, Definitions

    This norm uses the following terms and abreviations:
    UniqueID:This is the Decoder/Command Station manufacturer's explicitly implemented, non-ambiguous ID, consisting of 8 bit Manufacturer ID and 32 bit manufacturer specific number (e.g. product index and serial number).
    If this number is to be display or entered, the following format shall be used:
    VV:PPPPPPpp hereby every char represents a hex digit (nibble), VV denotes the vendor-ID, PPPPPPPpp denotes the individual number (given as 32 bit wide hex), this number is displayed big endian (general, DCC uses big endian). Thus pp denotes the low byte.
    DID:UniqueID of Decoders
    CID:UniqueID of the Command Station
    SessionID:A Variable that contains the current operating state
    Backoff:Should a Decoder fail to receive a registration confirmation, the Decoder does not respond X times to LOGON_ENABLE any more.

2. General Procedure

    In general, decoders that are operated under "electrically parallel" conditions, i.e. on the same track or on the same electrical wire. Therefore an addressing scheme is required. Decoders are individually identified by their respective UniqueID. On the basis of this UniqueID each Decoder is assign a shortened (Session-)ID. This is done to make best use of the limited bandwidth of DCC. Whenever possible the previous decoder address is used as the SessionID. In order to achieve this a logon procedure is launched. This logon procedure also communicates the properties of the decoder/vehicle to the command station / controller.

    This (automatic) logon procedure is divided into the following main phases:
  • Separation or Singling Out Phase:
    In this phase the decoders are identified and access contentions resolved. After this separation phase the command station is aware of the DIDs of the decoders.
  • Declaration / Notification Phase:
    Within this the command station and decoders exchange information about address to use, vehicle name, available functions and others.
  • Registration:
    The decoder is registered to the command station. After that the command station can control the decoders and send commands to them.
    • To speed up the logon process the command station is bound to register those decoders that are known from the last operating session directly, not going through Separation / Single Out Phase.

Separation / Single Out Phase

    The Command Station prompts the Decoders to log on (Command: LOGON_ENABLE). This sign up prompt contains a hash of the Command Station/LayoutID and a SessionID. Decoders are able to re-identify the Command Station after a PowerCycle. Decoders respond to the LOGON_ENABLE command with a logon, following certain rules and regulations. This logon carries the UniqueID of the Decoder with it.

    Whenever many Decoders are already known to the Command Station or local Railcom detection is used, this phase will be short. Colliding, simultaneous responses of several decoders render indentification unstable. In that case the decoders will be singled out via a dynamic Backoff. The coding of the LOGON_ENABLE command determines whether the separation / single out process is done for all decoders at the same time or separated into Accessory Decoders and Mobile Decoders respectively.

Declaration / Notification Phase

    The Command Station confirms the logon and talks to the Decoder using his DID (command: GET_INFO). The Decoder is now aware that its logon was successful and sends a corresponding Railcom-response, summarizing its most important parameters like preferred Decoder-address and other information.

Registration

    The Command Station assigns a Loco-address to the Decoder for use in the session. The Decoder confirms this with sending a revision index of its CVs. This enables the command station to verify if the parameters of the decoder, possibly already known to the command station, are still valid or if it is necessary to re-read the paramteres or do a (speed) calibration.

Accelerated Import of Decoder parameters:

    Effecitve use of the bandwidth of DCC / Railcom is necessary to move data between decoder and command Station with acceptable speed.
    To achieve this, data within the Decoder is organised in groups ( =clusters). Therefore it is possible to address an entire cluster with the SELECT_INFO / GET_DATA commands. Those groups of data (=clusters) consist of decoderproperties like loconame, function mapping, loco-image, CV-direct etc....

3. DCC Commands

    In general, all DCC commands for automatic logon are formated as follows:
    {syncbits} 0 1111-1110 0 {commandbytes} 0 PPPP-PPPP 1
    In general all commands for automatic log-on start with 1111-1110. The first commandbyte specifies the type of command, all other bytes specify the command parameters. DCC-commands (or DCC-message) can be as long as 10 bytes.

Coding of commands

    The first byte of a command determines the command type. This is a list of all commands, sorted by value of the first byte. After that the commands are described in order of their function.
    Befehlsbyte LängeEvalRailcom-AntwortBedeutung
    0000-0000 - - keine reserved
    0000-0001 3 histID14, D_ID, Data GET_DATA: continuing Data Inquiry
    000.-.... - - keine reserved
    0001-1111 3 bc keine FW_UPDATE_RESET Abbruch FW-Update
    0011-nnnn 11 histID12, FW-ACK FW_UPDATE_DATA_n
    0100-0000 11 did ID12, FW-ACK FW_UPDATE_SET_TARGET
    0100-0001 11 did ID12, FW-ACK FW_UPDATE_SET_BASE
    0100-0010 10 did ID12, FW-ACK FW_UPDATE_SET_SIZE
    0100-0011 8 did ID12, FW-ACK FW_UPDATE_QUERY
    0100-0100 8 did ID12, FW-ACK FW_UPDATE_END
    ....-.... - did keine reserved
    1100-xxxx 9/11 did ID13, Stat SELECT_INFO: sekection of data space / logon confirmation
    1111-0000 10 did ID13, Stat LOGON_ASSIGN: Assigning Address, Operating Approval
    1111-11.. - - keine reserved
    1111-11xx 6 backoffID15, Logon LOGON_ENABLE: prompt for logon (xx = mode)
    (The column "Length" shows the command's entire length including its parity-bit.)

LOGON_ENABLE

    This command has 6 byte length and is formatted as follows:
    0 1111-1110 0 1111-11tt 0 TTTT-TTTT 0 tttt-tttt 0 ssss-ssss 0 PPPP-PPPP 1
    This is the log-on prompt that is periodically sent by the Command Station. Interval festlegen
    Parameter Meaning
    tt tt determines which decoders are allowed to respond
    00All Decoders
    01Mobile Dekoders only
    10Static Decoders only
    11reserved
    TTTT-TTTT Track Identifier, MSB
    tttt-tttt Track Identifier, LSB
    ssss-ssss Session number
    Decoders sending their UniqueID for an answer. Decoders do not send any answer if they are currently going through a Backoff-Waiting time.

SELECT_INFO

    This command is 11 byte in length (including parity), formatted as follows:
    0 1111-1110 0 1100-iiii 0 HHHH-HHHH 0 hhhh-hhhh 0 ssss-ssss 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 PPPP-PPPP 1
    With this the Command Station fetches the most important data from Decoders. iiii determines the data-cluster / data-group inside the Decoder that is prompted. Through this, Decoders recognise their Logon was perceived and that they are not allowed to send further Logon-requests.
    Depending on the data-group the Command Station sends a differing number of GET_INFO commands. The Decoder sends the data from that group in response. The Decoder increments the access within the data-group. At the end of the data-group the Decoder cycles back to the beginning of the group by itself again. If the data-group iiii is changed the Decoder always starts with index 0 in that new data-group. A delay in an answer for a request within a certain data-group of 2 commands is acceptable. The Decoder delivers the ID of the respective data-group within his answer.
    Parameter Meaning
    iiii iiii determines the data-group
    data-group (cluster)
    numbercontent
    0000Shortinfo (Size = 5 Byte), contains the hidherto existing DCC-address of the Decoder et all
    0001Shortname (Size = 5 Byte), contains the shortname for control panels or control device
    0010ShortGUI (Size = 5 Byte), contains information of the GUI
    0011Fullname (Size = 24 Byte)
    0100Usertext
    elsereserved
    1101Railcom-Page (Size = 256 Byte)
    1110Image information
    1111CV-Block
    DDDD-DDDD ManufacturerID of the Decoder
    dddd-dddd ProduktID and Serial Number of the Decoder
    *) The first inquiry of the Command Station is always bound for Data-group 0000.
    **) Data-group 1111 is prohibited for the GET_INFO command due to the command length.

GET_DATA

    This command is used to carry on with an already started GET_INFO command. With this the data-group and index used by the prior GET_INFO or GET_INFO_SHORT command is carried forward. This command accelerates reading speed from blocks and data-groups. (Notice: command duration 6.4ms, therefore a block of 256 bytes can be read in approx. 420ms).
    Decoders are only allowed to respond to GET_DATA if there was no GET_INFO to any other Decoder since the last GET_INFO.
    0 1111-1110 0 0000-0001 0 PPPP-PPPP 1

LOGON_ASSIGN

    This command is 10 byte in length and is formatted as follows:
    0 1111-1110 0 0000-0000 0 DDDD-DDDD 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 dddd-dddd 0 AAAA-AAAA 0 aaaa-aaaa 0 PPPP-PPPP 1
    With this command the Command Station registers the Decoder, sends an address to the Decoder. This address is used for any communication between Command Station and Decoder from that point forward. The Decoder may only accept this registration in case it got knowlegde of the Track Identifier and SessinID before.
    The Decoder responds to the LOGON_ASSIGN with sending a message. This message contains a summary (hash) of the Decoder's CVs. This enables the Command Station to verify if the parameters of the Decoder, possibly already known to the Command Station, are still valid or if it is necessary to re-read the paramteres or do a calibration.

4. Railcom Messages

    Messages that are sent during Automatic Login are generally bundled in Channel 1 and 2. Timing partitioning remains untouched, though, as stated in RCN2.. Through this bundling all created messages are 8 byte in lenght, with 6-8-Coding, 48 bit remain. Those 48 bit are distributed as follows: th8..15
    0..34..716..47
    ID EXT1EXT2Databyte[0]...Databyte[3]

ID15 - Decoder-Unique

    This message is sent as a response to the DCC-command LOGON_ENABLE.
    ID15 - Decoder-Unique
    ID1111ID15, Identifier for Decoder Unique
    EXT1PPPPTestnibble according to CRC-4/ITU
    EXT2VVVV-VVVVManufacturer's ID (VendorID persuant to ...)
    DATADDD...DDD32 bit, distinct UniqueID of the Decoder
    Onlinetool for checking CRC4

ID14 - Decoder-Info

    This message is sent in response to DCC-command GET_INFO.
  • General format to transmit a data group:
    ID14 - Decoder-Info (general format)
    ID1110ID14, Identifier for Decoder Information
    EXT1NNNNData-group (Namespace) that is transmitted.
    EXT2IIII-IIIIIndex in Namespace; Index 0 refers to Databyte 0..3, Index refers to Datenbyte 4..7 etc.
    DATADDD...DDD4 Databytes: Data[4*Index+0], Data[4*Index+1], Data[4*Index+2], Data[4*Index+3]
  • Single Block format for predefined data group with a fixed size of 5 bytes
    ID14 - Decoder-Info (single block)
    ID1110ID14, Identifier for Decoder Information
    EXT1NNNNData-group (Namespace) that is transmitted.
    EXT2IIII-IIIIdatabyte data[0]
    DATADDD...DDD4 databytes data[1], data[2], data[3], data[4]
    Single block mode is used for data spaces 0 (Shortinfo), 1(Shortname), 2 (ShortGUI).

ID13 - Decoder-Hash

    This message is sent in response to DCC-command LOGON_ASSIGN, it contains a HASH of the Decoder's configuration. It also confirms the successful address assignment.
    ID13 - Decoder-Hash
    ID1101ID13, Decoder-Hash
    EXT1PPPPTestnibble, CRC-4
    EXT2CCCC-CCCCChangeflags, hinting to changes in Decoder parameters. (tbd)
    DATADDD...DDDHASH across all CVs

5. Data-clusters

    Historically information in Decoders is stored in CVs. Those CVs are spread out in a certain area and are not implemented uniformly or in standardised fashion. In order to do an automated logon, a fast and efficient data transfer is mandatory. This is achieved by grouping data in data-clusters (name space). By this, it needs much fewer transmission to get the information across.

    GET_INFO command addresses a data-cluster, the decoder then sends back the respective contents of this cluster in its railcom message. If a decoder does not suppport a specific data-cluster, it sends back an answer containing the respecitve identifier of the cluster, index and databytes are all 0 in this case. Data-clusters 0000, 0001 und 0010 are mandatory for decoders.
    Data-cluster
    NumberContents
    0000Shortinfo (Size = 5 Byte), contains the previous DCC-address of the Decoder and other information.
    0001Shortname (Size = 5 byte), contains the short name of the operator device
    0010ShortGUI (Size = 5 byte), contains information of the GUI-display
    0011Full name (Size = 24 Byte)
    0100Usertext
    elsereserved
    1101Railcom-Page (Size = 256 byte)
    1110Image information
    1111CV-Block
    0000 Shortinfo
    This cluster is 5 byte in size and contains all significant information about the decoder:
    Byte:BitEnthaltene Daten
    0:7 Info about decoder type (0=loco, 1=accessory)
    0:6 Additional info about decoder type. if loco: (0=motor, 1=function); if accessory (0=standard, 1=extended)
    0:5..0 Address (preferred address), bit 13...8. (high)
    1:7..0 Address (preferred address), bit 7..0. (low)
    2:7 reserved
    2:6 Motor control is regulated.
    2:5 Decoder has actvie consist.
    2:4..0Loco decoders: number of function outputs; if set to 30, more than F0, F1..F28 is available.
    3:4..0reserved.
    3:7..5Data cluster 6...4 is available.
    4:7..0Data cluster 14...7 is available.
    0001 Shortname
    This data-cluster is 5 bytes in size and contains the name of the Loco / Decoder:
    0..39 Shortname, 5 byte, UTF8-code (ISO-8859-1 ?). Names shorter than 5 bytes have to be filled-up with 0x00 until 5 byte size is reached.
    0010 ShortGUI
    This cluster is 5 bytes in size and contains shortinfo for displaying items/images in the controller:
    0..3 Fallback Icon to be used
    4..19Index of Loco images persuant to Appendix xxx.xxx
    20..39 Manufacturer specific ID
    0011 Fullname
    This cluster is 24 bytes in size and contains the name of the Loco / Decoder:
    0..191 Name, 24 byte, UTF8-coded (ISO-8859-1 ?). Names shorter than 5 bytes have to be filled-up with 0x00 until 5 byte size is reached.
    0011 Usertext
    This cluster is 24 bytes in size and contains the name of the Loco / Decoder:
    0..191 Name, 24 byte, UTF8-coded (ISO-8859-1 ?). Names shorter than 5 bytes have to be filled-up with 0x00 until 5 byte size is reached.

6. Command Station implementation

    This chapter talks about the behaviour of the Command Station during Logon and how it will cope with special cases. TEXT missing ... After each boot up of the Command Station the SessionID has to be incremented. 255 is follwed by 0.

7. Decoder behaviour

    This chapter describes the behaviour of Decoders during the course of Logon and how they cope with special cases. specific TEXT missing ...
  • Behaviour after (Re-)Boot:
    An initial rerail or a loose connection or slack joint are all treated as a new start by the Decoder. On top of that the Decoder cannot identify a priori if it is controlled by the Command Station with or without Logon.
    If there is no message including Advanced DCC command (1111-1110) within xxxx ms after start or restart, the Decoder should work under the assumption of a Command Station without Logon and is therefore allowed to react to commands issued for the normal Loco address.
    If a Decoder detects a motor that is already moving / turning it is allowed to assume a loose connection or slack joint and is therefore allowed to accept commands for the prior address.
    The Decoder should assume that it is already known to the Command Station in case it detects a Command Station by its HASH code AND that HASH code has not been incremented by more than 4. In this case the Decoder can start with the assigned address and does not have to go through LOGON procedure.


    • If during LOGON_ASSIGN the Decoder is assigned an address value of 0, the Logon process was rejected by the Command Station. The Decoder should indicate that error condition (e.g. flashing headlights). Any further Logon attempts are then not alllowed.

Backoff

    In case a Decoder does not receive a confirmation for a Logon attempt, a certain number doesnt respond to LOGON_ENABLE any more. The Decoder uses a random number (that contains its UniqueID) to determine the number of Logon attempts it should ignore. It is important that each Decoder uses a different random process. The random number is increased with every unsuccessful attempt.

    After PowerCycle the Decoder starts with a max. value for Backoff of 8 (Backoff = 8). This means the Decoder chooses a random number between 0 and 7 for the number of logon attempts to be ignored (this makes for a good and fast timing in a typical home layout of about 24 Decoders).
    Each failed Logon attempt increases the maximum Backoff by 8. This means the Decoder randomly chooses his new Backoff to be between 0 and 15.
    The ultimate maximum Backoff is limited to 64. With that limitation layouts with up to 180 Decoders will still terminate rather quickly (5% collision risk)

8. Feedback module behaviour

    This chapter focuses on the behaviour of feedback modules during Logon process and how they cope with special cases.

    Feedback modules must be able to detect messages for DCC-Advanced and to pass those messages on. Furthermore they need to be able to detect collisions in Logon-messages and pass those on, too. Multiple identical messages need to be filtered out within the feedback module itself, only the first of those messages will be relayed. This is especially important with collision_messages.