For reasons of personal interest, I have been going over the NMRA DCC specifications and recommended practices and I have not been able to determine what a typical Command Station is transmitting between packets if, for example, things are rolling smoothly for a few minutes with no change in Cab parameters ( speed, direction, etc.). There seems to be a requirement to transmit some kind of packet to a decoder at least every 30 milliseconds. I would think that power must still be applied to the track in some form of packet transmission at all times. Possibilities would be all "1's", which would be a continuous preamble, or all "0's', or so called "Idle" packets. Does anyone out there have a credible answer. At the present I have no DCC track analyzer or oscilloscope available to monitor the DCC signal, nor have I been able to find the answer elsewhere on the Internet or MRR Forums.
Mike
If you don't get an answer here, you might want to ask your question on the JMRI forum. Some of the folks who hang out there know a whole lot about the inner workings of DCC. I believe at least one of the JMRI developers was even on the NMRA's DCC Working Group at one time.
I think the reason you can't find the answer is that there isn't a requirement. Actually, S 9.2 allows power to be removed from the rails between packets. One thing this allows for is the possibility of two way communication.
For practical purposes it wouldn't matter if ones or zeros were used as "idle". The exception to this thought would be in systems where zero stretching is used, where it would make sense that zeros would be used.
Jeff But it's a dry heat!
As I recall, the DCC system will constantly repeat the commands to each engine. This is necessary for smooth operation. If only single command packets were sent, then an engine which "missed" a packet, possibly because it hit a dead spot on a frog, for example, would get "out of synch" with the command station.
I believe the "repeat cycle" depends on the number of locomotives in the stack. If you've only got 2 or 3 engines, then they all get updated quite frequently. On the other hand, if you've filled the 32-address stack of a Lenz Dispatcher throttle, the cycle time for each individual engine will be longer.
"Zero stretching" describes the method used for driving DC locomotives (as Engine Zero) on DC systems. Normally, the track voltage would be balanced by sending an equal number of zeros and ones. To get an unbalanced voltage, which will be seen as a DC voltage by a non-decoder-equipped engine, the system adjusts the relative number of zeros and ones, so the "average" becomes a variable negative or positive voltage, depending on the speed dialed in for Engine Zero on the throttle.
It takes an iron man to play with a toy iron horse.
When no data is being transmitted, the command station is sending 0's, which, unless zero stretching is in use to run a DC loco, are, or should be, square, with equal duration of both the positive and negative halves. The exact timings, and the threshold between a 1 and 0, are in the NMRA specs.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
mikept ...I have not been able to determine what a typical Command Station is transmitting between packets if, for example, things are rolling smoothly for a few minutes with no change in Cab parameters ( speed, direction, etc.)...
...I have not been able to determine what a typical Command Station is transmitting between packets if, for example, things are rolling smoothly for a few minutes with no change in Cab parameters ( speed, direction, etc.)...
What do you consider a "typical" command station? Different command stations handle this differently. For example, the old MRC Command 2000 could only control 10 addresses, so what it did was just continuously loop through those 10 addresses and send packets for each address. If there were no changes being made, then it just sent the same packets over and over. I believe the Bachmann EZ-Command works the same way.
Digitrax sends out packets for every address that is occupying a slot, again sending the same packets over and over if there are no changes being made. As long as at least one slot is occupied, then there is data to be sent. If every slot is free, then Digitrax does not send any mobile decoder packets. I have not tested it, but I suspect that at this point the command station would send continuous idle packets to insure no decoders try to convert to analog power. Continuous idle packets would not be all 0's. An idle packet consists of the string of 1's for the preamble, it's first byte is all 1's, it's second byte is all 0's, and it's third byte is all 1's.
Thanks for all of the information. I knew that I could get some good information from the Model Railroaders on this Forum. Also, I guess that the 30 millisecond requirement is for older pre-NMRA spec'ed decoders, and the Command station only has to have the capability to be able to send a packet to their address within that 30 milliseconds. If a user has more than, say 6 locos in the stack, it would take more than 30 milliseconds to get around to updating that address. I wonder if that has ever been a problem for some? Again, thanks for the info.
I don't think any decoders require a packet to their address within 30 ms, I think they just need to see a valid DCC packet within 30 ms.
The speed for all locomotives on the command station queue are being transmitted over and over.
Speed is not stored in the DCC decoder when it receives the command. It just sits in the temporary RAM of the decoder. So when the power dies, the speed is lost. I'm guessing resetting the speed is was done for safety reasons. It also gives you the ability to adjust the engine speed while the track is off. (Imagine running against the points, shorting @ the frog. So you push you train back when the power is off. If your train started running as soon as you restored track power then you would be in the exact same spot as before...shorting at the frog.)
Now imagine your train running down the tracks and it hits a dead spot, or temporary short. Your decoder resets and it lost it's last speed setting.
This is why speed is transmitted over and over again to every train in the command stack so the loco can pick up where it left off.
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
mikept Also, I guess that the 30 millisecond requirement is for older pre-NMRA spec'ed decoders, and the Command station only has to have the capability to be able to send a packet to their address within that 30 milliseconds.
Also, I guess that the 30 millisecond requirement is for older pre-NMRA spec'ed decoders, and the Command station only has to have the capability to be able to send a packet to their address within that 30 milliseconds.
The loco just needs to see any valid DCC packet in 30 msec. This applies to any decoder including those made today, although on most this timeout value can be programmed into a CV.
For decoders that do not have DC power mode on (CV29-Alternate power mode bit) the train is supposed to stop at a rate programmed into CV4 when a DCC packet timeout occurs. This is a recommended practice.
This serves two purposes:
1) Prevents runaway trains from command stations that have gone loopy.
2) Allows for DCC auto stopping sections. Imagine crossing a "Stop" signal and having the train come automatically to a gradual stop.
BTW: There is a provision for transmitting 0 packets. Bi directional decoders like Lenz Gold series can then communicate back to the command station during this period. However this is not standardized across all DCC systems or decoders. (In other words don't count on it) It was ratified in the last 3 years or so by the NMRA.
That's not transmitting 0's, that's not transmitting at all. During this brief period of no signal is when the decoders can send their information.
Regardless of th fact that some peopel have been able to get it to work, both the Lenz and Digitrax systems, I don;t see this taking off, at least not as designed. It relies too strongly on a very weak signal from the decoder being accurately detected. This harkens back to pre-DCC command control systems where the signal was of small amplitude superimposed on a solid carrier voltage. The realities of complex track arrangments and the wiring for them make it very easy for low power signals to get lost or corrupted.