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

 photo Ops-2016-11-20-01_zpsgsiwikxz.jpg
(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.

 photo Ops-2016-11-20-02_zpsi8fbt7nf.jpg
(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.

 photo Ops-2016-11-20-03_zps5w4ffdte.jpg

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!

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.

 photo ECoS-Forum-ScreenGrab_zps7cuiy0nr.jpg

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

 photo Spock-Controls_zpsptcybhhl.jpg
(“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…

 photo ECoS-01_zpsheibfb8e.jpg

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

 photo ECoS-02_zpsgu9lxd2p.jpg

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