Description of Issue

For a while we’ve had issues with the turnout T161. Trains would stop dead on the turnout. Other times they worked fine. Some trains could go through just fine yet we would have issues with steam engines.

Back in 2018, I identified the frog power showed a clear resistance, and posited it was due to faulty contacts in the Fulgurex. After changing the switch machine in 2018, the problem went away. Then since last year we’ve had intermittent issues again with this.

Two weeks ago, I did two things. First I hardwired the turnout for the straight route. Now the frog is always powered directly from the proper stock rail. The switch machine contacts powering the frog are entirely bypassed. The other thing I did is take an overhead picture of a similar turnout and color the rails to clearly understand the power routing of the turnout.

The “fix” from two weeks ago did not last long. At the next operating session, trains stopped on the turnout again. However this is good as it helped eliminate the Fulgurex as the culprit. It is not an issue of frog power routing. We also know that the turnout sometimes works fine, so I suspect a bad solder join or something similar on the way the turnout gets its power, something that varies with time & temperature as the track can expand or shrink -- a problem we have in a few other locations on the layout.

Here’s a picture of T161:

And here’s the same picture, annotated to understand power routing:

Now I understand how this all works:

Now for something a bit different… understanding power routing on turnouts as used at Randall on the mainline.

This replies to a question I had recently, and eventually I’ll add it to the Randall Layout documentation because it’s good for future reference. Once again I was tempted to write here an explanation of why turnouts are wired the way they are, yet that would be long and convoluted. For that, I’ll just refer to the excellent material at https://dccwiki.com/Turnout which is complete with detailed schematics and presents the various ways a turnout can be wired.

For our mainline turnouts, here’s a concrete example by taking an overhead shot of Turnout T05 and coloring the rails A and B and all the parts which are electrified the same way:

Turnout straight/normal.

Turnout thrown/diverging.

Non-isolating power routing turnout:

For reference, this style is called a Non-Isolating Power Routing Turnout: the entirety of the frog and the closure rails are one contiguous section and are all powered depending on the position of the turnout. Two wires bring power from both rails A and B into the switch machine and a contact moves to select power from either rail A or B and powers the frog and the connected closure rails accordingly.

The original Vision computer is back on the layout, running the latest version of the vision software:

I had issues with that Lenovo Yoga 15 at the end of last year and I quickly exchanged it for a smaller X1 I had as a spare at home. I’m glad to be able to have the Yoga 15 back on the layout as the screen is larger, and it’s also the most ridiculously good looking screen I’ve seen on a Lenovo line so far. Super sharp, rich in color and contrast. It really shines in this video display application. I don’t want to diss my beloved Lenovo X1 screen, it’s just that the X1 screen is matte and really works well for work and long coding sessions, whereas the Yoga screen is more vivid in color and obviously targeted more at displaying videos.

Here’s a description of the display when running the vision software:

On the picture, Live Cam 1 has a yellow highlight around the video to indicate that motion has been detected in this live video stream, and we can indeed see the yellow UP passenger train in view.

Eventually I want to move the cameras 2 & 3 to more interesting parts of the layout, yet before I can do that I’m waiting for the museum’s maintenance staff to fix the overhead lighting issue.

The interesting thing is that overall we use 60% of the CPU on this machine (Lenovo Yoga 15 with i5-5200U @ 2.2 GHz):

Description of Issue

Back in 2018, we had engines stop-and-go on turnout T161 for quite a while, especially steam engines, or short non-MU engines. The turnout was always in the normal position when this happened. Back then, it was determined the frog power routing on the Fulgurex created a resistance. This was solved in 2018-12-12 by replacing the Fulgurex. The issue re-appeared last year, and it was “fixed” by Allen spiking the frog in place. This worked for a while, and now the issue is reappearing again, with trains going dead on the frog.

Frog issue: Issue is frog power via the Fulgurex contacts. Last time, it was solved by swapping the Fulgurex. Eventually the contracts just oxidize or present some kind of resistance, likely to complete lack of use. And we cannot throw that turnout since the throw bar has been spiked.

We’re having a “dead spot” problem at turnout T161. Again. For the 3rd time.

I was going to ramble at length on the complexities of turnout designs and what causes them to short. Instead I’ve decided to skip that because https://dccwiki.com/Turnout has much better graphics, and better explanations. So please go read that.

One thing I do not know for sure is what kind of turnouts are installed at Randall. I should know. And document it.

Description of Issue

We’ve had some specific steam engines derail here in the past. It was identified the point rails were loose because there is no turnout throw rod at all. Previously the point rails were spiked.

We recently were having problems again with some specific engines, this time being this BLI 844 Challenger. The suspicion was that the spike may have been too high and derailed the engine.

Back in November, I did a major update to the Vision software that drives the Vision computer at the museum for the Train Vision Project. A major issue was the image detection had a lot of false triggers and would erroneously detect a change in the image when there was no motion. I reworked the image analyzer, and I also added logging to capture what motion is detected. The logging system dumps data to a JSON file compatible with the chrome://tracing protocol and the Perfetto web UI, which I can then collect remotely and analyze later.

Here’s an example of run from last Saturday:

What we see above is an automated run from the mainline Freight train. Rows represent cameras 1, 2, and 3 respectively. Let’s look at camera 1 in detail:

This year I’d like my projects to enhance the automation. There are two automation additions I want to get to, namely Fairfield and the Trolley line; however I realize these require a lot of research & preparation work that is mostly software and, if I go there, it will be yet another 6-9 months with nothing tangible for others to actually see.

So instead I’d like to focus on enhancing the variety of the current automation.

1- Branchline Automation

We currently have a single engine running, and we park it on the B811/B801 storage track. However the track & panel supports 3 storage tracks.

Branchline/Mainline Track Diagram (blue is mainline, green is branchline).

I’ve spent some time updating the Randall Documentation git repository. What’s changed:

• There’s a new hardware folder.
• Currently it only contains the PFM Fulgurex documentation.
• I plan to add more to collect the user manual of all the hardware we currently use on the train layout, from the command station, to the various electronic boards such as auto reversers or electronic circuit breakers.
• There’s a new ggmrc_history folder.
• This contains paper documentation I found on the layout’s archives. I scanned them all a few years ago. Scan quality was so-so; image contrast is really poor on many of these. I tried my best to find what they describe and rename them accordingly.

I was particularly interested in the historical documents I could find. They cover a wide time range, from 1965 up to 2010.

Layout wiring standard “adopted June ‘65”.

However these documents are a mixed bag. Some are early design schematics for the mainline or the yards, which may or may not be relevant today. There are some early construction standards for the layout. Others describe equipment which is not there anymore. There are a few yard or panel descriptions that I could not quite relate exactly to the layout, so these are labeled as ‘unknown’.

On the software side, while traveling during the xmas break, I have spent time cleaning up the Conductor source code, which is my script-based software that drives the entire model layout automation. I have not changed any functionality, just done maintenance on the code base; I have modularized the code to split the parser and the script engine into an engine module, and I have updated all the dagger components to make it easier to write tests for just the scripting engine.

I have remotely deployed the new version on the layout, and as desired this update was totally silent and unnoticed.

On the train model side, we’ve had issues with the Branchline for a little while.

Last month, the 2-car Santa Fe RDC from Rapido stopped working. I “solved” that by just running it with only one of the two RDC cars. The unit is also not doing sound anymore, at least not in a consistent manner.  That’s unfortunately the second Rapido RDC unit that developed similar problems. The small motors they use for each truck is apparently the weak link, and since they use two of them, the unit can’t run well once one of the motors fails. For the RDC SP 11, I worked around that by disconnecting one of the motors, making it single-truck powered, which is fine on our flat branchline. I could do that too here, however it won’t solve the sound issue (it does make sound from time to time IIRC so it’s not a speaker/wiring issue, maybe more like a decoder issue).

The other way I “fixed” the branchline automation is by thoroughly cleaning the engine wheels and then scrubbing the track where it was losing power with the Walthers hand cleaning tool.

But at some point we need to just work around the problem and address it. Time for an engine/train change on the branchline.

There’s a similar issue on the mainline. The trains were not stopping at the right spot, and that got solved by cleaning the engine wheels. But more importantly, we’re going to have to swap the engines at some point. Out of the two UP SD70ACe engines, one is out of commission, and I’m currently running with the backup UP 8749. There is no backup for the backup so we’ll need to deal with that.

The easy solution here is to try to get yet another UP SD70ACe once available. Currently Walthers or TrainWorld have none though. In any case, one of the many pending tasks I have is to look at what’s wrong with the first unit and fix it. What I have done in the past that worked well is get any similar unit from the same OEM and just do a shell swap.