Joined
·
10,744 Posts
I've been having a look at the NMRA standards and recommended practices (RPs) for DCC. The standards documents are very short - just 3 or 4 pages. The RPs are slightly longer, but not by much.
Here is my understanding of the situation. I am open to correction; interpreting standards is not as simple as one might think - ask any user of Bluetooth 1.0!
Standard S9.1 defines how the voltage supply is modified so that data can be transmitted to decoders. There is nothing any of us need to concern ourselves with unless we /really/ want to look at the signals on an oscilloscope.
Standard S9.2 (Communications Standards for DCC) specifies a "Baseline" packet containing 3 pieces of information:-
An Address: value 0 to 255, some of these values have "special" meanings
A data value: This can be one of four categories. The principle category is speed and direction
An error check: This is used for detecting transmission problems in the data
No other Packet type is defined by Standard S9.2.
The use of Configuration Variables (CVs) is defined in RP9.2.2. It was approved in July 2006! ??
For the purposes of this thread, only 4 CVs concern us here:-
CV1 Primary Address.
CV17, CV18: Extended Address
CV29 Configuration Register
CV1 is mandatory. The DCC value range is 1 to 127. When the value is 0, the decoder will seek some other power source if it has the ability to do so.
CV17, CV18 are optional. They are only active when configured by a setting in CV29. CV17 and CV18 work as a pair and can store a number in the range 0 to 65535. The valid range for this pair of CVs is 49,152 to 59,391 inclusive giving 10,240 valid values. Hopefully any CV programmer will hide all these offsets from you and only program valid values into the CVs.
CV29 is Configuration CV. This decides exactly how your decoder is going to respond to the instruction packets from the command station. CV29 controls up to 8 different feature responses. One of these feature responses is the address type - One byte or two byte which I believe can be paraphrased as "use CV1 or CV17/CV18"
Where they exist, all these CVs must work in the same way in all decoders.
Summary so far:
Basic packets can have an address value 0 to 255
All decoders store one address in the range 1 to 127
Extended decoders store /another/ address in the range 49,152 to 59,391
Extended decoders can be programmed to use the short or long address via CV29
Recommended Practice RP9.2.1 describes "Extended Packet Formats"
The RP begins by defining a set of "Address Partitions". What this does is take the Address value in a basic packet and give it "special" meanings. To try to keep it simple, I will only explain the two we are interested in:
First of all, addresses 0 to 127 continue to be directed to decoders using the address in CV1.
Addresses in the range 192 (192 x 256 = 49,152) to 231 are directed to decoders using address CVs 17/18 and an additional Address value (0 to 255) is inserted in the packet sent by the command station.
What does this mean for the 2 digit / 4 digit debate
![]()
Here's what I think:-
1) Extended address decoders still have a "short" address and can be configured to use it by changing an entry in CV29. This does not require the "long" address in CV17/18 to be reprogrammed.
2) "Long" addresses and "Short" addresses cannot be confused in the data packet on the rails because they have different patterns by design.
3) The command station composes the packets sent out on the rails. It is possible that entry level command stations only create "Basic packets" and so they will only be able to generate 255 different decoder addresses (and that includes accessory decoders too). On these systems CV29 MUST be set to use CV1, but remember the contents of CV17/18 remain unaffected by this change.
4) When extending addressing is used, the command station generates an address in the range 49,152 to 59,391. It is unlikely (I sincerely hope so!!) that the user interface on the command station does not say "Please pick a number between 49,152 and 59,391" instead, in conjunction with programming CV17/18 you will have chosen something more manageable and this will be translated to the correct range by the command station when it assembles the packet for transmission down the rails. This "mapping" concept can be extended to naming locomotives if the command station is given the facility for storing a simple index table.
So what do you if you are taking a 4 digit loco to visit a friend who only has 2 digit capability
![]()
I think you can proceed as follows (Disclaimer: I have NOT tried any of this) :-
1) Program your 4 digit loco CV1 with a short address which is "free" on your friends controller
2) Set your 4 digit loco CV29 to use CV1
3) Have a cracking time
4) Before adjourning for a celebratory beverage
![]()
, reprogram CV29 to use CV17/18
5) Enjoy beverage
![]()
6) Return home and rejoice that you have a "real" DCC system
Any questions
![]()
David
Here is my understanding of the situation. I am open to correction; interpreting standards is not as simple as one might think - ask any user of Bluetooth 1.0!
Standard S9.1 defines how the voltage supply is modified so that data can be transmitted to decoders. There is nothing any of us need to concern ourselves with unless we /really/ want to look at the signals on an oscilloscope.
Standard S9.2 (Communications Standards for DCC) specifies a "Baseline" packet containing 3 pieces of information:-
An Address: value 0 to 255, some of these values have "special" meanings
A data value: This can be one of four categories. The principle category is speed and direction
An error check: This is used for detecting transmission problems in the data
No other Packet type is defined by Standard S9.2.
The use of Configuration Variables (CVs) is defined in RP9.2.2. It was approved in July 2006! ??
For the purposes of this thread, only 4 CVs concern us here:-
CV1 Primary Address.
CV17, CV18: Extended Address
CV29 Configuration Register
CV1 is mandatory. The DCC value range is 1 to 127. When the value is 0, the decoder will seek some other power source if it has the ability to do so.
CV17, CV18 are optional. They are only active when configured by a setting in CV29. CV17 and CV18 work as a pair and can store a number in the range 0 to 65535. The valid range for this pair of CVs is 49,152 to 59,391 inclusive giving 10,240 valid values. Hopefully any CV programmer will hide all these offsets from you and only program valid values into the CVs.
CV29 is Configuration CV. This decides exactly how your decoder is going to respond to the instruction packets from the command station. CV29 controls up to 8 different feature responses. One of these feature responses is the address type - One byte or two byte which I believe can be paraphrased as "use CV1 or CV17/CV18"
Where they exist, all these CVs must work in the same way in all decoders.
Summary so far:
Basic packets can have an address value 0 to 255
All decoders store one address in the range 1 to 127
Extended decoders store /another/ address in the range 49,152 to 59,391
Extended decoders can be programmed to use the short or long address via CV29
Recommended Practice RP9.2.1 describes "Extended Packet Formats"
The RP begins by defining a set of "Address Partitions". What this does is take the Address value in a basic packet and give it "special" meanings. To try to keep it simple, I will only explain the two we are interested in:
First of all, addresses 0 to 127 continue to be directed to decoders using the address in CV1.
Addresses in the range 192 (192 x 256 = 49,152) to 231 are directed to decoders using address CVs 17/18 and an additional Address value (0 to 255) is inserted in the packet sent by the command station.
What does this mean for the 2 digit / 4 digit debate
Here's what I think:-
1) Extended address decoders still have a "short" address and can be configured to use it by changing an entry in CV29. This does not require the "long" address in CV17/18 to be reprogrammed.
2) "Long" addresses and "Short" addresses cannot be confused in the data packet on the rails because they have different patterns by design.
3) The command station composes the packets sent out on the rails. It is possible that entry level command stations only create "Basic packets" and so they will only be able to generate 255 different decoder addresses (and that includes accessory decoders too). On these systems CV29 MUST be set to use CV1, but remember the contents of CV17/18 remain unaffected by this change.
4) When extending addressing is used, the command station generates an address in the range 49,152 to 59,391. It is unlikely (I sincerely hope so!!) that the user interface on the command station does not say "Please pick a number between 49,152 and 59,391" instead, in conjunction with programming CV17/18 you will have chosen something more manageable and this will be translated to the correct range by the command station when it assembles the packet for transmission down the rails. This "mapping" concept can be extended to naming locomotives if the command station is given the facility for storing a simple index table.
So what do you if you are taking a 4 digit loco to visit a friend who only has 2 digit capability
I think you can proceed as follows (Disclaimer: I have NOT tried any of this) :-
1) Program your 4 digit loco CV1 with a short address which is "free" on your friends controller
2) Set your 4 digit loco CV29 to use CV1
3) Have a cracking time
4) Before adjourning for a celebratory beverage
5) Enjoy beverage
6) Return home and rejoice that you have a "real" DCC system
Any questions
David
