Identifying a decoder - another

[Greg Elmassian]

Greg,

Got to take issue with you on this one?

The emergency stop command is a broadcast command under DCC, which all decoders should respond to. - So the Central Station (in effect) 'shouts' stop-all, and all the decoders should respond to this.
(I do not know of a manufacturers system, which sends 'stop', to each address it thinks is running, in turn?)

The Central Station knows which loco's you have sent commands too, but can not know which are actually running, as DCC is a broadcast transmission system, with no feedback, to acknowledge receipt of a command, or (under normal running) way of knowing if a command has been implemented.
Hence DCC sends each command a number of times, and hopes it has been received.

This is different on a programming track, where the decoder acknowledges receiving (and acting) on a command by the 'twitch' we see of the motor. - The CS detects this, but it does not transmit any 'data' (in a '0' or '1' sense) back to the CS.


Simplified explanation, I know, but think the whole audience should get this?

Yes, you can do a broadcast stop, clearly.

But when you know the list of active locos, you can slow them to a stop by issuing the appropriate speed commands to just those locos, as opposed to the immediate stop from the broadcast. Some systems do this. The big advantage is being able to come to a rapid, but safe stop. If you pull the plug on a long train or one on a curve, it can lay all the cars on the ground (ask me how I know this, 50 car train, 1/2 on the concrete)

So this is an example of the architectural advantage of a central station as centralized control. And it DOES INDEED know which locos are running, or at least which are being actively commanded. If you have ever investigated this with a packet analyzer you would see that most command stations are CONTINUALLY sending speed commands to all locos in use, in round robin fashion.

(you could also infer this is happening if you lift a loco from the track and when you put it back on, it immediately starts off at the last commanded speed, this tells you 2 things, that the "last speed" is being transmitted over and over, and pretty darn often)

This is where the "wireless DCC" systems cannot compete, since they are throttle to loco, no "centralized control".... Aristo found out the issue when people complained the Train Engineer Revolution did not have an "all stop" function... so what did they do? They sent a stop command to every possible loco id, one by one.... well if you were using loco id's that were higher in number, it was quite a while before your loco got a stop command, usually crashing into something first.

So, a little deeper thought on why it was designed with a "command station" would belie some of the intrinsic advantages of the architecture of DCC as defined by the NMRA and others.

There are many more examples of why centralized control in a multi train / multi user system is advantageous, but I did not intend to make a college course in this, just coming back from the contention that "centralized control" has no benefits, and is only good to power switch motors

Track powered DCC has a lot going for it that people may not realize. If someone added communication between wireless throttles, maybe "wireless DCC" would work, but then this is a bit more horsepower needed in the throttles, probably needing a mesh networking system, and then there is the issue of battery life if the throttles are transmitting continuously, and interfering with each other.

It's not as simple as putting a wireless unit on a DCC decoder and having at it... that works but does not have all the advantages.

Regards, Greg

 

[dunnyrail]

Yes, you can do a broadcast stop, clearly.

But when you know the list of active locos, you can slow them to a stop by issuing the appropriate speed commands to just those locos, as opposed to the immediate stop from the broadcast. Some systems do this. The big advantage is being able to come to a rapid, but safe stop. If you pull the plug on a long train or one on a curve, it can lay all the cars on the ground (ask me how I know this, 50 car train, 1/2 on the concrete)

So this is an example of the architectural advantage of a central station as centralized control. And it DOES INDEED know which locos are running, or at least which are being actively commanded. If you have ever investigated this with a packet analyzer you would see that most command stations are CONTINUALLY sending speed commands to all locos in use, in round robin fashion.

(you could also infer this is happening if you lift a loco from the track and when you put it back on, it immediately starts off at the last commanded speed, this tells you 2 things, that the "last speed" is being transmitted over and over, and pretty darn often)

This is where the "wireless DCC" systems cannot compete, since they are throttle to loco, no "centralized control".... Aristo found out the issue when people complained the Train Engineer Revolution did not have an "all stop" function... so what did they do? They sent a stop command to every possible loco id, one by one.... well if you were using loco id's that were higher in number, it was quite a while before your loco got a stop command, usually crashing into something first.

So, a little deeper thought on why it was designed with a "command station" would belie some of the intrinsic advantages of the architecture of DCC as defined by the NMRA and others.

There are many more examples of why centralized control in a multi train / multi user system is advantageous, but I did not intend to make a college course in this, just coming back from the contention that "centralized control" has no benefits, and is only good to power switch motors

Track powered DCC has a lot going for it that people may not realize. If someone added communication between wireless throttles, maybe "wireless DCC" would work, but then this is a bit more horsepower needed in the throttles, probably needing a mesh networking system, and then there is the issue of battery life if the throttles are transmitting continuously, and interfering with each other.

It's not as simple as putting a wireless unit on a DCC decoder and having at it... that works but does not have all the advantages.

Regards, Greg

Interesting what you say about CTC within DCC, certainly some of the systems used in your neck of the woods have a level of sophistication that I have never been aware of or found the need for. And I take on board the point of a straight stop with a big train sending much of it crashing to the ground.

However I did not say that CTC or even DCC was ONLY good for changing points.

As for Wireless units interfering with each other, my two DCC ones have no issues whatsoever even when using other Battery Wireless units as they are all unique bands. Things have moved on some in the wireless world since the rusty bolt effect of RC back in the 1980’s.

And yes Battery life in Locomotives can be an issue, one that so far has not bit me in the soft rear bits as yet as we tend to run for between 3-4 hours at my timetable running days, though I have as an experiment run a loco on two of these days with the batteries still going strong. Also Battery life in my Fosworks Transmitters is phenomenal and I have only replaced one set in the 2 years that I have been using them.