Model Train-related Notes Blog -- these are personal notes and musings on the subject of model train control, automation, electronics, or whatever I find interesting. I also have more posts in a blog dedicated to the maintenance of the Randall Museum Model Railroad.

2023-11-24 - SDB: First Trolley Automation Test, Continued

Category SDB

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

The first prototype automation test has been overwhelmingly problematic:

  • At first, I could not get the ToF sensor to reliably detect the engine. It would seem to work, then most of the time it would not detect a decreasing distance as the trolley was approaching till it was right next to the sensor.
  • At the same time, my mere presence a couple feet on the side would influence the result. That’s not good.
  • The response time in JMRI seems extremely slow.

Let’s detail that last one.

Click here to continue reading...


2023-11-02 - SDB: First Trolley Automation Test

Category SDB

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

I brought my prototype board to Randall today and gave it a try with the desired trolley:

The SDB prototype detected the trolley properly. When placed this way against the end bumper, we can adequately measure the trolley distance between 10 mm and 400 mm (1 cm up to 40 cm). After that, we always get a value in the 400 range.

Note that in this test, I did not hook SDB to the main JMRI computer for actual control. The goal was to determine which sensor placement would fulfill the detection need. Whatever is on the picture above seems like it will work correctly, so I’ll go ahead and create some kind of sensor support -- probably out of foam/cardboard first and then later 3d-printed or stuck to a little building.

Here’s an overview of the track I want to control:

Click here to continue reading...


2023-11-01 - SDB: VL53L0X ToF Sensor Accuracy

Category SDB

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

The initial design called for the use of two ToF sensors, one on each side of the piece of track to automate. That would allow the automation to precisely stop the train on either side. The piece of track I want to monitor is about 3 meters long.

I selected the Adafruit VL53L0X “Time of Flight Distance Sensor” for this application.

The specification lists the sensor as having a 30 mm to 1 meter range. The idea was thus to have 2 sensors, one on each side of the track to monitor, thus creating 3 “virtual blocks”: each sensor would monitor about 1 meter of the track, and if the engine is not detected there, we would assume it would be in the middle.

Unfortunately, as soon as I tried the sensor, I realized that it does not work for this specific application.

Click here to continue reading...


2023-10-13 - SDB: Supporting two ToF Sensors

Category SDB

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

The initial design calls to use two ToF sensors, one on each side of the piece of track to automate. That would allow the automation to precisely stop the train on either side.

The sensor I use is the Adafruit VL53L0X. It connects on the I2C bus at a specific 0x29 address. However, it is possible to change the address in software: one of the sensor’s pins named XSHUT is to “shutdown” the sensor. The procedure is to connect both sensors on the I2C bus, and have the two sensors’ XSHUT pins connected to different GPIO pins. This makes it possible to selectively turn them on at boot, changing their address one by one.

Click here to continue reading...


2023-09-18 - Converting a Bachmann Spectrum Shay to DCC

Category DCC


The Shay running at Randall after DCC conversion.

I recently got a Bachmann Spectrum Shay -- the “80-ton 3 truck Shay” #81901. The one I got is an unlettered black version, used, and in good condition. All gears work. It has an 8-pin NMRA / NEM652 connector, and it screams to be converted to DCC so we’ll discuss this effort here.


The Bachmann Shay before DCC conversion, as unboxed.

Initial Observations

Here are the initial observations:

Click here to continue reading...


2023-09-11 - Conductor 2: Route Statistics with Numbers

Category Rtac

In the latest version of Conductor 2, I’ve added “end-of-route statistics”. I’ve now accumulated enough data to start looking at it.

First, I needed to parse a JSON log file (a log file with one JSON entry per line per day per run), and I needed a way to convert that to CSV to dump it in a Google Spreadsheet. I briefly considered writing a short python script to do that, then realized that nothing can beat the awesomeness of sed, so I ended up with this:

$ grep '{"name"' conductor-log-2023-09-* | sed -E -n '/Recovery/d; /true/d; s/^[^0-9]+//; s/([0-9-]{10})[^:]+:/\1 /; s/ R Seq[^\{]+/@ /; s/":/" /g; s/[^a-zA-Z0-9@.:-]+/,/g; s/@/,/g; s/,ms,([0-9]{3,})/,\1,ms/g; s/([0-9])([0-9]{3}),ms/\1.\2,ms/g; s/,name,|,th|,act|,err,false,nodes|,n|,ms//g; p'  | tee ~/temp/_csv.txt

I regret nothing. <insert appropriate meme>

I shall note that this expression purposely only selects log lines that have no errors, that is, successful runs that have completed with no issue. This will become relevant later.

Now let’s look at the collected data.

Freight Route

This is a simple shuttle route over two blocks: we’re moving from block B311 (the Stockton Station) to B321 (the Sonora Station), stopping there, and then back again to B311. The way I wrote the route stats aggregator, I add an index number when a block is repeated, so “B311.1” means “block B311 when leaving”, and “B311.2” means “block B311 when coming back”.

I have 98 runs for this one, and when we compute the stats we get a very nice result:

Click here to continue reading...


2023-08-23 - Conductor 2: Route Statistics

Category Rtac

The latest fix for Conductor 2 using a virtual block for B504 is now installed and has been working very well.

The latest change I did to Conductor 2 is to compute end-of-route statistics. Each time a route has finished, we log the time spent on each block as well as the error status of the route. This is sent to a little server over a basic JSON RPC, and in the statistics/status page we get a quick overview of the latest route -- how many times we ran that route during the day, when the last one finished, and how many seconds the train spent on each block:

This also keeps track of all the recovery attempts.

Having the time per block should help me fine-tune the automation script later. We can see the time spent on B321 for example, and directly relate that to the observations made in the previous post.

Finally I also have the info in the server log, which is rotated daily, which means I could compute statistics later. I’m interested in getting the time spent on each block for long term analysis. Can we get trends out of it? How consistent are these running times? For example, could we detect erratic behavior, or do engines suffer some kind of loss of performance before they stop working?


2023-08-12 - Conductor 2: Fixing an Unreliable Mainline Run

Category Rtac

A few months ago, I changed the automation to use the new Conductor 2 scripting engine as the default. It worked very nicely for a while, and in the last few weeks the behavior had degraded: the mainline automation was ending up in error recovery almost every day. The passenger train would be running fine, yet would end up with the automation in error.

There’s an interesting side effect here: One of the points of Conductor 2 is to have error recovery, being able to recover when things go wrong. Thus from an outsider’s point of view, the automation was “working” as in “doing something”, although from my point of view it was operating in a degraded running mode.

Eventually I had enough, reverted the automation computer to run the Conductor 1 script, while I investigated the issue to find the root cause.

First issue was figuring out what was not working, ending with the automated route in error recovery mode? I realized I simply did not have enough information in the logs to understand that after the fact.

That led me to enhance my logging: log error cases, log the root cause of an error, and log how long each sensor is triggered. I updated the logging, let it run for a while, and then captured one typical error:

14:56:20.416 D 8312 : Horn

14:56:21.117 D 8312 : -12

14:56:34.925 S S/NS771 B321 : ON

14:56:34.926 B S/NS773 B330 : TRAILING after 22.56 seconds

14:56:34.926 B S/NS771 B321 : OCCUPIED

14:56:35.696 S S/NS773 B330 : OFF

14:58:15.785 S S/NS771 B321 : OFF

14:58:35.012 R Sequence Mainline #3 Passenger (8312) : ERROR Sequence Mainline #3 Passenger (8312) current block {B321 [NS771]} suddenly became non-active after 120 seconds.

14:58:35.012 R Sequence Mainline #3 Passenger (8312) : ERROR

14:58:35.012 R Sequence Mainline #3 Passenger (8312) : ERROR Sequence Mainline #3 Passenger (8312) current block {B321 [NS771]} still occupied after 120 seconds.

Click here to continue reading...


2023-07-01 - Conductor 2 w/ Google Analytics 4

Category Rtac

One of the cornerstones of maintaining any automated process, especially daily automated running of little HO-sized trains on a public music model railroad, is to have dashboards to track the status of the automated processes and being able to see at a glance whether they are healthy.

For example this is part of a dashboard that I look multiple times a day:

My dashboards have a few moving parts:

Click here to continue reading...


2023-06-04 - DaVinci Resolve Plugin for the Mobius Car Ride Videos

Category Video

I have detailed in a previous post how I create my “car/cab ride” videos: a Mobius Maxi 4K is placed on a flat car, and either pulled or pushed by the train using a custom “3D-printed rod” draw-bar connector:

The only issue with this approach is the extremely visible rod on the camera, even after cropping a 1080p out of the 4K video. I’ve had many comments that it’s quite distracting; I fully agree; it’s been bugging me too:

Could there be a way to go from this:

to that?

Click here to continue reading...


 Generated on 2024-02-29 by Rig4j 0.1-Exp-e7e2d73