Peter's Model Railroading | Articles | Electronics | Battery Power
S-CAB Design

Neil's S-CAB system was designed for those people who are still running their layouts with analog/DC power. Surveys show that that is still a majority of model railroaders, despite the inroads that DCC has made. DCC is not cheap, and it is definitely not intuitive to use or "debug". The S-CAB system is the simplest system that I have ever used. Here's my typical scenario, from making the decision in my mind to run one of my trains:

1. Turn on the S-CAB throttle (small switch on the left side of the throttle).
2. On the locomotive, wave the magnet wand over the reed switch.
3. Move the speed slider on the throttle to move the locomotive.

We are literally talking 5 seconds here from deciding to run an engine to actually running it. No other system can do that from a totally "off" state!

However, the S-CAB system is not perfect and does have some limitations (on purpose). It is up to you to decide whether these limitations are deal-breakers for you.

1. It only supports two-digit addresses (most DCC systems can use 4-digit addresses).
2. Multiple-unit consisting is not directly supported.
3. Programming is easy, but the throttle only supports a handful of CVs.
4. Throttle doesn't remember the previous engine's settings (controls are mechanical).
5. The throttle can only talk to the receiver, but the receiver cannot communicate back to the throttle.
6. There are only 28 speed steps.
7. There is no support for accessory decoders.
8. Detection for controlling layout signalling is not directly supported (applies to all battery-powered systems).

With a bit of creativity, there are solutions for each of these:

1. I use the last two digits of the locomotive's engine number as the programmed address.
2. I don't do MU, but if I did, I would use the same address and use the same type of locomotives to consist.
3. I have been able to get satisfactory results with just the CVs that it supports for programming.
4. It is easy to switch between engines, but when you do, you just have to play with the physical controls on the throttle to adjust the engine that you are switching to; all it takes is a bit of practice to get used to it.
5. The only time bi-directional communication comes in handy is when programming the decoder; there is no way to read-back what the decoder is programmed to, so you either re-program the value, or you write it down in a journal or a software application.
6. I have found the 28- vs. 120-speed-steps to not be an issue in real-world practice.
7. I had to come up with a different way of controlling my turnouts, but it turned out to not be that big of a deal.
8. For signalling, I am thinking about using infrared detection circuits embedded in the layout (but currently I have no need for that feature).

There is an upper limit to the amount of current the BPS can supply to the decoder. As of September 2017, Neil's BPS boards are able to produce up to 1 amp of power. The older version I have only produces 1/2 amp, but it appears to be sufficient for my S-scale engines. For large power demands, such as with larger O-scale engines, Neil offers 4- and 8-amp receiver/decoders that will work with the radio frequency communication, but require custom battery power installation. These need to be series-connected larger batteries, such as LiPo (3S or 4S, i.e. 3- or 4-cell batteries), with an external charger. Contact Neil for more info, if this covers your scenario.