DCC Tutorial - Packets?

copyright Bob Backway 1997

Back to DCC Articles Menu
Back to ADCC home page

In the last article we learnt of the electrical properties of the Digital Command Control signal, how this signal transmits "one" and "zero" bits and how it also provides power to the locomotive. We will now discuss how these bits are combined to form a packet, the ‘envelope’ of information that carries the command message. Many people use a Post Office analogy when trying to understand packets. If you fear that this article may be over your head, don’t panic, just read along with the attitude of a systems engineer - understand each little bit, understand how they all work together but never, ever try to fit the whole system in your mind at once!

Again let’s define the buzz words before we jump in:

Address               A unique number that identifies a DCC decoder, just like your street address identifies your mail.

Bit                       One "bit" of data which can be a binary "one" or "zero" depending on the length of a DCC signals cycle

Byte                    Eight bits of information assembled into a "word" because computers like it that way.

Data                    The message information for the decoder contained inside the packet like a letter in an envelope.

Packet                 A collection of bits and bytes placed in a defined order known by the command station and all the decoders a so that messages or ‘parcels’ may be sent and responded to.

Synchronisation  The way that a receiver(decoder) can keep in step with the information that is being sent to it.

To understand the information in the boxes a knowledge of Binary counting (we normally use Decimal) is required.

Putting the packet into perspective

A DCC decoder continually analyses the packets it receives from the track pickups looking for packets addressed to it. It is only from these packets that the decoder extracts its command information. A decoder knows when a new packet is about to arrive when it sees what is called a Preamble.. A preamble is a string of ten or more "one" bits and this is the only time a DCC signal can have ten consecutive one bits. The dogs start barking.

At the end of the preamble is a "zero" bit called the Packet Start Bit which indicates that the next 8 bit byte is an address data byte, the first byte of the packet. The postie whistles.

The Address Data Byte contains the address of the decoder that the packet instruction is intended for. Some addresses are special and they will be discussed later in the article. The address values are divided into partitions for operating different devices and for using different packet formats. If a decoder finds that the address is not the one it has been assigned it ignores the entire packet. Check that it's addressed to you.

Referring to diagram 1 the start bit is always a zero and is not part of the data byte. The left most bit is the first bit transmitted and the bits are shown as transmitted from left to right. Bit seven of the byte is transmitted first, then six and so on to zero. Bit seven is called the Most Significant Bit (MSB) because it has the greatest decimal value of 128. Bit zero is the Least Significant Bit (LSB) because it has the decimal value 1, the smallest value. Because we are counting in binary the bits 0 - 7 have the decimal values 1, 2, 4, 8, 16, 32, 64, 128 only if they are one bits. To obtain the decimal value of a byte you just add the values of the "one" bits as shown above. In this example the value is 217.

Following the address byte is a Data Byte Start bit, of value zero, which precedes the Data Byte. A Data Byte can have further address information, command instructions or data to be stored in the decoders. You read the letter and act on the contents.

In a Standard DCC packet there are at least two data bytes with some packets having five. Each Data Byte is preceded by a "zero" start bit ensuring that every ninth bit must be a zero. It can now be seen how it is easy to identify the 10 "one" bit preamble mentioned earlier.

Regardless of the number of data bytes the last byte is always an error byte. An Error Byte is used as confirmation of trouble free packet transmission. The command station generates an error byte and sends it at the end of a packet. The receiver also calculates an error byte based on the data bytes it has received and compares its local error byte with the one that the command station has sent. If they don't agree the packet is ignored. You may choose to forget about error bytes from now on but if you're curious Table 1 shows how the error byte is calculated.

Bit Number









First Byte









Second Byte









Error Byte









Table 1 Composing the Error Byte

An Error Byte is calculated using a mathematical function of the data bytes as a check against faulty transmission. This function is called an exclusive OR (XOR) meaning that the error bit can equal "one" if only one of the corressponding data bits is a one.

For example in the Bit 7 column the "1" in the first byte XOR'd with the "1" in the second byte will give a "0" in the the Error Byte. In the Bit 6 columnone bit is a "1" and the other is a "0" giving a result of "1" for the Error bit. This is also the case in bit columns 5, 3 & 0.

Observe each vertical column in the table above to see how it's done.

Using a mathematical function reduces the chances of an error byte mistakenly confirming a faulty packet to those of winning the lottery

The closest the post office has come to the sophistication of error bytes is registered mail!

After the error byte comes the Packet End Bit which is a "one" and indicates the end of the packet. As there can be up to six bytes in a packet a decoder checks this bit to determine if it is at the end of a packet or if another byte is arriving. If it finds a "zero", a data byte start bit, it knows there is more to come, if it finds a "one" it's at the end.

Baseline Packets

There are many types of packets used in a DCC system but for the moment we will only look at what are called the Baseline Packets. Compliance with these packets is mandatory in a DCC system which means that all Command Stations and Decoders must use or recognise them. There are many other optional packets and these are described in the Extended Packet and the Service Mode Recommended Practices. The optional packets will be discussed in future articles. In the packet examples given below the bit values 1 and 0 are mandatory for that type of packet whilst bit values such as A, D, E etc are alterable values for that packet which are defined in the text.

Speed & Direction Packet for Mobile Receivers

1111111111 0 0AAAAAAA 0 01DUSSSS 0 EEEEEEEE 1

Preamble Address Byte Data Byte Error Byte

The address byte contains the binary address that can be from 0 to 127depending on the value of "AAAAAAA". It is permissible for command stations to address a reduced range of addresses, some have as little as eight addresses but more commonly ninety-nine. The zero at the start of the byte allows address space for other non compulsory packets such as those for accessory control.

The data byte starts with the bits "01" again to allow space for non compulsory packets such as function control (lights, bells, couplers etc). The next bit (bit 5 labelled D) provides for direction, "1" indicates move forward, "0" reverse. Bit 4, called the "U bit", is undefined in the baseline standard and was originally used by Lenz for headlights but is now used as the least significant bit for 28 speed control.

The speed control, bits 0 - 4 and labelled SSSS, allow for sixteen values. The first, "0000", is a Stop command. Emergency stop has the value "0001" while the rest of the values from "0010" to "1111" are the speed steps 1 to 14. Hence the fourteen speeds of the baseline DCC system.

A Stop command utilises any programmed inertia whereas the Emergency Stop brings the loco to an immediate undignified halt. Lawsuits from the passengers?


Bits 3 - 0


Bits 3 - 0





Step 7




Step 8


Step 1


Step 9


Step 2


Step 10


Step 3


Step 11


Step 4


Step 12


Step 5


Step 13


Step 6


Step 14

Table 2 Speed Table for Baseline Packet

Have a go at decoding the following packet:

1111111111 0 00001011 0 01100110 0 01111101 1

The Reset Packet

1111111111 0 00000000 0 00000000 0 00000000 1

Preamble Address Byte Data Byte Error Byte

The reset packet has an address and data value of zero and thus an error byte of zero value. This easily recognised packet allows the Command Station to clear some of its previous instructions kept in what is called volatile memory. These include speed and direction data from any decoders in the section the Command Station is connected to. Upon receiving such a packet a mobile decoder must bring a moving locomotive to an immediate stop. In practice reset packets are normally only sent as part of the programming or start up procedures to clear and power a decoder prior to receipt of programming packets.

The Idle Packet

1111111111 0 1111111 0 00000000 0 11111111 1

Preamble Address Byte Data Byte Error Byte

The idle packet allows packets to be transmitted that have no address or command status. In some instances it may be necessary to keep a decoder powered, remember packets need to be continuously transmitted to provide power to the locomotives. A decoder recognises an idle packet as a valid packet that has been addressed to some other decoder.

Continuity of Packets

A Command Station ensures packets are continuously sent to the track. Even if all the operators have their hands on their heads the Command Station will be repeating the last packets it has been given. This is done for two reasons. Firstly the packets are composed of the "ones" and "zeros" in the DCC signal that also have the task of supplying power to run the locos motor and accessories. Secondly, in a DCC system packets are continually repeated just in case one gets "lost", or rejected, due to noise on the track. Typically the list of packets to send (called the transmission buffer ) in a command station is over 20 packets long. For example in a Lenz system a packet is repeated every 24 packets.

The specifications include a minimum time of 5 milliseconds between packets to allow for the decoder's microprocessor to keep up. There is also provision for other non DCC command control systems in that it is possible to only send a valid DCC packet every 30 milliseconds. This allows time for switching signals between two systems as a typical 3 byte DCC packet has a transmission time of around 6 milliseconds. I believe Trix use this method in their combined Command Station sending mixed DCC and there own packets. The Trix packets are similar to DCC the main difference being their use of a four bit byte rather than DCC's eight bit bytes.

Packet reliability

In the first tutorial I mentioned the combining of the command control and power signals (true digital transmission) to give more reliable operation. Now that packet communication has been described it can be seen that with the preamble, synchronisation start bits, a unique decoder address, the use of error bytes, the continual retransmission of packets and with the decoder storing its commands in memory the DCC protocol is a very secure system. So secure that your telephone system uses a very similar protocol to manage your calls.

This becomes evident when you forget about all this technology, pick up the DCC handset and start running trains!


Please refer to NMRA Standard S-9.2 for further information.

The answer is: Locomotive address 11 proceed forward at speed step 5. Did you check the error byte?

Back to DCC Articles Menu
Back to ADCC home page