The little saga with the new Walthers Mainline SD70ACe continues for UP 8330: The engine had stopped working a few months ago, and it’s now working thanks to the excellent support from Walthers. I really appreciate how they stand behind their product -- seriously.

The issue here seems to be solely with the ESU new “Essential Sound Unit” decoder: all I had to do was provide a picture of the failed decoder, let my support contact identify the issue, and they sent me a replacement decoder. This avoided me having to send the entire engine, although that would have been an option (not everyone is going to be comfortable opening their engine and changing the 21-pin decoder, and that’s fine). Support as I like it: cordial, competent, fast, and flexible. “Walthers A++” seriously on that one.

Here’s a comparison of the decoders:

Left: defective decoder. Right: new decoder. Can you spot the difference?

In that case, there’s a tiny 22 Ω (code 220) surface-mount resistor (just below the “E.S.U.” stencil on the board). In the failed decoder, it is charred and has obviously overheated. It is pristine in the new decoder. I do remember pointing out in my initial issue page that the hood of the engine was hot when the decoder first stopped working. Coincidence? I don’t think so.

In between I had been chatting with another user via YouTube and they had a failure on a similar engine with the same decoder, and the cause was the same. That points to a defect on the decoder board.

I shall also point out that opening the engine to change the decoder is a fairly simple process. I’ve documented the shell removal here: Shell Removal: HO Walthers Mainline SD70ACe

One does need to be careful when removing the decoder from the 21-pin socket. That’s not unique to this decoder, but the same for all 21-pin decoders: one needs to carefully lift it from both front and back sides, using a small plastic tool like pliers for leverage. The problem is that it’s very easy to bend the pins if the decoder is not level when removed.

Same goes for putting back the decoder. One of the pins is purposely missing, which matches a corresponding key slot on the decoder board. This ensures proper orientation of the decoder. It should fit easily without having to force.

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”: