“Software Defined Blocks” is a new project I’ve started this year.

TL;DR: The Software Defined Blocks project uses an ESP32 with sensors to emulate block activations for a train model railroad.

The “Software Defined Blocks” project can be described as:

• An embedded processor (ESP32) and sensors (Time-of-Flight sensor, camera).
• An ability to define blocks, and programmable conditions to trigger block occupancy based on the state of these sensors.
• Report of the block occupancy to either a JMRI or MQTT server.
• Configuration and state displayed in some way (OLED display, web server).

The project is going to be split in two phases, each with their own MVP.

Phase 1: ESP32 + ToF sensor + Wifi + JmriJSON.

• This phase is known to be entirely doable. I expect most of phase 1 will be dedicated to the overall structure I want to achieve for the program.
• There are some unknowns (f.ex. how is configuration achieved, how is state reported) but that’s because there are multiple choices, not due to lack of knowledge.

Phase 2: ESP32-CAM + image analysis (OpenCV or something else).

• This phase is known to be purely experimental.
• The camera analysis part has some obvious challenges -- should I be using OpenCV or duplicate algorithms, can they even achieve what I want, what do I even want, etc. There’s an interesting open research area here, yet overall it should be achievable, and once achieved the stability of the solution remains to be measured.

To be clear, phase 2 is the “interesting” and novel part. It is based on my “Grade Crossing Camera” project from a couple years ago, which I toyed with but never fully finished. So it’s time to reuse what I did last time and finish it.

However there’s nothing wrong with phase 1 since the goal of that one is to provide a stable and easily reusable foundation.

The MVP for phase 1 is the Stockton’s Trolley Automation as described in 2018.

The main repository page is https://bitbucket.org/model-railroad/sdb.

Allen has a number of these Walthers Mainline Santa Fe cars, the 85' Budd Large-Window Coach Santa Fe (910-30002) and the 85’ Budd Dome Coach Santa Fe (910-30402):

Walthers Mainline 910-30402 85’ Budd Dome Coach Santa Fe.

In this post, we’ll see how to add lighting to that specific dome car, the 85’ Budd Dome Coach Santa Fe (910-30402), to get this result:

I have a fair number of “cab ride” videos on my channel. I particularly enjoy this kind of view. Over the years I’ve been experimenting with various ways to achieve them. This is what I’ve been doing recently:

The camera I use right now is a Mobius Maxi 4K. All these cameras are designed to be “action cameras”, and record “lifesize” objects, typically outside. When used in-door, image quality tends to be unsaturated, with low contrast. That can be easily adjusted in a video editor like DaVinci Resolve or Lightworks, which I use.

One prominent issue though is focus. These cameras simply do not have any adjustable focus. They have fixed focus. It’s great when shooting live action inside or outside. It’s a problem when shooting small details on an HO layout.

In the case of the Mobius v1 or the Mobius Maxi 4K, the minimal focus is about 4 or 5 inches. Anything closer than that will be blurry.

Camera Car

One thing I did early on is create my own “camera car” custom-fitted to hold the Mobius (v1 or Maxi 4K) securely:

This offers two mounting options:

I’ve done a number of “cab ride” videos at the Randall Museum layout over the last few months using a Mobius Maxi 4K camera. Here’s a summary of the pros and cons of this camera, and the setup I use for filming.

In the past, I’ve done my cab ride videos mostly using a Mobius v1 Action Cam. I’ve also tried the Runcam 2, the  SQ12, and the SQ23 camera, so I’ll compare it to these as well.

The Mobius Maxi 4K (left) vs the Mobius v1 (right).

Size

The Mobius Maxi 4K fits perfectly on an HO-size gondola or flat car, and fits in the NMRA HO gauge with lots of room to spare:

I’m preparing two new Walthers Mainline SD70ACe to be the main Passenger Automation engines at the museum. These are Walthers UP #8312 and UP #8330, HO scale, with ESU LokSound decoders. There’s some kind of drive noise issue out of the box so I need to remove the shell of the engines to investigate.

Removing the Shell on the Walthers Mainline SD70ACe

That’s an adventure. Well, not quite, because I’ve done similar engines. Walthers is very nice and provides documentation that clearly explains how to do that: remove the couplers, remove 4 screws somewhat tucked under the truck frames, no need to remove the fuel tank. Seems fairly standard procedure.

Removing the couplers is easy. Tip: hold the coupler boxes by their sides and it's fairly easy to keep the entire coupler box intact, and neatly put it aside as-is without the whole assembly disintegrating in the process. That was much appreciated.

Now when the documentation says to remove the 4 screws under the chassis, they meant the 6 screws. There are two on the inside part of the trucks next to the fuel tank, and two by each coupler. In retrospect I think that’s what the doc was trying to say, but it wasn’t super obvious when I read the first time. It’s easier to see it in a picture:

Tip: Not all the screws are the same head shape or the same length, so store them in a way you remember where each one came from.

I’m preparing two new Walthers Mainline SD70ACe to be the main Passenger Automation engines at the museum. These are Walthers UP #8312 and UP #8330, HO scale, with ESU LokSound decoders.

I’ve had some quality surprises with these engines new-out-of-the-box, so I’ll document that here.

The TL;DR is that I’m sending them back to Walthers and they will fix what are known issues with them.

Tip: If you have engines of the same run (Walthers Mainline DCC & Sound SD70ACe 910-19865 up to 910-19876), please reach out to Walthers’ customer support. They have been very courteous and helpful in dealing with the issues listed here, so please give them a chance to fix things (assuming you have any issue of course). Walthers should have sent your retailer a note, and your retailers should have contacted you about potential defects in that specific product run. In my case it turns out that there was a gap in that communication pipeline and it never happened so I had to figure most of this myself even before reaching out to their customer support.

In my case, the affected parts were Walthers Part# 910-19873 and Walthers Part# 910-19874.

Out of the Box

Disappointedly, out of the box, the engines already clearly showed issues that would require some work:

• The nose numbers plates were loose in the box. Needs to be glued.
• One of the engines’ front snow plow was also loose in the box. The other one was still attached.
• The ditch lights have unequal intensity.
• They make a weird noise when running… something’s definitely very wrong in the rear truck.

UP 8312 and UP 8330 came with a snowplow and the number plates fallen in the box.

Let’s discuss this below.

Although I haven’t posted anything here lately, I’ve spent most of the summer time completing the implementation of the engine for Conductor 2. The new kotlin engine is working well, with a suitable battery of unit tests, and I have a functional simulator to exercise the engine before I try it at the museum. I also converted the latest Conductor 1 script to the new Conductor 2 DSL. It’s all in the bitbucket repo under the dev branch:

• conductor/engine2k/src: The new Kotlin-scripting based engine.
• conductor/simul2k/src: The new simulator.

We can compare the Conductor 1 vs Conductor 2 scripts right here:

• script_v4.txt: Script v47 using Conductor 1 ANTLR-based language.
• script_v47_v2.conductor.kts: Script v47 using Conductor Kotlin-based language.

Going to change the way a route sequence graph is defined in Conductor 2 from:

nodes = listOf(

    listOf(B311_start, B321_fwd, B311_rev),

    listOf(B321_fwd, B330_fwd, B321_rev, B311_rev),

)

to:

nodes = listOf(B311_start, B321_fwd, B311_rev)

branches += listOf(B321_fwd, B330_fwd, B321_rev, B311_rev)

Over the last few months, I re-implemented my Conductor 2 prototype entirely. The initial Groovy DSL project lacked a clear structure, so I scratched it. And since I was rewriting it from scratch, I explored using a Kotlin DSL instead.

The verdict is to go with the Kotlin DSL approach.

Highlighting the pros and cons:

Here’s my latest DIY experiment: a homemade “dead spot detection car”.

Here’s a schematic and a rough explanation of how it works:

This is designed to work exclusively on DCC track.

The goal is to help operators detect dead spots on the track, either by rolling the car manually or by pushing it with an engine as seen above. They need to move it till the front green LED turns off. That will allow us to determine where the break in the track continuity is located. Then using the yellow LEDs, we can determine if the break is in only one rail or both rails.

This isn’t just about breakage in the rails, either. The original motivation was to help me find issues with unpowered frogs on the layout’s turnouts. In this case by moving the car manually over a turnout, we should be able to see a green LED go off when the frog or the closure rails are not powered correctly.

When building this, LEDs polarity does matter as shown in the following electrical schematic: