Thank you for making this

Thank you for making this easy to understand .Much appreciated!

Every tidbit helps.

Thank you for a well written article. I use NCE at home and Digitrax with a modular group. The short address information will be something to watch for as I program on my NCE Powercab yet end up on the Digitrax layout.

I am a little confused by the last couple paragraphs. On NCE Advanced Concisting 4th paragraph you stated that this type of consisting could become problematic when moving from one system to another. In the last paragraph you state the advantage of Advanced consisting is that it is transportable. Maybe I am not understanding correctly, but please clarify.

Are there any additional steps if I move my NCE created Advanced consist to a Digitrax layout? 

Thanks

Sorry for the confusion, John

I tried to make a differentiation between Advanced consisting being set up by programming CVs (decoder based) vs. being set up using the NCE Advanced consist function (system based).

I recommend decoder based, as it will work on your NCE system or the club Digitrax system.

If you are moving between systems, a decoder based system: either Basic or Advanced is the only way to fly. Moving consists set up by a system (Digitrax or NCE or any other manufacturer) between layouts is an opening for frustration.

Guess I didn't make the terms obvious enough. Sorry.

Long addresses from 0 to 10239

My point, Dave!

The NCE system by itself doesn't address above 9999.

Yes, JMRI, under the conditions you mentioned, can.

Thanks Bruce.

I appreciate the clarification. I had issues from the get go after setting up Advanced consists on my NCE Powercab  just to have it inoperable at the show with the Digitrax command station. So my solution is to change the CV's themselves and I should be golden.

...

High time this relic of the past gets the decoders upgraded to alpha numberic capability out to ten digits and this diversity of addressing modes goes the way of the dinosaurs....someday, I can dream!!

In order to represent a 4

In order to represent a 4 digit decimal number you would need 14 binary digits/bits.

So this would actually give a range of 0 to 2¹⁴- 1 = 16383.

10239 = 10x2¹⁰ - 1

Also why not 16 binary digits or 4 hex(base 16) digits?

So what happened to the other address be it based on 14 or 16 binary bits?

Some address bits are flags

Thanks

Thanks for explaining how addressing works. Your remarks about CV 19 could be most helpfull. 

I wish I had read this three

I wish I had read this three years ago when I first started to read into DCC. A consist made no sense at the time!

Long DCC addresses for locomotives with five digit numbers

Your recommendation to use the first four or last four digits of the locomotive number is a great idea. The last four digit approach will work on my five digit numbered British Railways locomotives. My model of "Tornado" 60163 will be addressed as 0163 etc.

Regards

Rod Tonkin

South Africa has a similar

South Africa has a similar conundrum... diesels are numbered 34-228, 35-624 or 43-003 etc etc... any suggestions?

Long Cab Numbers

Al -

I don't have any suggestions short of what was in the article.

Well, perhaps one, model North American trains! Very Big Grin

Very interesting but puzzling too.

As someone who worked in both the hardware electronics industry and later in the IT and network side of things, I find it puzzling that the NMRA adopted such a complicated schema. Why didn't they look at some of the network protocols out their such as IP where devices are addressed in 4-part Octal addresses such as nnn.xxx.yyy.zzz?

Given that each of these slots can support up to 255 possible combinations, the addressing here is limitless for model railroading. There would still need to be reserved slots and ranges which could be used for devices, peripherals, and then locomotives.

Without getting too technical, the first two positions, reading left to right, could be used to specify a device and type with a specific range of octets. The latter 2 slots could represent a channel and then actual physical device number.

The device number would be a physical address which the system sees, but we refer to it through what is called a logical address. This would get around the problem with assigning locomotive numbers to the DCC device.

Keeping this in mind...

If the spec was set for locomotives to be in the 192.168.yyy.zzz range then we can have 255 possible slots (channels) with 255 locomotives.

And further on, Locomotive 192.168.1.122 for example would be entered into a look-up table, not much different than assigning a channel today to a locomotive number. The look-up table would contain the physical address of 192.168.1.122, but that would refer to ATSF 238 which could be keyed in easily

John

Bruce, The problem is that

Bruce,

The problem is that almost all rolling stock is South African and it is all going over with me to Australia, 3x 42 gallon boxes full... I think I'll have to start buying some Australian stock from now, that will solve some problems

Dear John, You've answered

Dear John,

You've answered your own question. Put simply, unless someone deployed the built-in "lookup table" within the Comand Control System, 
(and the required interface to use it,
remember that DCC control system designs predate anything like a readily-available Arduino, Rasberry Pi, Panda, or NUC),

the average modeller is not going to do the IP-address <> "real loco address" conversion in their head.

That the DCC spec was donated to the NMRA largely "fully-formed" by Lenz means that many "why did they do it that way?" issues can be traced waaaay back to "that's how it was from Day 1"...

(Not saying it always has to forever more be that way, but there are solid tech-history reasons why it was/is...)

Happy Modelling,
Aim to Improve,
Prof Klyzlr

PS The RailPro system more closely matches the design ethos you are hinting at. However, the RailPro system equally demonstrates the compatibility issues such an approach entails RE interfacing with "traditional DCC"

...

Why are we still trying to do "computer work" in our heads?

You don't remember what IP address goes where, you remember the road number.  When you type in the road number, the software looks up the decoder based upon what road number you enter.

South African Diesels

Seeing as the 34-  35-  etc are only the Class numbers and all diesel classes are thirty-something except Class 43 (???), why not just drop the first digit and give loco 34-228 the number 4228.  It would then be understood that 4228 is actually Class 34 diesel number 228.  This would solve all your problems except if there are any clashes between Class 33 and Class 43.  In that case you are out of luck and will need to renumber one of the locos!!!

I suspect that once you start adding Aussie loco numbers to your roster you will have more number clashes.

Time to get out the decals (grin).

un3k

I had thought of that and

I had thought of that and considering diesels run on numbers 31-xxx through to 37-xxx (its a real soup of numbers) and then 39-xxx and 43-xxx

I do just wish that more models were produced but the modelling scene is rather small.

Any other RSA or Oz modellers out there?

Dear Al, Not actively

Dear Al,

Not actively modelling Aussie outline, but based out of Sydney NSW...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

PS the current project, due for debut 1st March, is NSWGR-esque, with a twist...

PPS the NSWGR had the 48-class (Alco 531 hood unit),
with 164 members (4801 thru 48164),

but also has a later 81-class (EMD SD40-2 in full-width body dbl-cab flavour)
with 80 members (8101 thru 8180)

Using 4-digit addressing ,
obviously 48101 - 48164 and the much of the 81-class roster are cruising for address-crossover hell... 

I guess there is one easy way

I guess there is one easy way to avoid the issue. Don't buy all the locomotives.If you have a total less than 40 you should easily be able to keep them separate just using the last four numbers. To steal a line from an Indiana Jones Movie, The Last Crusade, "you must choose wisely."

Rob in Texas

I so needed this!

I'm a little behind in my reading, but this was a timely article, as well as a very informative piece of DCC!  Thanks!

R/,

Norm

You are most welcome, Norm.

You are most welcome, Norm.