Electronics are expensive
Let's be more concise. Garden scale electronics are expensive, if available at all. I can't remember the last time I saw anything new when it comes to controlling trains. There are DCC offerings from a handful of manufacturers. They have managed to keep up with the times. The "drop in" DCC offerings are custom fit to specific locomotives and convenient. The freedom of battery powered wireless remote control is appealing. And expensive.
But then again, we're the oddballs, still powering our equipment through the track. There are many posts that cover converting to battery power, most likely using a wireless receiver. For those with deep pockets, live steam doesn't require power through the track either. Remote control of those locomotives involves wireless servo control via radio, similar to model aircraft.
There are Digital Command Control (DCC) systems available, and for the price, may fit the bill for your needs. Shelling out $600 or more just to control trains, before buying and installing decoders in locomotives and rolling stock is expensive, and still relies on power through the rails. Battery power requires a wireless receiver in addition to the decoder. That becomes a very expensive proposition for even a single locomotive.
We put something together for far less, that does the same thing, including the decoder. The most expensive part is the motor controller itself, but even that is under $20, and can handle more than 10 amps! The heart of these gadgets is a WiFi enabled Arduino module. Our gadgets support battery operation as well as power through the track. In fact, the block controllers can actually power the track, even reporting real time current sensor data on the web page!
Electronics are complicated
Yes they are. Very complicated. But the good news is most of the difficult stuff has already been handled for us. All we need to do is "hook everything up". If my Circuits III professor is reading this, I know, I fail the class just by saying that. The proper terminology is "connect everything together", and in essence, all that's required for most of these gadgets. That's the easy part.
The hard part is programming the Arduino module to do what we expect of it. Again, the good news is most of the difficult stuff has already been handled for us. There is a software module to handle just about everything out there. A giant, open source library, available to anyone with a PC and the ability to download it from the Internet. While it's not quite JMRI, our gadgets are web based, and most of that framework is already done for us.
What's JMRI? The Java Model Railroad Interface, JMRI for short, has been around almost as long as DCC. It's designed to reduce the complexity of DCC, translating the "computerese" into human readable form. Can't remember what Configuration Variable (CV) controls what? JMRI hides that. It controls the headlight on the locomotive without having to remember it's function 1 (F1) at address 13. Or was that 19?
DC vs. DCC vs. Battery
I've always run DC power on my HO scale pikes. DCC promises all that is needed is a single power bus, without the need to connect wires from panel switches to every block. But then it introduces power districts and circuit breakers connected to every block! Substituting a 69¢ toggle switch on the panel with $69 district power manager and circuit breaker module seems a high price to pay.
The discussion now becomes whether the cost justifies the elimination of having to manually flip a bunch of toggle switches on the control panel. Basically, "set it and forget it" vs. constantly stressing over which switch to throw next to run more than one train at once on the same track. Another tradeoff is DCC boosters vs. the number of "cabs" for DC. Typically two cabs for a mainline stretch of track, perhaps more for handling a switch yard.
We're migrating to battery power, while retaining power over the rails. A common complaint of battery powered operation is limited running time between long recharging times. We're working toward recharging while running, combining the advantage of wireless remote control with unlimited running time of power through the rails, the only feature missing from our passenger car lighting solution.
We need a hybrid approach that combines the advantages of the different approaches to overcome their disadvantages. An approach where the power to the rails is always present, able to keep onboard batteries charged, and DCC enabled to control equipment without the need for WiFi. Equipment like signals and switch machines, that can be powered from a single DCC bus, fits nicely into the latter category. No need to have hundreds of devices connected the network just because they can be.
Layout Control System
If you've made it this far, you may be asking "What's the point?" Automated layout control is the answer. Our goal is to have the entire layout operate with the flip of a switch. Granted, that sounds a lot easier than it is. The first thing we do when we run trains is "send a scout" so to speak. We walk the rails, sighting and manually removing obstructions, like twigs, acorns, and the like. Anything that would cause problems and derail a train.
There's just no way to automate that. Same with running the Egg Liners around the layout to test the track. We call them Doodlebugs, but we know they really aren't. When one can make a complete trip around the layout without flying off the rails, we add a track cleaning bobber caboose ahead of it, then let the combination make several more passes around the layout. The caboose is far less forgiving of poor track conditions than the Doodlebug alone.
Automation relies on sensors and feedback, as well as knowledge of the layout topology. It needs to communicate commands to all the things it must control. Receive status feedback from that communication to be sure the command was received and acted upon as expected. It needs to deal with exception conditions. Most of all, it needs to know about trains and consists and schedules, where they're at, and where they're going.
We don't use JMRI, mainly because we don't use DCC, but I'm pretty sure neither can automate control of our layout either. One thing JMRI does add is a more human friendly interface than inserting a bunch of hexidecimal numbers into machine registers. Our gadgets continue to use that human friendly approach. For example, throttle control settings are from zero to one hundred percent, not one of 28 steps and guessing how fast that is. Really only 26 steps, but...
If using speeds steps is more comfortable, the user interface can be configured accordingly. Prototypical diesel locomotives have only eight notch settings, but a heck of a lot of momentum to overcome in the process. That style of operation is possible, but requires simulation of all that momentum just to overcome it. All considerations for our automated layout control system design.
The idea is to allow control of each block individually, like with DC wiring, except DCC is also an option. Perhaps not powering the block at all, supporting control via a wireless connection. Current sensing is used to monitor block occupancy when the block is powered. Other means are used when not powered, like infrared proximity detection.
We're certainly not there yet. But what we have so far is all web based. Anything that can support a browser can control our gadgets. Things like smart phones, tablet computers, even a Raspberry PI. The gadgets themselves serve up the web pages that allow control of their operation! If you don't have WiFi, our gadgets can act as a "hot spot" to allow your smart device to connect directly.
Controller Highlights
The following video is a demonstration of the block controller configured as an analog DC throttle to directly power the rails. Pulse Width Modulation (PWM) is another option. A third option is DCC, still under development. The beauty of this arrangement is even without WiFi or a computer interface, the front panel controls are all that's needed to run trains! My affinity for analog panel meters shows. Call me old school if you like...
Another helpful feature shown here is distributed control. Simply put, control can be shared between many users. For example, one user at the control panel, one on a computer, and yet another with a smart phone. The front panel control is an encoder, so it doesn't matter what the absolute position of the control is, just how much it's rotated since it was last stationary. In effect, it "counts" the "clicks", adding to or subtracting from the desired speed.
Any devices connected will display updates from any of the other devices, so all control panels remain synchronized. If the panel knob is turned, the on screen slider is updated accordingly on all of the computer displays. If the slider control on one computer is operated, the other displays are updated, and the speed adjusted to match the request. Essentially all commands are acknowledged. The response is broadcast to all devices and used to update the displays.