Port Rowan: Satellite overlay

Port Rowan Yard - 2016
(“It’s around here somewhere, isn’t it?” Jack, Roy and Mocean stand in what was once the Port Rowan yard – but where, exactly, did the track go? And where were the buildings located? I now have an approximate answer…)

I’m not sure why this never occurred to me before…

… but while answering a question on the Stories and Legends of Long Point and Port Rowan Area group on Facebook, I realized I could probably take my scan of the prototype track map and superimpose it on a satellite image of Port Rowan. This would allow me to determine – roughly, at least – where various features were located in the large park that’s all that remains of the terminal. Here’s the plan:

Port Rowan Track Plot

And here’s the plan overlaid on the satellite image:

Port Rowan - Track Plot over Satellite Image

Next time I’m in Port Rowan, I’ll have a better idea of where I’m standing.

Abandonment Application – April 1938

In the 1930s, the Canadian National Railway sought permission to abandon the Port Rowan segment of the Simcoe Subdivision – including the two towns that I model. (Click here for a map)

As part of this effort, CNR submitted its description of the line and the communities that it served to the Board of Railway Commissioners for Canada.

I’ve written about this abandonment application previously on the blog and shared some of the data. But I realized I should share more – to expand on the record, as it were.

This information is not relevant to the era I model, of course – things changed significantly in the two decades that separate this document and my 1950s setting. Nonetheless, this document provides some interesting reading, and certainly can be culled as inspiration for operating sessions. So here it is:

Abandonment - Page 1

Abandonment - Page 2

Abandonment - Page 3

Abandonment - Page 4

Abandonment - Page 5

Abandonment - Page 6

Abandonment - Page 7

Abandonment - Page 8

Abandonment - Page 9

Abandonment - Page 10

Abandonment - Page 11

Abandonment - Page 12

Abandonment - Page 13

Abandonment - Page 14

Abandonment - Page 15

Abandonment - Page 16

(The following is the catalogue information from Library and Archives Canada, for those looking to find it themselves)
Abadonment - Archives Information

As one might expect, the village of Port Rowan was not happy about this proposal. Here’s their response.

I’m grateful to Jeffrey Smith of the CNR in Ontario website, who found this information in our federal archives and shared it with me.

“The Daily Effort” with Andrew and Chris

Yesterday, I hosted Andrew Batchelor and Chris Abbott for an operating session. Andrew took on the conductor’s role while Chris held down the engineer’s seat – and the session was different than most I host in several respects.

Ops - 2016-11-20
(The star of the show: M238 after collecting its lifts in St. Williams. It ended up being too long for my sector plate…)

This was the first session I’ve hosted in a long time in which we’ve run Mixed Train M233 / M238. Usually when guests arrive – especially first-time guests like Andrew – we run a freight extra because they’re more familiar to most hobbyists. But Andrew was really interested in the paperwork that I use on the layout, and since there’s a fair bit of paper involved with running The Daily Effort it was the better choice for an ops session.

Ops - 2016-11-20
(That’s a whole lotta paperwork…)

While I’m quite comfortable with using the waybills and switch lists, I’m a bit rusty with the paperwork for the mail, express, LCL and passenger portion of the Mixed Train, and it showed. My method for calculating the time taken to transfer packages etc between train and baggage wagon is clunky and distracts from the feeling of operating the train. This was not apparent when I was doing it myself, but is definitely an issue when I try to explain the process to guests. So I need to rethink this.

One possibility I’m now seriously considering is to use a set of triggered sounds to represent the time required. My layout’s ambient audio system easily supports this type of application. I may build several sound files that include the following:

– The railway car door unlocking and opening
– The rumble of a baggage wagon being positioned.
– The sounds of hand trucks and workers moving cargo.
– The railway door closing and locking.

If I were to build a half-dozen of these sound files, each of different lengths, and then have the audio system select and play one at random when triggered via a button on the fascia, that might add enough randomness to the time required for a station stop. The fact that each stop could require three such sequences (for combine, baggage/mail, and LCL boxcar) would further randomize the length of a station stop.

I would still retain the paperwork – the conductor would exchange these with the station agent, as he does now by using the pigeon holes at each station desk – but there would be less math during a session. And that would be a good thing.

I note that Kalmbach recently published a book by Jeff Wilson called Express, Mail & Merchandise Service. As the name suggests, it covers this head-end traffic and how to model it. I have not yet perused a copy, so I don’t know if it addresses how to represent the traffic at the kind of micro level that interests me, or whether it’s confined to (for example) moving carloads of LCL between freight houses. But I have other books by this author and he does a good job of covering a topic, so I’ll investigate next time I’m at my local hobby shop.

This session marked the first time we’ve run trains (beyond some five-minute tests) using my new DCC system – the ECoS 50220 command station and Mobile Control II wireless throttles from ESU.

Overall, things went well – although there were some minor issues. I put these down to the novelty of the new controllers. Chris, who was engineer for our session, is fairly used to my Lenz keypad throttles so it took a bit of time to adjust to the ESU approach.

For example, the ESU throttle knob also acts as the reverser: turn it all the way to the left until it stops then let go and it’ll click and switch direction. But we discovered that the movement has to be deliberate – if it’s done too fast the controller doesn’t necessarily register it. That’s not a problem with the controller – just something that operators have to learn. Now that I know this, I can explain it better to others.

Ops - 2016-11-20

On the positive side, I figured out ahead of the session how to program the physical buttons on the throttle. I mapped frequently used commands to them so that the operator does not have to look at the touch screen to use the horn, bell or progressive engine brake (which is a feature on the TCS WOWSound decoders I’m currently using).

On the slightly annoying and somewhat humorous side, we found that the throttle will save power by going to sleep – but the factory setting (one minute of inactivity) is too quick for a typical operating session. This is slightly annoying because Chris was spending a lot of time tapping the power button on the top of the unit to bring it back to life, and there’s a very slight delay while powering up. I’ve adjusted the sleep setting to a five-minute delay. We’ll see if that works. I can set it as long as 15 minutes, but of course the longer the screen stays active the more power it consumes. I’ve also tried to balance the extra power I’ll be using with the longer delay by dimming the screen.

The sleep issue was humorous because every time Chris woke up the throttle, the WOWSound decoder – which has something like 40 whistles built into it – would randomly change its whistle setting. The next time he blew the whistle, it would be different.

I have to admit that I’m underwhelmed by the WOWSound decoders. They have some neat features that my previous Tsunami decoders did not, including the progressive brake (which I really like) and an audio function to represent clearing the cylinders of condensed steam (which I know is vital when operating a steam engine). But the audio circuit occasionally blasts a “Matrix”-like digital distortion. And I’ve had other issues.

So I’m not too concerned about interoperability issues with the ESU throttles because I plan to replace the TCS decoders at some point. I’m waiting to see what Matt Herman from ESU in North America does with steam sound. He’s already done a great job introducing new diesel audio files under the “Full Throttle” banner and I know he’s been travelling over the past few months to record steam sounds across North America. So it’s only a matter of time. That Engine Brake button can always be remapped to the LokSound “Drive Hold” feature…

Naturally, food and drink was involved. Before our operating session, the three of us enjoyed brunch at Harbord House. While there are other places worth eating at, this has become the tradition of sorts for new guests. I’m currently quite keen on a Toronto brew, Henderson’s Best ESB from the Henderson Brewing Company.

Andrew: Thanks for getting in touch. It was great to see you and I hope the day answered some questions about paperwork. It did for me.

Chris: Thanks as always. Cheers!

Backus trucks

Here’s a detail I’ll have to create for the team track at Port Rowan:

Backus trucks
(Photo taken 1956 or 1957)

Backus trucks
(Photo taken in the late 1950s)

“Backus” is an important family name, closely tied to the area I’m modelling. And the family’s lumber and feed company was a key customer for the railway.

I’m grateful to John Backus for sharing his family’s photos on the Stories and Legends of Long Point and Port Rowan Area group on Facebook, and for giving me permission to share these photos via this blog.

The information I received with the first photo notes that the railway delivered the lumber stacked on the truck in the middle. That will make a great scene on my layout.

I’ve done a similar scene before. Several years ago when I modelled a Maine two-footer in O scale, I built a lumber truck for a team track, using a white metal kit for a Nash Quad from McKenzie Iron & Steel. Here’s a rather grainy photo showing the truck at the site of a future team track on that layout:

O scale Nash Quad

I always liked the look of the lumber overhanging the truck, so I’m looking forward to recreating this using a 1950s era truck in S scale.

(Thanks for sharing the photos, John!)

Fresh perspectives and little details

This morning I needed a photo to illustrate something on my layout in an email, and while I was in the layout room I decided to try to find some fresh perspectives from which to shoot images. I was particularly pleased with the two images here – both taken near the station in St. Williams.

Turnut study - St Williams

Turnout study - St Williams

In both, it’s the little details that stand out for me: The red waybill box on the station wall. The door handle. The telegraph service sign. The rail braces on the stock rails of the turnout.

Often, I overlook these details when I’m running trains. But they show up in photos, so I’m glad I made the effort to include them.

I have many more details to add to the layout. Some will require a fair bit of time and effort to build. But it’s photos like these that remind me why I want to include them.

Wabash work session : November 2016

Wabash work session

Yesterday, I joined friends Doug Currie, Mark Hill and Ryan Mendell at Pierre Oliver‘s house for a work session on Pierre’s Wabash Railroad.

Pierre organized the work session with one major task in hand: to pull the troublesome QSI decoders from his fleet of 20 Wabash F-units, and replace them with LokSound decoders from ESU. (UPDATE: After reading this post, Pierre has posted this morning on his own blog to explain why he decided to swap decoders across his fleet.)

Mark, Ryan and Pierre worked on this for most of the day at a table set up in the layout room:

Wabash work session
(Diesels disassembled and prepped for work)

Wabash work session
(The pulled and piled QSI decoders)

Wabash work session
(Plenty of room for a LokSound unit)

Wabash work session
(For this type of work, a professional soldering station is your friend: The Weller WES51)

Wabash work session
(With new decoders, Wabash cab units in the west staging yard are once again ready to race across southern Ontario)

Mark, Ryan and Pierre managed to re-decoder about half of the fleet before we had to leave, but Pierre promised to keep the momentum going and tackle the rest in the coming days.

While those three were busy at Soldering Central, Doug and I were given other tasks.

Doug made significant progress installing foam board insulation along the mainline east of St. Thomas:

Wabash work session

Meantime, I devised, built and mounted a push-rod for a switch in a tricky situation: right on the end of the steel trestle at the east end of St. Thomas yard. This required adding a styrene box around the mechanism to prevent scenery material from gumming up the works. It also required splicing in a new piece of fascia, which Pierre makes from 0.060″ thick styrene sheet. Pierre will shape the fascia after doing the scenery behind it. We mocked up the scenery with some green poly fiber to prove that the mechanism can be hidden under the hillside:

Wabash work session

Wabash work session

Wabash work session

All in all, an excellent day, including lunch at the Sunset Cafe and dinner at Boston Pizza. As always, work was accomplished and much hilarity ensued. Definitely a grand day out!

ESU ECoS owners forum: what a great idea!

I should’ve mentioned in my original post on my new DCC system that one of the features I really like about the ECoS system is that ESU runs a forum for its owners. To access the owners section, one submits the serial number from your ECoS unit.

The forum covers a variety of topics and is divided into several sections by language, which makes sense since ESU is a European (and therefore multilingual) company. It has a few thousand threads in the English section alone.

ECoS Forum - Screen Grab

There are many places online to discuss DCC – including ESU systems and decoders. But I think a forum in which every member is an owner is a great idea for several reasons.

For starters, the discussions are all about actual experiences. This means that when someone asks a question, they’re getting advice from people who have actually figured out the answer, instead of speculation. I found many useful answers to questions about, for example, hooking up the ECoS to a Macintosh computer to update the firmware.

As well, ESU monitors the forum and participates in it – and appears to take feedback from the forum members seriously. And why wouldn’t they, since we’ve all shelled out for their system?

As the screen grab of the topic list above illustrates, there’s even a thread where owners can propose features they would like to see included in future firmware updates. I think that’s neat, because these are suggestions coming from people who are actually using the system. If someone suggests a new feature and and a large percentage of your installed base of customers enthusiastically supports the idea, that’s a good reason to build it in right there.

I’m enjoying the forum immensely and look forward to diving into it further.

Say hello to the new DCC system

Spock at the controls.
(“These are my controls!”)

Poor Spock: Not only is his track plan completely illogical, but he’s still using a control system that looks like it was designed in the 1960s. All those toggles and buttons to learn – and his friends keep messing up and shorting out the layout. No wonder he’s holding them at bay with that phaser!

What Spock needs is an upgrade.

I know how he feels. I’ve had a Lenz DCC system for 20 years now, and while I’m happy with it, the 1990s approach to technology is really starting to feel dated. To provide just one example, equipment that was defined – and constrained – by its hardware has evolved into more flexible, scalable, upgradable systems that are defined by their software. Yet DCC has, for the most part, remained built around “the box”.

So, for a couple of years now, I’ve been keeping an eye on the evolution of DCC. And as reported previously, I’ve taken the plunge on a new system. It arrived this week and I’ve finally had a chance to hook it up to the layout and get it running. Say hello to DCC in a drawer…


For those who aren’t familiar with this (and many North Americans will not be) you’re looking at the ECoS 50200 and two Mobile Control II wireless throttles from ESU – the folks who bring us LokSound decoders.

This is a pretty powerful, console-based system that uses a high-resolution touchscreen to good effect. It makes programming pretty darned simple and intuitive. It has a pile of features (many of which, frankly, I’ll likely never use – at least not on this layout). Many operations are done graphically, although one can also access CVs.

The ECoS 50200 is also designed to allow hobbyists to take advantage of their legacy systems. In my case, I’ll be able to take my Lenz equipment, and wire the track output from the Lenz command station into a special port on the back of the ECoS. The ECoS will then pass through commands from the Lenz system. So, I can still use my Lenz throttles and the XpressNET throttle plug-in panels if I desire.

And since the unit can be easily connected to a home network, one can take full advantage of JMRI. But in addition, ESU can deliver firmware upgrades over the Internet. If ESU wants to add a new feature, it can be written in, and the touch screen interface updated accordingly.

An example of this is the Mobile Control II wireless throttles, which were not available when the ECoS 50200 was first introduced. When ESU launched the throttles, the company simply updated the firmware for the command station to allow it to connect to them: Now, the ECoS 50200 can also act as its own router, connected to a small WiFi access point (the little black box to the right of the command station in the photo above). Cool!

The Mobile Control II is an open source, Android-based throttle. It’s basically a specially-designed tablet computer, to which a few welcome hardware features have been added, such as the large throttle knobs. Overall, the throttles have a hefty, high-quality feel to them. The knobs are motorized, which gives them a nice tactile feel and allows the system to automatically zero the speed so that when one is acquiring a locomotive one doesn’t accidentally start running it randomly. Another nice feature is that the direction switch is built into the knob: turn it to the left past zero until it clicks, and the direction is reversed, even as the knob returns itself to the zero position.

Since the throttle is Android-based, one can customize it with apps from the Google Play store – for example, by adding a fast clock app, or even another throttle app. And since the throttle hardware is open source, developers can create new interfaces to work with it. So far (as far as I know) the ESU app is the only one available that interfaces with all features including the throttle knob. But those developing WiThrottle or other throttle apps can get the information they need from ESU to enhance their apps to make them fully compatible with the Mobile Control II. And of course, ESU can update their own throttle app by posting to the Google Play store.

The two built-in throttles remind me a bit of my Troller Twin-Pack days, and in normal operation on my layout they’ll note be used. But I’ve located the command station in the top drawer of one of my recently-built rolling stock storage cabinets


… and I plan to rewire the front track on the sector plate to serve double-duty as a programming track. One of the nice features in the ECoS 50200 is that one does not need to add a mechanical switch to the programming track: an internal relay automatically puts the track into programming mode when that mode is selected on the console. Otherwise, the programming track is treated as part of the mainline.

I’m still learning the many features on this system, but so far I’m really pleased – and very excited to be working with a state of the art DCC system!