Today on the bench, we have two things going on:

On the left side, we have a “Wifi Kit 32” ESP32 running a fork of the latest DCC++ EX firmware.
On the right side, we have my Cab Engineer DCC Throttle app for Android communicating with the DC++ EX command station.

A few clarifications and explanations are needed here.

Here’s a concrete example that shows how to wire LEDs directly to a turnout frog, as explained here, and makes it obvious how trivial this is:

Resistance used here is 1 kΩ, that gives good brightness for both the green and red LEDs.
A 2.2 kΩ resistance also worked well enough for the red LED yet made the green one too dim.
In this example, the frog polarity is switched between rail A and B by a microswitch using the EZ-Track coil mechanism.

Another variation of this that I plan to use on the Randall Model Train layout is to only have the red LED, to make it clear when a turnout is left thrown/divergent. Especially for mainline turnouts, it acts as a “warning” signal. There is no need for the green LED in that case. I will likely embed the LED directly next to the turnout in the ballast. These LEDs are small enough that they could even be placed between the ties. The LED and the resistance can be wired to the existing terminal connected to the auxiliary contracts of the Tortoises.

Here’s an idealized turnout, showing the polarity of the frog based on whether the turnout is normal or reverse:

The frog is directly connected to rails A or B via the switch points of a slow-motion turnout motor, be it a Tortoise or a Fulgurex (in the case of the Randall layout). This works for any turnout which has a metal frog which polarity changes based on the turnout position. Examples are turnouts powered by a Tortoise or Fulgurex where the auxiliary contacts from the slow-motion motor are used to change the frog polarity. Another example are the EZ-Track turnouts with a metal frog.

We can directly wire two LEDs, green and red, with a resistance, to the frog and the A / B rails to get them illuminated to indicate the position of the turnout, as follows:

One issue I have on the Randall layout is that operators or automation sometimes short the layout. Then the NCE EB1 circuit breakers take over and of course shut down their corresponding power district. Then operators or staff ask me why things do not work, yet a lot of them fail to check the circuit breakers to see if they are shorting.

One idea I had a while ago was to use an NCE AIU01 to monitor the NCE EB1 circuit breakers. Then I could feed that into my automation software and get reporting of actual shorts right on my status web page.

The proposed solution is to use dual-channel optocouplers to connect the EB1 LED output to the AIU inputs.

Here are the details, as updated on 2020-02-04:

I’ve just finished this project:

The car itself is a Model Power HO Scale “Safety First #624 Searchlight”. It’s a depressed flat car with a nice & sturdy die cast metal construction. It’s really well done.

Jim got it for Randall and when we tried to use it, somehow trains started crawling when pulling the car.

One of the goals of Conductor 2 is to codify and simplify some rules which are explicitly coded in the script for Conductor 1.

One such thing is the handling of train speeds along a route.

Most speed changes in the current V1 script can be codified as the following:

• Speed change when entering a block.
• Speed change within a block (with a delay).

A lot of the rules have extra conditions to make them happen only for a given route, and a specific direction.

Both combined gives us some explosive combination numbers: if this route is active, in this direction, and in this block, then set the train speed to such.

I have 2 suggestions.

Starting to implement the occupancy manager in Conductor 2 immediately showed an issue in the default route mapping: the default idle block of one route cannot be part of another route.

So let’s backup and analyze this.

Jim gave me this engine, with the sole purpose of changing the horn. How hard can it be?

Jim got this engine for Randall in commemoration of the 150th Anniversary of the Transcontinental Railroad.

My first attempts at doing that video were miserable as the engine would stop constantly at slow speed and I tried a few things to see if I could improve the power pickup.

One of the main concepts to be added in Conductor 2 is the concept of routes.

Conductor 1 already has “route” definitions. These are actually intended for display on the remote tablets. A route is defined using:

• A name,
• A DCC throttle object, used to display the engine speed and direction;
• The JMRI sensor used for the automation toggle on/off.
• A counter of number of times the automation started (incremented by the script).

The counter thing was a quick attempt at gathering some stats initially and never used -- it’s technically displayed by RTAC on the tablet, but the UI layout was designed for 2 routes, and with the current 3 routes the counter is ironically not visible. Even when it was visible, nobody was looking at it. Thus I suggest dropping it eventually, which will remove a couple lines from the script.

The concept of routes in Conductor 2 is supposed to be more elaborate. However I’d posit it can just be an extension of what is in Conductor 1 at the syntax level in the script.

So what properties would I want in a Conductor 2 route?