Description of Issue

The automated Union Pacific passenger train started stopping on that block, just at the exit of the Stockton Station:

Block power goes through the Stockton Passenger Station Panel:

Orion reports we have a potential dead block on B504, which is the block at the exit of the Stockton Station before it joins the mainline. That prevents the UP automated passenger train from running properly.

B504 is the track on the right after the turnout.

Block is controlled by a toggle on the Stockton Station Panel and the toggle appears to be properly set. The normal course of action would be to use a voltmeter and check either voltage or continuity (just remember to turn off power before doing a continuity check!):

The little saga with the new Walthers Mainline SD70ACe continues as UP 8330 stopped working yesterday. It doesn’t respond to any DCC command and is not even detected by the NCE on the programming track. The engine has only been running since February, merely 5 or 6 months. That’s not exactly stellar.

In any case, I swapped it and placed its twin engine, UP 8312, in automation.

We’ll see if UP 8312 fares a bit better while I try to get UP 8330 running again.

For comparison, the last batch we used was UP 8749 from Athearn, and along with its twin engine UP 8736, we ran them almost 4 years in a row.

The Walthers units were plagued with some mechanical problems out-of-the-box, as well as software issues with their ESU not-quite-LokSound “Essential Sound Unit” decoder. From my software engineering perspective, the whole thing stinks like a serious lack of QA both on ESU side and on Walthers’ side.

It’s too bad because the engines are beautiful. Their shells have a very good amount of detail, and the inside chassis is well organized, with a good weight giving them good traction.

A couple months ago, we had one case where the UP 8330 engine totally failed to stop while running under automation and kept circling around the layout, unsupervised. That was the initial issue with these decoders out of the box and it was supposedly fixed by the first firmware update. Apparently not quite. That’s not promising.

I shall note that these new ESU "Essential Sound Unit" decoders do not even have a product support page on the ESU website. It feels like a half-baked product. Apparently each OEM has their own unimpressive OEM-specific page to list CVs instead. In the Walthers case, it’s a random footnote in the engine’s listing. That is not a practice I like, and I will make sure to not select any more engines with this type of decoder in the near future (or at least till they iron out all the bugs).

The next task is to open the engine and check the motor on the defunct UP 8330. Since we now have a LokSound programmer, I’ll try to reset the decoder to see what happens. If the decoder is dead, it’s back to Walthers’ warranty again. Another option is to remove the ESU Essentials decoder and install my own LokSound 5 in there.

Update: Thanks to Walther’s support, the engine is now repaired and functional. Details available here.

That’s a major milestone for my automation project. I spent the last two years on-and-off rewriting my Conductor automation software based on the experience of the first version.

The first version of the Conductor automation software has worked really well, but I have reached a limit in the 2000-lines automation script, which state machine was getting increasingly complex and tricker to modify. Thus a huge goal of Conductor 2 was to have an easier to understand automation script. In these two years, I wrote and discarded two early attempt prototypes which were not satisfactory, and the current version matches my expectations.

Ironically, from an external perspective, nothing has changed. The automation works exactly like it did before -- which was one of the key goals to achieve. Under the hood, there’s a whole new scripting engine based around the Kotlin scripting language and a whole new route/block based way to describe the automation which makes the automation script easier to write and understand. It gives me more flexibility to add new features.

The new UI with a live block map, sensors’ state, trains’ status, and a new Kiosk Mode feature.

One of the goals of the new scripting architecture is that I can now have some kind of automated recovery. In certain conditions, even if the trains are not at the right place when the automation starts, the script can take an educated guess and bring them back where they should be. The old behavior of Conductor v1 was simply to panic and stop everything, and let human intervention take care of it.

The new recovery mechanism only handles simple cases for now. For example, it purposely does not handle the case of a train stopped on two blocks -- simply because I needed to prioritize features so I had to start somewhere. I will add that support next.

The BD20 sensors on the mountain are being problematic for blocks B321, B340, and B370.

They sometimes “flicker” when the trains run, and do not detect the trains once they are stopped.

The issue has been going on for a while, and depends a lot on the type of automation train I’ve been running. When we started the automation, the passenger train had two Rapido engines in push-pull configuration, and I initially calibrated the sensors for that train. Then we had a set of “older” engines such as Athearn, etc, which triggered the sensors just fine. A few years ago I changed this for modern Walthers or Bachmann SD70s, and the sensor sensitivity was borderline at detecting them -- I’m guessing these engines just use less current than the older kind.

With Orion and Allen, we fixed the lighting on top of the Richmond yard. This area had been fairly dark for a while since one of the fixtures did not work, and changing the other one required some acrobatics. Orion took care of changing the dead fluorescent lights by crawling on the yard to change one of the tubes!

The middle fixture had not been working for a while. It’s one of the 60s-era ballasts that is both antiquated and dead.

It took quite time and effort to remove the obsolete fixture:

We replaced it with a Lithonia CMNS L48 2LL (80 CRI, 4500 lumens, 4000 K).

The area with the new lights in place:

The little saga with the new Walthers Mainline SD70ACe continues as UP 8330 today totally failed to stop while running under automation and kept circling around the layout, unsupervised.

That was the initial issue with these decoders out of the box and it was supposedly fixed by the first firmware update. Apparently not quite. That’s not promising.

Like ScaleTrains, these Walthers use the new ESU "Essential Sound Unit" decoder and so far I have been less than impressed by this decoder. I don’t care that it has less features -- I don’t need any of the features that are missing. What I care about is solid reliability, and I’m afraid this decoder seems to have skipped the QA line for now.

I shall note that these decoders do not even have a product support page on the ESU website. It feels like a half-baked product. Apparently each OEM has their own unimpressive OEM-specific page to list CVs instead. In the Walthers case, it’s a random footnote in the engine’s listing. That is not a practice I like, and I will make sure to not select any more engines with this type of decoder in the near future (or at least till they iron out all the bugs).

The current Branchline engine is one of the two Rapido Amtrak F40PH we have. Here it is in action:

One of the most popular events at Randall Museum is Bug Day.

For the occasion, Jim and Orion ran a dedicated “bug train”:

We’re happy to announce that today, and today only, we’ll be running a fully staffed Junior Engineer Day at the Randall Museum Model Railroad.

To do so, we have acquired the latest most realistic locomotive controller from Walthers, the RailDriver Desktop Cab Controller.

However this controller requires a Windows XP computer. Since we don’t have that (our automation is all Linux-based for 24/7 maximum reliability), we need patrons to provide their own genuine CD-ROM of Windows XP with their own activation code for us to load it on our computers before they can run.