BiDiB

• Summary
• Examples

Protocol

• Introduction
• General Messages
• Firmware Update
• Command Station
• Accessory Control
• Accessory Configuration
• Occupancy
• Booster
• Distributed Control

• Printable Version

BiDiB, a universal control set for model railways

Content

• 4.5. Track-output devices
  • 4.5.1. Track-output control
  • 4.5.2. Features for track-output
  • 4.5.3. Downlink: Messages for track-output
  • 4.5.4. Uplink: Messages for track-output

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.29 of BiDiB, updated June 21, 2023.

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 output 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.

Inquiry: When a control or monitoring host program meets a running track signal generator and doesn't reset it, it will want to know about the active vehicles. The MSG_CS_QUERY command and the accompanying MSG_CS_DRIVE_STATE answer allow such a query of addresses, formats and states.

4.5.2. Features for track-output

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

  Value	Name	Meaning
  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

  Parameter	Description
  ADDRL	Address, lower 8 Bits.
  ADDRH	Address, upper 6 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 Bit Meaning 3…0 Format (5): 0000: DCC14 (14 speed steps) 0001: DCC SDF (126 speed steps) 0010: DCC28 (28 speed steps) 0011: DCC128 (126 speed steps) 0100: MM14 (14 speed steps) 0101: MM27a (27 speed steps with alternating command with 14 steps ) 0110: MM27b (28 speed steps by using the light bit) 0111: M4/MFX (126 speed steps) 1000…1111: reserved 7…4 reserved
  DATA1	Bitfield output active For formats DCC14, DCC28, DCC128 Bit Meaning 0 0: Do not output speed 1: Do output speed 1 0: Do not output F1…F4 1: Do output F1…F4 2 0: Do not output F5…F8 1: Do output F5…F8 3 0: Do not output F9…F12 1: Do output F9…F12 4 0: Do not output F13…F20 1: Do output F13…F20 5 0: Do not output F21…F28 1: Do output F21…F28 7…6 reserved 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.
  In accordance with RCN 211, all DCC decoder with addresses up to and including 127 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: ADDR_L, ADDR_H, DATA, TIME

  The accessory decoder with address [ADDR_H * 256 + ADDR_L] 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

  Parameter	Description
  ADDRL	Address, lower 8 bits.
  ADDRH	Address, upper 3 bits. The complete address is given by ADDRH*256+ADDRL. The address designates the real (DCC) address and is counted from 0.
  DATA	Bitfield Bit Meaning 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. Bit Meaning 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 use the messages for 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

  Parameter	Description
  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 Value Name Meaning 0x00 BIDIB_CS_POM_RD_BLOCK PoM (standard CV 0…1023) block-byte (4 bytes) read 0x01 BIDIB_CS_POM_RD_BYTE PoM (standard CV 0…1023) byte read 0x02 BIDIB_CS_POM_WR_BIT PoM (standard CV 0…1023) bit write 0x03 BIDIB_CS_POM_WR_BYTE PoM (standard CV 0…1023) byte write 0x43 BIDIB_CS_XWR_BYTE1 Short Form CV Access write 1 byte 0x47 BIDIB_CS_XWR_BYTE2 Short Form CV Access write 2 byte 0x80 BIDIB_CS_xPOM_reserved XPoM (extended CV 24-Bit) reserved 0x81 BIDIB_CS_xPOM_RD_BLOCK XPoM (extended CV 24-Bit) block-byte read 0x82 BIDIB_CS_xPOM_WR_BIT XPoM (extended CV 24-Bit) bit write 0x83 BIDIB_CS_xPOM_WR_BYTE1 XPoM (extended CV 24-Bit) write 1 byte 0x87 BIDIB_CS_xPOM_WR_BYTE2 XPoM (extended CV 24-Bit) write 2 byte 0x8B BIDIB_CS_xPOM_WR_BYTE3 XPoM (extended CV 24-Bit) write 3 byte 0x8F BIDIB_CS_xPOM_WR_BYTE4 XPoM (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: Opcode Value Meaning XWR_BYTE1 0b0010 Acceleration Value, CV23:=DATA0 XWR_BYTE1 0b0011 Deceleration Value, CV24:=DATA0 XWR_BYTE1 0b1001 Service Mode Decoder Lock XWR_BYTE2 0b0100 long address, CV17:=DATA0, CV18:=DATA1, CV29.5=1 XWR_BYTE2 0b0101 index 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. DID₄,DID₃,DID₂,DID₁,DID₀ for the decoder ID.

• MSG_CS_BIN_STATE:

  With this command, individual actions can be triggered at the decoder, e.g. activate coupling or analogue functions. Followed by 5 bytes: ADDR_L, ADDR_H, STATE_L, STATE_H, DATA. STATE denotes the type of DCC message.

  MSG_CS_BIN_STATE parameters

  Parameter	Description
  ADDRL	Address, lower 8 bits.
  ADDRH	Address, upper 6 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	Function control with group commands (RCN 212 2.3.1-4) 0: reserviert. 1: functions F1…F4, F0. 2: functions F5…F8. 3: functions F9…F12. 4: functions F13…F20. 5: functions F21…F28. 6: functions F29…F36. 7: functions F37…F44. 8: functions F45…F52. 9: functions F53…F60. 10: functions F61…F68.	Analogue Channel (RCN 212 2.3.8), range 0…255
  STATEH	Binary state number, upper 7 bits. MSB is 0.	0x80 (Opcode 0, MSB is 1).	0x81 (Opcode 1, MSB is 1).
  DATA	Binary state condition. Value range 0,1	Bit vector with the functions as in the table above, first named function in LSB. range 0…255	Analogue value, range 0…255

  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.

  Functions and analogue values are output once (with standard repeat count) to the track, they are not recorded in the command repeat memory. If a function command is already present in repeat-memory (ie from a previous MSG_CS_DRIVE), the value in there is updated.

  The support for analogue function commands and function groups up to F68 is announced in the FEATURE_GEN_EXT_AVAILABLE.

  MSG_CS_BIN_STATE commands will be acknowledged with a MSG_DRIVE_ACK (same as for motion commands).

• MSG_CS_QUERY:

  A query of active vehicles is performed with this command. Followed by 1 or more bytes encoding the query: QUERY[, ADDR_L, ADDR_H]

  MSG_CS_QUERY parameter

  Parameter	Description
  QUERY	ENUM of queried information and query mode: Bit Meaning 7 Query mode: 0: 0: Single query of object defined by ADDRL and ADDRH The node responds with a MSG_CS_DRIVE_STATE. 1: Query all objects of the specified type The node autonomously sends one MSG_CS_DRIVE_STATE for each address known in repeat memory, adjusting to the available transport capacity itself. The node must be able to receive and respond to other messages while delivering the answer sequence. If no object is known, the node responds with a MSG_CS_DRIVE_STATE on address 0. 6…4 Reserved, preset with 0 3…0 Type of object: 1: locomotive address
  ADDRL	Adress, lower 8 bits.
  ADDRH	Adress, upper 6 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.

  The support of the generator for this command is determined by the FEATURE_GEN_EXT_AVAILABLE.

• 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

  Parameter	Description
  OPCODE	Byte, defines the operation to be performed Value Name Meaning 0x00 BIDIB_CS_PROG_BREAK Cancel the current operation 0x01 BIDIB_CS_PROG_QUERY Query the remaining time of current operation 0x02 BIDIB_CS_PROG_RD_BYTE Byte read 0x03 BIDIB_CS_PROG_RDWR_BIT Bit read/write 0x04 BIDIB_CS_PROG_WR_BYTE Byte 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

  Name	Meaning
  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,14 Bits 13…0 00 loco address (short format up to and including 127, long format from 128; Value range 1…59391) 10 (reserved) 01 accessory address (value range 0, 4, 8…2044) 11 extended 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:

0. Acknowlegdement Level 0: The node has received the command.
1. Acknowlegdement Level 1: The command is issued at the track.
2. 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.

• 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

  Parameter	Description
  ADDRL	Address, lower 8 bits.
  ADDRH	Address, upper 6 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

  Parameter	Description
  ADDRL	Address, lower 8 bits
  ADDRH	Address, upper 3 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

  Parameter	Description
  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_MANUAL parameters

  Parameter	Description
  ADDRL	Address, lower 8 bits
  ADDRH	Address, upper 6 bits
  DATA0	Bitfield, Format
  DATA1	Bitfield Output active
  DATA2	Speed
  DATA3	3*reserved, FL (light), F4, F3, F2, F1
  DATA4	F12 – F5
  DATA5	F20 – F13
  DATA6	F28 – F21

• MSG_CS_DRIVE_EVENT:

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

  MSG_CS_DRIVE_EVENT parameters

  Parameter	Description
  ADDRL	Address, lower 8 bits
  ADDRH	Address, upper 6 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: Value Meaning 0 No event present 1 LOST: 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_DRIVE_STATE:

  This command reports results of MSG_CS_QUERY inquiries. Followed by one parameter which encodes the type of response, further parameters are coded identical to MSG_CS_DRIVE_MANUAL. When a non-existing loco is queried, the address is reported with all data fields set to 0.

  MSG_CS_DRIVE_STATE parameters

  Parameter	Description
  OPCODE	ENUM of the query mode and the requested information: Bit Meaning 7 Query mode: 0: Message is response to single query 1: Message is one of many responses in a stream 6 End: 0: more messages will follow 1: last message of the transmission (also set in single responses) 6…4 Reserved, preset with 0 3…0 Type of object: 1: locomotive address
  ADDR[2]	Coded identical to MSG_CS_DRIVE_MANUAL
  DATA[7]

• MSG_CS_PROG_STATE:

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

  MSG_CS_PROG_STATE parameters

  Parameter	Description
  STATE	Result Wert Name Meaning 0x00 BIDIB_CS_PROG_START This status is returned after receipt of the programming command. 0x01 BIDIB_CS_PROG_RUNNING Status during execution. RUNNING will be send during longer operations as an intermediate message for an QUERY request. 0x80 BIDIB_CS_PROG_OKAY Programming operation successful. 0xC0 BIDIB_CS_PROG_STOPPED Der Programming operation was stopped, Result is not valid. 0xC1 BIDIB_CS_PROG_NO_LOCO Programming operation was stopped, no load recognized at the track. 0xC2 BIDIB_CS_PROG_NO_ANSWER Programming operation was stopped, programming was not acknowledged by loco or no repsonse during reading. 0xC3 BIDIB_CS_PROG_SHORT Programming operation stopped, short detected. 0xC4 BIDIB_CS_PROG_VERIFY_FAILED Programming 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

  Parameter	Description
  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

  Value		Meaning
  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