Understanding Configuration Variables (CVs) is not that complicated. Here is my attempt at an explanation.
From the beginning
Let’s first remember how DCC started and what it is.
DCC is actually based on a digital system that had already been designed by Lenz in Germany. The system was selected and improved, before being adopted by the American NMRA (more here).
In analog (DC) trains, things were simple. More power on the track, more speed for the trains. All locomotives react together. Same principle as a light bulb behind a dimmer switch.
In DCC (as in all digital systems actually), the power is always on. The decoders in the locomotives draw power from the track, and analyze the embedded DCC signal to know what to do (light on, run at speed X…).
Each locomotive equipped with a decoder becomes intelligent. It can respond to instructions individually, with many other locomotives on the same track.
The CVs, or Configuration Variables, are quite simply the configuration information of the decoder. Editing CVs means changing the configuration of the decoder: what is the locomotive address, what are the functions…
There are many CVs and they are all numbered. What those CVs do depends on many things.
- Some of them are standardized, for example CV#1 will always contain the short locomotive address.
- Others are supposed to be standardized, but many manufacturers don’t respect that, and use them for other purposes.
- Finally, a full range of CVs are explicitly left free, for the manufacturers to use for their decoder configuration.
Bits, bytes and the stories they tell
Dissecting a CV
What is a CV really? Firstly, from the “human” point of view: it is a numbered “information slot”. Simple enough right? Not for long…
A CV is really a computer byte (with a “Y”), which means it is 8 bits (with an “I”).
A bit is a simple 0 or 1 information (and more poetically, the cornerstone of our modern society…). Why a byte contains 8 bits is a long story, see wikipedia.
Last point, quite important for advanced locomotive decoder programming: bits in the bytes (and in CVs) are numbered from right to left. This is logical, we do the same in our regular decimal numbers (e.g. “2” is the unit in the number “12”).
Less intuitive, the first bit is called bit number 0, meaning the last on the left is bit number 7.
So, here is our first CV:
Counting in binary…but just for enough for trains
The point of this article is not to explain the binary system. But we need to understand its basics.
Each of the bit corresponds to a value in decimal (this is a shortcut that will shock engineers, but it’s good enough).
So, here is how our CV (or byte) looks like, when we try to convert it to decimal:
Each higher bit (that is, more to the left) has double the value of the previous one. That’s easy.
So, now we can calculate the maximum value of a CV. We just need to sum up the different bits in decimal:
0 0 0 0 0 0 0 0 = 0
0 0 0 0 0 0 0 1 = 1
0 0 0 0 0 0 1 1 = 1 + 2 = 3
0 0 0 0 0 1 1 1 = 1 + 2 + 4 = 7
0 0 0 0 1 1 1 1 = 1 + 2 + 4 + 8 = 15
0 0 0 1 1 1 1 1 = 1 + 2 + 4 + 8 + 16 = 31
0 0 1 1 1 1 1 1 = 1 + 2 + 4 + 8 + 16 + 32 = 63
0 1 1 1 1 1 1 1 = 1 + 2 + 4 + 8 + 16 + 32 + 64 = 127
1 1 1 1 1 1 1 1 = 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = 255
So, here we are: a CV value cannot be superior to 255. This is why for example, if you want a locomotive with a long address (e.g. 434), you can’t rely on a single CV.
Of course, by varying all the 0s and 1s here, a CV can take any value between 0 and 255. That means 256 possibilities, a number you may have already encountered in the computer world (binary for trains is also binary for the rest of the world).
The wonders of CVs
Now, of course, it would be easy to think that 1 CV = one information. Unfortunately, since DCC is quite old, it’s not the case. If you’ve programmed some decoders and advanced functions (lighting options for example), you know that.
CVs (bytes) are an old construct, so in DCC, they can be used to:
- Store a unique configuration item
Example: short address (1-127) in CV#1
If you wonder why 127 and not 255, that’s because the use of the last bit – bit 7 – is forbidden by the DCC norm (In the Motorola digital system for example, CV#1 can use all bits and the address can be up to 255).
- Store part of a configuration item, larger than 255
Example: long DCC address in CVs 17 & 18.
- Store many configuration items
Example: CV29 which sets the orientation of the locomotive, whether or not it has a long or short address…
We just had to accept the sad fact that a CV can only contain numbers up to 255. But why, God, why also store many configuration items in one CV? Why not have one clean CV for each configuration item?
I haven’t looked up the details. Suffice to say, the lack of space in computer systems more than 10 years ago probably is a big part of the explanation.
That brings us to the next part, more related to our little trains.
Decoder programming hell
CVs with many configuration options
I don’t know about you, I was raised with the decimal system. Counting in binary is not something I do naturally.
Decoders Manufacturers know that, so they often try to makes things as easy as possible…within the limits of the DCC norm, and the space reserved in the CVs.
If you need to program a value in a CV reserved for that function (CV with unique function), then it’s no problem. Say the dimming of a light can be between 0 and 255. You just tell your command station to store the right value in the indicated CV.
But it gets messy when a CV contains many configuration options.
CV number 29 is a good example (because the DCC standard defines it so).
Let’s review how the manual of the decoder might look like:
- 0 = Standard orientation
- 1 = Reversed orientation
- 0 = Respond to short address as defined in CV#1
- 128 = Respond to long address as defined in CV#17 & CV#18
Most manuals are clear about what to do: sum up all the desired options, and this will be your final CV value. In the above (simplified) example:
- CV = 0 : Standard direction, Short address
- CV = 1 : Reversed direction, Short address
- CV = 128 : Standard direction, Long address
- CV = 128 + 1 = 129 : Reversed direction, Long address
In the above example, the decoder manufacturer was nice: he talks in decimal, we just need to sum up the values, and inject the total in the CV.
But sometimes, the manual uses computer trash talk, such as:
To activate lights only at stand-still, set bit 6 of CV#99 to high.
Let’s not panic. Setting a bit to “high” means setting it to 1, setting it to low logically means 0.
What we want to do is to go from a CV#99 that looks like that:
X 0 X X X X X X
(“X” indicates the other bits, that may be equal to 0 or 1)
X 1 X X X X X X
All central stations allow programming of CVs in decimal mode (“inject 234 in CV#99”), but only some of them allow you to play with the bits in a graphical manner. If you don’t have such a Command Station (for example the ESU EcoS II, or a PC Programmer), you need to convert this bit language into a decimal value, so you can inject this decimal value in the CV.
So in the above case, with a simple Command Station, what would we do? Easy. Let’s remember the values of all our individual bits in decimal. Bit number 6 means 64, so 64 is the magic number to activate the lights at stand-still.
But we don’t want to erase CV#99 (by setting it to 64). Very often indeed, its other bits (the bits marked with “X” above) may contain information about other options (which means the current value of CV#99 would already be something else than 0).
So we’ll read the current decimal value of CV#99.
In our case, let’s suppose CV#99 already is equal to “3” :
0 0 0 0 0 0 1 1
We’ll then inject 64 + 3 = 67 in our CV#99.
67 looks like that:
0 1 0 0 0 0 1 1
As you can see, we have kept the current settings (bits 0 and 1 are still “high”), and added our new option (bit 6 is now high).
You are now officially a programming pro !
I was myself very happy when I finally understood this high/low bit stories…
Reverse engineering a CV value
Now, if you get the above, you might wonder: how do I “decode” the current value of a CV?
Because of the nature of the binary system, one decimal CV value (up to 255) corresponds to a unique combination of the 8 bits.
So let’s say you want to analyze a given CV for a locomotive, you had forgotten which options you had chosen for it. Suppose it reads: 98.
The best way to do that is to memorize once and for all the possible bits values (128, 64, 32, 16, 8, 4, 2, 1). Then in your head, you can, in a few seconds, decompose this CV. Just try to make subtractions, starting from 128:
- Can I subtract 128 from it? No, so bit 7 is low. Keep 98.
- Can I subtract 64 from 98? Yes, so bit 6 is high. Keep 98 – 64 = 34
- Can I subtract 32 from 34? Yes, so bit 5 is high. Keep 34 – 32 = 2.
- Can I subtract 16 from 2? No, so bit 4 is low. Keep 2.
- Can I subtract 8 from 2? No, so bit 3 is low. Keep 2.
- Can I subtract 4 from 2? No, so bit 2 is low. Keep 2.
- Can I subtract 2 from 2? Yes, so bit 1 is high. Keep 2 – 2 = 0.
- Can I subtract 1 from 0? No, so bit 0 is low.
Believe me, this seems complicated the first time. Then it becomes a second nature…what a nice hobby isn’t it?
Anyhow, we now have our naked CV, 98 in binary is: 0 1 1 0 0 0 1 0
And if this were our fictive CV#99 mentioned above, then yes, bit 6 (in red), is high. So the lights would activate only at stand-still for this locomotive.
That’s it for now, I hope it helped.
We learned to decipher CVs to binary, from binary, and to configure detailed CV options in both systems.
More importantly, we now understand why some decoder manuals are so cryptical: because CVs have been around for some time now, and we need to deal with configuration “bricks” of only 256 values….in which many pieces of information are sometimes tightly packed.
There are many excellent online resources to learn more, or learn the same thing in another way. I think it’s important to understand the few basics I just presented.
If you just installed a fancy decoder in a new fancy locomotive, it would be quite sad to stop in front of a scary decoder manual !