The Halloween event at Randall Museum will happen on Saturday 21st of October this year.

As usual, Jim has prepared specific Halloween trains that Jim, Allen, Allan, and Orion will run:

The diesel engine is SP 7342 which features a fairly unique Daylights paint scheme, fairly appropriate for this event.

Here’s a video of the Halloween diesel train running, with a surprise apparition of 153 at the end:

Come enjoy the trains this Saturday!

My last attempt to revive the Walthers UP 8312 didn't last. So now…

UP 722 (GP30) is now in Passenger Automation.

This is a WalthersProto with a Tsunami decoder.

It’s twin-sister engine UP 712 will serve as a backup.

On Thursday, the Walthers UP 8312 engine stopped moving. At first the automation still had DCC control of the headlights, but no sound and no movement. On Saturday, the engine was as active as a brick, not even the lights would turn on. This is more or less what happened to its twin engine when UP 8330 stopped working back in July.

In between, I got UP 8330 working again thanks to the support from Walthers. The decoder had a physical defect, they sent me another one, I swapped it, I reprogrammed a couple CVs, and voila, the train is back in action. For the record, the parameters I need for this engine are:

• CV Acceleration = 24.
• CV Deccelation = 12.
• Function panel > F5 to activate the ditch lights (instead of F4).
• Function panel > Remove F9 for Drive Hold.
• Select the option to “Remember functions’ states”.

All of these are easy to do with JMRI (JMRI 5 and above have the definition file for the new Essential Sound Unit decoder).

Thus I put UP 8330 back in automation yesterday, yeah!

I realized I forgot to change the horn on the other one, not a big fan of the default. I generally go for a P5 of similar, imho that sounds better. That’s not an obvious change in JMIR or LokProgrammer, I need the CV values from the Walthers web site for that decoder.

Update 9/20/2023: Automation started running with the new UP 8330 yesterday, Tuesday 9/19/2023. Today Wednesday 9/20 at 2pm, the engine stopped moving. Again it still has light & sound control, but no movement. That’s the pattern from last time, then in a day or two, it won’t even have light & sound control via dcc commands.

The last 2 days, we had a problem with the UP automated train stopping just out of the Stockton Station:

At first I was a bit puzzled -- the train was fine, there was no dead block, there wasn’t any reason for it to stop.

This, ironically, turned out to be due to Conductor 2 working as expected: the script had a timing issue, and the automation software was stopping the train because the script said there was an error condition.

To understand the root cause of this, we need to deal with route statistics as explained here, and most specifically this data:

All the details are in the other blog, so I’ll only provide a brief summary here: the script defines the minimum time that a train should spend on a block, and my default ballpark value for this was 10 seconds for all the routes. The software then enforces that -- if a train activates the next block too fast, something’s definitely unusual and unexpected. In automation, we don’t like “unexpected” things. Typically that means something else (like another train) could be occupying that next block, or that the controlled train is going too fast for some reason, or any unexpected thing that would make that next block look occupied to the block sensor. In either case, that’s an error, and the automation software stops the controlled train right away before it crashes into something.

However it turns out that block B503a is really a very small block, and it really can take 10 seconds to cross it, or even less. For a week or so, the timing was very close to that minimum time, but just a tiny bit above. Then the last two days, the train was initially taking just a bit more than 10 seconds (everything’s good) and then, probably as it warmed up, it was taking around 9.5 seconds to cross that block, fast enough to trigger the error mode for the automation.

The fix is of course very simple: adjust the timing for that specific block. In that case, I’ve set it to 5 seconds minimum.

That’s why I added the capability to log statistics at the end of a run, and then made a nice spreadsheet showing every duration spent on every block. This way I have a complete understanding of how I should adjust these timeouts.

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.