The Branchline Automation has been failing for a week or two now. It seems to start ok, then fails mid-morning. Symptom is that the train drives back in recovery mode, whilst it’s already on the parked block. As a one-sentence recap, one of the main design points of Conductor 2 is to have fancy recovery abilities in the automation script to be able to re-align the trains when they are not at their expected locations.

Checking the logs last week, I could not figure why it failed in the first place. Let’s try again.

After monitoring the train for a little while this morning, I got this:

Thus the automation control sees 3 blocks occupied, whereas the train is visually stopped at the boundary between B820 (BL station) and B801 (BL parked). It goes without saying that only one block should be occupied here, or maybe 2 if the train is stopped at the boundary between 2 blocks.

Something interesting in this log… (Line starting with ⇒ are my annotations):

Orion is working on a project favorite of his: creating an internal intercom system for the Randall Museum Model Railroad.

When it was part of the GGMRC, the layout used to have a few phones connected together to a single phone landline. This project is not linked to that at all -- the landline is long gone.

The root of the project is that we have 2 yards on opposite sides of the layout, separated by a big mountain in between. If someone wants to enter the mainline from the back, it would be nice if they could talk to the operators in the front to warn them they are going to enter the mainline. Something other than yelling across the room -- which doesn’t work on a loud busy Saturday morning anyway.

Thus the project is to create an internal-only “intercom” system with 3 phones connected to each other. Orion wants to use POTS  wall phones, such as the one depicted on the left above, and use them unmodified.

To that order, he has installed some phone jacks and connected them all together.

My understanding is that he’s powering the phones by injecting 12 V DC on the line with a resistor. I need to double check and write the specs for this down here.

Overall the system now works -- both operators can pick up their phone and talk to each other.

What’s missing is making the phones ring. I suggested we simply simulate a ringer - an arduino with a speaker would be trivial to make that happen. Instead, Orion would like to stay true to his project and make the phones actually ring. Which would mean to introduce the proper ring signal on the phone line (90 V at 20 Hz). Challenge accepted? Sure. But that means what could have been accomplished in a few minutes is now going to take months whilst I research this. I did point out that was overdoing it, but then that’s his choice. As Voltaire said, le mieux est l'ennemi du bien.

https://pbxbook.com/other/trunks.html has some pretty good explanations of POTS signaling -- which is quite relevant because these terms have a railroad origin. I encourage you to read that site.

Unrelated anecdote: if you were in the US around 2005-2015, you would have heard of the Sprint Corporation -- they used to do landline phone and then cell phone before generating their own demise due to poor management. But more to the point is that SPRINT is a direct offset from the Southern Pacific attempt at using their track-side telegraph lines to compete with then-monopole ATT on long distance communications. See details on Wikipedia here.

UP 8330 is now the pulling mainline passenger train, replacing Walthers UP 8312:

You might recall UP 8330 has been its own little saga, and is now working fine after a motor swap (under Walthers’ warranty) and a brand new LokSound 5 decoder (out of pocket expense).

UP 8312 has been running nicely since February, yet I recently had issues where it would not stop when coming back to the station at the end of its run. The first time I found it on this stopped here on this dirty track spot:

Orion and I have completed fixing the ceiling light fixtures above the mountain. These fluorescent lights went off somewhere back in 2017 and were left unchanged because they are really hard to reach. This job has just been completed and it took about 3 hours to change the two fixtures:

The train room features fluorescent light fixtures which date from the 60s. They use old style ballasts, the kind filled with PCB, and some of them have leaked over the years. We already tried using Type A LED tubes in these and they won’t even work properly.

Back in 2023, I replaced one of the (somewhat) accessible light fixtures over Richmond Yard using one of the new-style “integrated” LED fixtures. This involves removing the entire old fixture. Instead, for the rest of the train room, I decided it would be easier to just do a fixture rewiring and use Type B (aka “Direct”) LED tubes, which would allow us to keep the existing fixtures in place. Orion was interested in learning more about that and do it, so I had him practice on the workbench using the old fixture from Richmond Yard, and once he got the hang of it, he did an in-place rewiring of the fixture in Lodi. That was a good learning experience and a great spot to do so because it’s easily accessible.

We had wanted to change the dead ones over the mountain for quite a while, but as you can see below, one challenge is getting in there and accessing the fixture:

For the new lights, I particularly like the GE Hybrid 32W QE T8 -- these can handle both Type A (ballast) and Type B (direct), and they have a physical color switch to fix them to the color temperature we want -- in this case 4100K.

Rewiring is actually a fairly easy job:

I’ve reinstalled the tablet by the Stockton Yard’s Valley Panel:

It had been out of commission for a while -- it wasn’t booting, that has been fixed. I also updated the RTAC software to work with the latest Conductor 2.

There’s a similar tablet in the front to show the currently running train to the public.

This one is for the Saturday Operators. They can see the state of the automation (whether it’s on, off, or in error), and when one swipes on the right pane, a map is displayed that shows the state of the track occupancy sensors:

Recently I was using a DIY “voltmeter car” to measure the NCE Boosters Voltage Levels. That’s how I found one of the boosters had the wrong voltage setting. I’m still getting sporadic reports of power loss in the mountain, and I ordered a RRampMeter to investigate this in more detail, yet in between I thought it would be nice to have an actual static display of the boosters’ voltage so I made this:

The design is fairly simple:

• 4x AC-DC Converters
• 4x DC Voltage Displays
• 1x 3d-printed case https://www.tinkercad.com/things/8XPdA7QdPjB-quad-display-voltage

I have just added this control switch to the automation computer:

What the heck does that even do? Well, it’s rather simple, really: the mainline in front of the main station has 2 tracks, and one of the automated trains is parked on the mainline 2nd track. That’s right. I park one of the automated trains right on the mainline. Unfortunately that prevents the Saturday Operators from exiting the yard using the 2nd track, which makes things “interesting” when we have a lot of traffic. If only I could program the computer to move that train occupying the 2nd track when it’s not in use!?

Well that’s exactly what I’ve done, and here’s a video of this in action:

And it’s not a complicated task, right, right ?

All this automation has to do is move the freight engine a bit, clear the block to the siding, throw the switch, and reverse in the siding. Without hitting the passenger train already stored there. And then throw back the switch.

Now imagine you’re doing that, but with your eyes closed, without looking at the trains, nor really knowing where they are precisely -- wild guesses are accepted. That’s how the automation proceeds. And you need to cover all the contingencies that could potentially arise, even the ones you have not thought of before, otherwise some of the Saturday Operators will rant at you. Oh, and at the end of the day, the automation needs to put the train back where it belongs, so that the normal automation can resume the next day. Oh, and the thing also needs to work even if one of the trains is missing or broken. Within reason.

Now to be fair, this is not a new idea. I got this idea back in…

I have continued fighting with the Trolley Automation. A couple months ago, I fixed the turnout where the Orange Trolley kept losing power. However, that did not solve the reliability problem -- the Bowser streetcar just doesn’t run reliably. There’s nothing wrong when I try the LokSound decoder on the bench, but it just doesn’t always start, and it often does not stop. Not a good thing when I’m trying to automate something!

Instead, I swapped it for this Bachmann #6119 Streetcar:

The software part of the automation uses my “Software Defined Block” (SDB) on the ESP32; this gets the distance sensor data and simulates track occupancy. That is published to JMRI using MQTT. My RTAC automation controller software then uses the track occupancy data to control the trolley’s movement.

Here’s a video of the trolley in action:

Now the running characteristics of this trolley are a bit primitive. There’s no sound, and light is minimal. The motor is fairly crude, doesn’t run well at low speed, and it has a distinctive gearing now. Yet it runs reliably, and that’s important for a daily automation routine!

Orion just completed this scenery project in Fairfield:

This used to be -- and is still -- an access hatch. I cut a piece of plywood a while ago of the right size, and Orion designed and added scenery to be easy to lift and move away as needed. He made the hill out of paper with a cloth surface, then painted, with grass and details glued in place.

This being California, we can see the clear fault lines around the park. That makes it easier to remove the access hatch.

The trolley automation regularly stops on this turnout:

This is definitely one of these Atlas turnouts where the frog is isolated. One way to handle these is to power the frog by placing a little screw and then soldering to it -- the metal of the frog is such that solder won’t stick to it easily as far as I know. There’s a little hole next to the frog that makes contact with the frog. I didn’t have a screw that would fit that, but I had some electrical wire of the adequate size. Also right now, we’re not going to run through the thrown leg of that turnout, so…