Today, the museum was closed to honor Veterans Day. This was a great opportunity for Orion and I to tackle the task of updating the overhead fluorescent light from Lodi that has been dead for quite a while. My picture archives show the overhead light working back in 2015 and dead in 2017, after the museum renovation. We tried several times to change the fluorescent tubes for either “legacy” ones or LED, and none worked, thus leading me to believe that the ballast had died.

The goal was simply to open the fixture, with the power off of course, remove the ballast, and rewire the fixture for Direct Wire and install new LED tubes. Orion wanted to do all the work for learning purposes. So I had him practice the task on another similar fixture I had removed from Napa a few months ago. It’s easier to learn with the fixture on a bench than working overhead.

The replacement LED tubes I got are GE Direct Wire Color Select 32-Watt EQ T8. They exist in both Type A/B (Direct Wire + Ballast), or Type B only (only Direct Wire). Interestingly, these have a little physical switch which allows to set them for either 4000K, 5000K, or 6500K.

Before starting, we turned the power off at the wall switches and turned off the associated circuit breaker at the panel in the room.

We first cleared the area a bit, to have some place to work:

These overhead fluorescent lights fixtures are fairly simple. The cover is simply held in place with two tabs, making it easy to remove. Once we did that, we got a somewhat nasty surprise:

All that black gunk on the bottom cover is actually the dielectric insulator “oil” from the ballast. Turns out that one had badly leaked. It’s worth noting that the roof is slanted (we’re under the museum’s theater), and thus the light fixture is not flat, which explains why it had only leaked in one direction. We even found some of it on the layout below:

The Vision laptop runs the vision software -- it displays some live views of the automated trains as well as pre-recorded videos. The laptop’s internal screen is no longer actually usable: it looks fine at first, then quickly displays purple strobing/flickering lines. It does that even in the BIOS. I've made many attempts such as switching from CPU graphics to the discrete GPU, trying lower or higher resolutions or refresh frequencies… For a while I had a workaround that involved a specific sequence of DPMS on/off, and that was enough to reset the controller or something. Now, nothing makes it stable anymore. I dismantled the laptop and found no physical issue with it. Trying to replace the screen or its cable would be almost as expensive or more than getting a new laptop or a new screen so…

So instead I did this:

I moved the laptop on the side and the main display is a new 22 inch monitor. It's a good size for the space available, without being too distracting. Behind the screen is a small hill, thus we’re not blocking any view of the layout.

Ironically that more or less matches the initial design for this project -- I had anticipated having a computer hidden under the layout driving an external monitor behind the glass.

Although my initial design was to hide the machine under the layout, I quickly opted not to do that since that happens to be extremely cumbersome for maintenance, and at the same time I had a laptop with a screen, so why not use it? Similarly, here I decided to just place the laptop on the other side of the “hill” behind the glass, with a linux command to make sure the screen stays turned off.

The only follow-up I need now is to modify the vision software to turn the external screen on/off when the layout is powered. I just need to hook a script in the existing DisplayController to control Linux’s DPMS.

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.