Addressing for the SC1

[speedstor49]

It would be great if the SC1 could be programmed for individual port addressing in a similar way to the Train Tech signal controllers. It would make linking signal and points addressing a lot easier.

[Paul Harman]

There are a few reasons why this has not been done.

1. I wanted to make the decoders as NMRA compliant as possible. The NMRA standard CVs have no facility for non-contiguous addressing so it would have been impossible to make the accessory decoders NMRA compliant and have non contiguous addressing. You will find that decoders that have non-contiguous addressing capability are either very simple, have no capability for service mode programming on the program track or in most cases neither. Being able to use a tool such as DecoderPro to configure the SC1 is quite key to how most people will use it. The SC2 point decoder uses contiguous addressing too, so with a bit of planning this should not be an issue

2. Many of the configurations require more than one address. Not having contiguous addresses would significantly overcomplicate configuration.

3. Since signals need to be driven from a control system in practice it does not really matter what the addresses of the signals are - as long as they are known they can be assigned to the control system. The programming jumper address learning method ensures that the decoder address is set to match control system.

4. The extra processing required in the decoder to match incoming addresses against a list of addresses for the various ports (up to eight on an SC1) is likely to result in delays such that incoming packets could be missed. This is not so much of a problem on simple decoders like the Traintech decoders with a maximum of two ports.

I guess that if it had been seen as a problem the NMRA would have updated the spec for accessory decoders to allow non-contiguous addressing within decoders, but that has not happened. If the NMRA spec changes the Signalist accessory decoders will be updated to match.

[speedstor49]

Thanks Paul.

I had been hoping to use the same address for grouped points and signals so that the signals automatically change, as appropriate, when the points are changed. However, since I am using semaphore signals, which do not move as quickly as the points, I expect the purists would be unhappy that the points change slightly before the signals. In the real world, I suspect that this would be considered dangerous practice.

[Paul Harman]

It is probably best to get a Raspberry Pi (or similar inexpensive computer) and run JMRI to sort out all the timing for you with the added benefit that it will do all the signal interlocking logic as well. Systems like NCE have macro capability which will do sequencing for you if all you want is quite simple.

[speedstor49]

Thank you for that. It sounds like an excellent solution. Time to dust off an old redundant PC or laptop.