Philosophy of digital train control


Controlling model trains with a computer has been around since 1986 when Märklin introduced their digital system. Since then there have been numerous improvements and a wealth of new digital items and products. Some things have, however, remained the same. All digital systems consist of decoders (usually in locomotives) and they are all controlled by computers, even if the computer does not look like a computer. The Märklin digital controllers, the Intellibox, ECoS and Viessmann controllers are all computers. Some of these controllers also allow computer input from general purpose computers such as PCs and Macintosh machines and allow greater flexibility and power in controlling a train layout digitally.

The level of control that can be achieved by dedicated controllers such as the Intellibox, ECoS, etc. will always be less than what can be achieved by these same devices plus a traditional computer. The advantage of these dedicated devices is that they are easily usable by people who know nothing about computers and software, all the software and computing is hidden from them. They provide good manual control of multiple trains, turnouts etc using manual human input, out of the box. Some components add a level of sophistication by allowing the 'programming' of routes etc.

Newer devices (such as the Märklin Mobile Station and Central Station) also ensure that loco decoder addresses are unique by using 2 way communication with newer (mfx) decoders and negotiating a unique address. This is useful for club operations where members might bring any number of locos to a meeting and reduces the need to maintain a unique list of addresses and set addresses manually.

There are also a number of commercial, shareware and open source software packages available that provide more sophisticated control by means of software running on an external computer that connects to the train control hardware. The sophistication, performance and elegance of these programs also varies. Some allow nothing more than manual control (via mouse or computer keyboard) of items and do not substantially add anything to what one could do directly with the hardware, others allow scheduling and sophisticated routing of trains, sound effects, lighting etc.

There are also some items available on the market that are designed to report the identity of a train, braking modules etc.

Below I provide my view of the general topic as well as the system I have used to implement a sophisticated system based on these principles.

What is useful? What should one look for, or avoid?

That depends on what how you want to run your trains. Some people like controlling the speed by hand. Some arrange their layout so that there is no routing needed (all track are simply loops that do not intersect with other active tracks). Others like to do shunting operations by hand in one area while the computer runs mainline trains about in the background etc.. It also depends on your level of computer software competence since some packages make even simple control very unfriendly.

I have been writing train control software since 1988 and over the years I have deduced some fundamental concepts that hold true for the way that I and many others like to run trains. I also believe that there is much misunderstanding of what is required to run a layout efficiently and realistically. Below I set forth my philosophy of digital model train control.

All references to software below now refers to software running on a generic computer that is connected to the train control hardware, not the software that is internal to dedicated train control hardware.

Fundamental Principles

The quality of the train control is directly proportional to the number of s88 style detection points you have in your layout.

In any computer system where a computer controls some device, some method of direct feedback to the computer is extremely important. Imagine send a train from point A to point B. We could start the train and then stop it and after some predetermined number of seconds. In theory that may work but in practice it is highly likely to provide any satisfactory result. The model will not always travel at the same speed due to different motor temperature, lubrication, track condition etc. Furthermore each model train is unlikely to match the driving characteristics of any other anywhere near enough for a simple time delay to be of any use. What is needed is some sort of direct feedback from the layout to indicate the progression of the train. Since the beginning of digital control this was possible through the use of s88 modules that provide feedback to the digital control system.

s88 is the original Märklin name for their feedback module, each of which will report an 'on/off' status for 16 inputs back to the controller. Other manufacturers such as Viessmann, Uhlenbrock and Littfinski now also build compatible modules. Typically, a length of isolated running rail is connected to an input on an s88 module and so when a train axle gets to the isolated rail it bridges the ground from the other running rail and that grounding is reported to the controller by the s88 module. From that it can be deduced that a train is now present at the location on the layout.

By installing some type of switch mechanism at various places along the track, the arrival of the train at each point can be monitored. The more detection points along the track, the finer the resolution of the data that informs the system where the train is. The finer the data the better the control that can be achieved.

The control of the layout needs to be state based.

The computer system has to maintain a state model of the layout including the trains on the layout. In other words it needs to 'know' where each train is. It needs to 'know' what address controls each locomotive. It needs to 'know' the topology of the layout (what track is connected to what other track) and where the s88 detection points are on the tracks.

Trains can comprise any number of locomotives

Typically there is only one loco, but that is never to be assumed.

Control is of trains, not locomotives.

The locomotive(s) may be running light (not pulling anything) but it is still a train.

Signals are cosmetic

Signals do not control trains. Train control is under human or computer control. Signals are set to simulate prototypical operation and have no ability to control trains.

Computer control should not preclude manual control

The humans should be able to operate trains at the same time that the computer is running others. A human should also be able to take over control from the computer at any time.

Best Practices

Ensure that the track is well laid and reliable.

If the layout is poorly constructed, no amount of computer power and software will make it work better than it is made.
See http://layout.mixmox.com/1/laying-track for some tips on laying Märklin K-track

Install s88 detection points judiciously.

This is the most important aspect of designing and building the physical layout
Place an s88 detection point at any location where you wish any of the following to occur:- trains are to come to a standstill (E.g. before signals and at the end of station tracks and sidings)
- trains are to start slowing down for a stop
- trains are to perform any special function such as blowing a whistle, switching smoke/lights on/off triggering external events such as sound effects, level crossing booms etc.

Place an additional s88 point about 30 cm before all stopping points.
Place an s88 detection point after every fork in the track.

An example of an isolated section of track providing an s88 detection point

Do not install track occupancy detection

Track occupancy was needed in the analog days before there was a computer to maintain the state. You only need to inform the software of the presence of a train when it is placed on the layout. Thereafter, the software can track its movement and the occupancy of every track will always be known. In addition the computer will know which train is there! Rather spend the effort installing an s88 detection point at either end. The only reason to have track occupancy detection could be to detect parts of a train that was inadvertently left behind by another train. I find that unexpected uncouping that can cause this is so rare with well laid track that track occupancy is not warranted. Isolating a long length of track also reduces the power feed to the track and just invites power losses.

Give every locomotive a unique address

The whole principle of digital control relies on the ability to control locomotives individually. Even if you plan on running two locos in one train, give them separate addresses. Any decent software will be able to send the same commands to both addresses. Even models having the same design and components will not have identical driving characteristics, so attempting to run two together by making both respond to the same address is going to stress one or both locomotives.

Do not mix digital and analog control

Digital control is much more powerful and capable of doing much more than what can be done with analog control. If you are to use digital layout control you should dispense with analog control elements.
So called braking modules are analog devices and are redundant in a digital system. Don't waste money and effort installing them. Put the effort and money into s88 detection points rather. Any two s88 detection points can be made to perform the function of a braking module by using software.

Keep all track powered.

Avoid mechanisms to remove track power from stretches of track. Do not use signals to isolate sections of track - that is analog control.

Do not get caught up by feature hype

This may seem obvious but I keep seeing various manufacturers persuading otherwise intelligent people to part with their money for gizmos or features that are not needed in a well designed digital environment. For example;

Train identification systems (such as Lissy).

Trains do not run unpredictably about a layout. In fact they are highly predictable, they tend to run along the tracks (and if they don't, they stop). This means that given the topology of a layout (how it is connected) and the state of the turnouts, a train started in a known direction will arrive at perfectly predictable locations along the track. This means that trains should not get lost. If they do not get lost there is no need to identify the train arriving at any location. Think of it this way - if you do not know how the turnouts are set or where a train is going to go.. would you send an expensive train along the track? It may collide with another or run off the end of some siding. If you don't know where a train is would you start it moving? If you do not know what train is arriving at any location then you have already lost control. Do not let your layout get into such a state and you will never need to identify trains. You need to be able to predict very accurately what train should be arriving at any point. Don't waste money and effort installing them. Put the effort and money into s88 detection points rather.

mfx decoders

If you have a decent computer controlled digital system, there is nothing compelling about mfx decoders. Lets look at their features:

  • Address conflict avoidance. For a personal layout you only need to ensure that each loco has a unique address each time you get a new locomotive. If someone visits with their locomotive and it happens to conflict with one of your own, simply change one or remove yours from the layout. Changing an address is so easy with modern decoders (usually there is even no need to open the loco up) it is not worth paying money to have automatic address conflict resolution.
  • more speed steps. This has been readily available on other decoders for years.
  • more functions. This has been readily available on other decoders for years.
  • more addresses. I have never heard of anyone needing more than the 65000 addresses that have been readily available on other decoders for years.
  • ability to name the loco. Any half decent software should let you name any locomotive. Placing a feature in the decoder to enable this simply points to the deficiencies (no ability to store data locally) of the controller . Software problems should be fixed in the software not the hardware.
  • automatic recognition of a loco. Any half decent software should remember where your locos are and allow an easy way to indicate that a loco has been added or removed. Placing a feature in the decoder to enable this simply points to the deficiencies (no ability to store data locally) of the controller . Software problems should be fixed in the software not the hardware. Note that recognizing the locos on the track still does not tell you where it is, so you will still have to update the software state model anyway.

Sound decoders

Restraint is needed. They are impressive and I also bought a couple. Having more than one or two going at the same time just produces a racket. Finding place for the speaker in a loco can be very difficult. I have found that layout sound can be implemented using speakers in the layout very well. The human observer usually does not realize that the sounds are not coming from the train itself. The movement of the train tricks our brains into thinking that it is also making the sounds. In addition, station sounds, church bells, bands, traffic, bird calls etc can also all be played through the same speakers at the same time producing a decent soundscape that is synchronized with other events on the layout. Limit yourself to a couple to impress visitors...

Fancy new controllers

There are lots of nice looking controllers hitting the market. For example, the ECoS, Viessmann commander, Märklin Central Stations and Mobile Station. Without documentation of the computer control interface they are useless for computer control. Hoping it works in the future is a bit of a gamble and I would wait until the computer interface is known and implemented.

The computer interface must be rich enough to be able to create sophisticated control and also has to be implemented in the unit.

If there is no way to obtain feedback from the layout to the computer (not just the controller) in some way similar to s88 type detection points, it is impossible to do any useful computer control.

The ECoS and Märklin Central Station have computer ports but no interface is defined. Until it is made available I would not waste any money on it in the hope that the interface will be usable.
Viessmann Commander - their brochure says: "link to PC via USB". No other information available...?

2008-09-10  update: the computer interface for the ECoS and Central station has been available on the web for some time now, the caution to note is that the interface has to be rich enough for good software to be written for the controller before one takes the plunge.

2018-07-26 I have looked at the command set for LocoNet since the manufacturer of my controller (Intellibox) has switched over to using LocoNet for the computer interface. I extended some sample code to get a good understanding of the implementation. I have found a serious flaw. It does not provide a way for software to obtain the existing state of sensor inputs (such as s88 data). The software can of course pick up changes as they happen, but when the software connects to a LocoNet system it has no way to directly find out what sensors are high (on). There are some commands that have the effect of making certain Loconet sensors to report their status as if they had just changed but that does not work with items on an s88 bus nor with the Intellibox I (Ver 1.55). There is no reliable way to obtain the information. The power state of the device is similarly unavailable until it changes! Uhlenbrock has told me that the Intellibox II has implemented a work around for this. The point is, even mature protocols can have important bits missing. See more details at https://cabin-layout.mixmox.com/2018/07/LocoNet-Intellibox.html

Software requirements

Good communication with the hardware

Any train control software that is to control a layout in a confident manner need to have a very solid and sound communication with the train digital hardware. The interface with train control units is typically through a serial port. This could be through an older RS232 port, or USB serial port. It is also possible to control digital system through a parallel port or over a network using TCPIP or other protocols. It does not matter what the protocol is, it just has to be solid so that commands and messages do not get lost of misinterpreted. Proper flow control is important to ensure that the computer and train interface stay in synch with each other. One cannot send commands too fast. Serial ports all have various methods of handshaking such communications and the use of proper flow control is important for optimal performance. Using time delays to simulate proper handshaking is crude and inefficient and should be avoided wherever possible and the appropriate flow control should be used by the software.

Normalize all locomotive speed steps to one common speed scale such as km/h

User interfaces that present speed controls in terms of loco decoder speed steps are just awful. Some locos have decoders that have 14 speed steps, others 27 or 126, so it should normalize them all by mapping them all to km/h speeds. Different model designs (motor, gearing, etc) also means that speed step 6 will be unlikely to produce the same speed in two or more locos. This means that the software needs to calibrate each loco and maintain a scale speed table for each decoder speed step for both forward and reverse. Once this is done, everything can work on the same baseline, multiple locos can be inserted into a single train and controlled independently so that their actual speeds are matched as closely as possible.

Sample calibration screen. In this case a 27 step Motorola decoder.
Interface (c) Dale Schultz

Do not require the user to memorize decoder and turnout addresses and such numbers

The software should not expect the user to remember decoder addresses. There should be a symbolic layer that the software maintains so that a loco can be named (e.g. BR 05) and that is mapped to the address of that loco under the covers for all operations on that loco.
Turnouts should be changed using a visual representation of the layout. A mouse click or similar friendly gesture should suffice and the user should not have to remember what the turnout numbers are.

Principles of control

Given correctly placed s88 contact points, this is how I define my layout within my software:


The fundamental unit on the layout is called a track. Each 'track' defines a stretch (in one direction) of layout track starting at an s88 detection point and ending at a second detection point. Between the two ends there can be up to 2 more additional detection points. These detection points are named as follows:

s88 start (required) E.g. s88 #2
s88 slow E.g. s88 #56
s88 stop (required) E.g. s88 #12
s88 longstop E.g. s88 #4

For each of the s88 points, the distance from the s88 start is entered in cm. If a train is to stop in the given track, it first determines if should stop at 'stop' or 'longstop' depending on the length of the train and the availability of a 'longstop'. If it determines that the train is to end up at 'longstop' then it uses the following schema:

When it gets to 'longstop' the train will be stopped dead.
When it gets to 'stop' it will slow to the 'creep' speed for the train.
When it gets to the 'slow' point it will start a deceleration curve that will result in a speed of zero after traveling the distance from 'slow' to 'longstop'
When it gets to 'start' it will start a deceleration curve that will result in the maximum speed tolerable at 'slow' after traveling the distance from 'start' to 'slow'

In other words the desired speed at each point in the track is calculated backwards down the route, starting at the end point at speed zero. The penultimate s88 initiates a creep so that the train comes to a nice gentle stop at the end point.

If there is no 'longstop' or the train is short enough to halt at the 'stop' point then the logic is shifted up one position as follows:

When it gets to 'stop' the train will be stopped dead.
When it gets to 'slow' it will slow to the 'creep' speed for the train.
When it gets to the 'start' point it will start a deceleration curve that will result in a speed of zero after traveling the distance from 'start' to 'stop'

Note that the actions carried out when trains trigger the s88 is thus dynamic and can differ from train to train. Note also that another 'track' can be defined that uses the physical track in the other direction in which case they could be defined as:

s88 start (required) E.g. s88 #4
s88 slow E.g. s88 #12
s88 stop (required) E.g. s88 #56
s88 longstop E.g. s88 #2

In addition to the s88s present, any turnout setting required to set the track are also defined. Any signals that protect the track are also defined. Each track can also be defined to be a station, (passenger or goods), electrified, stopping allowed or not, a dead end, etc. A speed limit can also be set along with the name of a digital image that shows the track at each s88 point.


Once each track is defined in the software they can be chained together to form 'Routes'. Each track can be used as often as needed in all the routes. Each chain of routes must start and end at a stopping point. Each route can also define an ordered list of subsequent routes.

When a train is placed on a track any routes that start at that track can be invoked. The interface does not list the route names, rather the destinations of each of the applicable routes. This allows me to click on a train on the layout diagram and pick a destination from the pop up menu. In order to run the train from its current position to the destination it works its way along the route checking that the track is empty. If it gets to a track in which the train is allowed to stop, it books that track and then works back to the train calculating the speed curves for each part based on the distances and the characteristics (mass and power) of the train as well as track speed limits etc. Once it gets back to the train the train is sent off on its way. As it trips the s88 detection points the speed is regulated to the previously calculated curves. Track that is vacated behind the train is freed up.

If there is no free track as far as a valid stopping point, the system keeps looking for a route to get to the destination until it succeeds in booking a route.

The list of subsequent routes allows a route to be defined as far as a set of sidings or station entrance tracks. The entrance and stopping tracks for each alternative are defined as routes in the list of subsequent routes. This allows the routing software to automatically select a vacant track as needed. Sidings are listed in order of increasing length so that the system finds the first siding that is long enough to accommodate the train.

Turnouts and signals are set accordingly in advance of the train moving through the chain of routes.


Each locomotive is defined in terms of its decoder type, address, mass, power, length etc. calibration speeds are stored for each step.


Trains comprise any number of locomotives. This allows flexible multiple traction (double heading) since all operations performed on a train are in fact carried out for every locomotive that is a member of that train. The total train length is also defined and is used to determine when tracks have been vacated. If the distance between the leading axle of the train and the end of the last track occupied is greater than the length of the train, the trailing track is freed up for other trains to use.

If a locomotive is in a train with other locomotives, any speed or direction adjustment made by hand on the Intellibox are detected and comparable speed and direction adjustments are also made to all other locomotives in the train. This allows me to adjust the speed of any train (even ones with multiple motive power) at any time. This does not require any linkage between the locomotives to be made in the Intellibox (consists). i.e. if I add an additional loco to a train in my software, all the required consisting is done automatically. Since all speeds are normalized to km/h it is possible to have trains with locos having different numbers of speed steps and gearing in a single train.

Unexpected trains

If an s88 is triggered anywhere where no train is expected to arrive, all trains are halted and an alarm is sounded because it means that somehow a train is somewhere unexpected. The computer screen indicates where on the layout the unexpected train was detected. This can happen if a turnout fails and directs a train down the wrong track (and is why I suggest placing an s88 after all forks in the track).

Manual control

At any time I can indicate that any tracks are reserved for my use. I can operate trains manually in this area and trains under computer control will not attempt to use those tracks. Any s88 detection points that are triggered in these tracks are ignored.

For any locomotive I can also switch on ballistic control. This is useful for locomotives with large number of speed steps such as 126. Without ballistic control it can take a lot of cranking of the speed knob in the controller to effect a lot of speed change. When ballistic mode is switched on for a locomotive, faster movement of the speed knob results in a greater speed change. The software detects the changes from the Intellibox and does the additional adjustment for you.


Creating the software has taken some years and works well. For me, this validates my design principles and gives me the confidence to make statements about train detection systems and braking modules etc. After inventing the system of calculating the speed backwards from the end point I found out that the scheme is very similar to the high speed control system of modern trains which travel too fast for visual signals to be used. Essentially the maximum speed is calculated based on the distance available to stop/slow in time at the next halt/slower speed limit. The system continually attempts to adjust the current speed to a desired speed. I found that very gratifying. Even more gratifying is watching the trains waiting for empty track, selecting available tracks, rolling about setting off sound effects, coming to smooth stops, etc.

What I have described here is just the basic principles. In addition to running the trains there are of course many other features such as arrival and departure boards, cab views of the track, remote PDA control and generic events (such as sound effects, switching on/off of smoke, lights, on board sounds) that can be triggered by routes starting, ending or specific s88s. etc.