Routes, Profiles, or even the latter idea of Includes for Conductor 2 are all vaguely unsatisfactory.

Includes are just a hack in the current v1 script language which do not really solve anything.

The core issue is modularization of the script.

One concept I explored earlier in the 2018-12-08 post and that I still want are routes.

A route is a sequence of blocks and a reservation principle. They have different modes, e.g. global interlocking vs ABS window interlocking. I think this concept is good and should be kept as-is.

Conductor 1 uses a custom language implemented using ANTLR 4. The goal for Conductor 2 is to reuse an existing scripting engine.

Continuing with this, recently I started looking more closely at Lua to see if it could be a potential configuration language.

I have been thinking about my definitions of routes & profiles for Conductor 2 and I am not convinced they will be useful as such for Randall.

I am interested in two kind of routes:

• “Linear simple” routes: typical circuit loop with ABS-type block guards. There are mostly linear and simple means they don’t have complex rules. There still could be customizations: different speeds for different blocks, specific customizations such as grade crossing horns, etc. Some of these may depend on an engine number (especially sound F functions).
• “Dedicated Shuttle” routes: this is mostly what we have at Randall right now where routes are a mix of generic block mapping conditions and carefully dedicated to specific engines.

I’m continuing my exploration of what we can do using these cheap small mini cameras when it comes to train layouts, and today’s subject is this mini pinhole wifi camera. How well does it work and what can we use it for?

Mini pinhole camera compared to an HO-sized gondola

Just to keep some perspective, here is how the current Conductor 1 script is architectured:

• There are 3 routes, 2 for passenger and 1 for branchline, with the passenger ones alternating.
• Where appropriate, the routes define variables for speed & timers upfront so that they can be adjusted for new engines / train configuration.
• They lack profiles but these are essentially an extension of the current setup.
• Within each route are sequences. Since the script is a parallel execution script, the sequences are implemented using state keeping, but that’s mostly what the states are for.
• That’s actually a bit of an issue as it makes the states hard to figure and keep track of, creating some unforeseen complications sometimes.
• There are events not associated with any route.
• Main example is the Sonora switch in non-automated mode.
• A lesser example is the RTAC display especially for stopped/error modes.

Having changed the trains for automation recently, I can see where the system works and where it breaks:

• Mostly I changed the passenger trains just by adjusting the speeds.
• I did alter 1 or 2 timers, for example the Freight’s run time before stopping at the mid station.
• It broke when I tried to use an MTH engine as its functions usage is vastly different.
• Same goes for the Rapido which has more fancy functions. In that case changing the engine in a route would require customizing the script for different functions.

After trying the SQ12 camera, I moved on to its newer sibling, the SQ23. The goal is to use it to record cab rides. As this one has wifi, a secondary goal is to see if it’s suitable as a “live camera” e.g. to broadcast a ride view to a screen.

Cab ride filmed using SQ23 Camera

This is the SQ23 Camera I got from Amazon (can be found cheaper elsewhere, e.g. on Aliexpress), compared to my  Mobius Action Cam and the SQ12 camera:

From left to right: SQ12, SQ23, Mobius compared to an HO-size engine + gondola

Above I mentioned the key features for Conductor 2 would be profiles, configuration language, and routes.

I should elaborate a bit on this, especially the routes.

First the profiles: A profile is simple a DCC address number and a map of variables values. Routes will defined variables for, e.g., timers and speeds. The profile will fill in these values to adjust them to a specific train.

I’ve been doing all my “cab ride” recordings using a Mobius Action Cam. A few months ago I tried the RunCam 2 for comparison.
This time I decided to try one of the SQ “mini” cameras series for a change.

Cab ride filmed using SQ12 Camera

I got this SQ12 from Amazon:

This is a follow up on that proof-of-concept I made at CMRS about touch panels for the mainline.

I'd like to elaborate a few points, with some pros and cons, which I had been thinking about when I started the project. Upfront I want to make it clear I am not advocating for one solution or another. I am offering "food for thoughts", pros and cons, and matters of discussion. Some of the discussion involves industries or city names which are specific to CMRS’ layout. A map of it can be found in the link above.

A lot of my interests when it comes to model train layouts are all about automation. Automation can mean to make the trains move automatically but it can also mean to automate signaling -- displaying semaphores and search lights according to traffic on the layout. The common denominator for both is block occupancy detection, namely to know where trains are on the layout.

An early prototype of camera-based block detection