This section discusses the available "bandwidth" of the DCC system to communicate DCC commands to DCC decoders both mobile (Engine Decoders) and stationary (Accessory Decoders). There section describes speed and repetition rates of the different types of DCC commands as well as addresses some misinformation both on the web and in publications saying "DCC does not have the bandwidth". This is written in a Q&A format.
DEFINTIONS
1) What does the terms Bandwidth mean as it related to DCC?
DCC Bandwidth is the number of DCC commands (messages) that can be sent by the DCC command station to DCC devices for a defined period of time. With DCC the unit of measurement is DCC Commands Per Second.
2) What does "Running out of Bandwidth" mean?
"Running out of Bandwidth" in a command/message communication system means the system can no longer increase the message rate to satisfy all the pending request to send messages for the defined period of time. Typically this can result in severely delayed messages or loss of messages depending on how the system is designed.
3) How does "Running out of Bandwidth" apply to DCC?
Running out of bandwidth does not apply to DCC! Why? DCC is always sending the maximum DCC commands per second rate (100%) possible for the given operating conditions all the time independent of the number of or type of DCC commands that need to be sent. That includes zero commands! Read on to learn more.
4) What does a DCC command Station do?
It accepts and manages all the information from throttles, control panels and optionally computers and generates DCC commands at the appropriate time to efficiently control locomotives and accessory devices.
HOW DCC COMMAND STATIONS WORK: QUESTIONS AND ANSWERS
1) What are the primary responsibilities of a DCC system?
The DCC system has TWO responsibilities.
a) Providing DCC Power continuously to the track to run locomotive and accessories as required.
b) Sending DCC Commands to the track to control locomotive and accessories as required.
2) How does the system accomplish both responsibilities?
DCC has been designed such that DCC power and DCC commands are one in the same. That means to send power to the track some form of a DCC command must be sent.
3) What happens if there are no DCC commands to be sent?
When there are no DCC commands to be sent, the DCC Standard has defined a "Do Nothing Command" that must be sent to "fill in the time" between true DCC commands. Typically when you turn on a given DCC system, there are no commands being sent other than the do nothing command endlessly. (NMRA DCC idle packet) Hence DCC power will still flow on the track even if there is nothing to do. This is also the very same reason why any and all DCC command station are always sending DCC commands at it maximum possible command rate (100% capacity). Anything less would result in DCC track power loss.
4) How fast does DCC system send normal DCC commands to the track?
The average number of DCC commands sent to the track is somewhere between 110 to 120 per second.
5) Why does the DCC command rate vary?
The actual value depends on the type of DCC command being sent. The more advance DCC commands (128 speed steps and Long Addresses) have a lot more bits in the DCC commands and hence take longer to send than simple DCC commands. The mixture of simple and advanced DCC commands determines the actual real world command rate. Example: If you operate your layout only using long addresses, you will have a lot lower DCC command rate than if you only used short addresses. Mix in NMRA Advanced Consisting, which uses short addressing, allows many locomotive to be control by a single simple DCC command increasing command rate compared to NMRA Basic Consisting. Very situational and operational dependent.
6) What are the typical DCC commands beings sent?
Operationally the most common is locomotive speed and direction commands. Next are decoder function commands with the fewest being accessory commands. Programming commands are only sent when you put the system into programming mode or putting together or taking apart an Advanced Consist.
7) Why are locomotive speed and direction commands the most common?
The command stations 3rd responsibility is to keep any locomotive that is moving stay moving. Any engine that is moving needs a regular stream of REDUNDANT DCC commands that tell it to move. Why? If the engine momentarily loses power due to dirty track, the decoder will lose the speed and direction information as well as function states (The latter depends on the age of the decoder). As the engine keeps physically moving over the dirty track due to flywheel power (no KA/Stay-Alive power) and track power is restored, the decoder will quickly get the "forgotten DCC commands" and pick up where it left off.
8) How does a DCC command station manage all these commands?
DCC command stations have the ability to prioritize and queue up different classes of DCC commands to maximize the effectiveness of the DCC commands being sent for the given time. Stated another way, DCC commands can be temporarily re-arranged so the newest commands that need to be sent take momentary priority over the background of sending redundant speed commands. Many command stations will also stop sending DCC command to any engine that are not moving. Once they are stopped, there is no need to keep telling them to stop. This allows it to focus on locomotives that are moving.
9) 110-120 Commands Per Second sounds like a lot. Is it?
Yes and No. It depends on the number of unique locomotives the command station is design to control. Simple command station control 10 locomotives where as larger command stations can control 60 or more. Assuming an average 110 Command per second are only being used to send redundant DCC speed and direction commands to moving locomotives:
Small Command Station:
2 moving locomotives means 55 commands per locomotive per second.
10 moving locomotives means 11 commands per locomotive per second.
Large Command Station:
22 moving locomotives means 5 commands per locomotive per second.
55 moving locomotives means 2 commands per locomotive per second.
Conclusions:
1) Small layout will never experience a slow response to any operating conditions since the command station has limitation on what it can control.
2) Large Club size layout or any layout that runs a lot of unique engines simultaneously can experience slower responsiveness and/or more erratic locomotive movement over dirty track.
The point is as you continue to run more and more engines, the division up of the fixed command rate among so many locomotive means slower updates to each locomotive. In other words the system slows down but it does NOT stop working.
10) Does this mean adding DCC accessories decoders to a large layout will cause the layout to become slower?
NO. DCC Accessory decoders need very few DCC commands to function. The DCC commands are repeated a few times to make sure they get through and then nothing more is sent. Fire and forget. You must also remember that a large DCC command station has smarts and can re-prioritize what commands get sent when allowing a DCC accessory command to move to the "front of the line" so it can be sent quickly despite a large number of locomotive that are running at the same time. It gets the accessory command out of way so it can quickly focus back on running locomotives.
11) MATHEMATIC EXAMPLE OF DCC ACCESSORY COMMAND HAVING MINIMAL IMPACT ON DCC SYSTEM PERFORMANCE
For this example, we are going to define a command station has a fixed 120 commands per second capability. In other words, the full (100%) bandwidth is defined as 120 commands per second.
Let say 2 accessory commands all sent in 1 second. Lets further assume 1 redundant packet is sent too for each unique accessory command within that same one second. So that is 4 commands in one second
Putting it together: 4 commands sent /120 command possible = 3% of the DCC bandwidth for 1 second. 97% of the bandwidth is still running other trains for the remaining portion of the second.
The only operating conditions that would generate the most accessory DCC commands would be a layout with signals. But signals do not change that fast. There is a blitz of signal commands all at once followed by nothing for a long time. So lets say there are 10 commands sent every 15 seconds. The means the signal commands only used 10 / (120*15) = 0.5% of the DCC bandwidth over 15 seconds. That is nothing.
Conclusions:
1) Accessory Command are sent so infrequently that is has no noticeable impact on DCC system performance.
2) It is NOT TRUE that a 3rd party accessory control bus system will allows a given DCC system to perform better by removing the burden of dealing with accessory commands.
12) If DCC bandwidth is not a problem, then what are the advantages of using 3rd party accessory control Bus?
It allows you to implement layout control in a more powerful, flexible and integrated way than what a DCC systems alone can offer especially if one is implementing signals on a large layout.
The basic problem is the DCC Standard has defined DCC accessories as one way communication devices. They accept commands and implement them. But there is no status feedback. For example, you cannot find out if a given turnout is in a specific position. Yes on some DCC systems you can add proprietary feedback devices allowing you to do simple things. However with the addition of Signaling, it not only needs turnout position status information but also status from all the occupancy sensors that report the physical location of trains as they move. Finally there is the signal logic that reads all the feedback input states and generates the signal aspects that must be displayed as a result of that information. When you look at the big picture, you will begin to understand that the DCC system is really just optimized for running trains and not for setting up and running signals and other misc control functions. They do not make it easy to setup these advanced systems. 3rd party system can offer a better solution especially as the size and complexity of the system is large.