As previously discussed, on the Randall layout, visitors press a button to trigger the trains’ automated sequence. Soon enough, we added a sign asking people to be nice with that button. The sign has nothing to do with the actual electronics behind nor the automation, not even the button itself. Both the button and the software are sturdy enough to survive any abuse.

And abuse there is. The abuse is simply… social. Kids hammer that button like there’s no tomorrow. Does it make trains run faster or more frequently? Nope. One would hope it would be a good exercise in parenting in teaching kids to be reasonable and treat common property adequately, but alas, no.

Eventually Jim and I had enough of it and I decided we could simply use a motion sensor as trigger instead of a hardware button. Back in March, I built this prototype:

The original design for the motion sensor was to use an ESP32 with an HC-SR501. The ESP32 would be used to send a sensor activation command to JMRI.

The Digispark Tiny is probably the most basic and compact Arduino-like I’ve worked with. It’s about the size of an USB A plug. It is powered by an ATTiny85 and offers 1-5 I/Os depending on usage (typically 2-3).

(image source: mister-bidouilles.fr)

Kickstarter Date: 2014.

Example of the Digispark Tiny connected to an USB OTG with a PIR sensor:

Another behavior I need right now in Conductor is to have an E-Stop feature when trains get blocked. It’s the 3rd time a train keeps running for an hour or more blocked somewhere. Ideally Conductor 2 would have a model of “what’s next” and error management, but I can’t wait for that.

What I need is simple: a route starts, and if the train has not reached the destination in say 10 minutes, send a stop to the train. We can do that trivially using a timer, which is canceled (aka “timer end”) when the train reaches destination.

Although not exposed through the script grammar, JmriThrottleAdapter (.py) and IJmriThrottle (.java) do have an eStop() method (the estop is only used when triggering an e-stop via RTAC). Right now just using a repeated stop should be enough.

Conductor 2 is nowhere ready and I need changes now so they go in Conductor 1.

The desired next step is to support the presence-based activation rather than button activation.

Although I have plans for a Conductor 2 which would be route-based, at that point this is an orthogonal task and it can be deferred for later.

Profiles is a Conductor 2 feature, and not tied to a presence sensor.

What is the minimum “clean” approach needed for the sensor presence?

What is the minimum I need to provide?

Several angles of discussion for Conductor 2.

First config file. Drop the ANTLR language. Don’t do a DSL using Groovy/Kotlin. Instead let’s keep it simple and use a Jython-based config file (like BUILD files). Sure it won’t be as eye candy as a gradle-like DSL but it might be easier to create and get started.

Example of “pythonizing” the current Conductor 1 script:

This is obviously more verbose. There’s a need to carefully stringify arguments and build lists or dicts where needed. However at that point it’s just about building an API, and there’s one benefit in having typed variables (e.g. a sensor var can’t be used where a turnout is used, etc.)

I’ll just leave this here for those who use Advanced Tomato on their wifi routers: the “Quality (%)” column in the Device List is not a percentage at all. It’s just a delta from the client’s RSSI to the interface floor noise in dBm.

From https://github.com/Jackysi/advancedtomato-gui/blob/RT-N/status-devices.asp, line 248:

How would a Conductor 2 differ from the current version?

Requirements

• Simulator.
• Validation via tests.
• Visual feedback from internal tests, both real and simulated.

State:

• Define JMRI turnouts.
• Define JMRI block sensors.
• Define map graph.
• Define virtual blocks.
• Define routes.

The latest video I did was an update of the full “cab ride” layout tour of the Randall Museum layout.

In the past I’ve used the same camera as for all my previous cab rides, a Mobius Action Cam. When I tried to use it after a year of inactivity, I realized the battery is dead and won’t hold a charge for more than 10 minutes. I can order a new battery, but maybe it was worth looking at what had changed in the domain in between. Let’s look at the Runcam 2.

Some members at the CMRS train club (the Carquinez Model Railroad Society, in Crockett, CA) desired to have large touch panels that members could use to toggle switches on the mainline. For testing, one of the members procured 32-inch touch panels and I wrote a quick experimental software to display the mainline on it and control turnouts based on touch.

The touch panels rely on the main JMRI server to trigger turnouts on the mainline.

This post documents my first prototype demonstration for this project. This was going to be an iterative process as I expected to incorporate feedback later. What I came up with is fairly easy to reuse for other layouts -- I’ve implemented something similar at Randall just after, so I’ll explain how it is implemented in the hope others want to use that or get inspired by it..

On the Randall layout, visitors press a button to trigger the trains’ automated sequence to start. Very quickly we noticed that sometimes the system would fail to notice the button was pressed.

We use a large button but that’s irrelevant. The issue has to do with how long it is pressed. Most people give a quick short push, and that’s the problem.

The button directly closes the contacts on an NCE AIU01 (Auxiliary Input Unit), which is regularly polled by the NCE command station. The computer runs my Conductor software which polls JMRI for the status at at least 30 Hz. The AIU01 is polled by the NCE Command Station at an appalling low refresh rate due to the NCE cab bus implementation: if an input doesn't trigger long enough (e.g. 1 second), it will be easily missed. In this case, it’s enough to give a short but quick push to the button and most of the time miss the polling window. The event is simply missed.

Question is what would be the simplest circuitry possible to make an input trigger longer?