Here’s a short update on current projects:

• SDB / Trolley Automation:
• I did a LokSound firmware update for the Trolley Bowser 1379. It seemed to behave a lot better after.
• I finally understood why the automation works yet fails every day. SDB is working fine at detecting the car and then updating JMRI. However the problem is the wifi link. I’ve noticed the JSON updates could take up to 1 or 2 minutes to be detected by the JMRI “internal sensors” monitored by the Conductor software. So that’s what I need to understand next.
• The BLI Hudson 4-6-4 #5278 that I’ve recently set up for the Polar Express automation is now non-functional.
• Decoder doesn’t respond anymore, which is a typical problem we have with the BLI Paragon 2 decoders.
• Saturday Operators are running the Polar Express train with another engine, but that’s not the same thing.
• I really miss that automation for this season.
• Walthers UP 8330 and 8312 engines:
• These are still not working. I tried 8330 again -- it worked for 2 days then stopped responding to DCC commands again. I tried to get them reimbursed but both TrainWorld and Walthers just played the finger-pointing game on the other party, and that got nowhere.
• I’ll call it as I see it: the Walthers engines suffered from obvious quality control issues from the start, and the newer LokSound Essential decoders in these engines are a piece of crap that clearly wasn’t finished properly before being sold. The logical next step is to replace them by real LokSound 4 or 5 decoders, or strip them entirely and use something solid like Tsunami decoders.
• WalthersProto UP 722 and 712 were my replacement engines for the mainline automation.
• These are no longer working either. Their Tsunami decoders seem to only reply to DCC commands intermittently.

So plenty of issues to address.

On the plus side, the new screen for the Vision computer is working great, and visitors enjoy the videos. In the back, I’ve reworked the workbench programming track with a selector and that allows me easily switch between DC, NCE, and LokSound programmers. I have a DigiTrax PR3 to also hook up to that. That comes in handy to deal with all these locomotive decoders.

I’m currently experimenting with the preliminary design for the Trolley automation:

The main focus here is the Software Defined Blocks project which uses an ESP32 with sensors to emulate block activations for a train model railroad. I’m using this new automation as a test bed to experiment with that and different sensors.

Although the software part is progressing smoothly, the automation part is not, c.f. results from the automation first test.

I have reinstalled #5278 and the Polar Express cars on the automated line:

Well, almost. It was pointed out to me later that I forgot the 3rd passenger car with the observation deck. Oops. NYC #5278, an Alco “Hudson” 4-6-4, is our lead engine in this operation. The train from last year also had a nice Hershey freight car before the traditional Lionel HO Polar Express cars. And let’s not dismiss the inkjet-printed labels that makes this a true Polar Express 🤣. We’ll update this one to match.

Since last year, I have entirely changed the automation program so I had to adapt the automation script to work with Conductor 2. The changes to the script were fairly easy to make, and I had to adjust the timing a bit, especially since the new Conductor 2 requires setting min/max “safety” times for each block. In hindsight, the timing changes may be due to the train having a different configuration, as its length influences the timing sequence.

Thanksgiving Update: The Hershey car has been added as well as the last observation car thanks to Jim and Orion, and indeed that was the root cause of the automation timing changes. I had to adjust it back -- Happy Thanksgiving 🦃 !

This train will be running at Randall on the shorter automated line all December, till the new year.

Here’s a run of the train captured back in 2019:

A NYC J-1 Hudson (4-6-4) pulls our Polar Express on the Automated Line on the HO Scale DCC Layout at Randall Museum, San Francisco.

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.