Over on Mike Cougill’s excellent blog, he asked a few weeks ago
I wonder, what sorts of hare brained ideas are we dismissing today, that we’ll take for granted tomorrow? What sacred cows are we clinging to that will soon be as antiquated as outside third rail power distribution?
Naturally, he has us all thinking in terms of control just by the examples he gives. Chris Mears responded enthusiastically with a whole series of interesting posts about finding space for layouts.
In the interest of joining the conversation, and at the risk of upsetting a whole lot of people, I’m going to suggest we look again at our standard throttle design: the knob. Every throttle I’ve ever used (save one on my friend Tom Hood’s original layout) has had some sort of variation on this theme.
Throughout model railroading, you have one input – either a knob or a pair of buttons. Twisting the knob or pressing the button makes the train go faster or slower. End of story. People love it!
But of course, real trains don’t work that way. Even cars don’t work that way! In trains, as in cars, you have at least two inputs: a brake and a throttle. In steam engines you have what amounts to a gear as well: the cutoff (reversing lever, Johnson bar).
Why in this age of increasing realism in everything to do with operations do we cling to a control method so fundamentally tied to the toy train set?
In my dream scenario, Pembroke supports two-person crews. However, both members of the crew control the train. The engineer has a throttle, brake, and reversing lever. The fireman controls the injectors, the blower and feeds the fire. If the fireman doesn’t do their job, the train doesn’t move. If the engineer behaves badly, the engine runs out of coal or water, and doesn’t move. (I suppose we could have a get out of jail free card)
While we’re saying goodbye to the knob, we can also cast function buttons on the scrap heap of history. Many of the sound functions should be related instead to the controls of the engine. If the engineer uses the brake a lot, then the air pump should cut in. If the fireman is supplying too much steam, the safety valve should pop.
I can see how to build this system using JMRI and smart phones or tablets. I can also imagine how to create a case for the smart phone that interacts with the user interface, offering a more tactile, no look experience (although in my limited experience driving steam engines, I spent a lot of time looking at the controls).
Maybe by the time I’m ready for it, someone else will have already built it. Wouldn’t that be nice.
Pembroke:87 
René,
In the 70s I was introduced to a rather nice electronic controller produced bySEC Electronics, the “Digitol Gemini” (http://www.rmweb.co.uk/community/uploads/monthly_11_2011/post-7104-0-48015000-1322072724.jpg) which had levers for regulator and brake. It was essentially a transitor based controller with inertia simulation, and the brake varied the discharge of the capacitor which was used for the latter. (A friend built something similar but less sophisticated when he was 14.) This was great fun to use, but was analog dc. It shows what is possible.
However what you describe is for DCC, using re-labeled function buttons. Isn’t this already available from NCE in the form of their ProCab/Power Cab, and on mobile phones via apps such as WiThrottle and Engine Driver? You could always develop an app yourself, maybe based on JMRI, if these aren’t what you want.
As for sounds programmed to “respond” to driving styles, search out Paul Chetter’s work with ESU and Zimo sound decoders.
It’s just a case of knowing where to look…
Simon
Interesting idea… but if we get rid of the knob, what do we replace it with? Are you thinking along the lines of a miniature backhead? I assume it would have to be something hand-held – because layout design has progressed beyond the “central control panel” that would make something like Jack Burgess’ quarter-scale backhead model practical. (I remember he wrote about this in RMC a few decades back.)
In defence of the knob and toggle approach, it does allow us to control speed and direction without having to look at the throttle – in the same way that an engineer on a real railroad doesn’t have to look at either the throttle or the reversing lever in order to operate his locomotive. It’s done by feel, while keeping one’s eyes on the track ahead.
Cheers!
– Trevor
Yes, the lack of a tactile interface is the principle complaint against smart-phone based throttles. This is why I propose the case, which I see as a handheld backhead.
I can see we need some pictures. I’ll see what I can whip up.
Having experimented with smart phone throttles, I find they have advantages and disadvantages. The tactile issue is definitely a problem: operators are forced to look at the throttle. The knob / toggle or physical buttons for speed and direction remains better from an ease of use perspective.
While it’s not in the same direction that you’re taking with this post, I’m intrigued by the ESU handset that combines a physical knob and assignable buttons with a touch screen interface. It’s an attempt to enhance the flexibility of a software-defined throttle, like an app, with the strengths of a hardware-defined cab.
Trevor and all, here’s my vote:
Obviously for steam you’d need something similar, if not quite the same, but it should be doable.
Love it! The future is here, it’s just not evenly distributed.
René:
I’ve been fascinated with the very same ideas and motivated by YouTube videos by Bruce Kingsly. While he has gone to an extreme in building a life size F unit cab and controls, I envision a hand-held steam engine throttle that behaves more like an engine than a toy.
The Arduino controller now has sketches for DCC packets and inputs can be digital or analog so a Johnson bar, that simulates the amount of steam in the cylinders, is entirely possible. I also like the possibility of “bars” and not knobs (except for injectors for example) that you push and pull, ratchet and set, as lifelike controls. How this might look I’m not certain. Your sketching talent could come in handy here if you feel inclined.
I have acquired an Arduino and testing tools, wires, connectors, and pots. This is all new to me so this sits next to my DCC interface for the NCE PowerCab to experiment once inclement weather and time coincide.
Neil Erickson
Oh, it sounds like you might the guy to do this, Neil! Having acquired some stuff you’re already far ahead of me.
Thanks for this post. I enjoyed it. I use WiiThrottle on an old iPod. That interface uses a slider for the throttle and buttons for everything else. It’s not too far removed from most traditional throttles, for either DCC or DC control.
I would really like a throttle that, if nothing else, would allow me to separate the throttle and brake functions. Using the ability to program in momentum, I don’t need the variability of the slider for the throttle. What if I could simply take the first F buttons on the throttle and make them into “notches” on the diesel throttle, such that F1 is notch 1 and so on. I’m thinking in terms of diesels here but… Moving up the throttle notches is simply a matter of pressing the button you need. The Notch button selects the Maximum speed and the system relies on Momentum in the decoder to manage the change in speed “up” to the new. Extending this further. If these new Notch buttons pick the max. speed they could be de-selected (remove focus). Once de-selected, the momentum values would bleed speed off until the model arrived at rest again. Of course, since we’re accelerating and eventually decelerating using buttons, that slider is now free for something that is variable and I wanted to use it for a brake.
I really like your suggestion of building subroutines of sounds based on keystroke combinations or the behaviour of the user. Most decoder sound functions I just don’t use since they require adding a step and my attention, during an operating session, is consumed with running the train and not playing the sounds. It’s a pity since the models sound so wonderful now.
/chris
Hi Chris:
Much of the functionality you describe is already available. On my layout, I use Lenz keypad throttles. They have a set of four buttons for acceleration and deceleration. Left to right, they are “large decrease”, “decrease”, “increase” and “large increase”. If using 128 speed steps on a decoder, “large” changes the throttle setting by 16 steps. I only use the “large” buttons – and program high momentum values into my decoders to smooth out the transitions and enable dynamic exhaust sounds. Acceleration (CV3) is typically 50. Deceleration is typically 150 – which I can do because the WOW Sound decoders I use incorporate a progressive braking feature: each application of the brake (mapped to F7), applies 20% braking power. Releasing the brake (F6) allows the loco to return to speed.
Not perfect, but close.
-Trevor
Thanks for the comment, Trevor.
Here you expose another issue with DCC: we are pushing too much functionality into decoders, where it is expensive. More to come in a separate post.
Interesting thought. I look forward to seeing your post. Cheers!
I have used the Lenz throttles but never thought of using them exactly that way (or that context) – there’s my linear mind ignoring something interesting, again.
I can see potential in this compromise. You still have the tactile “feel” for what you’re doing without having to look at the throttle yet have a closer feel of notching the engine forward or braking.
Works for diesels and trolleys. I’ve never been lucky enough to be at the throttle of a steam engine to appreciate what might help the controller feel authentic.
/chris
Rene’,
Would’nt it be interesting if we had controllers that were as different as running a steam engine is from a diesel? Thanks for joining a conversation I didn’t realize I started. -Mike
Absolutely! If you’re a steam engineer and you need to drive a diesel, you should have to go through the training and get certified. 🙂