DCC

Overview

On this page:
Command set | Bandwidth | Domains

Abstract

DCC command optimization is very important. Both DCC and Railcom provide very limited bandwidth therefor optimizing the command flow is critical, especially for bigger setups.

DCC command set

Because my DCC generator runs on the PC its implementation becomes easy. Below the list of commands supported by the generators,

In addition to the above the following features are also available,

  • Automatic short address decoder discovery
  • Automatic long address decoder discovery
  • Automatic LOGON (DCC-R extension)
  • Decoder Firmware update over main tracks (DCC-R extension)
Because the real-time bus provides a high-bandwidth, low-latency network, the DCC generators and Railcom detectors can operate in closed loop. This enables many DCC optimizations that make the protocol more robust, e.g. error free reading decoder CVs while the loco is driving.

DCC bandwidth

DCC sends about 100 commands per second over the tracks. While this may be sufficient for small layouts with limited number of decoders, it becomes a factor for larger layouts.

Assuming a driving loco should get at least 6 DCC commands per second and a parked loco should get at least 1 DCC command per second (to keep Railcom address monitoring alive).

With 50 decoder on the layout, 42 parked and 8 moving, the DCC bandwidth of typical ~100 cmd/sec is nearly exhausted,

(42 x 1) + (8 x 6) = 90 cmd/sec 

Time critical commands, such a pressing the ‘whistle-button’, may be delayed and makes system behavior sluggish. To address this, DCC command should be sent with different priorities. For example, a ‘FN’-press command should be sent at high priority. Similar, changing the loco speed should be sent asap. All these optimizations come to their limits if there is a lot going on on the tracks. The final resort is adding additional DCC generators to the layout. For example, one DCC generator for the main tracks and one DCC generator for the Tram lines. Perhaps another DCC generator for the marshalling yard.

Bandwidth utilization

Let’s look at DCC protocol optimization in more detail. I don’t have 50 decoders but I would like to do an experiment to undermine the formula above. Below a recording of the DCC bandwidth consumption with 8 mobile decoders on the tracks.

  • 11:24 – Initially with no decoder logged into the system the DCC utilization is 1%.
  • 11:25 – Now I enable DCC-R logon protocol on my command station and immediately all 8 decoders LOGON within 4 seconds. We see the spike in DCC bandwidth consumption caused by the decoder logon protocol. Because all decoders remain idle (= not driving) the command station gradually ramps down the decoders priority and frees up DCC bandwidth.
  • 11:26 the DCC bandwidth consumption has retracted to about 8%. We can calculate that every idle decoder needs about 1% bandwidth for some alive pinging.
  • 11:30 – Now I start driving one decoder after another with finally all 8 decoder driving concurrently. The DCC bandwidth consumption goes up to 50% which translates into 6% bandwidth consumed per driving decoder. This bandwidth increase is due to the DCC command refresh needed for driving decoders.
  • 11:42 – Finally, I am stopping (speed=0) all 8 decoder simultaneously. The command station ramps down the decoder priority gradually again until we reach 1% bandwidth consumption by each of the stopped decoder.

Learning

The experiment above has demonstrated that any non-moving decoder consumes 1% DCC bandwidth while a driving decoder consumes 6% bandwidth. We can now estimate the maximum number of decoders per DCC domain,

  • 3 locos driving
    Max decoder = 100 – 3 * 6 + 3 = 85 decoder
  • 5 locos driving
    Max decoder = 100 – 5 * 6 + 5 = 75 decoder
  • 8 locos driving
    Max decoder = 100 – 8 * 6 + 8 = 60 decoder

If the number of decoders stays below the recommended maximum as shown above, the RTB command station will guarantee 6 commands sent to the running decoders in equal time distance (1/6 sec = 167ms). This is very important to keep Railcom address detection delay predictable and reliable. Of course, the above will only apply to my RTB command station. Other DCC stations may come to different results.

DCC domains

To grow the number of decoders beyond the limits of a DCC domain (see above), multiple DCC generator domains need to be introduced.

RTB layouts, using multiple Power Domains, have multiple DCC generators per design. By default, all DCC generators in a RTB domain run in step-lock mode and behave like a single instance. Their timewise synchronization is down to 200ns allowing rolling stock to roam between DCC domains and cross Booster boundaries any time. But the architecture also allows to dynamically isolate DCC generators. This works on a per-DCC-frame basis. DCC domains can join and split dynamically at any time. Coordination takes place in the software layer on the PC.

Consequently a RTB Domain with up to 16 DCC generators scales up to 16x over a single command station architecture. Assuming a single DCC generator supports up to 50 decoders, a RTB domain with 16 DCC generator may support up to 800 DCC decoder. This outscales any existing DCC system by a magnitude, because in RTB all 16 DCC generators are still a single layout system. Of course, there may be other limiting factors such as power supply which lowers the number of active decoders to a more reasonable number. But it shows the scaling that is possible using multiple DCC generators.

Single DCC generator within a RTB domain

One DCC Generator

Two DCC generators within a single RTB domain

Two DCC Generators

Three DCC generators within a single RTB domain

Three DCC Generators