OpenDCC

• Command Station
• Description
• FAQ and version overview
• Command overview, P50X
• Command overview, Xpressnet
• Configuration
• Configuration using rocrail
• Configuration using TrainProgrammer
• Download
• Software
• Properties of the software
• Feedback addressing
• Update of the software
• Overview DCC and CV's
• Development environment
• Hardware
• Schematics, details
• Construction manual
• Starting up and operation with USB
• Throttle adapter (Xpressnet)
• Partlist, BoM
• Mechanical Issues, dimensions, frontpanel
• Application
• Howto: wiring a layout
• Data base for locomotives
• Turnout feedback, technique and implementation
• External Stop
• OpenDCC, linux/MAC and rocrail
• Roomlight control with DMX output acting as virtual decoders
• OpenDCC running as miniDMX

OpenDCC Z1 command set in p50x-Emulation

Overview

The interface protocol to the host of OpenDCC Z1 can emulate different command stations. Following the command overview for the Intellibox Mode® is listed.
I ask to communicate by mail discovered errors or ambiguity. Widely used common names for other command stations may be registered trademarks of their respective owners, here these names are just used for clarifcation.

General characteristics

• Interface:
  OpenDCC uses a default baud rate of 19200. However 2400, 4800, 9600, 19200, 38400 and 57600 baud can also be used. The data format is always 8 data bits, no parity, 2 stop bits (8N2), whereby in receipt it does not matter whether 1 or 2 stop bits are received. When sending, always two stop bits are transmitted, this is necessary to get USB to serial converters working (esp. together with traincontroller).
  When using the USB port a serial interface is emulated. In this case the recommended baud rate is 38400 or 57600.
  OpenDCC supports automatic baud rate identification like the Intellibox (called BABI). The implementation is somewhat different, however it runs together with traincontroller.
  NOTE: When running USB, after restart of OpenDCC (e.g. by switching off and on) or disconnect the USB cable the used serial interface port number over USB is no longer valid, since the interface device will reconnect to the PC. In this case, the control program file handle may get void and the host program may fail to transmit data. This may lead to a 'hang' of the host software. Please first disconnect the logical connection.
  
  Full duplex operation with hardware handshake is supported, the transmit and receive fifos are 64 bytes long, 10 bytes before runout occurs CTS = high is asserted.
Sorry! English page not yet completely available, please refer to the German page. " Protocol: With the Intellibox there are three protocols: - Märklin of 6050 binary interface instructions (Called with the Intellibox [IB] P50-Commands). - ASCII command extension (Called with the IB P50Xa-Commands). - Binary command extension (Called with the IB P50Xb-Commands). If in the P50-Mode the first indication is an X, then switched to extended level of command, if the second indication is an ASCII Indication (¡ 0x80), then the ASCII extension is addressed, otherwise the binary extension. OpenDCC does not support the P50-Mode at all (exception: 0xc4 for auto Baud switching), the ASCII mode and the binary mode to a large extent. In ASCII mode each answer is completed with the character sequence +']'. " Locomotive protocol, locomotive stack: OpenDCC does not work with a locomotive stack or a Slot, which operates cyclically, but with dynamic priority lists, which are filled by an organizational unit. Thus an extremely fast Reaction to driving instructions of the PC is obtained. This organizational unit can administer at the same time 64 locomotives *in motion*. Locomotives, which were not moved for longer time, when calling further locomotives are automatically no more regarded by the organizational unit; it is not on or out Protocol necessarily. Another advantage of dynamic lists is consistent performance even on prolonged driving. This limit of 64 traveling locomotives can set differently by an appropriate #define setting. However it makes hardly sense to let with DCC more than 40 locomotive travels at the same time. Timing at the track is to the limits. OpenDCC permits locomotive addresses of 1 .. 10239. (Entire DCC address area). The range from 10239 to 16384 remains reserved. The address zero is in principle invalid and is not converted into an appropriate Broadcast. The locomotive format from OpenDCC is pre-set on a default value (by Compile setting). All locomotives are addressed in this format (e.g. DCC28). Since the original Intellibox protocol does not know an instruction for determining the format, a new command was introduced, Lok_Cfg_Set (LS) to address locomotives with another format. By Lok_Cfg_Set defined exceptions to default protocol will be stored permanently in the EEPROM. There are 64 storage locations for exceptions. With the help of the program OpenDCC_configtool these lists can be easily managed. Speed setting: The speed at the interface is independent of the format of the locomotive 0 to 127 and will be converted internally to the available speeds in each case. The speed 1 always means thereby emergency stop (Emergency stop). Supported functions: OpenDCC knows the functions F1 to F12, as well as F0 (and FL/light). " Feedback (S88): OpenDCC makes basically s88-Autoreset, i.e. reading of a s88 Module supplies the accumulated state (OR operation) since that last reset. These bits are read out after the set back to zero. Through the S88 interface can also define the turn out feedbacks (chapters 3.5 on page 93) to be read in, this must be adjusted accordingly with special Options (chapter 3.3 on page 80). 1.1.3 P50-Commands (Märklin 6050) OpenDCC does not support this format only the two commands 'x' (or' X') and 0xC4 are supported (returns as response is always 0x00 or 0x00 0x00, depending on the mode). Thus Baud rate identification function and one of the P50X command sentences can be switched on. Also the Märklin MM1 and MM2-Mode is not until further notice released. 1.1.4 P50Xa-Commands (ASCII COMMANDs): General rules: P50Xa messages always begin with an X (unless you are already permanently in the P50X-Mode). A command can be up to 63 characters long and is finished with (= 0x0D). The answer will always end with "]". Contrary to the IB a character which was already dispatched at OpenDCC, cannot be deleted with"". In the following optional parameters are in parentheses with […].If an instruction without parameter is transferred, this instruction is executed as inquiry instruction. " ? or H: Help Action: none Answer: "Help cmds: HL, HF, HT" " HF: Help for function commands Action: none Answer: "F Lok#, [F1], [F2], [F3], [F4], [F5], [F6], [F7], [F8]" " HL: Help for locomotive instructions Action: none Answer: "L Lok#, [speed], [FL], [you], [F1], [F2], [F3], [F4]" " HT: Help for Turnout COMMANDs (switches) Action: none Answer: "T Trnt#, [Color], [status]" " . or STOP: Stop Action: Leads a STOP out (same action as twice pressing that red stop button). The track signals are switched off. Answer: "Pwr off" " ! or GO: Go Action: Leads a GO out (same action as pressures of the green GO button). The track signals are switched on. Answer: "Pwr on" " HALT: Stop Action: The function holds on all locomotives (by Emergency stop), the Track signals however are not switched off. Turn out can still be switched. Answer: "Halted!" " L: Locomotive instruction Syntax: L Lok#, [speed], [FL], [Dir], [F1], [F2], [F3], [F4] Parameter: Lok#: Locomotive address (1 .. 10239) Speed: Speed (0… 127:0 = stop, 1 = Em.Stop) FL: Front Light (0 = out, 1 = on) Dir: Direction (0 or r = backwards, 1 or f = forward) Fn: Function exit n (0 = out, 1 = on) The speed is independent of the locomotive format always within the range indicated from 0 to 127. OpenDCC counts this speed internally over the respective drive positions of the locomotive. The following algorithm is valid (This is identical to Tams EasyControl and Intellibox; it is calculated in each case as integer): 1. Speed of 0 remains 0. 2. DCC, 14 drive positions: V = (speed - 2) /9 + 1; 3. DCC, 28 drive positions: V = (speed - 2) * 2/9 + 1; 4. DCC, 128 drive positions: V = (speed - 1); 27 speed levels are not supported. The highest gear on the track is thus depending on the protocol with the following entry: Locomotive format max DCC14 119 DCC28 124 DCC128 127 LC: Locomotive protocol configuration output Syntax: LC Lok# Parameter: Lok#: Locomotive address (1 .. 10239) Answer: " DCC" and number of the drive positions If the locomotive was so far never used and if it is not declared as an exception, then the default locomotive format is returned. " LS: Locomotive protocol set (new in OpenDCC!) Syntax: LS Lok#, [format], [steps] Parameter: Lok#: Locomotive address (1 .. 10239) Format: MM1, MM2 or DCC, codes as 0,1,2; with OpenDCC only DCC is permitted. Step: 14, 28, 126 Action: If format is different from the default, this is saved as locomotive Exception. " F: Function Syntax: F Lok#, [F1], [F2], [F3], [F4], [F5], [F6], [F7], [F8] Parameter: Lok#: Locomotive address (1 .. 10239) Fn: Function exit n (0 = out, 1 = on) Action: If at least one parameter is available, then the function bits are set accordingly. Answer: The output function bits. " FX: Function (eXtended) Syntax: FX Lok#, [F9], [F10], [F11], [F12] Parameter: Lok#: Locomotive address (1 .. 10239) Fn: Function exit n (0 = out, 1 = on) Action: If at least one parameter is available, then the function bits are set accordingly. Answer: The output function bits. " LOCADD: add Locomotive to data base Syntax: LOCADD Lok#, SPEED STEP, FORMAT, NAME Parameter: Lok#: Locomotive address (1. 10239) SPEED STEP: Number of drive positions, possible selection: 14, 28, 126 FORMAT: Locomotive format, possible selection: here only DCC NAME: max. 6 indications (ASCII) Action: The locomotive is taken up to the internal data base and permanently stored. This data base is *** not*** the locomotive stack - i.e. It can also be driven locomotives, which are not included in the database. Conversely, locomotives which were not yet called are not contained in the output for track, even if they are contained in the data base. The names are converted into uppercase. If a locomotive is already available with same address in the data base, then this is replaced. Only available with OpenDCC XP " LOCDUMP: Locomotive data base dump Syntax: LOCDUMP Action: A list with a data record per line is send. The Structure of each line is as follows: Lok#, SPEED STEP, FORMAT, NAME SPEED STEPS, FORMAT, NAME are formatted as with LOCADD. The List is terminated with a line" *END*". Only available with OpenDCC XP " LOCXMT: Locomotive data base to an attached multiMaus® (ausgeben?) Syntax: LOCXMT Action: The locomotive data base is sent on the Xpressnet. The output takes place twice in each case for each locomotive spaced by 100ms. Thus depending upon Range of the locomotive data base this may last some times. Only available with OpenDCC XP " LOCCLEAR: delete completely Locomotive data base Syntax: LOCCLEAR Action: Answer: ' ok'; The data base is deleted - and away it is! (Don't worry) a PC program (Configtool) can with LOCDUMP read all locomotives (or start from scratch) and construct an internal list of locomotives (e.g. leave to edit by the user). It then deletes the locomotive with LOCCLEAR and sends a completely new list with LOCADD at OpenDCC. Then After transfer the list can be distributed with LOCXMT to the hand controller. . Only available with OpenDCC XP " T: Turnout (switch or signal switching command) Syntax: T {Trnt#, [Color], [status]} Parameter: Trnt#: Switch number (1 .. 2040) Color: 0 or' r' = red/branch, 1 or' g' = green/straight out Status: 1 =,'ein' 0 or not indicated = out Action: OpenDCC sends at present both the status on and the status off instruction on the exit. I want in the future to amend the switch feedback as follows: For status on the command is passed, if status is off the command is also passed, but then will acknowledge receipt of the query. A feedback-able turnout decoder thereby acknowledges the preceding switching command and it indicates by the ACK pulse that the switch is in correct position. If this acknowledging pulse is missing, then either a Turnout Event or a S88-Event will be generated - more details is to clarify still with Mr. Freiwald. Action: Turn the switch in accordance with the status of the switch out. Example: "T 5 g 0" " RC: Railcom Syntax: RC {[mode]} parameters: Without parameters: the current status is diusplayed: 0 The production of cutouts is switched off. 1: In the DCC power Cutout are inserted after each instruction for the length of 434us . Answer: "BiDi on" or "BiDi off" " Y: Status Action: send the momentary system status. Answer: " Pwr off", "Halted! ", "Pwr on", "DCC program" or "RESETS" " V: Version Syntax: V Answer: send the version number of OpenDCC: "OpenDCC V0.12" " MT: Magnet article timer not implemented In OpenDCC " SR: s88-Autoreset Syntax: SR [flag] Answer: Flag: 0 (out) or 1 (ein) Implemented in open DCC, the automatic adjustment is not always used. " SS: s88-Modul select syntax: SS module number Answer: module number: 1..32 Not implemented in open DCC, all acknowledgments do not run over XEVSens. " SE: Number of s88-Module define Syntax: SE [# of module] Answer: # of module: Number of s88-Half module (0..64) Not implemented in OpenDCC, since three strings are present. These are adjusted actually over EEPROM constants. The number of modules which can be read in automatically is the indicated number divided by 2 (the IB counts here in 'half modules', according to bytes). Odd numbers are rounded upward. A specification of 0 as number reading half modules leads to power-off the s88-Bus (no data are read in). Answer: tbd. " ZZA: Switch between P50X-Only and P50/P50X-Mixed mode Syntax: ZZA [value] Value: 0 (mixed mode) or 1 (P50X-only mode) Connect OpenDCC into the P50X-only mode (only P50X command permitted) or again back into mixed the mode (P50 and P50X command permitted). Answer string ZZA0: ' Mixed P50/P50X mode' ZZA1: ' P50X only mode (P50 is disabled)' Note 1: This instruction is not case sensitive contrary to the IB. Note 2: The starting mode can be specified with a Compile option. (Default starting from 0.14: Mixed mode) " @@: Cold starting and/or @: Warm start Syntax: @@ only RESET is needed - creates possible crash - therefore this command is not in OpenDCC. : -) " B: Baud rate Syntax: B [Baud] Parameter: Baud: Baud rate (2400, 4800, 9600, 19200, 38400, 57600) The Baud rate is set to the indicated value, whereby the response of this instruction is transmitted still completely with the old Baud rate. If an incorrect value for baud is specified so DEFAUT_BAUD (usually 19200) is set. If the parameter is missing, then the current Baud rate is returned. " SO: EEPROM read or write variable Syntax: SO address [value] Address: The address of an EEPROM variable. The IB makes addresses possible of 0 .. 999. OpenDCC has another allocation of the addresses (see SOURCE code). An exception applies for SO 1: here is a query in the internal ENUM for the baud rate (which is normally the Lenz-counting equivalent) implemented on the Intellibox syntax. This then also work with the pseudo-intelligent process of TC, when already connected switch the baud rate on the basis of SO 1. For the maximum compatibility with railware special options with meaningful values as preset are demanded by Railware (chapter 3.3 on page 80). " PT: Power-on or switching programming mode off Syntax: PT [0|1] 0 connected programming mode out, 1 connected. With no parameter: current status is displayed. " PTRD: Reads DCC-CV by byte instructions Syntax: PTRD [CV] Parameter: CV: 1..1024 Answer: Okay, followed of contents of the CV or failed " PTWD: Writing DCC-CV by byte instructions Syntax: PTRD [CV, byte] Parameter: CV: 1 .. 1024, byte: that is written Answer: Okay or failed " PA: Writing DCC-CV by Programming on the Main, for Accessory decoder Syntax: Pa [CV, byte] Parameter: CV: 1..1024, byte: that is written Answer: Okay or failed " PAR: Reads DCC-CV by Programming on the Main and BiDi, for Accessory Decoder Syntax: PAR [CV] Parameter: CV: 1..1024 Answer: read byte (0xAB) or failed That is a planned extension, this is not yet implemented! " PD: Writting DCC-CV by Programming on the Main, for locomotive decoder Syntax: PD [ADDR, CV, byte] Parameter: ADDR 1..10239 locomotive address, CV: 1..1024, Byte: Data contents Answer: Okay or failed " PDR: Reads DCC-CV by Programming on the Main and BiDi, for locomotive Decoder Syntax: PDR [CV] Parameter: CV: 1..1024 Answer: read byte (0xAB) or failed That is a planned extension, this is not yet implemented! 1.1.5 P50Xb-Commands (binary Y-commands): If after the introductory 'X' comes a character with a binary coding >0x80, then binary protocol is addressed. If OpenDCC is set on *only* P50Xb, then the leading 'X' can be omitted. The first character (byte) is the command byte and specifies, how many parameter Bytes follow. This command is always acknowledged immediately (return code). If the command was associated with a longer action (e.g. a programming command) then get the result of this command with a query. The respective response can be also a longer list (chained as required) of individual bytes. Here IB-protocol uses different techniques: 1. With a MSB (extension bit) further answer byte is announced. 2. The first answer carries out a coding whether further answers follow. In each case these answers can also be packages of bytes. 3. The response begins with the number, of response packages which are transmitted. Obviously IB-protocol grew rather historically and from different Developers designed in Freestyle: - ( Command list: " XLok (0x80) - length = 1+4 bytes Instruction byte: 0: 0 x80 XLok 1: LSB of the locomotive address 2: MSB of the locomotive address (address within the range 1.. 10239) 3: Speed (0 .. 127). (independently of locomotive format) 4: Function and status bit: bit# 7 6 5 4 3 2 1 0 Chg-f Forc Dir F0 F4 F3 F2 F1 Chg-F: if 1: the bits F4… F1 as Function bits take over, 0 ignore. Force: by OpenDCC one ignores, Locomotive COMMAND is always valid. Dir: Driving direction: 1 = forward 0 = backwards F0: Front light (FL): 1 = on 0 = out F4. F1: Status of the functions F1… F4 (only if bit F- set Valid) Answer: 1 byte: 0 or error code Possible error codes: OK OK, instruction implemented XBADPRM Locomotive address outside of the range (1 .. 10239) XNOSLOT At present the locomotive cannot be included in the queues or (too many instructions) instruction repeat later XLKHALT OpenDCC is in HALT mode. The command was accepted (with respect the functions and the direction of travel) but taken with V = 0 in the buffer. XLKPOFF OpenDCC is in the stop mode. The instruction was accepted (relative the functions and the driving direction) but with V=0 taken up to the Buffer and not sent to the track. " XLokX (0x81) " This is an extension of TAMS. Like XLok, however with genuine decoder speed; Not supported by OpenDCC. " XLkDisp (0x83) " Dispatch status; Not supported by OpenDCC. " XLokSts (0x84) - length = 1+2 bytes Instruction byte: 0: 0x84 XLokSts 1: LSB of the locomotive address 2: MSB of the locomotive address (address within the range 1 .. 10239) Answer: 1 / 4 byte 0: Error code. If OK (0x00), then following those further answer bytes Byte 1: Speed (0 .. 127). 1 means Emergency stop. Byte 2: Functions and direction (as with XLok): bit# 7 6 5 4 3 2 1 0 0 0 Dir F0 F4 F3 F2 F1 Dir: driving direction as with the XLOK COMMAND: 1 = forward, 0 = backwards F0 front light (FL): 1 = on, 0 = out F4. F1 status of the functions F1 .. F4 Byte 3: Genuine locomotive speed like it is send at the track (depending upon locomotive format) 0 = stop, 1 .. 15/29/127 Possible error codes: OK OK, instruction implemented XBADPRM - Locomotive address outside of the range (1 .. 10239) XNODATA - No locomotive data lie forwards (locomotive not in Refresh queues) " XLokCfg (0x85) - length = 1+2 bytes Instruction byte: 0: 0x85 XLokCfg 1: LSB of the locomotive address 2: MSB of the locomotive address (address in Range 1 .. 10239) Answer: 1 / 5 bytes 0: Error code. If OK (0x00) follows, then four further answer bytes 1: Locomotive format: with OpenDCC always, DCC means 2 2: Number of speeds (without stop): 14, 28 or 126 3: 0xFF (with IB for marking virtually Locomotives - > there is not here) 4: 0xFF (with IB for marking virtually Locomotives - > there is not here) Possible error codes: OK OK, instruction implemented XBADPRM Locomotive address outside of the Range (1 .. 10239) XNODATA No locomotive data are present (Locomotive not in Refresh queues) " XLokCfgSet (0x86) - length = 1+4 bytes This command does not exist in the IBox, Tams has thankfully taken over compatibility. Instruction byte: 0: 0x86 XLokCfg 1: LSB of the locomotive address 2: MSB of the locomotive address (address in Range 1 .. 10239) 3: Locomotive format: by OpenDCC one ignores (we speak only DCC; -) 4: Number of speeds (without stop): 14, 28 or 126 Answer: 1 byte 0 or Error code Possible error codes: OK OK, instruction implemented XBADPRM Locomotive address outside of the Range (1 .. 10239) XNOSLOT Too many locomotives with special format (perhaps such a user should the default format change over). Explanation: The locomotive is *not*, called by this command but only the format is set. If the format corresponds to the pre-set Format, then nothing else happens. If it does not correspond to the pre-setting, then this locomotive address will be permanently stored as exception in the EEPROM; there are 64 storage locations for such exceptions. " XFunc (0x88) - length = 1+3 bytes Instruction byte: 0: 0x88 XFunc 1: LSB of the locomotive address 2: MSB of the locomotive address (address in Range 1 .. 10239) 3: Status: F1 (bit #0)… F8 (bit #7) Answer: 1 byte 0 or error code Possible error codes: OK 0x00: OK, instruction implemented XBADPRM 0x02: Locomotive address outside of the Range (1 .. 10239) XNOSLOT 0x0B: Queues are full, command rejected. " XFuncX (0x89) - length = 1+3 bytes Instruction byte: 0: 0x89 XFuncX 1: LSB of the locomotive address 2: MSB of the locomotive address (address in Range 1 .. 10239) 3: Status: F9 (bit #0)… F16 (bit #7) Answer: 1 byte 0 or error code Possible error codes: OK - 0x00: OK, instruction implemented XBADPRM 0x02: Locomotive address outside of the Range (1 .. 10239) XNOSLOT 0x0B: Queues are full, command rejected. Note: OpenDCC supports only F1 to F12, F13 to F16 are not implemented. " XFuncSts (0x8C) - length = 1+2 bytes Instruction byte: 0: 0x8C XFuncSts 1: LSB of the locomotive address 2: MSB of the locomotive address (address in Range 1 .. 10239) Answer: 0 (followed of a byte) or error code Status: F1 (bit #0)… F8 (bit #7) Possible error codes: OK - 0x00: OK, instruction implemented XBADPRM 0x02: Locomotive address outside of the Range (1 .. 10239) XNOSLOT 0x0B: Queues are full, command rejected. " XFuncXSts (0x8D) - length = 1+2 bytes Instruction byte: 0: 0x8D XFuncXSts 1: LSB of the locomotive address 2: MSB of the locomotive address (address in Range 1 .. 10239) Answer: 0 (followed of a byte) or error code Status: F9 (bit #0)… F16 (bit #7) Possible error codes: OK - 0x00: OK, instruction implemented XBADPRM 0x02: Locomotive address outside of the Range (1 .. 10239) XNOSLOT 0x0B: Queues are full, command rejected. Note: OpenDCC supports only F1 to F12, for F13 to F16 0 will be returned. " XTrnt (0x90) - length = 1+2 bytes Instruction byte: 0: 0x90 XTrnt (= and/or switching command turnout) 1: LSB of the switch address (A7 .. A0) 2: MSB of the switch address and status bit (Colour and coil activation) (Address within the range 1 .. 4095) bit# 7 6 5 4 3 2 1 0 Color Sts Res NoCmd A11 A10 A9 A8 Meaning: A11 .. A0: ADDR OF Turnout - > max. 4095 (the IB permits here less) Note: All possible addresses are transmitted, however only the lowest 512 will be stored in the OpenDCC. (See SIZE_TURNOUTBUFFER). Colour: 1 = closed (green), 0 = thrown (red) (Reference: with Lenz is interpreted the other way round) Sts: Coil condition: (1 =, 0 = out) Res: Here one could lock a switch - does not work in OpenDCC (and obviously also not in the Intellibox) NoCmd: ignore. Answer: 0 or error code Possible error codes: OK - 0x00: OK, instruction implemented XPWOFF 0x06: switched off! XBADPRM 0x02: Switch address outside of the Range (1 .. 4095) XLOWTSP 0x40: The queue is nearly full Note: in some cases the response to a command with coil status is altered = due to a feedback query message - See above " XTrntFree (0x93) - length = 1 byte There is no switch reservation in OpenDCC. Not supported Answer: 0 = ok, accepted " XTrntSts (0x94) - length = 1+2 bytes Instruction byte: 0: 0x94 XTrntSts (=turnout- Status inquiry) 1: LSB of the switch address (A7… A0) 2: MSB of the switch address Answer: 0 = ok, accepted (a byte follows) or error code Byte# 7 6 5 4 3 2 1 0 n.u. n.u. n.u. n.u. Conf1 Color Res Conf0 Conf 0 / 1: 00 Motorola 10 DCC 01 SX 11 FMZ Note: OpenDCC always returns DCC; After cold starting: always "red", "does not reserve" Possible error code: XBADPRM (02h) illegal parameter value XBADTNP (0Eh) error: illegal Turnout address for this protocol Note: Because of limited RAM resources not all switch situations are stored. At present the memory is limited to 512 switches: (see config.h, SIZE_TURNOUTBUFFER). " XTrntGrp (0x95) - length = 1+1 bytes Instruction byte: 0: 0x95 XTrntGrp (Status inquiry, by groups) 1: Address of the group address = ((address turnout - 1)/8) + 1; 2: MSB of the switch address Answer: 0 = ok, accepted (two bytes follow) or error code 2. Byte 7 6 5 4 3 2 1 0 W8 W7 W6 W5 W4 W3 W2 W1 Bit field with the positions of the switches: each bit stands for a switch, 1 = straight/green, 0 = turns/red; 3. Byte OpenDCC does not support Bit field with the "reservation flags" of the switches; always acknowledged as 0. Note: After a cold start; always does "red", "not reserve" possible error code: XBADPRM (02h) illegal parameter value Note: Because of limited RAM resources not all switch situations will be stored. At present the memory is limited to 512 switches: (see config.h, SIZE_TURNOUTBUFFER). " XSensor (0x98) - length = 1+1 bytes Instruction byte: 0: 0x98 XSensor (inquiry S88 Feedback) 1: s88 module number (1..128) (module = 16 bits) Answer: 1. Byte: 0 = ok, accepted (two bytes follow) or error code (02 = XMsg_BADPRM = parameter > no of configured modules) 2. Byte of contacts 1..8 of this module (bit 7..0) 3. Byte of contacts 9..16 of this module Contrary to the IB open DCC always supplies the accumulated status of the S88 bits. During the reading also the CHANGE flags are taken back. (@modeltreno: who actually perpetrated this bit arrangement?) " XSensOff (0x99) - length = 1 byte Instruction byte: 0: 0x99 XSensOff (deletion and resetting S88) Answer: 1. Byte: 0 = ok, accepted Clear All S88-Bits to zero all CHANGE flags. " .XP88Get (0x9C) - length = 1+1 bytes Instruction byte: 0: 0x9C XP88Get (read in the S88 configuration) 1: Parameter number: 0: Number of the automatically read bytes 1: Number of the bytes on port 1 2: Number of the bytes on port 2 3: Number of the bytes on port 3 Answer: 1. Byte: 0 = ok, accepted or error code 2. Byte: Value the queried parameter Note: the original IB with 1 and 2 returns the source for timers and Counter; OpenDCC does not give it and has been replaced by specifying the length of the substring. TC uses this command with parameter 0. " XP88Set (0x9D) - length = 1+2 Bytes Instruction byte: 0: 0x9D XP88Set (adjust the S88 configuration) 1: Parameter number: 0: Number of the automatically read bytes 1: Number of the bytes on port 1 2: Number of the bytes on port 2 3: Number of the bytes on port 3 Answer: 1. Byte: 0 = ok, accepted or error code Note: the original IB with 1 and 2 returns the source for timers and Counter; OpenDCC does not give it and has been replaced by specifying the length of the substring. The lengths of the substrings can be adjusted by corresponding special options. " Xs88Tim (0x9E) - length = 1+1 bytes Note: OpenDCC does not support. Who needs that? " Xs88Cnt (0x9F) - length = 1+1 bytes Note: OpenDCC does not support. Who needs that? " XVer (0xA0) - length = 1 byte Instruction byte: 0: 0xA0 XVer (version inquiry) Answer: List, each entry is developed as follows: 1. Byte: Number of bytes in this list element (list means 0 to end) 2. Byte: Low order byte of the version. 3. to n. Byte: Bytes with higher order, if available. In case of OpenDCC there is only one list entry of length 1. Example: 0x01 = length 1 0x0D = version 0.13 0x00 = end of the list Note: the original IB provides back a list of six elements including a serial number. " XP50XC (0xA1) - length = 1+1 bytes Change over "escape characters" for the P50X protocol to another character. This obviously used a PC program and OpenDCC does not support. Was probably built by Modeltreno, to access any malicious Protocole change Aunt M can respond. " XStatus (0xA2) - length = 1 byte Instruction byte: 0:0xA2 XStatus (status inquiry for tension, Etc. was entitled) Answer: Bit field, according to the following allocation: Bit 7: Extension bit, if = 1, still a further byte in answer. (Momentarily always 0) Bit 6: VREG: 1: Voltage regulation switching on (is with OpenDCC set) 0: no voltage regulation Bit 5: I2C 1: external I2C equipment available 0: nothing attached (OpenDCC) Bit 4: STOP 1: Locomotives stopped, but track tension available Bit 3: PWR: 1: Condition "ein", green LED shines. 0: Condition "OUT", red shines. Bit 2: HOT 1: too hot 0: (OpenDCC) Bit 1: GO 1: If just the green button pressed. (No debounce) Bit 0: STOP 1: If just the red button pressed. (No debounce) Note: since The STOP state is not released manually, there with the IB it can be simply ignored by control programs. " XSOSet (0xA3) - length = 1+3 bytes Instruction byte: 0: 0xA3 XSOSet set (special option) 1: Address low order part. 2: Address high order part. More valid Range 0 .. 1023 3: Contents Answer: either 0 (command okay) or error code Note: This command is not given with Orginal Intellibox, it is one Extension of OpenDCC. Warning: use it with caution, variables can be changed in such a way, that OpenDCC does not function any longer. " XSOGet (0xA4) - length = 1+2 bytes Instruction byte: 0: 0xA4 XSOGet select (special option) 1: Address low order part. 2: Address high order part. More valid Range 0 .. 1023 Answer: either 0 (command okay, a byte will follow) or error code 2. Byte: Contents of the Special option Note: The special options are chosen in your address so to reach the best possible fit with the Intellibox. The reason was the analysis of various settings by railware, the "complaints rate" from railware is reduced by the allocation. Note: THUS SO 1 is recoded to read but not write. " XHalt (0xA5) - length = 1 byte Instruction byte: 0: 0xA5 XHalt (Locomotives stopped, however DCC remains active) Answer: 0 (command okay) Note: evidently no control program uses this option, they switch off always immediately. " XPwrOff (0xA6) - length = 1 byte Instruction byte: 0: 0xA6 XPwrOff switch off (DCC Maintrack) Answer: 0 (command okay) " XPwrOn (0xA7) - length = 1 byte Instruction byte: 0: 0xA7 XPwrOn switch on (DCC Maintrack) Answer: 0 (command okay) " XNop (0xC4) - length = 1 byte Instruction byte: 0: 0xC4 XNop (nothing do) Answer: 0 (command okay) Sure, "Nothing to do," we can because we are strong! No, seriously: the Command is used for the amusing BABI in the variety of protocols for IB to find out the baud rate. " XP50Len1 (0xC6) - length = 1+1 bytes This command is used in the original Intellibox for passing "through the back door" the command P50 to the underlying protocol. One with modeltreno was obvious not really sure and beside the X-Char instruction has still in further loophole. Not supported By OpenDCC. " XP50Len2 (0xC7) - length = 1+2 bytes Still a secret door as above. " XEvent (0xC8) - length = 1 byte Instruction byte: 0: 0xC8 XEvent (status inquiry for condition changes, like e.g. S88, programming of etc.) Answer: List of bit fields (8-bit), in each case the MSB indicates whether still another further bit field follows: Byte 1: Bit 7: Extension bit, if = 1, still further byte in answer. Bit 6: reserved Bit 5: TRNT 1: there was at least a yielding Event Bit 4: Tres 1: there was at least one access on a reserved switch Bit 3: PWR 1: there was at least a Power off Event (*) Bit 2: S88 1: there was at least a s88-Event (*) Bit 1: GO 1: there was an IR-event Bit 0: LOK 1: there was at least an access up a locomotive Byte 2: Bit 7: Extension bit, if = 1, still further byte in answer.. Bit 6: Sts: 1: change in the status Bit 5: Hot 1: Temperature indication Bit 4: PTsh 1: End of the programming track to Main track Bit 3: RSsh 1: end on the programming track or on the booster connection Bit 2: IntSh 1: Short-circuit internally Bit 1: LMSh 1: Short-circuit on the locomotive mouse connection Bit 0: LOK 1: Short circuit message of an external Boosters Byte 3: Bit 7: Extension bit, if = 1, still further byte in answer.. Bit 6: reserved Bit 5: reserved Bit 4: ExVlt 1: External voltage available Bit 3: TkRel 1: transfert of a locomotive by others CONTROLLER Bit 2: Mem 1: MEMORY Event Bit 1: RSOF 1: RS232 OVERFLOW Bit 0: LOK 1: Programming TRACK Event (*) Note: OpenDCC supplies status bit only with marked (*). " XEvtLok (0xC9) - length = 1 byte Answer: 0x80 Note: not supported by OpenDCC. " XXEvtTrnt (0xCA) - length = 1 byte Answer: 0x00 Note: not supported by OpenDCC. This may be used in some cases for the feedback of switches not switching. " XEvtSen (0xCB) - length = 1 byte Instruction byte: 0: 0xCB XEvtSen (inquiry sensor Events) Answer: List from maximally 128 entries, every Entry is developed as follows: 1. Byte: if 0: this is the last list entry. if! 0: s88 module number (1..128) (Module = 16 bits) 2. Byte of contacts 1..8 of this module (bit 7..0) 3. Byte of contacts 9..16 of this module (bit 15. .8) A S88-Event being present is announced with XEvent; It is possible for an Event to be announced, while S88 does not change, because in the meantime it is already again reset. During the reading the CHANGE flags become taken back, no module is twice announced. (@modeltreno: who actually perpetrated this bit arrangement?) " XEvtPT (0xCE) - length = 1 byte Instruction byte: 0: 0xCE XEvtPT (inquiry of programming results) Answer: 1. Byte: if 0xF5: not yet finished, there is nothing to announce if [1,2,3,4,6] number of the subsequent bytes 2. Byte status of the Programming task 0x00 COMMAND completed, NO error 0xFF Timeout 0xFE NO acknowledge from decoders (but A write maybe was successful) 0xFD Short! (on the PT) 0xFC NO decoder detected 0xFB generic error 0xFA error during DCC direct bit mode operation 0xF9 NO acknowledge to paged operation (paged r/w not supported?) 0xF8 error during Selectrix READ 0xF7 Ok (direct bit read mode is (probably) supported) 0xF6 XPT_DCCQD: Not Ok (direct bit read mode is (probably) not supported) 0xF4 task terminated (see XPT_Term cmd) 0xF3 NO task to terminate (see XPT_Term cmd) 0xF2 Cannot terminate task (see XPT_Term cmd) 3. Byte (only if announced by the 1st byte) First result of the programming task, this can be: - contents registers or CV (DCC READ cmds); - low byte of a long address (DCC long addr read cmd); 4. Byte (only if announced by the 1st byte) Second result of the programming task, this can be: - high byte of a long address (DCC long addr read cmd); " XDCC_PDR (0xDA) - length = 1+4 bytes Instruction byte: 0: 0xDA XDCC_PDR (= locomotive programming on the maintrack = POM, CV-reading) 1: LSB of the locomotive address 2: MSB of the locomotive address (1-10239) 3: Low byte of the CV-address, which is to be read. 4: High byte of the CV-address, which is to be read. (1..1024) Answer: 0 = ok, accepted. 0x80 = busy, COMMANDs ignored The response is transferred over XEvtPT With POM programming instructions can be transmitted at the main track. Provisionally still no reading is possible by POM - NMRA BiDi has not yet OpenDCC. " XDCC_PAR (0xDB) - length = 1+4 bytes Instruction byte: 0: 0xDB XDCC_PAR (= Accessory programming up the Maintrack = POM, CV-reading) 1: LSB of the accessory address 2: MSB of the accessory address (1-510) 3: Low byte of the CV-address, which is to be written. 4: High byte of the CV-address, which is to be written (1..1024) Answer: 0 = ok, accepted 0x80 = busy, COMMANDs ignored The response is transferred over XEvtPT Under address the decoder address is meant here, not the switch address! With POM programming instructions can be transmitted at the main track. Still no reading is possible by POM - NMRA BiDi has not yet OpenDCC. " XPT_DCCEWr (0xDC) - length = 1+4 bytes Answer: 0x00 Producing and writing a speed characteristic. Note: not (still).supported by OpenDCC. " XDCC_PD (0xDE) - length = 1+5 bytes Instruction byte: 0: 0xDE XDCC_PD (= locomotive programming on the Maintrack = POM) 1: LSB of the locomotive address 2: MSB of the locomotive address (1-10239) 3: Low byte of the CV-address, which is to be written. 4: High byte of the CV-address, which is to be written. (1..1024) 5: Value Answer: 0 = ok, accepted 0x80 = busy, COMMANDs ignored With POM programming instructions can be transmitted at the main track. They are not acknowledged. Still no reading is possible by POM - NMRA BiDi has, not yet OpenDCC. " XDCC_Pa (0xDF) - length = 1+5 bytes Instruction byte: 0:0 xDF XDCC_PA (= Accessory programming on the Maintrack = POM) 1: LSB of the accessory address 2: MSB of the accessory address (1-510) 3: Low byte of the CV-address, which is to be written 4: High byte of the CV-address, which is to be written (1..1024) 5: Value Answer: 0 = ok, accepted 0x80 = busy, COMMANDs ignored Under address the decoder address is meant here, not the switch address! With POM programming instructions can be transmitted at the main track. They are not acknowledged. Still no reading is possible by POM - NMRA BiDi has, not yet OpenDCC. " XPT_Sts (0xE0) - length = 1 byte Instruction byte: 0: 0xE0 XPT_Sts (= query status of the Programming routine) Answer: two bytes, as follows codes; Byte 1: bit# 7 6 5 4 3 2 1 0 Evt X X X X X X Rel Mode Evt: 0 = no PT event is pending 1 = a PT event is pending Rel: 0 = PT relay is off 1 = PT relay is on (always in OpenDCC mode) Mode: 0 = PT in' PT only' mode 1 = PT in' auto' mode Byte: 2 0 = There is no programming routine 1 = just what runs " XPT_on (0xE1) - length = 1 byte Instruction byte: 0: 0xE1 XPT_On (= programming mode) Answer: 0 = ok, accepted " XPT_off (0xE2) - length = 1 byte Instruction byte: 0: 0xE2 XPT_Off (= leaving programming mode) Answer: 0 = ok, accepted OpenDCC connected after this command on RUN OFF i.e. Maintrack is selected, but still switched off. " XPT_DCCSr (0xEA) - length = 1 byte Search for address of a DCC decoder (decoders which are not 'readable', e.g. Roco/Lenz digital crane) - not supported by OpenDCC " XPT_DCCQA (0xEB) - length = 1 byte Read address using obsolete "Address Query" packet (can only report 7-bit addresses in range 1..111) - not supported by OpenDCC " XPT_DCCRR (0xEC) - length = 1+2 bytes 0: 0xEC XPT_DCCRR (= reading in the Register mode of instruction) 1: Register, which is to be read (1..8). 2: 0 Answer: 0 = ok, accepted " XPT_DCCWR (0xED) - length = 1+3 bytes Instruction byte: 0: 0xED XPT_DCCWR (= writing in the register mode of instruction) 1: Register, which is to be written (1..8). 2: 0 3: the contents of Which can be written (0..255), Answer: 0 = ok, accepted " XPT_DCCRP (0xEE) - length = 1+2 bytes Instruction byte: 0: 0xEE XPT_DCCRP (= reading in the Register mode of instruction and Pages) 1: Low byte of the CV-address, which is to be read. 2: High byte of the CV-address, which is to be read. (1..1024) Answer: 0 = ok, accepted With the Paged mode, register 6 will be described first with a selection address. This selection address selects a "memory page" (= PAGE) in the decoder. This is then inserted in place of registers 1-4. Then on this registers one makes the actual read or write operation. This is not really fast; therefore it is better to use the following direct instruction. " XPT_DCCWR (0xEF) - length = 1+3 bytes Instruction byte: 0: 0xEF XPT_DCCWP (= writing in the register mode of instruction and Pages) 1: Low byte of the CV-address, which is to be written. 2: High byte of the CV-address, which is to be written. (1..1024) 3: contents Which can be written (0..255), Answer: 0 = ok, accepted " XPT_DCCRD (0xF0) - length = 1+2 bytes Instruction byte: 0: 0xF0 XPT_DCCRD (= reading in Direct mode) 1: Low byte of the CV-address, which too read is. 2: High byte of the CV-address, which too read is. (1..1024) Answer: 0 = ok, accepted This instruction selects the CV from the locomotive with the help of the DCC direct READ command. With this command, the DCC locomotive will simply be asked whether the CV has the specified content. Thus the central station must normally search in sequence, until a data is found. To accelerate this, there is the following special feature of the direct reading of a byte by DCC: Open DCC tests beforehand whether the decoder controls bit operations. " If so, the byte is read with the bit instructions and then still cross-checked. " Case no, is looked up conventionally with a search cycle over all 256 possible states. Open DCC notes for 500ms whether the decoder can achieve bit operations. If within these 500ms a further read instruction is executed, then automatically the renewed check is allotted to bit ability. " XPT_DCCWD (0xF1) - length = 1+3 bytes Instruction byte: 0: 0xF1 XPT_DCCWD (= writting in the Direct mode) 1: Low byte of the CV-address, which is to be written. 2: High byte of the CV-address which is to be written. (1..1024) 3: contents Which can be written (0..255), Answer: 0 = ok, accepted " XPT_DCCRB (0xF2) - length = 1+2 bytes Instruction byte: 0: 0xF2 XPT_DCCRB (= reading in the Bit mode) 1: Low byte of the CV-address, which is to be read. 2: High byte of the CV-address which is to be read. (1..1024) Answer: 0 = ok, accepted This instruction selects the CV from the locomotive with the help of the DCC bit READ command. Although this is a bit instruction, the whole CV-byte is picked out, which the host must actually filter. From reading the implemented methods is the fastest, since only 8 hits are required plus one control access. " XPT_DCCWB (0xF3) - length = 1+3 bytes Instruction byte: 0: 0xF1 XPT_DCCWD (= single bit writing with the bit mode) 1: Low byte of the CV-address, which is to be written. 2: High byte of the CV-address, which is to be written. (1..1024) 3: Bit position (0..7) (on three bit in the byte) 3: The content to be written (0|1) (last bit of the byte) Answer: 0 = ok, accepted " XPT_DCCQD (0xF4) - length = 1 byte Instruction byte: 0: 0xF4 XPT_DCCQD (= query whether that Decoder can do single bit) Answer: 0 = ok, accepted " XPT_DCCRL (0xF5) - length = 1 byte Instruction byte: 0: 0xF5 XPT_DCCRL (= query long address) Answer: 0 = ok, accepted The long address is stored and particularly coded into CV17 and CV18. In the CV-overview there is a calculator for that. " XPT_DCCWL (0xF6) - length = 1+2 bytes Instruction byte: 0: 0xF6 XPT_DCCWL (= writting long address) 1: Low byte of the long address. 2: High byte of the long address. Answer: 0 = ok, accepted Automatically also the bit 5 in CV29 is written; this bit switched on the long address active. The decoder must control bit mode. " XPT_DCCRA (0xF7) - length = 1 byte Instruction byte: 0: 0xF7 XPT_DCCRA (= query long address, Accessory decoder) Answer: 0 = ok, accepted The long address is put down and particularly coded into CV513 and CV521. In the CV-overview is a calculator for it. This instruction is not yet implemented!!! " XPT_DCCWA (0xF8) - length = 1+2 bytes Instruction byte: 0: 0xF6 XPT_DCCWA (= writing long address, Accessory decoder) 1: Low byte of the long address. 2: High byte of the long address. (0..511) Answer: 0 = ok, accepted This instruction is not implemented yet!!! " XPT_term (0xFE) - length = 1 byte Instruction byte: 0: 0xFE XPT_Term (= terminating the current Task of programming (abort)) Answer: 0 = ok, accepted and terminated 0xF3 = NO task is active 1.1.6 Configuration and firmware update: " Configuration There is a set of parameter, which changes the behaviour of OpenDCC. These are stored permanently in the EEPROM. " Firmware update Simply at the start of the equipment keep up the stop key pressed and then with the appropriate tools import the firmware (chapter 3.7 on page 103). This instruction selects the CV from the locomotive with the help of the DCC direct READ command. With this command, the DCC locomotive will simply be asked whether the CV has the specified content. Thus the central station must normally search in sequence, until a data is found. To accelerate this, there is the following special feature of the direct reading of a byte by DCC: Open DCC tests beforehand whether the decoder controls bit operations. If so, the byte is read with the bit instructions and then still cross-checked. Case no, is looked up conventionally with a search cycle over all 256 possible states. Open DCC notes for 500ms whether the decoder can achieve bit operations. If within these 500ms a further read instruction is executed, then automatically the renewed check is allotted to bit ability.