The Randall Museum in San Francisco hosts a large HO-scale model model railroad. Created by the Golden Gate Model Railroad Club starting in 1961, the layout was donated to the Museum in 2015. Since then I have started automatizing trains running on the layout. I am also the model railroad maintainer. This blog describes various updates on the Randall project and I maintain a separate blog for all my electronics not directly related to Randall.
The little saga with the new Walthers Mainline SD70ACe continues for UP 8312.
Back in January, I got the replacement motors sent by the Walthers’ customer support representative. I finally got around to replacing the motor in 8312. The design of the Walthers engine is not too bad in that regard except that I noticed a few of the wires easily get stuck between the circuit board and the plastic shell, which tends to break their insulation. Thus one would have to be very careful when opening/closing that engine repeatedly.
Click here to continue reading...
Last year, I was having problems with some of the track occupancy block sensors on the mainline automation. Turns out that the new UP Walthers engines use a lot less power than the previous engines, and the NCE BD20 were having difficulties detecting the presence of the trains.
Instead, I finally finished replacing the problematic sensors by newer Iowa Scaled CKT-BD1 sensors:
Only blocks B320, B321, B340 + B350, and B370 have the new sensors.
This is located behind the Mountain 1 Block Panel. Quite frankly, it’s a bit of a mess and that install needs an organization overhaul at some point:
Click here to continue reading...
It’s time for the regular Freight train to go back to the automation and replace the Polar Express.
The trolley automation is starting to work as promised:
The ESP32 software now communicates with JMRI using MQTT, which gives better response times (down from 1050 ms to 2-6 ms!)
I’ll leave this running as is for a couple more weeks to see if I got all the issues figured out. I may want to slightly adjust the timing of the trolley, for example.
The next step after is to finalize the sensor installation: first I’ll change the ESP32 for one without the OLED display (the display is very useful for debugging, but useless after since nobody will be looking at it), then I need to add a couple LEDs to display an ok/failure status (since there won’t be any screen anymore), and finally the goal is to mount the sensor next to the track, probably hidden by a building, while the ESP32 should be mounted below the layout. See, just a few loose ends to finish… the usual 90/90 rule of software engineering.
2024-01-01 - Happy New Year
Category RandallHappy New Year 2024 from the Randall Museum Model Railroad team.
Tis’ the season for the Polar Express cars on the automated line:
I reinstalled the Polar Express for the season barely two weeks ago, and almost immediately the BLI Hudson 4-6-4 #5278 lead engine failed while being used by the Saturday Operators. I plan to try to fix the Paragon 2 decoder later, yet that will take some time.
Instead, I got a new engine, a Bachmann Berkshire 2-8-4 to lead the train, but not just any of them -- specifically Pere Marquette #1225, which is allegedly the actual inspiration for the engine in the Polar Express book -- speaking of which, if you have not read the Polar Express book, I encourage you to go find it at your local library -- it’s a fairly short story yet it is very well written and the painted illustrations are simply delightful. The animated movie was interesting, yet the book is in my opinion the best medium for this story that you can read as a kid or an adult. It’s a timeless piece about hope and dreams.
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.
Click here to continue reading...
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:
Click here to continue reading...
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.