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?

Very interesting discussion here: http://cs.trains.com/mrr/f/744/t/230553.aspx

Summary, TL/DR: We can power a LED directly from DCC, just add a resistor to limit to about 10 mA (or less if too bright).

Suggestion is "nice to have" a reverse parallel diode to limit the reverse voltage on the LED:

However another comment indicates it's enough to compute R to be within the specs of the reverse voltage of the LED (assuming I have the specs).

I tore down my previous layout #2 since it didn’t have a purpose anymore -- originally it was for the kids to play with and for me to play with cameras recognition of trains and automation. I’ve done my part, and the kids didn’t show interest anymore. Being a 4x9”, it was still taking valuable space in my small room. Time to update.

What I cared for is having a workbench and a simple test track on top of it. I came up with a very simple L-shaped workbench design. The workbench is designed to not have any legs in the way and lots of storage space underneath. For the test track, I have a bunch of EZ-Track around so I just used that. It’s suitable for minor switching. I won’t add any scenery, it does not need to look like a shelf layout since it’s a workbench.

“Conductor” is the name of the software that controls the automation on the Randall Museum Model Railroad. It’s written in Java and integrates into JMRI. The other part is the Android tablet display software. Combined, both create “RTAC” -- the Randall Train Automation Controller. I started the conductor project in mid-2016 and by the end of 2016 I had a working version deployed on the layout at the museum. Immediately after that, I started thinking about extending it already :-)

The RTAC / Conductor source can be found in this Bitbucket repo https://bitbucket.org/randall-railroad/automation with a GNU GPL v3 license.

--

Here's a rethink of the automation software.

Right now I have JMRI for sensor management and DCC throttles. Conductor acts as a plug-in that drives the automation purely on sensor+timer event based script.