The Onehouse Model Railway
Documentation Page
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
<tfc@onehouse.co.uk>
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.
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.
Options:
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.
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.
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.
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.
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.
The TOOLBAR could have such options as:
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.
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.
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++).
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.
There are two functions to the client as I see it.
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).
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.