DCC Basic 'Standards'?

[newbryford]

 

 

It will be interesting to see if future alternative control systems offer more flexibility than four digits, by design.

 

I think historically four digits has been down to the limitations of bits/memory etc within the decoder processor.

As processors have improved, I would expect decoders to be able to take on alphanumeric addressing before too long - but that will also require matching controllers capable of being able to address accordingly. We're already halfway there with the controllers like ECoS and Multimaus - that you can already give alphanumeric descriptions to locos.

 

Cheers,

Mick

[Ron Ron Ron]

It will be interesting to see if future alternative control systems offer more flexibility than four digits, by design.

 

 

I think historically four digits has been down to the limitations of bits/memory etc within the decoder processor.

As processors have improved, I would expect decoders to be able to take on alphanumeric addressing before too long - but that will also require matching controllers capable of being able to address accordingly. We're already halfway there with the controllers like ECoS and Multimaus - that you can already give alphanumeric descriptions to locos.

 

 

 

It's already here with a couple of those "alternative control systems".

 

The Ring Engineering RailPro system, which is a long way advanced over DCC, has been around for a few years now.

The long decoder addresses are tied to the decoder and not re-assigned or re-addressed by the user.

As such, the decoder address is usually hidden, because it's of absolutely no use to the user in normal circumstance

Instead, the loco name is tagged in both the decoder and control system and the locos are identified, controlled and set-up or programmed, by using their ID name or graphically.

Take the loco to another RailPro controlled layout and the loco name will be read by the other host system.

 

Similarly, the BlueRail Trains Bluetooth based system also hides the loco address from the user.

Again, it's simply not needed under normal circumstances, as locos are identified, controlled and set-up or programmed, by using their ID name or graphically.

 

 

The benefits of using loco names and accessing them by that ID or by the graphical interface are already available on several DCC systems, although they still retain the need of a user assigned 4 digit DCC address, as the naming feature is only contained in the DCC system itself.

e.g.

ESU ECoS

Roco Z21

ESU Cab Control

Piko SmartControl

Viessmann Commander1(discontinued)

Viessmann Comander2

Marklin CS2 & CS3

 

Other DCC systems just have the simple loco naming feature.

Some examples.....

Roco MultiMaus

Roco MultiMaus Pro (discontinued)

Bachmann Dynamis (discontinued)

Bachmann Dynamis Ultima

ESU Navigator (discontinued)

Hornby Elite

Lenz LH101 (forthcoming)

CT ElektroniK HR3/ZF5 

Uhlenbrock Intellibox 2

Uhlenbrock Daisy 2

Zimo MX series

 

 

You'll note that the American DCC manufacturers* don't have the loco naming feature on their systems.

Apart from their current offerings just being updated versions of fairly old designs, there isn't such a desperate need when North American loco road numbers are generally 3 or 4 digits long.

 

[*Digitrax, NCE, CVP, MRC (sold in the UK under the Gaugemaster brand)]

.

 

 

.

Edited December 29, 2017 by Ron Ron Ron

[Pete the Elaner]

I would be very surprised if 4 digit addressing itself was not limited within the NMRA DCC standard. The systems which offer better addressing seem to do so at the control end, using standard 4 digit addressing between command station & loco.

 

If American attitudes are similar within the hobby to what I see at work then if a feature is not required in the US, then nobody should need it & therefore they won't support it.

[Dungrange]

My understanding of DCC is that the established standards set down make it impossible to implement full five digit addressing.  The long address is stored in two CVs: CV17 and CV18.  All CVs are one byte and therefore contain eight bits of data.  Consequently, the largest number that could be represented by these two CVs in combination is 2^16 = 65,536.  Any number bigger than that simply cannot be contained in two CVs.  CV29 controls whether long or short addressing is used, so unless either bit 6 or 7 of CV 29 can be used to introduce an extra long address accessing three high numbered CVs, then we're stuck with what we have.

 

However, for some reason that I am not sure of, I understand that CV17 has to have a minimum value of 192 (ie the left two bits are always set to 1).  This therefore restricts the number that can be written to the remaining 14 bits of the CV pair to 2^14, which is 16,384.  However, I also understand that CV17 is restricted to having a maximum of 231 written to it, which means the maximum number that can be represented by CV17 and CV18 is 10,239.  It's a five digit address and I understand that some systems are not restricted to 9,999 but what's the point.  I can't see anyone needing more than 10,000 different addresses.  However, removing the restrictions on the value of CV17 would be the easiest way to increase the number of available long addresses (ie allowing some five digit numbers).

[Nigelcliffe]

 

However, for some reason that I am not sure of, I understand that CV17 has to have a minimum value of 192 (ie the left two bits are always set to 1).  This therefore restricts the number that can be written to the remaining 14 bits of the CV pair to 2^14, which is 16,384.  However, I also understand that CV17 is restricted to having a maximum of 231 written to it, which means the maximum number that can be represented by CV17 and CV18 is 10,239.  It's a five digit address and I understand that some systems are not restricted to 9,999 but what's the point.  I can't see anyone needing more than 10,000 different addresses.  However, removing the restrictions on the value of CV17 would be the easiest way to increase the number of available long addresses (ie allowing some five digit numbers).

 

All basically accurate. 

 

But, how could one "remove the restriction on CV17" without recalling all the systems and decoders already in existence ?   They work the way they do, so any change has to stay back-wards compatible with the existing arrangements.  

 

The practical limits on addressing are:   1-99 (Short addresses) and 128-9983 (Long Addresses)   Anything else and you risk confusion when moving between systems (eg. Lenz regards 101 as "long", Digitrax as "short", and NCE as "depends whether you typed 101 or 0101" !!).   And some systems (inc Digitrax) top out at 9983 (convenient binary number), so 9984 isn't a valid address for them. 

 

 

Its probably simpler to have a masking/naming arrangement onto an underlying address list, which is what all the extended alpha-numeric systems achieve.    Then your loco can be "number 5" or "Thomas" or "The blue oily box thing", or whatever you wish to call it. 

 

 

 

- Nigel

[newbryford]

My understanding of DCC is that the established standards set down make it impossible to implement full five digit addressing.  

 

Is there anything stopping a new standard being written?

 

It may be that in the future, controllers and decoders are sold as "complying with phase 2 of the addressing standards" or whatever anyone wants to call it. Nothing stopping them being used with the existing 4 digit system.

 

 

Cheers,

Mick

[Ron Ron Ron]

Is there anything stopping a new standard being written?

 

 

It would require a universal recognition that a step change to more modern technology base, would deliver significant benefits.

That would probably mean a completely new digital control standard.

 

There's certainly more modern technology "out there" and some "alternatives to DCC are using these technologies.

 

As for DCC and loco addresses, at the present time is it necessary to change when we can already use 5 digit TOPS numbers and up 16 character alphanumeric names, if we have the right system?

For example, I can use TOPS numbers or names and also rapidly select or switch between locos just by recognising their photo image or icon.

 

 

 

.

[newbryford]

It would require a universal recognition that a step change to more modern technology base, would deliver significant benefits.

That would probably mean a completely new digital control standard.

 

There's certainly more modern technology "out there" and some "alternatives to DCC are using these technologies.

 

As for DCC and loco addresses, at the present time is it necessary to change when we can already use 5 digit TOPS numbers and up 16 character alphanumeric names, if we have the right system?

For example, I can use TOPS numbers or names and also rapidly select or switch between locos just by recognising their photo image or icon.

 

 

 

.

 

I get that, but can that alphanumeric name be recognised by for example, your friend's identical system when you take your stock to run there?

Or do you have to generate the name again with it's effectively hidden 4 digit address - that you may have forgotten?

 

It would be great just to turn up at another layout - that supports "phase 2 address standard" and just type in XC221 for example, rather than trying to remember the exact four digit address that I programmed it with a couple of years ago. 

 

As you mentioned above about alternative technologies, the Railpro system has the ability to have alphanumeric descriptions unique Why can that not be encompassed in an upgrade to the DCC standards?

 

 

Just a thought.

 

Cheers,

Mick

[Dungrange]

But, how could one "remove the restriction on CV17" without recalling all the systems and decoders already in existence ?   They work the way they do, so any change has to stay back-wards compatible with the existing arrangements.

 

Unfortunately, I can't answer that one because I don't know why CV17 seems to have to have values between 192 and 231.  However, I can't see why allowing CV17 to have values up to 255 would not maintain backwards compatibility with existing systems, albeit long addresses in the range 9983 to 16384 would not be recognized on all systems.  The minimum value restriction would however seem to be more problematic to remove, as allowing the leftmost bits to be set to zero is likely to have unpredictable results with existing equipment that will expect these two bits to be 'on'.  As such, I'd have thought that 16384 would likely be the maximum number of addresses that could be accommodated if backwards compatibility were to be maintained.

 

Of course there is always the option of a new DCC standard for the future, but I'm not sure that being able to accommodate alphanumeric addresses is a big enough advantage to change the current NMRA standards.  As such, I think the best option is simply for command stations to have a lookup table that defines the relationship between the four digit address and the desired alphanumeric description (as many seem to do already).

[peach james]

I get that, but can that alphanumeric name be recognised by for example, your friend's identical system when you take your stock to run there?

Or do you have to generate the name again with it's effectively hidden 4 digit address - that you may have forgotten?

 

It would be great just to turn up at another layout - that supports "phase 2 address standard" and just type in XC221 for example, rather than trying to remember the exact four digit address that I programmed it with a couple of years ago. 

 

As you mentioned above about alternative technologies, the Railpro system has the ability to have alphanumeric descriptions unique Why can that not be encompassed in an upgrade to the DCC standards?

 

 

Just a thought.

 

Cheers,

Mick

 

Because to "upgrade" the DCC standard in the way you are suggesting breaks the standard... the standard is that CV 17 and 18 contain the addresses.  If you add (for instance) CV 112 to the address scheme, what happens when the number is >9984 ?  The "old" DCC standard would be broken by this, and unless the "new" standard defaulted to say, everything > 9984 = 9984, then you have rendered your system into not DCC, but something else.  Feel free to do so, but don't call it DCC, or imply that it is warranted(*), or in any way shape or form DCC, because it would not be.  It could be MCC (Mick's Command Control), but DCC it isn't.

 

The issue is one of how much RAM cost in 1984, nothing more or less- each bit was important, because they each cost $, so therefore, the design only allows for up to 9984 addresses.  Since that beat 16 (Zero1, CTC 16), and it far beats 1, it is what it is.  While there may be some future in proposing a change to DCC, I don't think this is an issue that will make or break DCC as a system.  Because of the advent of computers mixed into DCC (in the form of using a smart phone as the handheld, or otherwise using TCP/IP at some point as part of the control mechanism, I can see that it might be to the advantage of users to add that at the throttle level.  However, remember that DCC does NOT dictate how the throttle to base unit is to talk to one another, and there are several options out there.

 

James

 

(*)warranted= approved by NMRA who own some patent rights, and some trade dress, regarding DCC and the performance spec's of DCC)

[Dagworth]

Or do you have to generate the name again with it's effectively hidden 4 digit address - that you may have forgotten?

 

Write the address underneath the loco in silver marker pen. That's what I do...

 

Andi

[newbryford]

Because to "upgrade" the DCC standard in the way you are suggesting breaks the standard... the standard is that CV 17 and 18 contain the addresses.  If you add (for instance) CV 112 to the address scheme, what happens when the number is >9984 ?  The "old" DCC standard would be broken by this, and unless the "new" standard defaulted to say, everything > 9984 = 9984, then you have rendered your system into not DCC, but something else.  Feel free to do so, but don't call it DCC, or imply that it is warranted(*), or in any way shape or form DCC, because it would not be.  It could be MCC (Mick's Command Control), but DCC it isn't.

 

 

Admittedly it breaks the existing standard, but what's to say that the standard cannot be improved and/or rewritten and consequently renamed? 

Why can't the standards evolve if better/cheaper components such as memory are available?

 

Although I quite like the sound of MCC, it will be forever associated with the humble game of cricket..................

 

Lets for an example, call it DCC mark2. (Which isn't the existing DCC but quite similar) 

 

All decoders that comply with DCCMk2 can run on original (let's call them Mk1 for sake of simplicty) system controllers but limited to 4 digit addressing. Likewise Mk1 decoders will still be able to run Mk2 systems - with the restriction of 4 digit addressing.

 

Or am I missing something obvious?

 

 

 

Write the address underneath the loco in silver marker pen. That's what I do...

 

Andi

 

I have a yellow pen - will that do instead?  

 

Mick

Edited December 29, 2017 by newbryford

[Pete the Elaner]

Admittedly it breaks the existing standard, but what's to say that the standard cannot be improved and/or rewritten and consequently renamed? 

Why can't the standards evolve if better/cheaper components such as memory are available?

 

Although I quite like the sound of MCC, it will be forever associated with the humble game of cricket..................

 

Lets for an example, call it DCC mark2. (Which isn't the existing DCC but quite similar) 

 

All decoders that comply with DCCMk2 can run on original (let's call them Mk1 for sake of simplicty) system controllers but limited to 4 digit addressing. Likewise Mk1 decoders will still be able to run Mk2 systems - with the restriction of 4 digit addressing.

 

Or am I missing something obvious?

 

NMRA's DCC standards have been a huge benefit in making DCC what it is today. I can run my ESU, Zen, Zimo decoders with my NCE system or a friend's Lenz.

Introducing something outside of these standards will bring up back to the previous generation where different manufacturers did their own thing & you couldn't use a Zero 1 chipped loco with anything other than a Zero 1 system.

[Harlequin]

The definition of the addressing bytes in the "extended packet formats" section of the DCC standard allows for around 10,000 addresses and it's important to note that some combinations of bits in the two address bytes are "reserved for future use".

 

So, the number of address bytes could be increased in future within the DCC standard. I.e. the number of digits within a loco address number could be increased to 5 or more digits without breaking the standard.

 

Having said that, I agree with Ron: Decoder addresses are really a technical part of the standard, not designed for human readability or to be mapped to any prototype numbering system, and in setups with many decoders it's best to use a controller that can map human recognisable addresses down onto the raw DCC addresses.

 

For example, your controller should show you "4472 Flying Scotsman" rather than just "4472" so that you can avoid possible confusion with the roster of class 44's you might be running... ;-)

Edited December 30, 2017 by Harlequin

[John ks]

If I understand DCC correctly then the CV’s in the decoder are set so that the decoders know how to respond to the packets of information coming through the tracks

 

Each packet will contain

 

Start of message

Address (loco number)

Information (go faster, headlight on , sound horn etc)

End of message

 

When a decoder reads the start of message

It will read the address number

Depending on the address it will either ignore it or respond accordingly

 

A DCC+ system could use 3 or more bytes to store the extra long address ( there are CV’s that are reserved for future use in NMRA standards)

 

The DCC+ decoders would use all the normal DCC CV’s & would be backward compatible, including programming from any DCC system

 

When programmed from a DCC+ system the long address would be set to 9983*(highest valid long address) & the extra long address would be put into the extra long address CV’s

 

The packets from the DCC+ command station for DCC decoders would contain

 

Start of message

Address (loco number)

Information (go faster, headlight on , sound horn etc)

End of message

 

The packets from the DCC+ command station for DCC+ decoders would contain

 

Start of message

Address loco number 9983

Extra Long Address (loco number xxxxxx)

Information (go faster, headlight on , sound horn etc)

End of message

 

When you run your DCC+ loco on a DCC layout it will respond to 9983 as will any other DCC+ loco on that layout.

 

The smarts in the DCC+ decoder will be able to work out if it is on a DCC or DCC+ layout

 

Just a thought

John

 

*

I used 9983 so that so that locos could be run on an DCC & still keep the packets from the DCC+ command station fairly unchanged & compatible with DCC.

There are probably more elegant ways of doing this.

It also means that 9983 on DCC+ systems becomes an invalid address (like 9984-9999 on DCC)

[Oldddudders]

As others have said, a 4-digit number should suffice for any loco collection. Just knock off leading digits to arrive at the final four. And if that leaves zeros, make the number two or three digits, or even single.

 

I’m not sure I quite understand the fascination with anything but a number ID for a loco. After all, with very few exceptions, a number is what the prototype bears, typically to distinguish it from dozens if not hundreds of identical locos in the fleet. Names are much in the minority, and while some, e.g. GWR single-drivers or LNER pacifics, had inspired names, some have been just plain silly, e.g. Brighton Evening Argus, a loco named after a local newspaper. When trainspotting was perhaps more popular than today, because trains and locos were more numerous, we wrote down numbers, not names. The Ian Allan ABC books were full of numbers, with a small minority of names added.

 

Grahic images of a model only ‘work’ if the model is unique in your fleet. If you have even a handful of identical locos - surely a more realistic representation of the prototype you are modelling than the one-of-everything we so often see - the image may be less helpful. I have to regard this as a sop to ‘play value’ rather than adding something I would ever find remotely useful.

[RFS]

I would suggest the extra complication and incompatibilities introduced by any "DCC+" system are likely to greatly outweigh the benefits.  Someone would have to explain to all the DCC equipment manufacturers what the business case is for spending a lot of money on providing more than 9999 addresses, and maintaining 2 standards indefinitely.  And what about modern DMUs and EMUs which have 6-digit addresses? 

 

Also, I believe, most modern US locos have 4-digit numbers so would there be support from the US fraternity for such an enhancement?

[Butler Henderson]

Also, I believe, most modern US locos have 4-digit numbers so would there be support from the US fraternity for such an enhancement?

And given that the US market pretty well dominates model production globally - if the UK market came anywhere near then for example Kadee would no doubt be making offset NEM couplings to fit misheight sockets on UK models.

[WIMorrison]

Plus, how many people have more than 9,999 locos? Seems that they left more than enough space in the existing standard for people to uniquely identify each decoder.

[newbryford]

Plus, how many people have more than 9,999 locos? Seems that they left more than enough space in the existing standard for people to uniquely identify each decoder.

 

Agreed that 9999 is more than enough.

My suggestion - and basically that's all it is, is not about having more than 9999 addresses. It goes back to various posters comments regarding duplicated numbers if a particular numbering system is used.

 

As its is, when I'm wanting to add to my fleet, I'll consider it's intended DCC number based upon it's TOPS number that doesn't duplicate within four of us that provide stock for the club layout. It's not unknown for me to choose a different prototype to model if there is a clash.

 

 Cheers,

Mick

[Ron Ron Ron]

Plus, how many people have more than 9,999 locos?.....

 

 

It's a tempting challenge, but I think I'd prefer a death from natural causes. 

 

If you catch my drift?

 

 

.

[Ron Ron Ron]

.....I’m not sure I quite understand the fascination with anything but a number ID for a loco.

After all, with very few exceptions, a number is what the prototype bears, typically to distinguish it from dozens if not hundreds of identical locos in the fleet.

Names are much in the minority......

 

Ian,

Loco names in this context, refers to the use of alphanumerics. Numbers and letters.

Therefore a "loco name" could be entirely composed of numbers.

 

e.g.  using "92220" instead of "Evening Star".

 

 

.

[John ks]

I model mostly US prototype & while I havent quite got to 9999 locos I do have 10 locos with numbers ranging between 9000 & 9809

For US modellers 4 digit address up to 9999 works well 

 

For British modellers with 5 or 6 digit loco numbers some sort of compromise is necessary

 

As I posted early in this thread I settled on the first 2 & last 2 Digits

 

& then there is the ICE train with a number like 400 001-2 which for me becomes 4012

 

Until (if ever) we get a DCC "insert you favourite name here" system capable of 6 or more digits then were stuck some sort of compromise

 

John

[Crosland]

Unfortunately, I can't answer that one because I don't know why CV17 seems to have to have values between 192 and 231. 

 

It's not the CVs that set the limits, but the format of the packets sent by the command station.

 

It all starts with the first byte of the address.

 

A short address has only one byte and uses 7 least significant bits of a byte to encode 0 - 127 with 0 being the broadcast address.

 

Any address with the high bit set to one is further decoded into other "address spaces".

 

192 - 231 is a long addresses and need a second byte. The maths is earlier in the thread, but this leads to the 10,239 limit.

 

The values in the CVs must match a valid long address to be meaningful, hence the restriction on legal values in CV17.

 

As already pointed out, there is room for interpretation of what a system should present to the user.

 

Getting the NMRA to change anything would be a non-starter (look where we are with a standard layout control bus, it's been glacially slow with way too much internal politics).

 

An independent development would need a very brave manufacturer, willing to create an open standard. Look at the opprobrium heaped on "train set" DCC systems in some quarters for not being fully compatible.

 

My opinion is that "smarts" should be built into the command station with alpha-numeric virtual addresses presented to the user such as "Thomas", "Lion", "The big red one" etc., ... being mapped to that actual DCC address.

 

[markw]

My opinion is that "smarts" should be built into the command station with alpha-numeric virtual addresses presented to the user such as "Thomas", "Lion", "The big red one" etc., ... being mapped to that actual DCC address.

 

As has been said some systems all ready do that. What is missing is a means to transfer that info between systems from different manufacturers.

 

Most modern systems have USB/LAN/Wi-Fi so a physical means of connection all ready exists, only needs a standard for the format of that info to be decided upon and write the code to implement it.

 

There is an existing standard that is open source and requires no licensing fees. The JMRI roster file, a simple version would only need data for CV's 1,17,18 and 29 and the loco name, but could optionally include names for function buttons.