The SPROG family of DCC devices

How DCC Works, or How SPROG works with DCC

This is designed to be a very brief introduction to DCC and how it works, in order to give some more information about the SPROG II and its capabilities.
This section does not set out to be a comprehensive guide to DCC, and there are many good reference books and online resources that can provide more.


The basic concept of Digital Command Control (DCC) is to control an item, most often a locomotive, by sending specific commands directly to that item. Thus the complete system consists of a message sender, a transmission method, and a message receiving device that can act upon the message.

  • In the case of our system, a model rail setup, the message sender is some kind of "Command Station". The SPROG II is an example, in conjunction with the software running on the attached computer, of a command station.
  • The transmission method is a combination of the rails in the track, the power voltage supplied to the track, and the messages that are modulated onto the power voltage.
  • The message receiving device is a "decoder", a small computer that monitors the track, reads every message on it, and recognizes and responds to specific messages.

So how does that all work?

Command Station and Track Power features

In the DCC system, the command station supplies enough power to run the layout, and also the messages to all of the decoders on the layout. In DCC, track power is AC, where the voltage swings equally above and below 'zero' very rapidly reversing the polarity. A normal locomotive with a DC motor does not move with this kind of track voltage, and so needs a decoder and motor control electronics. The track power is also the carrier of the messages, which are sent by adjusting the length of time of the voltage swings. A message is made up of some "long" swings, and some "short" swings, controlled by the Command Station. Every message consists of an "address" and an "instruction", and many messages can be sent out sequentially by the command station, with instructions for many different deocders.

Decoder Features

A DCC decoder comprises an AC to DC power converter, a computer that reads the raw power signal and identifies the messages, a set of parameters, and some number of power outputs capable of doing the job the decoder is designed for.

Each decoder is configurable, and that is achieved through parameter settings known as Configuration Variables (CV). Each CV has 8 bits, and so can have a range from 0 to 255. Most decoders have dozens of CVs, and some complex sound decoders have several hundred.
Some of these CVs set the decoder to have a specific address. Every decoder reads all the messages, and recognizes - or 'decodes' - those which are addressed with its own specific address. It then responds to the instruction that came in that message, such as "turn on the headlight", or "set the speed to zero". To do this, the decoders have several "function outputs", that can be turned on or off, or controlled more finely, depending upon the particular decoer and the CV settings. The most common function for a decoder is to drive the motor, and all motor decoders have outputs dedicated to that purpose, with control for speed and many other factors. See the decoder vendor's documentation to understand more about this topic. Other outputs can drive lights, or other actuators, and of course there are many sound decoders now available.

So what's "programming"?

The decoder needs to have a unique "address", otherwise messages will be responded to by all the decoders connected, and chaos results! Warning: this is not so far fetched as it might hopefully sound; as you will find out below, it is possible for this to happen!
The process of programming sets the address for a given decoder, and also allows several other settings to be made, for example to select lighting modes, sounds, performance characteristics, and consists.

How DCC Programming Works

Programming in DCC can be done in one of two ways, frequently known as Service Mode or Program Track Mode and Operations Mode or Program-on-the-Main. SPROG is designed to work in one or the other of these modes within a given session, and needs to be switched from one mode to the other by shutting down the software and the SPROG.

Service / Programming Track Mode

In the Programming Track mode, we work with only one loco or other decoder at a time. This enables the programming of all the parameters, controlled by the CV values. On the Programming Track, it is also possible to read back the values set in the decoder (Note: most - but not all - decoders support this read back).

Read Back

This is how the SPROG - or every other command station - works, when reading decoders in the "Programming Track" mode.
DCC today (in general) is a one-way message system. Decoders do not send messages, so another technique has to be used to get a read back.

It sends a question to the loco, or really to the decoder it suspects might be out there, to try to read a CV.
"Is the value of CV1 '0'?"
If the decoder recognizes the question, it will look at the decoder CV values, and if the value is found to be as asked, will reply "yes".
Well, the decoder doesn't have a way to say either Yes or No, so what actually happens is it draws a 60mA current pulse (NMRA standard, same for N Scale or G) if the answer is Yes, and does nothing if the asnwer is no.
Then if "No" the next message will be "Is the value of CV1 '1'?", and so on until it gets a Yes.

In "Paged" mode, a block of 4 CVs is read together, and for each CV this steps from 0 to 255, so takes some time if the answer is a large number.
Direct Bit Mode asks "is bit 0 a 0?", and so only has to ask 8 times to get the whole CV, but not all decoders support that.

So, the decoder has to be able to draw 60mA to reply; many sound-only or function-only decoders cannot do this, but most power/motor decoders work just fine.
For a different example, QSI decoders draw far more than 60mA to generate the "Ack" pulse, and so have been known to be difficult on some systems, but SPROG is specially set up for this need.

Note that if there is more than one decoder connected, the response could be from any decoder, and so it is not possible to get reliable read back in this situation.

Also, some decoders can only be easily programmed "on the main"; a separate topic discussed briefly below.


When programming, DecoderPro forms the message to send a value to a specific numbered CV. No addressing is used, and so if there is more than one decoder connected, the message will look as if it is for that CV in all decoders. The SPROG takes that message, and sends the CV number, and the value to be written. The SPROG expects to see an acknowledge (Ack) pulse (see above) to confirm that the program command was received and executed. If it is seen, the program will move on to the next CV to program, but if it is not, the programming will retry.
this can lead to apparent failure when programming (Red indications in the DecoderPro values), if the decoder cannot send a suitable Ack pulse. Often in this case, e.g. for a function-only decoder, there is no way to confirm the programming other than to try out the intended function and see if it works as expected.

Operations / Program-on-the-Main Mode

Operations Mode is also called "Programming on the Main". To use it with SPROG II, you need to start up in a different mode.
This requires that you change the DecoderPro software Preferences.

The simple thing to do is duplicate the DecoderPro desktop icon, open the new icon's Properties, and at the very end of the Target line, add a space and a new name such as sprogCMD.xml.
Then double-click this new icon, and DecoderPro will start without a connection, and display the Preferences. This time, pick SPROG Command Station for the connection, and set the other entries as before for the right COM port.
Now, you have two desktop icons, one to run as before in Program Track mode, and one to run in Prog on the Main, aka Command Station.

When operating in this mode, SPROG II is no longer a service mode (programming track) programmer. When switching between modes, to ensure a clean reset shut down DecoderPro, power down the SPROG, then re-power the SPROG and restart DecoderPro in the other mode. You can connect to a small piece of track, as you would for Program Track mode, or - more usually - to the whole layout.

Warning! never connect your SPROG to any other DCC Command Station, power device, booster, etc. or to any piece of track that might be connected to another source of power, DCC or DC.

CVs may still be written in operations mode but the contents of CVs cannot be read back.

You may now open multiple throttles, one for each loco you wish to control. Use the power control in any of the throttles to turn the track power on or off. When track power is on, the SPROG Power light will flash on and off continually.
(See below for a note on the limit to the number of locos that can be controlled).

An additional SPROG feature in Command Station mode is the slot monitor which is accessed from the SPROG menu in the main DecoderPro window.
The top portion of the slot monitor contains a checkbox to control whether unused slots are displayed, a button to force an emergency stop of all locos and the output current being supplied by the SPROG II.
The output current readings are filtered and averaged over a number of readings by SPROG II and the display in the slot monitor will change more slowly than the actual output current.
The remainder of the slot monitor is the list of slots, at least one slot is associated with each throttle (see below).
When you use a function button on a throttle, you will see an extra slot occupied momentarily with the address of the loco on that throttle and speed 0. This indicates that the function command is being sent to the loco. To allow for errors in reception, function commands are repeated three times. After the third copy is sent, the slot will be cleared.
Sixteen slots are available, (but SPROG II may not be capable of operating sixteen of your locos without an external booster, depending upon individual current consumptions). Run each loco individually with a representative load and note the current reading. The total required for your layout will depend upon the “diversity” or how many, and which, locos are to be operated at the same time. It should be possible to run at least 3 or 4 modern HO, 00 or N locos, and maybe several more lightly loaded.
Some slots should always be left free for sending function control commands. These free slots will be shared between throttles as required, it is not necessary to have a free slot for every throttle.

Decoder Compatibility List

SPROG programmers should work with any DCC decoder conforming to NMRA standards. We have had few reports of any specific problems. We have had positive feedback that SPROG definitely works with the following. However this is only a very partial list.

We always appreciate further feedback of decoder types that have been tried and will add them to the list.


Gold and Silver series, and mini

Train Control Systems
WoW (likes rather more volts to program properly; we recommend using a 15V supply)


DN163 series "drop ins"


version 6 (Due to a decoder bug, CV1 cannot be read in direct mode)
version 7 (fully operational)

N 1645 and similar "plug and play" sound decoders
N Challenger and Big Boy
(SPROG II fully reads/programs these MRC decoders)

About Us

We are the BBM Group LLC, a family business specializing in solutions for model railroaders.
Model railroads come in many sizes, and we specialize in N Scale, with a track gauge of Nine millimetres.

Contact us for more information, and to share your ideas and needs.