After a not-so-short retrospective, let’s look at the future/pending projects in the pipeline:

KTLO stands for “Keep The Lights On” -- we use that in the software industry to encompass all the invisible yet essential tasks that maintain systems in operations. I was not in the habit of listing these tasks before: all the layout repairs to turnouts or dead spots, or all the time dealing with automation engines that stop working -- because I can’t predict these, obviously, and when they happen they take precedence over whatever pending task I’m working on anyway.

However it turns out that these tasks account for at least half of my time, if not more. A lot of my planning involves having contingencies so that the layout automation is running 5 days a week, all year long.

One nice thing about that table above is that pretty much all the projects are now in the “want” category. In the project list from 2021, half of the projects were in the “need” category -- meaning I deemed them primordial to keep the weekly automation or the Saturday operations ongoing. A few of these projects are still there -- I simply split them into phases, and did the mandatory parts first, then I can go back and expand on a task later.

I want to expand a bit on the various “DCC control” tasks. After all, the layout has automation, so I’m done, right? Well, not really. What’s there is basically “phase 1” of a multi-phase development. That’s exactly what I was describing in the previous paragraph: I took care of the necessary parts first, yet at some point I want to go back to it and complete the original vision. I can have more monitoring of the trains, and I can provide new automation lines if I add these:

• Mountain Sensors:
• The goal was to add more mountain block sensors, e.g. finish the current panel and add to the other panel.
• Issue 1: In the current Mountain Panel 2, I’d want to redo my board to make it easier to add/adjust sensors, and incorporate the new IAScaled ones.
• Issue 2: A new added task has been to understand the issue with some of the Mountain blocks.
• There’s legitimate concern on the actual usefulness of sensors on Mountain Panel 1. I don’t plan to automate any engine run there. However I’d like to be able to detect trains not at the right place.
• Valley Sensors:
• I’d really want to have sensors on some of the valley blocks (not all).
• Issue 1: The major issue is that I don’t see an easy way to even add the sensors, physically, to the lines to be monitored. I simply don’t want to touch the panels like I’m doing on the Mountain Panels.
• One option I envisaged was to mount sensors after the distribution block under the yard. However all the wires are bundled and it’s really hard to discern which one is which. I also don’t want to touch the distribution block itself.
• I vaguely considered monitoring the “return” wires, but after realizing all ground lines are basically connected together, that’s absolutely guaranteed to fail.
• Issue 2: There’s a certainty that some of the blocks will be impossible to monitor that way, especially all the Stockton yard blocks or mainline which have multiple cross-linked feed points.
• For these, it would almost make more sense to have the sensors next to the feed lines at the track, either right out of or after all the complex relay routing.
• In a way, that could solve the above problem of not touching the panels.
• Turnouts Mountain:
• Issue 1: The Mountain turnout board needs to be entirely rebuilt. I wanted to come up with a clean board solution, the current one is messy.
• At the same time, I’d venture it’s worth controlling all the known-to-be working turnouts.
• Issue 2: Consideration should be given to whether they are Tortoise or Fulgurex.
• This one is easy because I basically don’t want folks to use the panel directly so I don’t care that toggle control is not an option.
• Turnouts Lodi:
• Lodi has very little usage so it’s not a stretch to ask people to use an NCE controller to toggle turnouts. Thus it could use a regular NCE Switch-8 with no toggle control.
• Issue: OTOH because it has little usage and it’s quite easy to access, it’s a perfect test bed to experiment with how I could have a Switch-8 and functional toggle control. The real usefulness of that is as a test bed for Valley below.
• Turnouts Valley:
• Toggle control is a requirement. I can’t just disconnect everything and ask operators to use the NCE controller for every single Valley turnout.
• The only ones I have converted this way are the “remote” turnouts for the other side of the Mountain.
• Issue 1: I do not want to “convert” more turnouts unless I have a way to keep the toggle controls functional.
• Issue 2: Consideration should be given to whether they are Tortoise or Fulgurex. Some of the cross-overs can be both.

One design goal was to keep using off-the-shelf components for blocks and turnout control.

For turnouts, we have 2 solutions:

• Concentrated at the panel, reusing the existing 12V control lines. That’s the NCE Switch-8 or the DS64 solution. Requires relays to deal with Fulgurex ones. The only issue with these is that none are designed to have permanent toggle switches as input, they all only support momentary push switches.
• They get their orders from the DCC track, so that works with JMRI, NCE, etc.
• In-situ at the turnout. That’s the Hare/Rabbit kind -- power from the DCC track, and monitor the DCC track, typically connected directly to a Tortoise.
• Pros: Good for new design layouts as the control can be local, and doesn’t need to run long cables to power/control turnouts.

None of the turnout boards I know work with permanent toggle controls. They all assume momentary push buttons, either as absolute or as toggles.

• One option would be to use a Switch-8 Button board. I’ve tried reprogramming one but it wasn’t so successful (it kept locking up). Instead I could have another custom ESP32/Arduino board in front that takes 8 permanent toggle controls and “transforms” that into momentary push button signals for the Switch-8 or a DS64.
• Another option is to directly send a signal to the JMRI computer. Requires a wired or Wifi ESP32.
• That goes against my goal of keeping off-the-shelf components that are easy to source and replace.