BiDiB, a universal control set for model railways

The German version is the definitive specification. Any discrepancies between this translation and the original are unintentional.
BiDiB - Bidirectional Bus - Logo

Content

General

The intention of BiDiB protocol is to control a model railway. It allows the control of locomotives, accessories and safe transmission of feedback information from the model railway to the controlling computer.

BiDiB can be transported over different transmission media, framing and protection of messages is guaranteed.

The used terms and the basic principles will be explained in the general part of the protocol description. Hints for usage and the license can be found there too.

This section of the protocol description explains only a part of the messages.

Current revision status

This document describes revision 1.26 of BiDiB, updated aug 15, 2016.

The revision history can be found at the general section.

4.5. Track-output devices

4.5.1. Track-output control

Track-output devices are nodes with the ability to generate a DCC-signal. This DCC signal is by default only known by the node itself and all directly connected devices. The node can be enabled through system messages in order to control the distribution of the DCC signal (via the corresponding line pair). BiDiB contains the ability to run different DCC systems in parallel. Possible applications for the above feature is e.g. a separate programming track, which can be operated independently of the main track or a separate DCC signal branch, which is used for switch accesories only.

A common problem on exhibition layouts are 'down' locos with contact problems. This locos are not able to receive commands and therefore they interrupt the operation. BiDiBus provides a fast information transfer via a separate channel which allows to receive a railcom acknowledgement from the loco. This information is received from the track-output unit and can be combined to one message if the corresponding loco is still in communication with the control station. If the control station detects a lost loco, it reports this information to the host.

During regular operation, the track-output device is addressed by the host. However, there might be the request that DCC generators can be addressed decentralized and also from the host. The already existing trade-off ('who controls the loco, who secures driveway'), becomes an additional conflict: which device receives an acknowledgement from the command and the successfull output to the track? In BiDiB, it is intended (in regular opration conditions) that local control devices (distributed handhelds and switch boards) sends their demands to the host. The host checks and filters occasional (i.e. no turnout operation in a reserved route) and issue the appropriate command to the track-output device. In regular operation, the track-output device acknowledges against the host.

Accident and test mode: Moreover, there might be situations in which the host is not able to provide desired commands, e.g. because the operating situation is not intended, the PC program has crashed or the PC is simply not connected. Direct local control is provided for this scenario (accident and test operation).

For this emergency operation, DCC generators are allowed to listen for loco control commands on local bus structures (e.g. BiDiBus) and execute these commands without acknowledge. This ability is controlled by a feature. If this feature is enabled, handheld commands (which are actually sent to the host) will be read from the track-output device in 'spy mode' and are being executed. With this solution, the trade-off (who controls) can be resolved. The host has the possibility to stop this 'spy mode' via the command MSG_CS_ALLOCATE and the handheld will be therefore 'locked out'. This handheld 'lock out' with the command MSG_CS_ALLOCATE is only valid for a limited time, therefore MSG_CS_ALLOCATE has to be repeated continuously. That guarantees a smooth transition between PC and handheld control, also driving without a PC is possible without further actions.

Watchdog: The track output is equipped with an optional connection monitoring for the event of an unexpected connection loss between host program and track output which result also in a lost of the locos controls. The host program must renew the ON-status at the command station in regular intervals via MSG_CS_SET_STATE (BIDIB_CS_STATE_GO). The feature FEATURE_GEN_WATCHDOG defines the interval until the status renewal must be made.

If the renewal doesn't take place within the time limit, the track ouput controller stopps all locos which are currently controlled by the host.

A host program must fetch the feature FEATURE_GEN_WATCHDOG in advance before controlling any locos and it must renew the ON-status accordingly.

General note: This section 'command station' is still in the testing phase. Certainly, there might be still a need for one or other for the control of loco's – e.g. address reallocation, set control format, manage loco names (who manages this – the output unit?), etc.

4.5.2. Features for track-output
Listing of features for the track signal class
NumberNameMeaning
100 FEATURE_GEN_SPYMODE Spymode
Here will be set if local control (monitoring of handheld messages) is allowed or not.
0: Monitoring not allowed.
1: Monitoring allowed in general, but might be disabled by MSG_CS_ALLOCATE.
101 FEATURE_GEN_WATCHDOG Host Monitoring
0: No monitoring (=no watchdog function).
1…100: host control program must repeat MSG_CS_SET_STATE(GO) permanently. The repetition must occur before FEATURE_GEN_WATCHDOG * 100ms is elapsed. default = 20, corresponding to 2s.
102 FEATURE_GEN_DRIVE_ACK Acknowledge for drive and programming commands – bit field:
Bit 0 additionally activates level 1 (track output)
103 FEATURE_GEN_SWITCH_ACK Acknowledge for switch commands – bit field:
Bit 0 additionally activates level 1 (track output)
106 FEATURE_GEN_POM_REPEAT Number of DCC PoM messages, which are generates for each PoM command to the command station
2: according to railcom specification (default).
3…8: larger number of DCC messages (for decoders, which are not fully spec conform).
107 FEATURE_GEN_DRIVE_BUS DCC-bus control (within BiDiBus)
0: Node receives DCC from BiDiBus
1: Node drives DCC at the BiDiBus
108 FEATURE_GEN_LOK_LOST_DETECT Track output detects and reports 'lost' locos
0: Lost locos will not be recognized or reported.
1: Lost locos will be recognized and reported.
109 FEATURE_GEN_NOTIFY_DRIVE_MANUAL The track output may have occasional local controls.
Bit:Meaning
0 0: Local operated locos will not be reported.
1: Local operated locos will be reported. (default)
1 0: Local operated accessories will not be reported.
1: Local operated accessories will be reported. (default)
2…7 reserved
110 FEATURE_GEN_START_STATE Initial state of generator after power up.
0: DCC is off.
1: DCC is on.
111 FEATURE_GEN_RCPLUS_AVAILABLE 1: The generator supports the RailcomPlus messages MSG_CS_RCPLUS and MSG_CS_RCPLUS_ACK
4.5.3. Downlink: Messages for track-output
  • MSG_CS_ALLOCATE:

    Followed by a byte with content 0. (= local bus address of the host)

    The track-output node does not receive commands from any other local addresses. This lock is valid for 2 seconds and then expires by itself.

  • MSG_CS_SET_STATE:

    With this command, the state of the track output is set or queried. Followed by one byte which encodes the new state. The node responds with a MSG_CS_STATE.

    Before first turn on, the speed settings of all locos should be checked resp. the loco stack should be cleared. This avoid unintentional driving of loco with speed settings from a previous session.

    Encoding of states of track-output devices
    ValueNameMeaning
    0x0 BIDIB_CS_STATE_OFF Track output will be switched off. As a consequence, also all connected boosters will be turn off.
    0x1 BIDIB_CS_STATE_STOP All locos will be stopped by an emergency stop, turnouts may still be operated. If stop is not supported by the control station, then OFF will be executed.
    0x2 BIDIB_CS_STATE_SOFTSTOP All locos will be stopped with speed step 0 (with their own delay), turnouts may still be operated. If soft-stop is not supported by the control station, then STOP will be executed.
    The track-output device execute the soft-stop and changes over to STOP mode afterwards.
    0x3 BIDIB_CS_STATE_GO Resumption of operation, locos and turnouts can be operated. If the watchdog-feature is enabled, this command must be repeated in the given interval by host program.
    0x4 BIDIB_CS_STATE_GO_IGN_WD Resumption of operation, locos and turnouts can be operated. A watchdog event will be ignored.
    0x8 BIDIB_CS_STATE_PROG Programming mode; the control station has switched over to programming mode and is ready to execute programming instructions (on the programming track). Normal operation is not active.
    0x9 BIDIB_CS_STATE_PROGBUSY Programming mode; This message indicates that there is currently a programming operation is active at the programming track. (only on request).
    0xD BIDIB_CS_STATE_BUSY The track output is not able to receive new commands, e.g. because corresponding output FIFOs are full. (Message only on request)
    0xFF BIDIB_CS_STATE_QUERY The state is queried. (only for MSG_CS_SET_STATE).
  • MSG_CS_DRIVE:

    Motion commands will be issued with this command. Following by further parammeters, which contains format and output functions. If an loco has no higher functions, the appropriate groups of the function commands should be marked as inactive. This conserves the limited bandwidth at the track.

    MSG_CS_DRIVE commands will be acknowledged by one or more MSG_CS_DRIVE_ACK messages. The various acknowledgement levels can be activated in the output unit via FEATURE_GEN_DRIVE_ACK. If multiple commands for the same DCC address are issued, the output device is allowed to combine them in case of low bandwidth. In this case, intermediate acknowledgements can be omitted.

    Motion commands will be passed always with the step number of 127 + direction bits. Only the track-output unit converts this motion command to the appropriate speed-step on the track depending from the selected format.

    MSG_CS_DRIVE parameters
    ParameterDescription
    ADDRL Address, lower 8 Bits.
    ADDRH Address, upper 8 Bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC) address and is counted from 0. Address 0 is not assigned to a specific loco and has a special role. (3) (4)
    DATA0 Bitfield
    BitMeaning
    3…0 Format (5):
    0000: DCC14 (14 speed steps)
    0001: reserved
    0010: DCC28 (28 speed steps)
    0011: DCC128 (126 speed steps)
    0100…0111: reserved
    1000…1111: reserved
    7…4 reserved
    DATA1 Bitfield output active
    For DCC formats
    BitMeaning
    00: Do not output speed
    1: Do output speed
    10: Do not output F1…F4
    1: Do output F1…F4
    20: Do not output F5…F8
    1: Do output F5…F8
    30: Do not output F9…F12
    1: Do output F9…F12
    40: Do not output F13…F20
    1: Do output F13…F20
    50: Do not output F21…F28
    1: Do output F21…F28
    7…6reserved
    These bits indicating the valid data fields in subsequent bytes. Only those data fields whose bits are set will be taken over by the output device.
    If all bits are set to 0, then the loco will be removed from the repeat-memory at the output device (2), this is acknowledged with ACK=1.
    DATA2 Speed, consisting of direction (MSB) and velocity (7 LSBs) (1)
    DATA3 FL, F4 – F1; 3 MSB is reserved.
    The bit order of the function bits is: 3*reserved, FL (Light), F4, F3, F2, F1
    DATA4 F12 – F5
    DATA5 F20 – F13
    DATA6 F28 – F21
    (1)
    Speed is coded similar to the DCC 128 speed command, regardless of the loco format.
    • MSB is coding the travel direction: 1 = Forward, 0 = Reverse
    • The LSB's (Bit 6…0) are coding the speed: 0 = Stop, 1 = Emergeny stop
    Values from 2…127 are describing the speed step. Only the track-output unit converts the speed step into the respective format. The following conversion shall be applied:
    • DCC128: speed_step (1…126) = speed - 2 + 1 = (speed-1)
    • DCC28: speed_step (1…28) = integer((speed - 2) * 2 / 9) + 1 = ((speed-1) * 2 + 7) / 9
    • DCC14: speed_step (1…14) = integer((speed - 2) / 9) + 1 = ((speed-1) + 8) / 9
    See also: Notes on the speed encoding.
    (2)
    An unused loco should be unregistered at the output unit in order to save limited bandwidth on the track that would be used up by unnecessary refresh-cycles.
    (3)
    If loco 0 is unsubscribed from the output unit, then all locos are removed from the loco stack. (init)
    (4)
    In DCC there are two addressing schemes: short and long address. Theoretically these are two completely disjoined address spaces. It is however customary in control units to merge them into a single address space. In BiDiB, all loco addresses are generally represented in one 16 bit address space as well – independent from format or addressing.
    Following RCN 211, all DCC decoder with addresses up and including 17 are approached by short address, from 128 onwards by long address. The DCC address space is nominally restricted to 1 … 10239. The output unit won't check for that, when using addresses greater than this duplicate addresses may occur on the track.
    Tip: By ORing the address with 0xC000 it is possible to force long addressing. Still, the address must not be used as a short address at the same time (feedback does not distinguish them).
    (5)
    When a format (track protocol) is not supported by an output unit, it sends a MSG_CS_DRIVE_ACK with ACK=0.
  • MSG_CS_ACCESSORY:

    Accessory items will be controlled with this command. Followed by 4 bytes: ADDRL, ADDRH, DATA, TIME

    The accessory decoder with address [ADDRH * 256 + ADDRL] is driven by the term in DATA. DATA is a bit structure, constisting of CONFIG (Bit 7,6) ACTIVATE (Bit 5) and ASPECT (Bit 4 – Bit 0).

    MSG_CS_ACCESSORY parameters
    ParameterDescription
    ADDRL Address, lower 8 bits.
    ADDRH Address, upper 8 bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC) address and is counted from 0.
    DATA Bitfield
    BitMeaning
    7 Extended / normal Accessory: 0=normal, 1=extended
    6 Timing control: 0 = conventional control via coil-on/coil-off, 1 = Output unit does the timing; see note below
    5 Activate: 0=coil-off / 1=coil-on
    If ACTIVATE is set, the track output generates the appropriate ON-command for the coil output. If ACTIVATE is not set, the track output generates the OFF-command.
    4…0 ASPECT
    Accessory decoder with 2 aspects will be controlled with (ASPECT 0 = red) and (ASPECT 1 = green).
    TIME Switch time, given like the specification of railcom.
    BitMeaning
    7 Base unit:
    0: 100ms (total range 0…12.7s)
    1: 1s (total range 0…127s)
    6…0 value 0…127
    This allows to set timings in a range between 10ms and 127s.
    Hints:
    If accessory timing control is implemented in the output unit:
    • only possible with normal accessory (bit 7 = 0)
    • the aspect is limited to 0 and 1
    • both aspects are not interlocked at the output unit.
    • The number of simultaneously active accessory commands may be limited. In this case, an MSG_CS_ACCESSORY is rejected and must be repeated some time later.
    Addressing scheme:
    BiDiB transports the address of the DCC command 'as is', there is no translation. DCC basic accessory addresses are limited in their address space through the DCC standard: decoder address 0 is not used (and therefore the addresses 0…3 are not used) and address 2047 with aspect 0 denotes an emergency stop command.

    There is a multi-level acknowledgement mechanism for accessory commands too. Its levels can be activated via FEATURE_GEN_SWITCH_ACK. The node sends the respective MSG_CS_ACCESSORY_ACK messages.

    Note: This message targets accessory decoders connected to DCC. It is recommended to directly connect accessories to BiDiB. These accessory use the message MSG_ACCESSORY_STATE inside the class accessory and offer more features.

  • MSG_CS_POM:

    Programming commands for the main track (Program On Main) will be issued with this command. Followed by other parameters that describe address, selected CV, data and operation to be performed. Programming commands will be acknowledged by one or multiple MSG_CS_POM_ACK messages. The various acknowledgement levels can be activated in the output unit via FEATURE_GEN_DRIVE_ACK. If a track output unit can not issue a command (e.g. because the operation is not implemented), it sends a MSG_CS_POM_ACK with ACK=0 nonetheless.

    If a Railcom-capable decoder answered the POM command, the appropriate bidi detector generates a MSG_BM_CV or MSG_BM_XPOM message.

    POM commands are available in several variations, with the following key differences:

    • Addressing of the target decoder can be done either via the DCC address (normal procedure) or via the decoder identifier. The decoder identifier is a 40-bit number consisting an manufacturer ID and a unique ID. In the command the MID (manufacturer ID) field is used to decide whether addressing is done via loco address or DID.
    • The target decoder can be a loco or an accessory decoder. At accessory decoders there is a further distinction between accessory and extended accessory. This is encoded in the two MSBs of the address, similar to addresses from bidi detectors.
    • Addressing of the target CV within the decoder: There is a classic version (POM) where 1024 CV's will be addressed and the content (read/write) is one or four bytes. With the introduction of Railcom, another version came up which extends the CV address to 24 bits and transmits 32 bits (XPOM). These are distinguished by the OPCODE of the BiDiB command.

    The parameters of the command MSG_CS_POM will always be encoded with the maximum field size, even if only short CV's will be addressed. Therefore, the address field is always 8+32 bit, the CV address field is 24 bit and the data field is 32 bit wide. As customary in BiDiB, the LSB will be transmitted first (little-endian).

    MSG_CS_POM parameters
    ParameterDescription
    ADDRL Address, lower 8 bits (DID0 at decoder addressing).
    ADDRH Address, upper 8 bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC-)address and is counted from 0. (DID1 at decoder addressing);
    The distinction whether a accessory or loco decoder is addressed, is encoded in bit 14 and 15:
    • Bit 15,14 = 00: Loco decoder
    • Bit 15,14 = 10: (reserved)
    • Bit 15,14 = 01: Standard accessory decoder
    • Bit 15,14 = 11: Extended accessory decoder
    ADDRXL 0 at loco addressing, DID2 at decoder addressing
    ADDRXH 0 at loco addressing, DID3 at decoder addressing
    MID 0: Addressing via loco address
    1…255: Addressing via decoder ID, then this field is the manufacturer ID (=DID4)
    OPCODE Byte, defines the operation to be performed
    ValueNameMeaning
    0x00BIDIB_CS_POM_RD_BLOCKPoM (standard CV 0…1023) block-byte (4 bytes) read
    0x01BIDIB_CS_POM_RD_BYTEPoM (standard CV 0…1023) byte read
    0x02BIDIB_CS_POM_WR_BITPoM (standard CV 0…1023) bit write
    0x03BIDIB_CS_POM_WR_BYTEPoM (standard CV 0…1023) byte write
    0x43BIDIB_CS_XWR_BYTE1Short Form CV Access write 1 byte
    0x47BIDIB_CS_XWR_BYTE2Short Form CV Access write 2 byte
    0x80BIDIB_CS_xPOM_reservedXPoM (extended CV 24-Bit) reserved
    0x81BIDIB_CS_xPOM_RD_BLOCKXPoM (extended CV 24-Bit) block-byte read
    0x82BIDIB_CS_xPOM_WR_BITXPoM (extended CV 24-Bit) bit write
    0x83BIDIB_CS_xPOM_WR_BYTE1XPoM (extended CV 24-Bit) write 1 byte
    0x87BIDIB_CS_xPOM_WR_BYTE2XPoM (extended CV 24-Bit) write 2 byte
    0x8BBIDIB_CS_xPOM_WR_BYTE3XPoM (extended CV 24-Bit) write 3 byte
    0x8FBIDIB_CS_xPOM_WR_BYTE4XPoM (extended CV 24-Bit) write 4 byte
    Hints:
    Bit 0,1: corresponds to DCC CC bits
    Bit 2,3: denotes number of bytes -1 in XPOM operation
    Bit 6,7: denotes POM/short form/XPOM
    CVL, CVH, CVX CV-Address, low byte first. CVX is only required with XPOM and will be transferred as 0 for classic POM. CV starts counting at 0 (same as track the command). The CV naming of decoders starts at CV1 (CV1 will be coded with 0).
    For Short Form CV Access, this field directly sets the 4-bit Instruction Type, with the following values:
    OpcodeValueMeaning
    XWR_BYTE10b0010Acceleration Value, CV23:=DATA0
    XWR_BYTE10b0011Deceleration Value, CV24:=DATA0
    XWR_BYTE10b1001Service Mode Decoder Lock
    XWR_BYTE20b0100long address, CV17:=DATA0, CV18:=DATA1, CV29.5=1
    XWR_BYTE20b0101index register, CV31:=DATA0, CV32:=DATA1
    DATA[1…4] CV values.
    For standard POM there is only one datum, for XPOM write there are up to 4 data bytes.
    Hints:
    When writing a bit, the bit to be written is determined by DATA: DATA = 1111DBBB. BBB indicates the bit position and D indicates the value of the bit (identical to DCC definition).
    For each access from the track-output, a sequence ID (modulo 4) is generated for XPOM. This sequence ID will be transmitted together with the command. The track output must be 'in_order' with the commands.
    To ease the implementation of detectors, there should only be a global sequence generator instead of separate ones for each decoder.
    Decoder ID, CV address and data bytes are represented in little endian format. DCC transmission uses big endian and sends them in reverse order; e.g. DID4,DID3,DID2,DID1,DID0 for the decoder ID.
  • MSG_CS_BIN_STATE:

    With this command, individual actions can be triggered at the decoder, e.g. activate coupling. Followed by 5 bytes: ADDRL, ADDRH, STATEL, STATEH, DATA

    MSG_CS_BIN_STATE parameters
    ParameterDescription
    ADDRL Address, lower 8 bits.
    ADDRH Address, upper 8 bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC-)address and is counted from 0. Address 0 is reserved.
    STATEL Binary state number, lower 8 bits
    STATEH Binary state number, upper 8 bits.
    DATA Binary state condition. Value range 0,1

    Binary states include 32767 possible outputs, they will be transmitted on the track together with the date D in 2 bytes: DCC codes this as DLLLLLLL HHHHHHHH. The Binary state number 0 means the addressing of all binary states in the decoder.

    Binary state commands will be acknowledged with a MSG_DRIVE_ACK (same like motion commands).

  • MSG_CS_PROG:

    Service mode commands (at programming track) will be issued with this command. These track commands are only supported from output units with enabled class bit 3.

    Followed by further parameters, which describes the addressed CV, data and operations to be performed. MSG_CS_PROG command will be acknowledged by one or more MSG_CS_PROG_STATE message(s).

    Programming commands are available in several variations (for historical reasons) and they have the following key differences:

    • Address programming: simple, direct programming from the target address, no CV select possible. Will not be supported from BiDiB.
    • Register programming (paged): Selection from a CV within the range 1…8, further CVs can be addressed by setting of an page address. This is not any more supported by BiDiB.
    • CV-Programming, byte-mode: CV's can be queried byte-wise within an range of 1-1024.
    • CV-Programming, bit-mode: A single bit can be queried or set within a CV.

    The target decoder can be an loco decoder (standard) or an accessory decoder. There is no difference between an loco or accessory decoder if the programming is made at the programming track.

    Addressing the target CV within the decoder: 1024 CVs can be addressed with the programming track commands. Any higher CVs can be addressed by setting of an index register (CV 31 and CV 32) at host side.

    MSG_CS_PROG parameters
    ParameterDescription
    OPCODE Byte, defines the operation to be performed
    ValueNameMeaning
    0x00BIDIB_CS_PROG_BREAKCancel the current operation
    0x01BIDIB_CS_PROG_QUERYQuery the remaining time of current operation
    0x02BIDIB_CS_PROG_RD_BYTEByte read
    0x03BIDIB_CS_PROG_RDWR_BITBit read/write
    0x04BIDIB_CS_PROG_WR_BYTEByte write
    CVL, CVH CV-address, low byte first. CV will be counted from 0 (same like track command). Decoder CV designation starts at CV1 (CV1 is coded as 0)
    DATA[0…1] CV-Data. In case of byte-read, DATA is not required but may still be included in the command.
    Hints:
    In case of bit writing, the bit to be written will be determined by DATA: DATA = 111KDBBB, BBB indicates the bit position and D indicates the value of the bit. K is the correspondig command (1=write, 0=read) (identical with DCC definition).
    The answer to a bit operation will be either OKAY or FAILED (ie. with timeout). If a set bit inside a CV is queried with 'verify,D=1', the answer will be OKAY. If this bit is queried with 'verify,D=0', the answer will be FAILED, TIMEOUT, since there is no acknowledge from the decoder.
    The node responds immediately with an MSG_CS_PROG_STATE and after completion of the operation he responds again with another MSG_CS_PROG_STATE. [Discussion: should we require continuous STATE messages – progress bar?]
    MSG_CS_PROG is sequential action, the first programming action must be terminated before a second action can be started.
    Programming mode:The output unit must turn on programming mode by a status change to BIDIB_CS_STATE_PROG before programming commands can be executed. No normal track commands are possible as long as a service mode action is running. Output unit must be switched back to the normal operating mode after the service mode operations are completed.
    Service mode is a global and address-free method to change CVs in the decoders. This involves the risk that the user accidentally re-programm all locos and attached accessory decoders on the layout. A host program should inform the user (e.g. with an warning message) before the programming mode gets activated and if possible, the software should also switch off all dependent boosters and keep only the booster with the service mode alive.
  • MSG_CS_RCPLUS:

    (optional, whether a node supports this command is defined by the FEATURE_GEN_RCPLUS_AVAILABLE)

    This command controls the Railcom-Plus packet output of the signal generator. Followed by at least one byte (OPCODE), depending on this opcode value followed by further bytes.

    Every MSG_CS_RCPLUS is responded to by one or multiple MSG_CS_RCPLUS_ACK with the respective OPCODE.

    Encoding of opcode for RailcomPlus command
    NameMeaning
    RC_GET_TID The track output device will return the current TID.
    RC_SET_TID Setting of TID. Followed by another 6 bytes: CID0, CID1, CID2, CID3, CID4, SID
    RC_PING Permanent transmission of the RailcomPlus track identifier (TID).
    Followed by another parameter INTERVAL, which defines the time difference between the transmissions in the unit of 100ms. A value of 0 disables the transmission.
    RC_PING_ONCE_P0 Singular transmission of the RailcomPlus track identifier (TID).
    RC_PING_ONCE_P1
    RC_BIND Assigning a decoder address. Followed by another 7 bytes:
    DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID, NEW_ADDRL, NEW_ADDRH. The new address is coded as follows:
    Bit 15,14Bits 13…0
    00loco address (short format up to and including 127, long format from 128; Value range 1…59391)
    10(reserved)
    01accessory address (value range 0, 4, 8…2044)
    11extended accessory address (value range 0…2046)
    With address 0 a decoder can be logged off, with DID 0 even all at once. In doing so, the SID has to be incremented as well.
    RC_FIND_P0 A FIND packet with (un)set P-bit is issued. Followed by 5 bytes:
    DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID
    RC_FIND_P1
    Hints:
    The permanent transmission of the TID is inactive (INTERVAL = 0) after every start or reset of the node.
    At the permanent transmission of the TID both phases are approached. The interval is the maximal time for gaps between two transmissions with the same phase bit.
    To ensure the delivery of the packets to every decoder, they will have to be repeated (typically back-to-back). The number of repetitions can be set via the feature FEATURE_GEN_POM_REPEAT.
4.5.4. Uplink: Messages for track-output

For drive, switch and programming instructions there is a multi-level handshake process:

  1. Acknowlegdement Level 0: The node has received the command.
  2. Acknowlegdement Level 1: The command is issued at the track.
  3. Acknowlegdement Level 2: The decoder has confirmed the command by ACK (via BiDi).

While level 0 is always compulsory, the higher levels can optionally be activated with features. Their acknowledgement messages are sent additionally.

Kodierung der Werte für ACK-Parameter
ValueLevelMeaning
0 0

Immediate acknowledgement: The command could not be accepted.

This happens when the corresponding buffers are full or the track output is switched off.

Also a 0 acknowledgement is sent when the output unit does not support the requested command (e.g. XPOM opcode, DRIVE format).

1 0

Immediate acknowledgement: The command has been accepted and will soon be issued to the track.

2 0

Immediate acknowledgement: The command has been accepted and will be issued to the track with a delay.

This acknowledgement is an indication to the host that currently a certain bottleneck exists in the rail output and a reduction of instructions is advised by the output unit.

The track-output device must still be able to accept at least one DRIVE command after an acknowledgement with 2.

3 1

Spontaneous acknowledgement: The command packet for this address was output on the track.

4 2

Spontaneous acknowledgement: The command packet had been output to the track, but was not confirmed by any decoder.

5 2

Spontaneous acknowledgement: The command packet had been output to the track and was confirmed by at least one decoder.

  • MSG_CS_STATE:

    With this message, the current state of the output is reported, followed by one byte which encodes the current state. The state is encoded similar to MSG_CS_SET_STATE.

  • MSG_CS_DRIVE_ACK:

    Motion commands will be acknowledged with this command. Followed by further parameters:

    MSG_CS_DRIVE_ACK parameters
    ParameterDescription
    ADDRL Address, lower 8 bits.
    ADDRH Address, upper 8 bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC-)address and is counted from 0.
    ACK Acknowledge, coded as described above.
  • MSG_CS_ACCESSORY_ACK:

    Switching commands will be acknowledged with this command. Followed by further parameters:

    MSG_CS_ACCESSORY_ACK parameters
    ParameterDescription
    ADDRL Address, lower 8 bits
    ADDRH Address, upper 8 bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC-)address and is counted from 0.
    ACK Acknowledge, coded as described above.
  • MSG_CS_POM_ACK:

    POM commands will be acknowledged with this command. Followed by further parameters, address and acknowledge. Address is coded identically to the MSG_CS_POM command and will be just 'passed through' at the node.

    MSG_CS_POM_ACK parameters
    ParameterDescription
    ADDRL Address, lower 8 bits (DID0 at decoder addressing)
    ADDRH Address, upper 8 bits. (DID1 at decoder addressing);
    The complete address is given by ADDRH*256+ADDRL. The address designates the real (DCC-)address and is counted from 0.
    The distinction whether a accessory or loco decoder is addressed, is encoded in bit 14 and 15:
    • Bit 15,14 = 00: Loco decoder
    • Bit 15,14 = 10: (reserved)
    • Bit 15,14 = 01: Standard accessory decoder
    • Bit 15,14 = 11: Extended accessory decoder
    ADDRXL 0 at loco addressing, DID2 at decoder addressing
    ADDRXH 0 at loco addressing, DID3 at decoder addressing
    MID 0: Addressing via loco address
    1…255: Addressing via decoder ID, then this field is the manufacturer ID (=DID4)
    ACK Acknowledge, coded as described above.
  • MSG_CS_DRIVE_MANUAL:

    Manual operation (via handheld) of an loco will be reported with this command. For this purpose, the feature FEATURE_GEN_NOTIFY_DRIVE_MANUAL has be set to 1. Followed by further parameters with the same structure like MSG_CS_DRIVE:

    MSG_CS_DRIVE parameters
    ParameterDescription
    ADDRLAddress, lower 8 bits
    ADDRHAddress, upper 8 bits
    DATA0Bitfield, Format
    DATA1Bitfield Output active
    DATA2Speed
    DATA33*reserved, FL (light), F4, F3, F2, F1
    DATA4F12 – F5
    DATA5F20 – F13
    DATA6F28 – F21
  • MSG_CS_DRIVE_EVENT:

    This command reports the events in a loco. Followed by further parameters:

    MSG_CS_DRIVE_EVENT parameters
    ParameterDescription
    ADDRL Address, lower 8 bits
    ADDRH Address, upper 8 bits. The complete address is given by ADDRH*256+ADDRL.
    The address designates the real (DCC-)address and is counted from 0.
    EVENT Event, coded as follows:
    ValueMeaning
    0No event present
    1LOST: The loco is not responding to commands. This tracing can be enabled through FEATURE_GEN_LOK_LOST_DETECT.
    Notes on LOST:

    A common fault during operation are 'down' or 'hanging' locos which are not able to receive motion commands due to contact problems. If a model railway is fully equipped with railcom detectors, the track-output unit can notice the lost connection and report it to the host.

    The track-output unit monitors the ACK-wire at the BiDiBus and is activating the watchdog for a loco decoder address if ACK-confirmations will be received for this decoder. After 10 loco commands without ACK-confirmation, the MSG_CS_DRIVE_EVENT should be generated. This will work, of course, only if the system is fully equipped with railcom detectors, otherwise the 'LOST' message already appears if a loco is running on non railcom-monitored track sections.

  • MSG_CS_PROG_STATE:

    (under development)

    This command report results from an programming operation in service mode. Followed by further parameters:

    MSG_CS_PROG_STATE parameters
    ParameterDescription
    STATE Result
    WertNameMeaning
    0x00BIDIB_CS_PROG_STARTThis status is returned after receipt of the programming command.
    0x01BIDIB_CS_PROG_RUNNINGStatus during execution. RUNNING will be send during longer operations as an intermediate message for an QUERY request.
    0x80BIDIB_CS_PROG_OKAYProgramming operation successful.
    0xC0BIDIB_CS_PROG_STOPPEDDer Programming operation was stopped, Result is not valid.
    0xC1BIDIB_CS_PROG_NO_LOCOProgramming operation was stopped, no load recognized at the track.
    0xC2BIDIB_CS_PROG_NO_ANSWERProgramming operation was stopped, programming was not acknowledged by loco or no repsonse during reading.
    0xC3BIDIB_CS_PROG_SHORTProgramming operation stopped, short detected.
    0xC4BIDIB_CS_PROG_VERIFY_FAILEDProgramming operation stopped, verify failed (see hint below).
    TIME Predicted remaining time in units of 100ms.
    For technical reasons, the remaining time is difficult to estimate, especially on decoder assemblies which does not support bit-mode the result is fluctuating greatly.
    The node attempts data just sequentially through and is done by an 'Hit'.
    CVL, CVH CV-address low byte first. CV will be counted from 0 (same as track command). The CV designations of decoders start at CV1 (CV1 will be coded with 0). Value range 0…1023
    DATA[0…1] CV-Data. DATA is not needed in case of byte-write or an error message but can be included in the command yet.
    Hints:
    At STATE, MSB is coding the status 'running / done' and bit 6 'Error occurred'.
    If a STATE is reported as 'finished', the TIME field is present but invalid and must be encoded with 0.
    BIDIB_CS_PROG_VERIFY_FAILED may, for example, occur if 2 decoders are present at the track output: Replies can overlap during bit-wise reading of CV contents and the read result will not be confirmed at the final check.
  • MSG_CS_RCPLUS_ACK:

    (optional, whether a node supports this message is defined by the FEATURE_GEN_RCPLUS_AVAILABLE)

    This message acknowledges Railcom-Plus commands. Followed by at least one byte (OPCODE), depending on this opcode value followed by further bytes.

    MSG_CS_RCPLUS_ACK parameters
    ParameterDescription
    OPCODE Classification of the response, see below
    ACK (for BIND, PING_ONCE and FIND) Acknowledge, coded as described above. Additionally to the usual level 0 receipt acknowledgement as the immediate response to MSG_CS_RCPLUS, the device may send acknowlegements of higher levels. Support for this is defined by FEATURE_GEN_DRIVE_ACK. The permanent transmissions of the TID with the interval set via RC_PING are then reported with OPCODE = RC_PING_ONCE_P0/P1.
    Enoding of opcode for RailcomPlus acknowledgement
    ValueMeaning
    RC_TID Reports the queried or assigned TID. Followed by another 6 bytes: CID0, CID1, CID2, CID3, CID4, SID
    RC_PING Reports the interval between transmissions of the TID.
    Followed by another byte INTERVAL (unit 100ms, the value means "inactive")
    RC_BIND Assignment of a decoder address. Followed by another 6 bytes:
    ACK, DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID
    RC_PING_ONCE P0 Transmission of the TID. Followed by 1 byte with the acknowledge code.
    P1
    RC_FIND P0 Search for decoders. Followed by another 6 bytes:
    ACK, DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID
    P1