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

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: