There are two areas of DCC you need to know: how to wire the layout; and how to use the controllers. Consequently, most web pages about DCC miss the bit in the middle, the nuts and bolts of getting a message from the controller to the train.
This, then, is everything about DCC you really do not need to know.
Preamble
DCC or DC
Direct Control, or DC, is the traditional way to control a loco. It is conceptually very simple. You apply a voltage to the track, and the loco on the track goes. Increase the voltage to go faster, reverse the polarity to reverse the loco. This goes back to three-rail systems at the start of the twentieth century.
However, as soon as you add more locos to the system it gets more complicated because you need systems to ensure one loco is moving and another it not.
DC layouts have the complications in the track wiring.
Digital Command Control, or DCC, is the modern way to control locos. The track is always live, and at a slightly higher voltage. Your controller sends signals through the rails to a chip – the decoder – in the locos. If the loco decoder recognises the code as applying to it, it adjusts the speed of the loco as required. The decoder can also change lights and can also provide sound – though that makes it much more expensive.
Digital control systems first appeared in the late seventies, but the current DCC dates from the mid-nineties, and has had a few updates since then. Given how fast computers have developed since then, it is quite a dated system, but it is unlikely to be replaced for many years.
DCC layouts are significantly easier to wire as everything is connected to the same two wires – though points, cross-overs and return loops need some extra consideration.
DCC layouts have the complications in the programming of the decoder.
A Note About Volatile and Non-volatile Memory
Decoders have two types of memory. Volatile memory is lost when there is no power, and is used to hold speed, direction of travel and transitory values like that.
Non-volatile memory is retained when the decoder is not powered, and includes the address, sound data, inertia.
How Does DCC Work?
DCC works by broadcasting messages. The command unit sends any message from a controller out across the entire layout, to be received by every connected decoder. Each decoder will then decide if the message is for it, and if it is, react accordingly. Thus, a message is seemingly targeted to a specific loco. Note than there is no feedback from the loco that it has received the right message.
When looking at how something like this works, it can be useful to consider it in layers, where we zoom in to see a lower layer with more details, or zoom out to see a higher layer to see the bigger picture. This is analogous to maps, where you might zoom into a street plan to see the road names, and zoom out to see the motorway network. These layers are my perspective on it, and not official names.
The Physical Layer
This is how things are wired, and outside the scope of this article. This is an area where there is plenty to be found on-line.
The Electrical Layer
At thiis level we are looking at the hardware, the voltages.
The NMRA standard indicates 12 volts to be used for N gauge and smaller; 15 volts for HO, OO and O; and 18 volts for larger scales. However, quite a range is permissible, from 8.5 volts to 22 volts for O and smaller.
The voltage is supplied as a square-wave AC. That means that it flips polarity several times a second, and it does so abruptly, rather than the smooth sinusoidal wave of mains AC. It can, therefore, be rectified to smooth DC easily. An implication of this is that a standard multimeter will not give an accurate reading for the voltage, as it will assume a sinusoidal wave.
DCC is digital – everything is sent as a series of ones and zeros. A single bit is represented by a flip to one polarity, and a flip to the reverse polarity. Whether the bit is a one or a zero is determined by the timing. This is known as Pulse Width Modulation (PWM), and is quite different to most systems sending binary data, which work on one and zero being high and low voltage.
To signify a value of one, the voltage must be positive for 58 μs, and then negative for the same time (within limits). For a zero, the two times must be greater than 100 μs, but can be significantly longer, and need not be the same. So-called “zero stretching” can allow a DC loco to run on DCC track (however, the current will still be significantly higher and so there is a risk of burning out the motor).
Each one or zero is a “bit” of data, and these are combined to make up a message.
I would guess there is some error checking in this layer in that both halves of your ones and zeroes have to conform to the required times; if they do not the whole packet will be rejected. However, I have not seen this written down anywhere.
The Byte Layer
Messages are sent in packets, which are made up of bytes with additional bits too.
Preamble
The first part of a packet is the preamble, and is a sequence of one-bits. Command centres must transmit at least 14 one-bits to signal the start of a message. Decoders, meanwhile, must ignore any sequence that starts with less than 10 1-bits, and must not expect more than 12.
This is (I assume) to address issues with messages getting partially missed. When you put a loco on the track, it may be that the command centre is part way through sending a message; the decoder must ignore that. It will see a sequence of ones and zeroes, and just ignore that until it sees at least 10 ones in a row.
There is also a potential issue that it will not know if a bit will start positive or negative, as this will depend on which way the loco is on the track. A long series of ones followed by a zero will allow it to decide.
Bytes
A byte is a sequence of eight bits, and is proceeded by a zero-bit. The eight bits represent a number from 0 to 255. See the appendix for a quick introduction to binary.
The first standard, in 2004, allowed only one byte in each section (mostly), a total of three bytes per packet. The extended standard, 2012, allows up to six bytes.
The end of a packet is marked by a one-bit.
A packet might look like this, with the preamble, three bytes (the first two representing the number 8, the third representing 0), each with a zero before it, and a 1 at the end.
111111111111 0 00001000 0 00001000 0 00000000 1
The spaces are just for our benefit; there are no actual gaps in the data sent.
Note that the standard tries to pack as much data as possible in as few bits as possible, so sometimes a number is split across bytes, and a bit set in one place can radically change the mean of bits in another.
The Packet Layer
Packets are sent multiple times. The standard says “Packets sent to Digital Decoders should be repeated as frequently as possible” – what that actually means is unclear.
The packet is composed of three parts; the address (one or two bytes), the instruction (one to three bytes) and the error detection (one byte).
Address byte
This is one or two bytes that signify the loco the packet is for. A decoder will simply ignore any packet that is not addressed to it.
Older systems used a single byte and the address can range from 1 to 127, meaning the first bit must be zero. Some systems actually limit the range to 99 presumable because it is easier to display on a controller. Other types of decoders, such as accessory decoders, use the higher number range, starting with binary 10.
The address 0 is for broadcast mode – it will be accepted by all decoders. This is useful for emergency stop, for example.
The address 255 is for idle mode – it will be ignored by all decoders. I think this is used when there are no messages to be sent; the command centre has to send something to keep the power to the rails, so sends out an idle message.
The addresses 232 to 254 (that is, starting with 11) were reserved, however…
Newer systems use two bytes, or sixteen bits, and the addresses can range from 1 to 10239. The first two bits of the first byte must be one (hence, they use the previously reserved range) and the remaining six bits must not be 111111, as that would indicate an idle instruction.
This does leave a large block of addresses that are reserved for future use.
Here are some examples:
Message to one-byte decoder at address 8 (binary 100)
0 00000100 0 xxx…
Message to two-byte decoder at address 1024 (binary 100 0000 0000)
0 11000100 0 00000000 0 xxx…
Message to two-byte decoder at address 8 (binary 100)
0 11000000 0 00000100 0 xxx…
Consider a decoder receiving a message… If the first byte is 11111111 it can ignore the message, if it is 00000000 it must respond. Otherwise, if it starts 11 the decoder knows it is a two-byte address, and if not, it is a one-byte address.
Decoders sold on their own default to an address of 3 (decoders in locos may not).
Instruction or data
This is the command telling the decoder what to do. In the original standard, this was one byte except for a CV instruction, when it is two bytes.
In the extended standard a CV instruction can be one, two or three bytes. Speed instructions can also be longer, but in that case that might be done via a CV?
The first three bits of the first byte indicate the instruction type. The remaining five bits, plus the other bytes when used, give the data. Note that decoders for accessories (which have a specific address range) use a different set of instruction types, as, for example, they do not need direction and speed control.
I am not going through all the instruction types, but 010 and 011 are interesting as they control speed in reverse and forward respectively. The data is the speed, which is therefore 5 bits, and so ranges from 0 to 15. A value of 0 indicates stop, while 1 indicates emergency stop (ignoring inertia), so there are 14 speed settings by default. Decoders can try to add more; if you are at speed 8, an instruction to go faster could take the loco to 8.5, rather than 9.
The standard allows decoders to ignore a change of direction when the loco is not stationary.
The other important instruction type is 111, Configuration Variable Access Instruction. This is used to set various values in the decoder. This leaves five bits for the instruction, with the data in an additional byte or two. It appears that using a single extra byte is only of limited use.
The long version looks like this.
0 1110CCVV 0 VVVVVVVV 0 DDDDDDDD
So the first three bits indicate this is a Configuration Variable Access Instruction, the next, 0, indicates this is the long form. The fifth and sixth bits, CC, indicate if the mode is verify (01), write (11) or bit manipulation (10).
The bits flagged as V are combined to make a 10-bit number, indicating the CV minus 1 (people count from one, but computers count from zero, so CV1 to us is 0 in the decoder). The bits flagged as D are an 8-bit number that is assigned to the CV. Thus, to write the number 1 to CV1
0 11101100 0 00000000 0 00000001
Bit manipulation allows you to set a single bit, rather than the entire byte, and uses a special data type for the second byte:
111CDBBB
C is 1 to indicate write or 0 to indicate verify. D is the value to set or check, and BBB indicate the bit number. It seems likely the bits are number from 0 on the right to 15 on the left, but the standard does not specify.
Error detection byte
The address bytes and data bytes are used to determine a check value by XORing them all. If not valid, the message is rejected. See the appendix for more details.
Packet end bit
A single one-bit, which could be part of the next preamble.
There is a requirement for an additional 26 μs; not sure what that is.
There is an implication that the command centre sends one-bits when nothing is happening.
The packet
How long is a packet? It depends, but we can take an estimate…
The packet contains up to six bytes, each of which could be up to 9x 200 μsincluding the starting zero-bit, giving 10800 μs, and at least 14 one-bits of 116 μs in the preamble (the end bit could be part of the next preamble so is not included), adding 1624 μs. It is probably fair to say that messages are around 10 ms long, or about 100 per second.
The Data Layer
The data layer we are concerned with what each packet actually means. The is fairly well documented elsewhere.
Service Mode
Service mode is a special mode used to send extra instructions to the loco, including settings its address. This therefore needs a special arrangement to ensure the message goes to the right decoder, which is usually achieved by sending to an isolated second of track that has only the one decoder on it.
The track is usually supplied with lower voltage so less damage is done if a mistake is made. There is also limited communication back from the loco, which is achieved by briefly starting it moving, which is detected as a rise in the current.
The decoder will act differently in service mode, so will try to decide if it is in service mode based on the commands it receives. For example, it will require two service mode messages with no other intervening messages to enter service mode, to ensure the first was not an error.
Appendix: Binary
We count in base ten – there are ten digits, from 0 to 9. When you count upwards, after nine, you go back to zero in the units and add one to the tens. After ninety-nine, you go back to zero in the units, add one to the tens, which in turn sets the tens back to zero, and adds one to the hundreds.
1 2 ... 9 10 11 ... 99 100 101
In base ten each column represents a power of ten, of the first column from the right is units, the second is tens, then third is hundreds and so on.
Electronics, including computers, count in base 2, also known as binary. In binary, there are only two digits, 0 and 1 (because a switch is either on or off), and you add one to the previous column when you get to two (the number in brackets is the base 10 number).
1 (1) 10 (2) 11 (3) 100 (4) 101 (5)
In base two, each column represents a power of two, of the first column from the right is units, the second is twos, then third is fours and so on.
Consider the number 11010 in binary; what is that in base ten? Start from the right…
0 x 1 1 x 2 0 x 4 1 x 8 1 x 16 = 26
Consider the number 39 in base ten; what is that in binary? The highest power of two it contains is 32, so we need one of them. That leaves 7. The next power of two is 16, which is too high, the next is 8, again too, high. The next is 4, which is less than 7, so we do have a for.
32 <= 39, so we have a 1, with 7 (39-32) left over 16 > 7, so we have a 0, with 7 still 8 > 7, so we have a 0, with 7 still 4 <= 7, so we have a 1, with 3 (7 - 4) left over 2 <= 3, so we have a 1, with 1 (3 - 2) left over 1 <= 1, so we have a 1, with 0 (1 - 1) ^ ^ | | This is our answer, 100111 | | These are the powers of two
Bitwise operations
The error checking uses a operation called XOR. This is a bitwise operation, which means you compare each bit (binary digit) in isolation to the other bits in the number.
Consider adding 1 and 1 in binary. Addition is not bitwise; when we add the units, we get 1 + 1 = 10; the result is affecting the adjacent column – just as adding 7 and 5 will change the tens as well as the units in base ten.
The AND operation works bitwise. A bit in the answer is 1 if the corresponding bit is also 1 in both the original numbers. In the example below the first digit is 1 for both of the original numbers, so is one in the answer. The last digit, however, is 1 in the first and 0 in the second, so in the answer, the last digit is 0.
11001001 AND 11011100 -------- 11001000
The XOR operation
XOR is short for eXclusive OR, which means the bit in the answer is 1 if either the bit is one in the first number OR is 1 in the second number, but eXcluding if it is 1 for both of them. To put it another way, it is 1 if they are different, or 0 if they are the same.
11001001 XOR 11011100 -------- 00010101
With more inputs, you work out the result for the first two, then use that with the next, and the next. Alternatively, you can count how many ones are in the position. If the answer is an odd number, the result is one, otherwise zero. So below, for example, first bit for all three is one so we have three ones, three is an odd number so this gives a one in the result below.
Three bytes XOR
11001100 11100001 10011111 -------- 10110010
When error checking, the DCC decoder looks at all the bytes, including the check value. Suppose it was sent the previous three bytes plus the check value. It does the XOR operation on the whole lot. If the result is zero, the message is good.
Three bytes plus check value XOR
11001100 11100001 10011111 10110010 -------- 00000000
It is as simple as that!
Hexadecimal (base 16)
So we have learn about base 2, we might as well do base 16 as well. Base 16 needs 16 different digits, and letters are used for the extra ones, so A is used for ten, B for eleven, and so on.
Numbers in parenthesis are the base 10.
1 (1) 2 (2) ... 9 (9) A (10) B (11) C (12) D (13) E (14) F (15) 10 (16) 11 (17) ... 19 (25) 1A (26) ... 1F (31) 20 (32) 21 (33) ... 9F (159) A0 (160) A1 (161) ... FF (255) 100 (256) 101 (257)
Electronics use base 2 and people use base 10; base 16 is kind of compromise between the two. It is easy to convert between base 2 and base 16, because 16 is 10000 in base 2, but base 16 is easier for people to use than long strings of 1s and 0s.
To convert from binary to hexadecimal, break the number up into groups of four from the right, and then you can do each block in isolation.
11 0010 1011
->
11 3
0010 2
1011 B (11)
-> 32B
You will often find a symbol at the start of a hexadecimal number to flag it as such. This could be any of:
# (common on web pages) 0x (common in programming languages) $ (common in DCC)
Reserved addresses for 2-byte addresses
Two-byte addresses can range from 1 to 10239. Where does that number come from?
I am going to work in hexadecimal here, as I think it will be easy to understand how the bits are divided up. In hexadecimal the numbers range from $1 to $27FF.
The actual number stored is higher, as the first two bits must be set – the binary number has to start 11. This mean the actual range is $C000 higher than that, from $C001 to $E7FF.
Note that adding 1100 0000 0000 0000 ($C000) to a hexadecimal number only changed the first digit.
$27FF +$C000 ----- $E7FFF
This is why we are using hexadecimal.
That leaves three address ranges.
$E800 to $EFFF (addresses that start 11101) $F000 to $FFFE (addresses that start with 1111) $FFFF (the idle command)
I am not aware of any actual future plans, but this system does allow for 3-byte addresses to be implemented in the future, allowing you to have over a million 1,000,000 locos! Or perhaps each member of a club could have their own 4-digit number, and up to 1000 locos, which does seem a little more plausible.
So that accounts for $F000 to $FFFE, what of $E800 to $EFFF? I wonder if the current system was designed to give just over 10,000 addresses, which can be done as a four figure number, and they decided that was enough, so saved $E800 to $EFFF just because it seemed unlikely manufacturers would use it.
It is worth noting that the NMRA are promoting a second standard, called LCC, that is quite different to DCC (as it takes advantage of recent technology and experience), and is designed to control the layout (points, signals, etc.), rather than locos, in part because the DCC bus is getting overloaded. Speculating somewhat, but I think it unlikely that the NMRA will use those spare addresses for anything other than locos (or other rolling stock).
Further Notes
Address ranges are also called partitions.
DCC systems can handle addresses in their own way to some degree, and while 1 to 10239 is the maximum for a 2-byte address, this is slightly reduced in some implementations, to varying amounts.