This is the hand-held controller requirements and issues for the MRNet project.

MRNet Hand-Held Controller Requirements and Issues

My economic model for hand-held controllers is that it is unlikely that any one hand controller is likely to satisfy all model railroad enthusiasts. Instead, it seems likely that there is to be a range of hand controllers to fit a variety of needs/desires and the ever important hobby budget. Below I have partitioned hand controllers into three broad catagories:

Basic: The basic hand controller is for the model railroader that wants to spend their hobby budget on other things. It basically has just about the bare minimum of required features and not much more.
Typical: I have not come up with a good name for this controller catagory. Basically, all I mean is somewhere between basic and full featured.
Full-featured: This is the hand controller for the model railroad enthusiast who wants just about every feature that can be imagined.

I talk about the expected features in each catagory in the paragraphs that follow.

The features I would expect in a basic hand held controller are list below:

Speed Control: The speed control controls the train speed.
Direction Control: The direction control controls the train direction.
Brake Control: The brake control provides an alternate method for slowing down the train from the speed control.
Horn/Bell Control: The horn/bell control sounds the (diesel engine) horn or (steam engine) bell.
Turn-out Control: The turn-out control toggles the turn-out that immediately preceeds the train in its current direction of travel.
Uncoupling Ramp Control: The uncoupling ramp control activates the electomagnetic uncoupling ramp that the train is currently over. There is an issue that the train may be sitting over more than one uncoupling ramp.
Train Selector: The train selector allows the hand control to switch between the control of more one train from the same controller.
Simulatation Selector: Different people have different tastes when it comes to the overall simulation of train motion. This selector allows different people to select between different simulation levels.
Stationary Operation: For stationary operation, the controller is wired into a single location at the layout. A controller that is built for stationary operation can attempt to achieve a realistic look and feel of the locomotive cabin.
Wired Handheld Operation: The controller is electrically connected to the layout, but moved from station to station. While the controller is electrically disconnected, the train will maintain its speed for a while. While batteries are not an issue, overall controller weight and size are issues.

The features I would expect in the `typical' catagory hand held controller are listed below:

Wireless Hand-held Operation: For wireless hand-held operation the controller is always electrically disconnected from the layout. Communication is either via RF or IR. Batteries, power consumption, and wei
Speed Indicator: The speed indicator shows the current train speed.
Incline Indicator: The inclune indicator shows the track grade.
Signal Light Indication: The signal light indicator shows the state of the next signal light that is ahead of of the train in its current direction of travel. When the signal light is not visible from the engine, this indicator can be blank. For some layouts, the operator will be able to visually see the actual signal lights on the layout, but for other layouts it may not be as easy to see each and every signal light as the operator walks around; for example, when the train is coming out of a tunnel towards the operator.
Block Number Indicator: The block number indicator shows the current train block number. This is usually a number that is attached to the signal on the light ahead of the train. Thus, when the signal light is not visible from the train, the block number indicator can be blank.
Air Pressure Indicator: The air pressure indicator shows the air pressure available for the air brakes.
Time Indicator: The time indicator shows the current time. Many clubs use fast clocks to try to get more realistic operations.
Motive Power Control: The motive power control is used to help the central computer identify the what locomotives are currently pulling a train. When a MU train is assembled in switching yard, the central computer may not be able to determine which locomotives are being assembled together.
Longer term I like the idea of putting a bar code on the bottom of the locomotive and sprinkling bar code readers through out the layout to read the bar codes.
Maximum Speed Control: For a lightly loaded train, the maximum locomotive speed may be reached before maximum power is reached. Again, the central computer may not be able to figure out the maximum speed without a little help from the train engineer.
Train Load Control: There may not be a easy way for the central computer to determine how many cars and how heavy the cars are that make up a train. The train load control allows the overall load to be specified from the hand controller rather than having to enter the information at the central computer console.
Train Length Control: Specify how long the train is. This can be the number of cars or the length in feet/meters.

The features below are what I would expect from a full-featured, spare-no-expense hand held controller:

Fuel Indicator

The fuel indicator specifies the amount of fuel remaining for the engine.

Water Indicator

The water indicator is shows how much water is left for the steam engine.

Crossing Gate Indicator

The crossing gate indicator shows when the train engine is passing a crossing gate. This feature is probably better done using sound (see below.)

Uncoupling Ramp Position Indicator

The uncoupling ramp position indicator helps the operator figure out when a couple of magetic couplers are reasonably positioned over the electro magnetic uncoupling ramp. This can be accomplished using a number of closely space optical sensors.

Container Loading Control

With more and more people modeling intermodal opertions, it is reasonable to assume that somebody is going to eventually figure out how to actually load/unload containers from intermodal container cars. Technically, this is not a control locomotive control, but some operators are not going to be purists about what features are/are not on their hand held controller.

Compass Indicator

The compass indicator shows the compass direction for the train. This control is a bit debatable. I only include it because I suspect many locomotive cabs do have a compass in them; I could be wrong though.

Altitude Indicator

The altitude indicator shows the current train altitude. Like the compass indicator, this one is a bit debatable and I only include it because I suspect that many locomotive cabs have an altimeter.

Weather Effects

Most model railroads tend to operate in relatively balmy model railroad layout rooms. The real thing does not have it so good; they have to deal with rail, snow, freezing cold and blistering heat. Here's some possible weather effects to simulate:

Temperature Indicator: The temperature shows the outside temperature for the train.
Wheel Slippage Indicator: The wheel slippage Indicator shows that the locomotive wheels are starting to slip on the rails. This effect can also be indicated by a sound effect.
Sander Control: The sander control ejects some sand onto the rails to increase traction.
Wind-Shield Wiper Control: Can you imagine a G-scale locomotive with working wind-shield wipers? Can you image the dropped jaws when people first saw such wind-shield wipers in operation? I can! Alternatively, the sound of wind shield wipers can be simulated.

Sound Effects

Provide a way for the controller to inject sound effects. For a stationary controller, this can be done with stationary speakers. For a handheld controller, this can be done with headphones that plug into the controller. Here are some possible sound effects:

This sound simulates the engine sound. The sound should change according to throttle setting, train weight, rail conditions, and grade.
Horn/bell noise: This sound simulates the sound of the (diesel) horn or (steam engine) bell.
Air brakes: This sound simulates the sound of air brakes being applied.
Steam blow-down: This sound simulates the sound of a steam engine blowing off steam.
Crossing signals: Ths sound simulates the sound of crossing gate signals.
Voice Activated Radio Integration: Some clubs use walk-around voice-activated radios to simulate radio dispatching; in this situation the controller would also plug into the voice activated radios and merge the sound effects with the voice signal.
Wind-shield Wipers: This sound simulates the sound of wind-shield wipers.
F.R.E.D.: Simulate the transmission messages of a F.R.E.D. (Flashing Read End Device). My extremely limited (and probably faulty) understanding of FRED's is that they have a relatively low power transmitter broadcasts human synthesized voice of the conditions at the end of the train (e.g. brake air pressure, speed, etc.) The train engineer has a radio tuned into the FRED broadcast. If I have this totally screwed up, could somebody please let me know. The FRED sound simulates the sound of the radio tuned into the FRED.
Hot Box: Like FRED's, my understanding of hot box detectors is pretty limited. My limited (and probably faulty) understanding of hot boxes is that they are detectors that are placed along the path of a train to search for wheel bearings that are starting to overhead. Again, the hot box detector sends its problem signal the locomotive engineer via a radio transmission.
Dispatcher: There is no reason why the central computer can not simulate the sound of a dispather dispatching trains.
Wheels Squeeling: This sound simulates the sound of wheels squeeling around a tight turn.
Wheel Slipping: This sound simulates the sound of slipping wheels on wet rails.
Thunder: This sound simulates the sound of thunder while running through a rain storm on the parrie.
All-Aboard: This sound simulate the infamous `all aboard!' call.
Stereo: There is no reason why the sounds can not be generated in stereo.
Audio Gages: This `full-featured' controller has so many bells and whistles that people will start to complain that they spend all their time looking at the controller and never spend any time looking at their train. The concept here is to inject audio indications of useful information so that people can look at the train and not the controller. So the operator would hear things like "current speed is 30", "grade is 3.5%", "rails are getting slippery", "the engine is starting to overheat", etc. This is not realistic operation! However, it may be fun operation for some people.
Shoveling Coal: This sound simulates the sound the poor fireman shoveling coal into the firebox of a steam engine.
Anguished Scream: This sound simulates the sound of the co-engineer screaming because you just hit the brakes hard, and he/she has spilled hot steaming coffee over his/her pants. :-)

As long as all the sounds are prerecorded in a ROM, all of these sound effects are quite feasible within a handheld device. The possibilites of sound integration in model railroading are really just beginning to be explored.

Telegraph Dispatch Simulation

Prior to radio dispatching and CTC, trains were controlled via the telegraph. It is not that hard to imagine an LCD display that can show arbitrary text to simulate a telegraph message handed off by the telegraph operator.

Multi-layout Support

Some clubs have more than one layout in the same building. This is also the case with modular layouts at various train shows. It sure would be nice if these layouts could all support wireless walk-around without a lot of hassle. Given that the RC aircraft folks seem to be able to fly more than one plane at a time at an RC aircraft meet, this is within the realm of the feasible.

Even thought the list above is pretty exhaustive (and exhausting) I'm sure I've missed some obvious features.

Here are some comments on the features above:

I drew the line for the basic catagory functionality pretty much where the basic MRC (Model Rectifier Corparation) power packs are. While I personally am not satisfied with the level of simulation provided by MRC power packs, they sure do manage to sell a lot of the things. (I have two of them!)
The two primary features that I added for the typical catagory functionailty are wireless operation and feedback. Wireless means that people do not have to fiddle around plugging and unplugging their controller. While adding feedback to the typical configuration can be debated, I don't think many people would argue that a full-featured controller would not have feedback. The good news is that it is fair inexpessive to put a simple radio receiver in each controller and have a central station broadcast the various feedback information to all the controllers. So, really, this is no biggie.
For the full-featured functionality, I basically added a full up LCD panel, sound, and multiple layout support. The monochrom LCD panels are getting pretty inexpensive these days, that a full-featured controller could easily have one. Sound is pretty easy given an ROM of prerecorded sounds and a couple of A/D converters. The multiple layout support could be done by assigning each layout their own frequency from a band of frequencies. When each controller is powered up, it will listen to each frequency in sequence until it finds the frequency corresponding to its layout. All this really relies on is a frequency synthesis capability at FM frequencies; again, this is not a biggie.

Hopefully I have articulated a range of features and a corresponding range of budgets. People would pick the level of features that they want or at least what they can afford.

From the feature list above, I conclude two things:

There are two controller "bus" implementations that need to be designed -- a wired bus for stationary and low cost hand held controllers and a wireless "bus" for more expensive hand held controllers.
For me, the multi-layout feature dictates the design of an RF wireless "bus". However, since not everybody needs to work in a multi-layout environment, I could easily imagine that there are situations where an IR wireless "bus" has economic advantages over an RF wireless "bus".
Feedback must be part of the "bus" architecture. A controller bus that only supports the transmission of "control" information from the controller without a way of receiving feedback from the simulation will not be acceptable for people who desire more detailed simulations.

{Abrupt ending}