The Onehouse Model Railway
Documentation Page

This page will grow considerably over time as we add more and more documentation to it. We have decided to split the page into more manageable blocks of information so that this page continues to be the thought processes of the those involved. Our progress on what we have already done and achieved has now moved to the PROGRESS page.
Thanks for advice passed on to us by other railway modellers, suppliers etc will also be posted on PROGRESS page as will any links to those individuals or groups who have helped us in any way to achieve our aims.

This page is meant to be thought provoking for the people involved in the design stages of the electronics and computer programming. As such they are only the thoughts of individuals and are therefore the basis for much discussion. If you wish to comment on any of the thoughts published here then please feel free to email us at <>
As time progresses and we will add more to this page as we begin to firm up on our ideas and identify those paragraphs that we intend to work to.

We have gathered our information on this page from numerous web sites around the world and from our own ideas as to how to do things. Where we have gleaned information from a particular website you will find a link to that site. We do not intend to copy pages from other sites to this site or to mirror any particular site from this location.

And so to our thoughts and ideas:



Given the size of the Onehouse Model Railway the use of standard block section control is considered nonsensical. With over 100 block sections it would involve several miles of wiring and a large number of control relays switching sections on and off between a number of different controllers. One alternative considered was the Hornby Zero 1 style of control, available during the mid to late seventies. The same style of control also appeared in the Maplin Electronics Magazine in 1982 as Multi-Train Control. Unfortunately both of these systems have severe limitations in that they allow only 14 locomotives on the layout simultaneously (each with a unique address) and can only control a maximum of 4 locomotives at any one time. The Onehouse Model Railway needs higher availability on both counts.

Having searched the World Wide Web for alternative methods of control, the National Model Railroaders Association (NMRA) of America have a website where they have supplied the full, detailed specifications and recommended practices for a digital command and control (DCC) system. The original ideas and plans came from a German company LENZ .
Having drawn up the specifications, other major manufacturers have taken these specifications and recommended practices and implemented them fully.
Manufacturers include Marklin , Digitrax and ZTC (a UK company)


The figures quoted below are what we understand to be correct but then we could be wrong. I feel sure somebody will correct us if it is wrong (Thanks in advance for your help).
Standard DCC offers the ability to control up to 126 locomotives and 128 peripherals simultaneously. Enhanced DCC offers the ability to control up to 254 locomotives and up to 9,999 peripherals.



a. Buy the necessary units; hook them together, away we go.
b. Buy some parts, make the rest, hook up, away we go.
c. Design and implement our own system following the specifications and recommended practices of the NMRA.

We have chosen to take option C.



This is essentially a power amplifier / converter. It takes its input from the logic board in the form of TTL level data at low power. It produces an output of +/-17 volts at up 5 amps. (Could be higher, but 5 amp is considered a sensible maximum). NMRA suggest additional boosters for current ratings higher than 5 amps.
Onehouse Model Railway will use 2 such units. 1 will feed the track and control all the locomotives. The second unit will feed the ancillary bus to control the points and signals etc.


The logic board has an onboard oscillator to create the correct timing frames to satisfy NMRA Specifications. It must continue to produce an output to the boosters even if the input from the PC Control Station is lost (PC Failure etc). There are 2 possible options for the logic board.
Option 1 uses discrete components, ie 8 TTL Integrated circuits, resistors, capacitors etc.
Option 2 uses a PIC, which with a single crystal as the oscillator and programming produces the same result.
The software to program the PIC is available from the Internet and could be used without further effort on our part, although we may consider reverse engineering the HEX code and modifying / regenerating the code.


This is a Pentium 75 with 64MB RAM and a single 545MB Hard disk. It is anticipated that there will be 2 programs running on this machine. A Terminate Stay Resident Program (TSR) written in C++ that receives interrupts from the logic board and delivers the next byte of data to the parallel port. A Java based database management program that takes input from the keyboard for management functions and from the handheld controllers; cab simulators and layout feedback system via the serial port or perhaps a second parallel port. The two programs use a common database area. The Java program will read and write to this database and the TSR will only read from it to feed the logic board.

d. The HANDHELD Controllers

These will take the form of TV / VCR style remote control units. We envisage these having a keypad of some 25 or more keys with a 16 character by 2-line LCD display. For trial purposes we are playing around with an old PSION Organiser II LA unit which provides some 36 keys with an LCD display and is programmable using OPL. If anybody has a serial cable to connect the PSION to a PC please let us know. We may decide to obtain more of these units and use them in the final game play or we may choose to design and build our own units using PIC’s and an LCD display of either 16 x 2 line or 20 by 2 line. We may even choose to obtain the later PSION Organiser II which has a 16 x 4 LCD display for experimentation.


These are basically the same as the handheld controllers but are designed to simulate a real cab environment. Proper throttle, brake etc and combined with micro cameras mounted in the locomotives a video display. You really drive the train using just the camera view and the controls in front of you.

f. The FEEDBACK system

The purpose of this section is to provide feedback to the database of the state of the railway. It will provide information such as point position (Normal or Offset needed for track plan indication); signal condition (Red, Amber or Green for track plan indication and for train management); track occupation indication (see note 1 below).

Note 1. This subject requires some serious discussion before we go much further. How are we going to achieve this? Simple infrared yes / no (is the track occupied or NOT); more complex such as identifying each loco in some manner or other; or more complex still by identifying each piece of rolling stock and locomotives. This would give us the means to build consists from the handheld controllers or the PC Control Station and keep the details in the database. Perhaps the database could complain if a consist is identified that isn’t in the database. How would we identify the locomotives and or rolling stock as it passed a track occupation sensor? One possibility considered is barcodes. Unfortunately this isn’t practical because the trains run in both directions and the data received has therefore to be palindromic (same in both directions) which barcodes are not.

Some additional thoughts.

What has to happen at switch ON.

A full reset to ALL decoders must be sent. This is easily achieved by sending a continuous sequence of ALL ZERO’s. This according to the NMRA documentation causes decoders to reset to the known state.

The database should be set to DEFAULT state and then transmitted to the decoders such that the layout starts in a known state. Monitoring of the feedback system should confirm all points and signals set correctly. Default settings to held in a file separate to the database such that it can be edited either from the command line in a text editor or as part of the Java Application.

A FULL clear to be sent to ALL handhelds and cab simulators.

JAVA application thoughts

The TOOLBAR could have such options as:


Drop down menu to display map of choice (Could be a single level or combination of levels). Map to show the track plan; the position of points and the state of signals; track occupation (if known) at this stage.


A tabular display of ALL points with positions.


A tabular display of ALL signals showing settings.


Option to select ALL loco’s or only active loco’s then display the current state and location if known.


This will be used to program the Configuration Variables (CV’s) in the decoders. See the NMRA Recommnded Practices for the CV’s and their settings.
See also specific manufacturers documentation.


Open, Edit, Save etc.

Thoughts on Rolling Stock Identification

Thoughts on Locomotive and Rolling Stock Identification. Having looked through my old Maplin magazines I stumbled upon the weather station (Issue 31 and 33) which uses the likes of a double width barcode. The Upper bar carries strobe marks, the Lower bar carries the data marks. See Bar A below.

If we require a 10 bit code then we produce a 12 bit barcode so that the LSB and MSB can be used as a direction of travel flag.

Eg. If the first bit read is a ‘1’ then this is FORWARD travel and the next 10 bits should be read as they are, the final bit is ignored. See Bar B below. If however the first bit read is a ‘0’ then this is REVERSE travel and the next 10 bits should be read and reversed and the final bit is ignored. See Bar C below. You will notice that if you read left to right on Bar B, OR left to right on Bar C and then reverse it you achieve the same 10 bit barcode identifier. Ie Binary 1011010100. (Decimal 724) Bar D is another bar code which is a FORWARD travel bar showing Binary 0111000101 (Decimal 453)

Basically we need an IR LED in the track which will illuminate both bars as they pass over it, with an IR sensor either side of it to collect the data from the barcodes. Each time the strobe mark shows white this will trigger the data circuit to read the state of the barcode IR sensor. A BLACK area will absorb the IR and thus the data read will be as a ‘0’, a WHITE area will reflect most of the IR and thus will read as a ‘1’. We have chosen a 10 bit code to provide 1024 unique identifiers. Given that we already have over 50 locomotives and multiple units, over 70 coaches and over 100 trucks, a simple 8 bit code would quickly be used up. A 9 bit code would provide 512 unique identifiers and may well be enough. We would rather start out with 4 times what we have than go for a 9 bit (512) and then a major upheaval in 10 years time because it wasn’t enough.

Because of light spillage from the barcode being read by both sensors we may need to add an aperture over the IR LED and sensors to ensure each sensor only reads its own codes.

Matthews thoughts on the Programming of the system

More for completeness, as far as the backend of the system is concerned.

Operating System to be used: Red Hat Linux, probably v6.0 using the latest 2.2.6 release kernel.

Development Environments: Backend to be written in Java and C++, frontend in Java. At least Java 1.1.7 to be used, if available and reliable, 1.2 is preferred. Any number of supplemental packages, including the JGL from KL-Group.

Backend Datastore:

A PostgreSQL Database, containing all persistant storage information such as a complete database of all rolling stock and the accessory data (eg. what points there are, their id's, what lights there are etc). Also to contain dynamic information such as point settings, light settings, last known locations for trains. Reason for putting dynamic information into the database is so that multiple clients can connect to the system to drive trains, not necessarily just the one running the layout, since we will be using a socket based system (next section). This allows, for example, all four machines in the room to be able to (potentially) drive trains, as well as hand controllers etc.


The next level up from the RDBMS is a number (1 or more!) of C/C++ programs that will interface directly with the logic boards and hand-held controllers. These programs will run only on the Linux server acting as the master controller. Their functions will inclide: o Ensure a continuous datastream to the logic boards, o Ensure data from hand-held controllers is handled correctly, o Allow clients to send updates to the layout to change points, loco speeds etc.

The 'drivers' will communicate using a TCP Socket based system for simplicity (since this is extremely easy to do in Java and not too difficult in C++).

It is anticipated there will be the following drivers:


Daemon to sit and deal with the DCC Logic Board exclusively. Ensures there is always data being fed to the logic board. Listen on a published port for connections (which can be persistent, so support for multiple connections must be implemented). Connections coming in will be to send information to the layout so a protocol must be defined that the clients use.


I'm not very sure about how this is best implemented, so i've come up with 'an idea', but there could be better solutions: This is the hand-held controller daemon. It's job is to find out what controllers are currently switched on and then listen on a published port for the master control client to connect. The Master Control Client software can then enable the various controllers and have visual on-screen representations of them. Since the controllers will be dumb terminals for the most part, the client software will have to be able to receive communications from the hand held, translate them to real commands and then send the updates out to the database and the layout, updating the screen as it goes. It is quite probable that much of this will be implemented as part of the backend Java interface and will not be dealt with by the 'Java Client' as such.
Note: The Master Control Client being nothing more than a version of the Java Client software running on the master control machine.


Again, not overly sure about this one. The purpose of this daemon being to monitor input streams, including the track occupation sensors and any other inputs we have. This daemon I would anticipate working similar to whatever way we end up implementing the controller daemon, ie. listen on a port waiting for the client to connect and then feeding data back as it comes in, in it's raw form for the client to process and update the database.

Backend Java Classes:

These would form support classes and interfaces that would hide the backend away from the client. Presenting things such as 'setSignal()' to the front end so that the backend can then send the appropriate requests to the layout as well as update the db and so forth. The Backend Java Classes could also kick off threads as part of their initialisation that can set up connections to the controller and input daemons, hiding this too from the front end program.

Front End Java Client:

There are two functions to the client as I see it.

1. Monitoring

Monitor what happens on that layout, as sensors fire or points change or loco's move etc, this all changes on the on-screen drawing. Also, the ability to 'focus' on a loco and have a mini controller view so you can see exactly what a loco is doing (speed, direction).

2. Driving

The 'focus' view mentioned above could have a checkbox on it to enable 'write' privs on the window, allowing the operator at the PC to drive the loco, or indeed drive many loco's simultaneously.

Included in with the client, that will most likely be 'silent' processing done by the backend Java classes would be to see if we're the first client running and if so to establish connections to the various daemons and bring online the processing of the controllers, the layout itself, and any input streams automatically in the background.

Page last modified: 4th March 2001 by Onehouse <>
© Copyright 1996-2001 Pete Peddlesden. All Rights Reserved.