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

The base idea is to use MQTT to publish block changes, instead of targeting the JMRI JSON protocol. I was originally going to support both, but that seems redundant. We’ll see. JSON is simple and very convenient for debugging, so it’s always a great idea to get started.

Here we’ll detail how that works for this specific project:

• ESP32 monitors sensors, sends messages to an MQTT broker.
• JMRI MQTT subscribes to messages from the MQTT broker.
• Requirement: An MQTT broker running on the network (either the same machine as JMRI, or another local one, or a public one).
• Requirement: Set up the ESP32 with the broker IP, and block/sensor topics.

For background, my RTAC Conductor automation software embeds “KV Server”, a distributed key-value server/client architecture which is fundamentally very similar to MQTT, except mine is nowhere as ubiquitous and it is buried somewhere in my LibUtils project. In the case of the Conductor automation software, I use the KV Server as a way to distribute configuration from the automation script to the accessories. Which means we can do the same here with MQTT, and we can take advantage of that to configure the ESP32 with block triggers defined in the automation script.

For now I’ve been doing block detection on the Randall layout using NCE BD20 current detectors. I have part of the Mountain Panel wired, and I’d like to have more there. I’d like to also have block detection of part of the Valley, and that’s where I have been hitting a wall for the last two years. I just can’t figure out a clean way to do it.

Block detection using BD20-style current detectors can be done at various points. Let’s review the possibilities:

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

The desire for the MVP is to be designed around “modules”.

Modules

Each module should have:

• An init method called when the main starts.
• A start method called once all other modules have been initialized.
• A loop method called as part of the main loop.
• The loop method will return the max time it wants to sleep before being called again. The loop method may be invoked sooner than requested, but not later.
• Its own thread-safe message queue.

Each module is free to start a thread or do their process in the main loop.

“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.