Contents NMRA DCC Proposals  

On this page I have collected the different proposals I made or which I try or tried to move forward to improve the NMRA DCC Recommended Practices.

Function Group Three, Topic 0501151

There have been several indications that we need to define packets to control functions F13 and above. To achieve compatibility in function control the packet has to be defined in short time frame. There are different approaches and the proposal is changing. For reference I keep the older version on line. The most current version is at the bottom of the list. Most files are in the PDF format.

Please note that this topic has been closed and replaced by topics 0504021 Function Expansion and 0504022 Binary State Control.

  • Function Group Three, V1.0 (Jan. 15 2005)
    This approach uses one data byte to control 8 functions with a single packet. However we will need further packets, if we intend to go for more than 21 functions.
  • Function Group Three, V2.0 (Feb. 5 2005)
    This approach uses the data byte to address 128 functions with one data bit defining the function state. Reserving one address as broadcast there may be up 127 functions controlled by a single packet type. However refresh of the functions is not efficient with this approach.
  • Function Group Three, V2.1 (Feb. 15 2005)
    Improved and reworded version of the above.
  • Function Group Three, V2.2 (Mar. 16 2005)
    Improved and reworded version of the above for the formal comment period.
  • Function Group Three, TN (Mar. 16 2005)
    Technical Note to go with the V2.2 proposal. This describes all the details which can't be addressed in the RP itself.

Function Expansion, Topic 0504021

As noted above this topic is the successor of the Topic 0501151 Function Group Three. Two packets controlling eight functions each (F13 to F20 and F21 to F28) are defined. These functions shall not be assumed to be refreshed.

There is also a Technical Note about the intended future assigment of sub-intructions within the Future Expansion and Advanced Operations intructions.

Please note that this topic has been accepted and closed.

Binary State Control, Topic 0504022

Additionally to the Extended Functions F13 to F28 under topic 0504021 there are up to 32767 binary states to be controlled in an addressed manner. The binary states are similar to functions, but do not overlap with the functions and will never be refreshed.

To avoid incompatibilities due to usage of F0 to F28 and the Binary State Controls for the same type of feature, I wrote a proposal for a Technical Note.

Please note that this topic has been accepted and closed.

21 Pin Connector, Topic 0504023

This connector has been defined by Märklin an ESU. It is a 22 pin connector with one pin pin removed as an index key. The intention of this proposal is to add its definition into the RPs or at least a Technical Note to have it defined in a public place. An attempt to make the pins with special meanings to be used in different ways to allow a wider acceptance has failed.

22-Pin Connector - PluX, Topic 0603242

As the 21 pin connector has been defined specifically for Märklin locomotives with brushless motors and ESU sound decoders with 100 Ohms speaker impedance, it is not accepted by several other manufacturers. This resulted in the definition of another connector of the same density. To avoid confusion, this connector uses opposite gender then the 21-pin connector. It is designed to allow the use of a subset of pins, i.e. either all 22 pins, 16 pins or only 8 pins (all numbers include the index pin). They are called PluX22, PluX16 and PluX8.

22-Pin Connector - PluX, Topic 0603242

While discussing the proposals for the 21 pin and PluX connectors the question was raised, how long the older connectors should stay in the RPs. The following proposal was written to have a practical solution to be voted on by the working group. This topic was not approved. However, there may be a second go in some years time when the new connectors are in wide use.

Other proposals


Valid HTML 4.0!