This is what I used for the red door: https://amzn.to/43dp9e9 “USB Lights Bars 12 Inch, 3 bars chained”.

I’m powering this with a custom-made USB A-to-C adapter, which is turned off and on by a contact switch on the door. That works well, but it’s been bugging me because the light is stuck in the white-ish 9000K mode instead of the better looking 3500K 6500K mode. So I took one apart to see how it is built inside.

It contains a USB C with a 6-pin connector. That’s a “power-only” connector: GND / VBus / CC1 / CC2 / VBus / GND.

So essentially they “abuse” the CC1/CC2 lines as ground for the yellow-ish LEDs.

I got these for Randall and they are working very nicely: https://amzn.to/4evzCYk “DC-DC Boost Converter, XH-M411 DC to DC 3-35V to 5-45V (2 pack)”. The cost was $6.50 per converter.

There’s no usage manual (or I lost it?), so let’s copy stuff here:

What the button does is switch the display from displaying input to displaying output voltage. The blue LED turns on on the input/output side depending on what is displayed.

Output voltage is adjusted using the tiny blue potentiometer next to the radiator.

In the old Conductor 1, anytime the train sequence did not work as expected, the engine simply stopped everything, and we had to manually replace the trains as expected and restart everything.
Thus, when I redesigned the new Conductor 2, I added some “recovery” functionality -- the idea is that if the train sequence does not happen as expected, the automation engine should do something to try to recover the trains.

Unfortunately, the idea of “recovery” is basically to more or less predict the unpredictable and decide what the automation program should do in that case. Which means there are always cases that one never thought about because that “could never happen” and thus such cases are not handled. Today is one such case.

Orion and I have been slowly working on fixing the Branchline T324 turnout. That involves crawling through one of the mountain access holes, and then we need to reach the Branchline over the Mainline track. To make it more fun, that’s one of the tracks used by the Passenger train automation.

Twice I’ve seen the Passenger train go into error mode while we were trying to work on the Branchline T324 turnout. What was even more puzzling is that the Passenger was at Summit and then the Freight train just… started! Suddenly, on the same track, I had the Passenger train go into recovery and thus reversing towards the station whilst at the same time I had the Freight train leaving the station… Each going towards each other in the opposite direction. Not exactly a good scenario.

Hilarity ensues.

The first part of the puzzle was easy to find: when we crawl into the mountain access hole, we somehow activate the block B340. It’s not exactly clear why and how that happens, yet that sure is the result.

Here’s an excerpt from conductor-log-2024-10-12-08-40-03.txt:

This happened once, when Allen and Jim ended their Saturday session:

• At 1:40pm, they turned the "Saturday mode" switch off, turned the Mainline Automation toggle on. Consequently, the Freight train correctly moved back to its normal position.

So far that seems normal. However...

• At 1:42pm and 1:43pm, the computer registered multiple on/off instances of block detection on Block B330 -- there were about a dozen on/off activations for 2 seconds -- but also B360 registers as on -- see below.
• Cameras show they were not running anything at that time, and that block B330 is clearly empty. I cannot see B360 however nothing on the video indicates there should be anything on it (no trains going in or out in the following minutes).
• Camera shows Allen moving trains to Richmond via B160/B150 a minute later. I don’t think it’s related.

Here’s an excerpt from conductor-log-2024-10-12-08-40-03.txt:

⇒ This starts just after the Freight train has reached its default parking location at the Station:
13:42:34.779 R Idle Mainline #0 ML Ready : ACTIVE

13:42:35.972 S S/NS773 B330 : ON

13:42:36.937 S S/NS773 B330 : OFF

13:42:37.833 S S/NS773 B330 : ON

13:42:38.962 S S/NS773 B330 : OFF

13:42:39.659 S S/NS773 B330 : ON

13:42:40.639 S S/NS773 B330 : OFF

13:42:41.520 S S/NS773 B330 : ON

13:42:42.416 S S/NS773 B330 : OFF

13:42:43.348 S S/NS773 B330 : ON

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

One of his requirements is to make the phone rings using their internal ringer, without modifying the phones, or without using the easy solution of simulating the ringer using an arduino+speaker setup.

That means we need to simulate the POTS signaling for the ringer on his closed phone line: such phones ring when they receive a signal 90 V AC at 20-40 Hz:

• https://www.jkaudio.com/article_10.htm 
• https://pbxbook.com/other/trunks.html (fascinating details including railroad origins)

Orion and I looked at his BlueTooth phone adapter -- the ring does provide a 90~100 V signal at about 20 Hz. We checked that with a real old-school scope. One thing I did forget to measure was the current draw, doh. But since the adapter is powered via a regular USB brick, it can’t be more than 5 W (1A x 5V).

Thus the goal is to make some circuitry, the simplest possible, that will generate a 90~100 V DC square signal switched at 20 Hz. And, as an extra precaution, I want this circuitry to be isolated from the power grid.

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.

I realize I don’t know the exact details of what’s needed for DCC-EX. So let’s look into it.

I also wonder how much some of the hardware parts cost, out of curiosity.

To start with, a DCC-EX Command Station is, as the name suggests, a command station for DCC -- digital control of model trains. What makes this interesting is that it’s a complete DIY system based around an Arduino board, an extra board providing the track power, and an open-source free software. Depending on the kind of Arduino board used, the trains can then be controlled via a computer and a web page, or even an Android or iPhone.

Here’s the one I made using the recommended components. It is pictured next to an HO-scale engine to show you how small it is:

An Arduino UNO with a Motor Shield.
Bottom jack is the input power for the track.
The USB cable provides power to the Arduino + web page for control.

Of note, a DCC-EX command station can generate two track outputs. That can be 2 DCC signals -- for example for a mainline track + a separate programming track -- or it can be one DCC signal plus a separate DC signal. E.g. one could make a circuit with one loop on DCC, one loop on DC voltage, and control both independently..

On the hardware side, one needs two things:

• An Arduino board -- that’s the “computer” part
• A “motor shield” -- that’s the part at the top that produces the track voltage.

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:

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.

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.