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

How can the current modules benefit from the FreeRTOS tasks?

An initial prototype was built using MicroPython. There’s good support for ESP32, especially using the Adafruit libraries. Unfortunately, MicroPython on ESP32 still has quite some limitations. For example there’s no OpenCV support, etc. Since the goal is to make the project as accessible as possible, sticking to the regular Arduino / C++ seemed a better option.

One issue with the MicroPython version is that I realized that “MicroPython Threads” are implemented using FreeRTOS tasks all of the same priority. Thus they execute in round robin fashion, with no control from the application. That means a task doing some IO can be pre-empted in the middle of e.g. an I2C-in-software operation.

With better FreeRTOS control, we can use tasks and we can:

• Use priorities to ensure some tasks are run before others.
• Use critical sections or mutexes to avoid same-priority tasks from interrupting each other.

For now I’ve been doing block detection on the Randall layout using NCE BD20 current detectors. They work well. There are others DCC-compatible detectors but they all use through-hole core transformers, which means they cannot be used with existing wiring without desoldering or disconnecting something.

There are other contenders to the BD20, such as the cpOD and the CKT-BD1. I plan to switch to these once I exhaust my current supply of BD20. But the bottom line is that they all use these “through-hole CT”, and sometimes I wished I had the convenience of a split core transformer that I could quickly snap around a track feeder wire.

I had two goals in mind:

• Main goal: Have an alternative to the through-hole CT block detection sensors that do not require disconnecting nor cutting wires to install them.
• Secondary goal: Make a little portable “current detector” that I could quickly snap around a track feed wire to trace wire continuity.

Thus a while ago I got two sensors, with the purpose of figuring out to use them to monitor train track current with an ESP32:

• https://amzn.to/3q7qG4z Hall-sensing ACS712-5A current module.
• https://amzn.to/3AJM5FP Split core SCT013-005 5A 1V current transformer.

Spoiler alert: I discussed that topic on the MRH forum and the Arduini forum and I was clearly told that would not work, and to make a long story short, I never managed to make them work for this application.

Upfront I want to indicate why that was anyway not a surprise and I was likely to fail:

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.