“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!

3 thoughts on ““The Daily Effort” with Andrew and Chris

  1. Great fun seeing the continued evolution of the layout. Yes, the new throttles will take some time to get used to but I think the functionality/flexibility improvements will be well worth it.

    My favorite is the tug-boat whistle.

  2. Love your idea of triggered sounds. I very much like your notion of using sounds to simulate actions and to provide entertainment for the operators while they mark time.

    Along the same vein, I’ve mused about having random timing on loading and unloading signaled by a recorded call from the industry requesting car movement. This also adds an element of modeling humans into the equation – a goal of mine on this layout.

    • Hi Riley:
      Thanks for the feedback. I’m looking forward to exploring the use of random-length sounds as timers for various activities. I still want the conductor to do a bit of paperwork – because I want the job to feel like a conductor’s job, and I think pushing buttons on the fascia will feel more like the fry cook Chez Ronald’s. But I need to pare down the amount of paperwork currently required – the hobby is railway modelling, not railway accounting.
      Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

Please prove you're not a nasty spamming robot thingy * Time limit is exhausted. Please reload CAPTCHA.