I have Digitrax command station, one thing that I have alway wondered about
Does the Command Station send out constant info or does it only do it when there is a "change" or "new" command given, such as change in speed or direction, head light on/off.... etc. , or does the loco retain last given commands until there are new ones?
The command station sends out the commands repeatedly. There is no "dead" time.
I am assuming the loco does retain some information...i am basing this on videos I have seen demonstrating "keep alives"... running locos over electrically dead track sections. The loco would have to retain the speed command thru that dead track to keep moving
Most decoders have a packet timeout setting, which is how long it can go without seeing a packet addressed to it before it stops. But DCC is fast enough that even with 100 locos running, each one will get several packets within the timeout limit.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
so...that said...if a loco is picked up while in motion & then placed back on the track in a reasonable time..it will "take off" until told to stop or recognizes a new command from the Command Staion?
If it has no keep alive, then no, it won't do anything until the next packet comes along to tell it what to do. But that happens so fast it will seem like it tries to take off the second the wheels touch the rails.
If it has a keep alive, it will continue to run when you pick it up, and if you put it down before the keep alive is drained, it will just keep going at the last commanded speed and direction. If the keep alive fully discharges, then it will behave like a loco without a keep alive.
rrinker Most decoders have a packet timeout setting, which is how long it can go without seeing a packet addressed to it before it stops. But DCC is fast enough that even with 100 locos running, each one will get several packets within the timeout limit. --Randy
If you set an engine in motion on a circle of track and never touch the throttle, no new packets are sent, but the engine will never "time out" and come to a stop on its own. IF the engine loses power temporarily, the engine will pick back up and proceed under the parameters of the last command given. Only if that power loss exceeds the given time-out setting, will the engine be stopped and not restart on its own.
Mark.
¡ uʍop ǝpısdn sı ǝɹnʇɐuƃıs ʎɯ 'dlǝɥ
Mark R. If you set an engine in motion on a circle of track and never touch the throttle, no new packets are sent, but the engine will never "time out" and come to a stop on its own. IF the engine loses power temporarily, the engine will pick back up and proceed under the parameters of the last command given. Only if that power loss exceeds the given time-out setting, will the engine be stopped and not restart on its own. Mark.
That isn't correct. The command station continues to send the commands. If it didn't, you'd have either straight DC or no power at all on the rails. Remember, it's the DCC waveform that provides both the power and the packets to the decoder.
See the "HOW DCC COMMAND STATIONS WORK: QUESTIONS AND ANSWERS" section on this page for details:
https://sites.google.com/site/markgurries/home/technical-discussions/dcc-bandwidth
Well, the IDLE packet takes care of when there is nothing else to send, so you get a DCC waveform regardless of what's going on.
Sometimes, out of curiosity I'll watch "Monitor Loconet Activity" on one of the JMRI Decoder Pro panes. You can see all activity of the network here. It is interesting to watch.
Regards, Ed
Mark R.If you set an engine in motion on a circle of track and never touch the throttle, no new packets are sent,
the command station repeatedly sends speed commands to each loco it is polling. on large layouts with many engines, the delay between updates is the total time to poll all the locos. 275 msec for 64 polls (see cab bus protocol)
i don't believe light commands are repeatedly sent
Mark R.IF the engine loses power temporarily, the engine will pick back up and proceed under the parameters of the last command given.
if it loses power it loses the last speed command. hence, the command station repeatedly sends the speed command so that a loco will quickly resume speed after power is restored (no need to store last speed)
greg - Philadelphia & Reading / Reading
gmpullman Sometimes, out of curiosity I'll watch "Monitor Loconet Activity" on one of the JMRI Decoder Pro panes. You can see all activity of the network here. It is interesting to watch. Regards, Ed
gregc the command station repeatedly sends speed commands to each loco it is polling. on large layouts with many engines, the delay between updates is the total time to poll all the locos. 275 msec for 64 polls (see cab bus protocol)
You guys are talking about the cab bus, not the DCC signal to the tracks They're different.
You'd need a DCC sniffer to monitor what's on the tracks. NCE used to make one, and so did Pricom I believe, but they are no longer produced. You'd have to build your own using an Arduino or similar.
Also, gregc, not all DCC systems use a polled buss. Some , like LocoNet, are event-driven so there is no polling of the throttles or other devices.
StevertYou guys are talking about the cab bus
you're right. thanks
so the command station sends a packet on the rails for each loco that it has received a controller command from. the repetition rate depends on the time to send a packet (42 bits, 6-9 msec) and the # of locos.
Packets sent to Digital Decoders should be repeated as frequently as possible, as a packet may have been lost due to 115 noise or poor electrical conductivity between wheels and rails.
The command station's software will decide which packets are sent and how often. If a throttle is very active, packets for its locomotive will be sent more often than those for trains which have little change.
Idle packets do have a purpose: They trigger RailCom events. Since RailCom is going nowhere, not really an issue.
The DCC spec says packets should be sent to decoders "as frequently as possible". This is because it cannot be assumed that just because a packet was sent it was recieved. Packets with the same address must be seperated by at least 5ms, and there should be a packet sent at least every 30 ms to prevent dual mode decoders possibly switching to analog mode.