I know the NMRA is working on "next steps" for the standard. They elected to focus on the LCC (track/layout/accessory) aspect first, which in theory would alleviate some of the signals being sent through the track. The more difficult challenge (train control) I believe is (or was) called their "traction" document. I know that RailCom has been introduced, which adds a certain amount of bi-directional communication (some people have told me this isn't completely dependable, but I don't have enough feedback from people to know whether to agree with that). My question is: in regards to DCC train control, what are the deficiencies in the current standard that are worth addressing in any future standard? I would like to see a prioritized list of what aspects of the current standard might be improved upon.
Isn´t that question a bit academic at this point of time? The current DCC "standard" has not yet reached the end of all possible exploits and I am sure that companies like Lenz (Bernd Lenz actually invented DCC) and ESU are working to enhance and extend the current use.
DCC is an international standard and I am sure the largest number of DCC users can be found outside of the US and Canada.Whatever the NMRA will come up with needs to have the acceptance of the much larger European market to have a chance of realization.
Dcc systems could use keep alive capacitors standard in all decoders.
Steve
If everything seems under control, you're not going fast enough!
Two things, probably inter-related, come to mind:
One would be to re-write the standards so they aren't ambiguous. For example, the "two-digit" short address can, under certain interpretations, go up to 127. So some DCC systems treat up to 127 as short, some treat up to 99 as short, and some treat everything up to 127 as long OR short.
The other would be to remove the politics from the standard-making process. I have heard, from a former DCC Working Group member, that a LOT of politicking went on when the DCC standards and RP's were being developed. This article would seem to indicate that at least one DCC manufacturer had (and may still have) similar concerns.
Standardizing the CVs would be a good start. And how about making a CV1 that goes up to 4 digits?
A Standard isn't what many seem to think it is.
The NMRA DCC standard defines the signal's electrical and digital parameters at the railhead. How they get there, and what happens afterwards is not part of the standard. They also define a required set of CVs every decoder must have.
Standards are set by committee. Look at any published standard you will see a mix of interested parties, including manufacturers. So it will include the practical and the possible. After all, if you make something that must meet various standards, you don't want things that will make your product uncompetitive or require extensive investment for little return. New features/requirements are added in much the same way.
In the case of DCC, the standard does not tell the manufacturer how to make the hardware or the software. In some cases it is vague, allowing the software engineer to decide how to implement the feature. Being too specific can introduce new problems later.
It dictates a minimum feature set needed, also if certain features are not present it must be stated on the packaging so the buyer will be aware and make an informed purchase.
Doing this allows you to make a command station in software and build a Raspberry Pi command station/booster using it. Or purchase a microcontroller and make your own decoders.
It is impossible to make CV1 go to 4 digits. First of all, a CV is only a single byte, that's 8 bits. The only possible values are 0-255. Second, by altering how CV1 works, it would require the data packet format to change that nothing made prior to this change would work.
This was all addressed in the early days of finalizing the specifications with the extended packet format and the addition of CV17 and 18 to handle addresses over 127. I do also wish they had set it up one way or another, not allowing each manufacturer to decide what was a short and what was a long address, but SOME manufacturer would have been left out in the cold and had to redesign their system, ironically the most oddball of them was Lenz, who supplied most of the basis for the DCC standard.
- -Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Better bi-directional communication. I'd like to be able to put an engine on the track, and have the command station know what functions are on, and the state that they are in. This is especially important for some ESU functions that alternate between multiple color marker lights. Speed and load/BEMF compensation info would be nice, too, but generally is less important.
Requiring BEMF would be nice, if only to force MTH to implement BEMF w/ custom speed curves.
Otherwise, it's a pretty good standard. Most of the complains I see with it are more UX related, and not knowing how Digitrax/NEC/etc work, than it is with the protocol itself.
I would think that any "improvements" to the standard should be backward compatible with existing DCC systems and decoders. Perhaps some of the improvement(s) might not be available using a former system but the older system would still be useable. If changes were so radical that only new equipment, designed for the new standard, would work then that would best be called NOTORIGINALDCC or the like for clarity. Such a change is not likely to be accepted quickly by current SCC users unless offering great incentive for changeover, rather unlikely.
I don't know if there are DCC Recommended Practices but perhaps that's where more opportunity exists. I'm thinking of improvements that would work with existing systems. That way perhaps more fundamental features could become common, or would faster do so, between brands, perhaps with their next decoder series, for instance. While the market over time might accomplish some of this an RP might help. An example would be for all decoders to include CVs 2, 5 & 6 for simple 2 slope speed curve adjustment. One of my favorites would be how sounds on a loco start or not with track power initiation as opposed to an operator action. Another quirk is how well a system (throttle, Decoder Pro or LokProgramner) can read & write CVs from the program track withou a booster. But agreement to add RP specifics for some features, such as approach to indexed CVs, is rather unlikely. We should recognize that manufacturers like to have features that distinguish their brand so agreement would probably be attained only on more basic things.
I would not be surprised if there has been NMRA consideration about this after the Standard release.
Paul
Modeling HO with a transition era UP bent
I am not a programmer. But if I had to upgrade, it would be my system, which is a lot easier to change than the 30 decoders I installed. So if innovation was to come from somewhere, it would be the system. Could that be compatible with the old and a new generation of decoders?
Simon
I would like to see the standard extended out to the throttles, so we would not be stuck with a single brand of throttle when we buy a DCC system. This becomes even more attractive as wireless throttles become more popular.
It takes an iron man to play with a toy iron horse.
MisterBeasley I would like to see the standard extended out to the throttles, so we would not be stuck with a single brand of throttle when we buy a DCC system. This becomes even more attractive as wireless throttles become more popular.
This is where Layout Command Control comes into play.
i thought he was talking about the interface between the hand-held and the command station
does LCC have any support for interface to a command station?
greg - Philadelphia & Reading / Reading
Yes, LCC can bridge to other networks.
https://www.dccwiki.com/Layout_Command_Control
betamax A Standard isn't what many seem to think it is. The NMRA DCC standard defines the signal's electrical and digital parameters at the railhead. How they get there, and what happens afterwards is not part of the standard. They also define a required set of CVs every decoder must have.
https://xkcd.com/927/
Disclaimer: This post may contain humor, sarcasm, and/or flatulence.
Michael Mornard
Bringing the North Woods to South Dakota!
Be nice if Function buttons were standardized. Beyond F0 (lights) F1 (bell) and F2 (horn/whistle) it's often a jumble...and sometimes even those three aren't standard either!
Bayfield Transfer Railway betamax A Standard isn't what many seem to think it is. The NMRA DCC standard defines the signal's electrical and digital parameters at the railhead. How they get there, and what happens afterwards is not part of the standard. They also define a required set of CVs every decoder must have. https://xkcd.com/927/
LOL do you subscribe to Jack Ganssle's Embedded Muse newsletter? He just used that same XKCD in the most recent on.
--Randy