Let’s implement virtual blocks. These have been part of the original design and I now have a need for them.

As a reminder, what is a virtual block and what is it good for?

Let’s look at the Branchline. It’s is a simple straight chain of blocks as shown in yellow on this map:

Because the track is curved and goes through tunnels, it looks complicated, yet it’s really a straight line:

• [ B801 parking ] ⇒ [ B820 station ] ⇒ [ B830 canyon ] ⇒ [ B850 tunnel ] ⇒ [ B860 reversing block ]

One thing not obvious on this map is that B830 has no track sensor associated with it. When I did the original sensor wiring back in 2017, I simply couldn’t identify the corresponding track feeders, and I suspect (or hope) there are actually two blocks in there because it’s a fairly long segment. That’s why I left a B840 in my naming scheme, for potential later usage.

But now the concept behind the Conductor 2 automation is for the engine to track on which block the train is supposed to be, and match that with the reality of the track sensors. That’s a problem in this case since after moving out of block B820 we have no idea… the track appears empty, and that’s a definite error condition. How do we solve that in the script?

Right now we load a single map via the Conductor script. That SVG map is displayed on the remote tablet and also on the automation computer’s main screen.

I want to change this to have different maps displayed in the Conductor Ui2 on the larger screen versus on the tablet’s remote status display. The original map data exchange format over KV Server was designed to allow sending more than one map to the tablet. The original design for RTAC was to have a list of map fragments in the tablet’s horizontal pager. Then users could just swipe to show different maps, each one highlighting one part of the layout. The initial implementation took the shortcut of displaying just one map. Same goes for the Conductor Ui.

As noted above, during the first test running “live” with JMRI, all routes instantly became in error as soon as the engine moved and activated the next block for BL or PA.

This is due to the simulator being too naive: it instantly changed from one block to the next one, in perfect sync. This made it “perfect” when I was debugging the engine. But unfortunately, that’s not how reality works: when an engine crosses a block boundary, both blocks become temporarily active since the engine bridges both blocks. And depending on the speed of the engine, this can be anywhere from a second to a handful of seconds.

It’s actually even a bit worse than that as even non-powered car wheels can bridge two blocks for a fraction of a second.

I’m now proceeding with the first tests of the new Conductor 2 “live” at the museum using JMRI and the actual trains, and the first two tests have been… interesting. In the pure line of “no plan survives first contact with the enemy”, both tests were highly “educational” and produced a list of issues to address.

Since I’m doing quotes, let’s also quote Eisenhower’s “plans are worthless, but planning is everything”. The planning I did recently to prepare for the deployment really paid off and I was able to run the tests easily -- that is I can trivially change accounts on the automation computer and switch between the stable current Conductor 1 setup and the experimental Conductor 2 setup. Then when the computer boots every morning, I’m guaranteed it will safely run the stable version automatically. That’s where that bit of planning paid off.

A bunch of unexpected things happened during the experimental Conductor 2 tests, and I collected enough data to know  what to do next. I would have been highly suspicious if the new automation engine had worked perfectly out of the box. It didn’t, and more importantly I got some valuable data to work on it.

One thing I still don’t like in the Conductor 2 DSL is the name of the “ActiveRoute” object.

It’s misleading and confusing.

As a reminder, in the current DSL:

• An “active route” is a list of routes, of which only one is active at a single time.
• A route is a sequence of nodes, each node corresponding to one block in a given direction.

It’s fairly misleading as one may think that an “active route” is one route that has become active, when it is actually a container of routes combined with a switch selector.

Possible name alternatives:

Orion, Allen, and I had a discussion on how to refresh the buildings’ lighting on the layout.

For the record, the current lighting uses the traditional 12V light bulb system, controlled by a central massive power supply under the main yard, with rows of toggle switches mostly unused. Wiring is the usual mess (a.k.a. both neat yet over-complicated and hard to trace). We don’t know which buildings are equipped with lights, nor which light bulbs are either not working or not connected.

I’ve made an attempt identify the power supply and what few buildings are visibly lighted here:
https://www.alfray.com/trains/randall/about.html#h.p043jf65vl34

One thought is that next time we dust the city, we should inventory which buildings are equipped with wires, and map existing through-holes in the support boards.

But going forward, how should we improve the lighting?

Let’s discuss Conductor 2 strategies for deployment.

One issue is that I can’t just install this on the main automation computer at the museum and just “hope it works the first time”. Even though it’s volunteer work, I take it seriously and I have an unofficial SLA of 7/5 -- my automation needs to work reliably for 7 hours for 5 days a week. That makes my downtime only two days (Sunday and Monday), one being a workday for me, so really I have one day to get stuff done, and it’s on the week-ends when I often have other commitments. Then I wonder why any project takes so long to accomplish… oh well.

So the solution is that I have a clone of the automation computer at Randall. It’s the “backup” computer in case the main one fails. It’s a 99.9% exact setup so it’s nice for testing software upgrades. And because I can’t often easily go on place, I also have another fairly similar machine at home for testing. Thus I deploy on the machine at home, sort of a canary, and if I like it, I deploy on the backup machine at the museum, and finally on the main one. It’s a bit of a process but it works neatly. I can identify issues early, as is the case here.

My early attempt at deployment failed, and I addressed it already.

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

Wifi offers the typical bootstrap dilemma on all these tiny gizmos: we need to select an SSID and enter some wifi credentials to connect to an existing network.

The typical “Arduino way” to deal with this problem is to encode both the SSID and the password in the Arduino code. That forces users to recompile the Arduino sketch before deploying.

On devices with an sdcard, a work-around is to have users create a small config file with the info that we can read at boot.

Here instead I want to have the traditional “wifi-enabled gizmo” behavior.

An ESP32 running SDB shall offer this behavior:

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: