DCC Accessory Addresses - A Single Group?

[C855B]

With the GC&W electronics starting to come together, I could stand some help with clarity on DCC accessory addressing. After multiple web searches, clarity is not forthcoming. I am dealing with:

• Turnouts
• Detection
• Signals (per signal head, in my case)

The question of the moment is, "Are there (just) three unique DCC address groups, Locomotives, Accessories and Sensors?", begging the question whether turnouts and signals are all lumped into a single "accessory" group, and need unique addresses relative to the whole group.

I guess what I'm asking is whether there is a unique "Signals" command group. There is a bit of obfuscation with many or most of the signal boards designed to piggyback on turnout commands supposedly to make signaling "easy", without separate logic. This method somewhat falls apart under JMRI.

Also, where does transponding addressing fit with this, although it is not in the short-term operating plan?

[John]

Mike .. each device (signal head, turnout, etc) will need it's own SW address ..

I use a mixture of digitrax and rr-circuits devices .. and what normally happens is that each board has an address, which then supports a range of SW addresses.   it would help if you describe what your architecture is going to be ..

[C855B]

No issues with multi-address boards and the subgroups that go along with managing those addresses, the burning question is if I have a turnout 101 (LT101 in JMRI parlance) and a signal head 101 (LH$101) is it a conflict? Or, even worse, if I have a locomotive 101, a sensor 101, a turnout 101 and a signal (head) 101, who overlaps?

To answer your question, however, it's a peculiar mix at this point. Tam Valley Singlet II for some turnouts, Tam Valley QuadLN_S for clustered turnouts and general occupancy sense logic (MRCS cpOD at the rail level) and Team Digital SHD2 for signal heads. Everything works great so far, but I will be integrating the signal boards in the next couple of weeks and need to rework the address planning if turnouts and signals are in the same address space.

[C855B]

Experimenting, two useful data points that more or less answer the question:

Signals and turnouts can overlap addresses. In that case, the turnouts understand turnout commands (only) and the signal decoders understand signal commands (only). Certain signal decoders can be configured to understand turnout commands to display aspects based on routing. Without monitoring DCC packets, the only possible downside I can imagine is both decoders sending return acknowledgements to the control station. However, I think the SHD2 decoders don't have a transmit capability, they are simple listen-only devices.

Second, I had it in my head that accessory decoders were limited to three digits.   [sigh]  Just solve the issue by using the leading digit as a device group indicator, 1xxx for sensors, 2xxx for turnouts, 3xxx for signals, u.s.w. We're not talking duplicate loco numbers here.

The need to solve this now is pretty significant. As far as I know, the JMRI UI doesn't have any facility for editing hardware addresses. The only means to change an address is to delete the entry and create a new one. That creates all sorts of downstream issues once you get into signaling logic. I don't want to build half the layout and discover at that point the address scheme falls apart.

I could possibly edit at the JMRI XML level, but there are many hidden connections within the XML to trip me up. I tried this with the system I used to admin (similar architecture), and got myself in a world of hurt on a live customer system. Thank goodness for backups!

[bdennis]

Mike,
Here is how I see it.
Lets assume your using Digitrax and JMRI. Lets assume your using Digitrax products and loconet for turnout control, signal control and block detection. (But it works the same if you are using other Loconet connected devices)
There are 3 types of addresses. Loco, Input and output. (or Loco, Sensor, and Switch)
So you can have a loco address of say 51 and a Sensor 51 and a switch 51. There will be no conflict. So now lets focus on Sensor and switch or in JMRI speak "Turnout".

In JMRI at the lowest level you will have a large number of LSxxx inputs or sensors and a large number of LTxxx outputs. Note the "S" for Sensor and the "T" for turnout / output.
Each Loconet connected device will have a board address.. This board address is only used to program the board it self and configure the ports on the board. Once the board is configured, the Board address is no longer required and is not needed within JMRI.
The critical factor here is that you cant have 2 boards or devices with the same output number or sensor number.
It then gets confusing if your using digitrax products as the board ID for a BDL168 can be the same as a SE8C. In these cases the board address or number determines the sensor or output addresses.

When planning a signal system or a system that is going to drive turnouts and a bunch of other sensors, it is critical you you plan and document all the boards your have and the ports they have on them and then the addresses of those ports. I have designed and built 3 JMRI systems on 3 different layouts all with 10 + various types of sensor and output boards on them and this "planning" part is critical..

In terms of signals within JMRI. Yes there are signal heads and signal masts. But at the micro level, those signal heads and masts all have multiple Output or LTxxx numbers associated with them.
You can have LT89 and SH89.. They wont conflict.
Lets assume you have a signal mast on a SE8C and the mast is a 2 search light mast and each search light has 2 colours. Green and red.
To make this work, you have 1 Signal mast, 2 signal heads, each signal head has 2 LTxxx outputs.. So thats 4 outputs for a single signal mast.
To signal a single turnout with signals that are 1 search light per mast, you need 3 masts, 3 signal heads and 6 LTxxx outputs.
Again, this all needs to be planned as it helps for fault finding if you have all the ports documented to ensure no over lap..

Thats only Signal outputs.. Then you have LSxxx sensors for block detection or other inputs..
You can have LS89 and LT89.. There is NO conflict..

I developed a excel spread sheet to plan and track the port numbers on the 20 odd boards on had on my layout to ensure that there were no conflicts. Its not a complicated spread sheet.. Just needs to be done.

Make sense?

[John]

No issues with multi-address boards and the subgroups that go along with managing those addresses, the burning question is if I have a turnout 101 (LT101 in JMRI parlance) and a signal head 101 (LH$101) is it a conflict? Or, even worse, if I have a locomotive 101, a sensor 101, a turnout 101 and a signal (head) 101, who overlaps?

To answer your question, however, it's a peculiar mix at this point. Tam Valley Singlet II for some turnouts, Tam Valley QuadLN_S for clustered turnouts and general occupancy sense logic (MRCS cpOD at the rail level) and Team Digital SHD2 for signal heads. Everything works great so far, but I will be integrating the signal boards in the next couple of weeks and need to rework the address planning if turnouts and signals are in the same address space.

Ok .. I got it now .. so with JMRI  .. if I am using Digitrax with Loconet ..

Turnouts are driven by switch SW .. so you could have turnouts SW1-9999 an they would hve loconet IDs of LT1-9999.. signals heads are composed of switch entries LT1-9999..   Sensors are listed as LS 1-9999 etc ..

So, lets look at a device .  I will use an SE8C Signal controller .. since I'm most familiar with it ..

Lets say that our SE8C has a board ID of #1

An SE8C has 8 driver sections ..  and assuming we are going to drive signal heads with 4 aspects .. R/G/Y/Flashing you can drive 4 signal heads per driver ..  the "Switch" range for driver1, is LT257-264 .. and so forth .. (see the digitrax manual for SE8C page 7) .. an SE8C also has the ability to drive 8 turnouts .. board ID 1 by default will drive LT1-8 for your turnouts .. and accept sensors on LS1-8 ..

This is where it can get confusing ..   

If you decide to use the SE8C to drive both turnouts and Signals for the entire layout, then you just change the board ID, and everything adjusts accordingly .. but if you use other loconet devices, you have to map in the switch ranges and the signals ..

On my layout, I use turnout numbers 1-100 .. so in JMRI, LT 1-100 is turnouts .. that allows me to then keep my signals at LT257 and above ..  I have 5 SE8Cs, and 5 DS64s and a few other odds and ends ..

Just make sure that you keep turnouts and signal heads "switch" settings from coliding, and you should be OK ..

I hope that makes sense .. I can send you my jmri files if you would like to see mine in action ..

[C855B]

Appreciate the help, guys. I think the most salient information was establishing that there are three different DCC address groups - locos, input, and output. Turnouts and signals fall into the output group, so each device must have a unique address, whether the device-decoder ratio is 1:1, or there is a clustered decoder with a base address controlling multiple devices, i.e. A, A+1, A+2, etc.

In the case of the Tam Valley QuadLN_S, turnouts are base address (T₀), then T₀+1 through T₀+3, optionally to T₀+7. Sensors have two base addresses independent of the turnout address group, for S₀, then S₀+1 to +3, and S₁, then S₁+1 to +3. Adding to the fun is a unique board configuration address, usually > 11000, and this would be in the output address group.

Bottom line in this case is the sensor address group is a unique subset, turnout addresses are not a unique subset, and therefore must be managed in concert with signals and board configs in the output address universe.

While I do plan a spreadsheet to keep track of all this (grand plan is around 300 turnouts, 150 signals at last count), imposing an address numbering protocol based on layout location and device type will assist immensely in controlling conflicts.

[bdennis]

John,
Yep spot on.
The SE8C can get confusing due to the Signal outputs starting at 257..
Per your post. The key is to keep track of what port numbers are configured on each board.

Mike,
Yep spot on....

Re outputs.. Yep turnouts and signals effectively use the same output range....

[C855B]

After further research, back to the drawing board. With only 2044 addresses (9 bits minus 3 reserved, 2045-2047) in the accessories address space, any large-scale grouping scheme falls apart. Device addresses need to be assigned serially, or close to it.

Which reminds me... JMRI can handle multiple network interfaces. Device numbering can start from 1 for each network. By chance do any of you know where the theoretical and practical limits are? Can a single JMRI instance on a reasonably powerful front-end drive four, five or even eight DCC interfaces/command stations?

[bdennis]

Mike just remember you can have 2044 Inputs / Sensors and 2044 outputs..  thats 4088 ports in total.

I had a layout in a 20ft x 26ft room with over 15 odd different boards.
I mounted the devices in locations around the layout and made labels for each of the locations that list the board ID's and the port ranges. This helps with fault finding.
With your size layout, you will need to plan / document all the boards and ports so using a excel sheet you an easily copy the data and make labels.

I would think that if you wanted to split the loconet bus and have 2 Locobuffers that would be sufficient for your needs if the 4088 ports per above are not..??

[C855B]

Yes, the unique sets of input and output addresses have been taken into consideration. With a new numbering scheme, I finished the spreadsheet entries for the first peninsula last night. With the most numerous device (signal heads) topping out at 36, so far it appears that everything in the layout will comfortably fit within the 2044 for each range.

The challenge with the numbering convention was whether breaking the peninsula districts into groups of 99 would be sufficient for the most-populated districts. For example, per convention the first peninsula devices fall in the ranges LT101-LT199, LS1101-LS1199 and LH$1101-1199. Second district, LT201-LT299, LS1201-LS1299, LH$1201-1299, and so on. IOW, do any of the districts have more than 99 of each device type? Fortunately there are 8 districts, so I can keep two groups of 3*99 in reserve for overflow (no risk of exceeding 99 sensors even in the dense districts - I'm not detecting yard tracks! ).

I am probably looking at three USB-Loconet interfaces of some manner, one for train control, and two for accessories. (I'm leaning pretty hard towards a DCS240 for all three, as a DCS150 plus AR3 or Locobuffer total to roughly the same (street) price. Weird.) I am somewhat concerned about Loconet throughput (it's only 100kbs*), and then there are the device groups (mostly signals, some turnouts) on the power bus (10kbs!).

* - I'm not factoring throughput reductions from ALOHA collisions here, which can take performance down to a realized 27kbs. Loconet is an asynchronous bi-directional network with event-driven peripherals, where even small numbers of potential "talkers" on the network affect real-world bandwidth. I've read somewhere that Loconet can tolerate up to 40 LN-resident devices without a repeater, but I think that's from a bus power perspective, not comm capacity.

LCC is not in the picture.

[John]

Mike .. I think you are worrying too much .. I have a large layout that is fully detected, has signaling, run SE8Cs and other devices .. if you keep the trottle net and the booster net separate, you shouldn't have any issues .. the JMRI will work just fine on one locobuffer .. if it gets to complex, get a loconet repeater.   your not controlling planes here .. and a 1 second delay between detection and consumption by the JMRI computer will not be that significiant .. especially if you force the layout to run at scale speeds ..

[C855B]

Mike .. I think you are worrying too much ...

"Worrying" was in my job description, John.   Like I said, I did remarkably similar integrations in my working life, I know where the scalability gremlins tend to hide, and... frankly... where the mfrs' specs are so much crap. The big difference is these hobbyist systems don't really take into consideration the 99th-percentile user, and much experience tells me there will be a performance wall... somewhere.

So a little bit of extra hardware cost and design work in the beginning in planning to hit capacity thresholds is going to save beaucoup re-engineering effort downstream. Been there, and the T-shirt is now a rag being used to wax the car.