In this discussion I will present the advantages and challenges of using solid state components in signal systems for ride-on railroads.  I will also discuss why I believe these solid state automatic signals have many advantages over other systems.

Introduction

This discussion can easily get out of hand because there are many approaches to signals that will work depending on the railroad – track construction, physical needs, length of blocks, power availability, knowledge and backgrounds of the people implementing the system, budget, on and on.

It’s kind of like talking about boiler treatments, opinions differ, sometimes strongly.

I’m going to cover a lot here. I can get “wordy” and “Technical”. If I bore you to tears, I apologize.

My educational background is Electrical Engineer (Minor in Computer Design) but my professional life was in software development of large fault-tolerant bank communications and transaction processing systems.

To The Subject

Many people say that you can’t use solid-state components in a ride-on railroad signal system because they are not reliable (mostly due to lightning and environmental issues). I’m here to say that, in my experience, this is false.

I run a 7.5” gauge, Little Engines “Old Northern” (UP-844) fired with propane. I used to travel a lot with 844 and loved running bi-directional when the track I was visiting supported it. To me it was more interesting to pause for meets with other trains than to go endlessly round-and-round.

One of the great tracks I visited every year had engineer-operated “button” blocks (the Capture/Release type). Every year, on Saturday night, they would setup the track for bi-directional running after dinner. Every year everyone would depart the yard after dinner and every year the railroad would get snarled up in short order. Many would get frustrated and park their trains.

It was not a track problem and it wasn’t the signal system (inexpensive and worked if operated properly), it was the fact that there were a lot of visiting engineers who were unfamiliar with the railroad, unfamiliar with how to use the buttons properly, got distracted, or were just forgetful. The biggest problem was when the railroad came to a stop because someone forgot to release the block behind them which left a block in the ‘occupied’ state. The result was frustration when it should have been a fun experience for all.

This experience set me on the path to develop a reliable automatic signal system. Since 2009 I have been developing a system that meets my basic requirements which were that the system must:

• Guarantee only one train in a block at a time (see: Why ABS or APB Signals Are Not Sufficient) … but handle the case where someone ignored a Stop (Red) signal.
• Designed to handle the demands of full-time, bi-directional running (many ABS-like systems do not support bi-directional running – i.e.: traffic in both directions at the same time)
• Be affordable
• Aid the user in diagnosing problems such as broken bond wires, etc.
• Minimize cable runs
• Be reliable (if it’s not reliable, people will not trust it and it’s useless)
• Reliably detect trains in any weather/track condition (i.e.: the wet/dry track problem) and account for wheel contact noise, etc.
• Be flexible by allowing the run pattern to be changed without changing hardware, e.g.: one configuration for normal run days, another for large meets, and another for Card Order runs, etc.
• Support both fully automatic (ABS/APB-Like) and dispatch (CTC) modes (dispatcher controls some/all signals and powered turnouts).
• “Do the right thing”, even when engineers do the wrong thing, e.g.: traffic must be allowed to proceed as much as possible even if a train captures a block but (due to derailment, inattention, etc.) the train does not proceed into the block.
• Promote traffic flow where possible to avoid congestion and prioritize certain routes over others (i.e.: some level of ‘auto dispatch’)
• Not require a central PC to operate (i.e.: distributed system, no single point of failure).
• Support an arbitrary number of single-track entry/exit points.
• Support ‘convenience’ items such as: “Approach Lit” signals, dimming of signals at night and allowing the user to define the signal lamp configuration (light combination) for each signal aspect.
• “Cool” stuff, like a real-time display of the track occupancy on the web and/or allowing engineers to view real-time track occupancy on their smart phone so they can decide if they want to go left or right at a given choice point to avoid congestion.
• Support a real-time display at one or more dispatcher positions as well as one in a passenger loading area so the public can see trains progressing around the track, etc.

Now, one might say “but I don’t need all that” … and that’s a fair statement. As I said, every railroad has its own needs, but, I assert that you can get all the above for not much more than some button or relay systems I’ve seen. One track I visited used industrial, sealed limit switches for their engineer-operated signals (2 capture and 2 release per block). These switches are very reliable but cost close to $100 each. They could have had fully automatic signals with all the features above for less than that.

The first problem is that there is no way that an engineer-operated (i.e.: button, ‘whisker’, etc.) or relay system can come close to addressing the range of functionality listed above.

In the past, industry relied on relays to operate everything from simple on/off pumps to huge industrial machines. These tasks have all been handed over to Programmable Logic Controllers (PLCs) that incorporate micro-controllers. Why? Because PLCs offer far more flexibility, less complexity, diagnostic information, and more features than relay systems while reducing the amount of hardware required.

I started by building a prototype micro-processor based controller to test various methods and software algorithms for reliable track occupancy detection. Then I designed a 3”x2” module that was to become the building block of the system. I ordered 100 printed circuit boards implementing my design, not knowing if they were 100% correct or not. This was just before Christmas, 2010. I figured that I would either have 100 useful boards or 100 coasters to give away to family for Christmas! I’m happy to say that, to this day, those cards have not required modification (no cut traces, no added jumper wires, etc.). I did have to replace the processor with one having more memory (I should have remembered this lesson from my professional days). It was pin and software compatible with the previous processor so a very minor change.

The biggest changes over the years have been in the firmware as I added support for new features.  The “Base Card” that the controller plugs into and field wiring is connected to has changed as I have learned more and more about how to deal with lightning. The Base Card contains most of the lightning and surge protection. At this point I can draw a 3/16” arc from a high voltage AC supply on one of the track input terminals with no damage.

Each controller shown above has 8 track inputs.  These track inputs can also be used for contact sensing, etc.  Each controller also has 16 Pulse Width Modulated (PWM) outputs that can drive 5 three-LED signal heads or other devices.  There are also add-on cards for expansion to drive relays, etc.

The system is installed by locating the controllers around the railroad close to the items they are connected to without regard to block boundaries.

Only 4 wires are buried along the track right-of-way to connect the system together. One pair for power (we use one pair of #16 for over 3,000 feet of controlled track) and a data pair (in practice this is one pair out of a CAT-5 cable). In our case, this supports 19 controllers, 60 signals, many powered turnouts at route choice points.  The system samples about 100 track segments and other inputs (powered turnout position, etc.). This system draws 1.9 amps at 16 volts from a single supply located in the dispatch tower.

Contrary to most systems, no additional wires are used to connect the signals at the ends of a given block and a given block may have many entries and exits, separated over an extended distance.

The controllers are placed near whatever item needs to be connected to them, tracks, turnout motors, signal heads, etc. regardless of which block they are associated with. The block coordination is defined in the (user edited) configuration text file. The controllers communicate over the data pair to carry out the block coordination, turnout operation, signal aspects, etc.

To add a new track, signal, or controlled device you just connect it to the nearest controller or tap into the closest power/data and add a controller.

There is basically only one type of module used – the controller. They are all the same. We only need to stock spare controllers and signal heads. The controllers differ only in the configuration that the user loads into them (the firmware is the same in all controllers).

Reliable Train Detection

The system addresses this issue on several levels. First, the track input passes through physical lightning/surge protection, then through electrical conditioning and to one of the analog inputs on the processor. The raw track voltage is then processed by an adaptive signal processing algorithm designed to address track condition (wet/dry, imperfect joint bonding, etc.) as well as wheel-to-rail contact issues (oxide, leaves, etc.).

This is what the controller “sees” for a typical track segment (‘Strip Chart” display from the SComm system monitoring program):

This shows the passage of two trains on fairly dry track.  The rising of the red trace shows when the system considered the track segment ‘occupied’.

Note that the track voltage itself (green and yellow traces) did not immediately rise to the max ‘unoccupied’ level.  This shows that, due to the electro-chemical characteristics of the ballast, rail, ties, screws, etc., the track is exhibiting the characteristics of a distributed RC network.  This will be different for each type of rail, ballast, ties, etc. but the track signal processing algorithm will adjust itself automatically on a track-by-track basis.

To date I have not encountered any track condition (other than welded ties) that the train detection can’t handle – even a railroad that uses crushed shells for ballast … shells come from the ocean and thus contain a lot of salt … imagine the leakage that causes when it gets wet!

There has been discussion of the track current required to reliably actuate relays. I try to keep the track current to the absolute minimum for two reasons:

• Minimize the system power requirements to allow the railroad to operate from a single supply fed over long distances.
• Minimize corrosion of the rail, track screws, etc. caused by the current that flows constantly when the track segment is idle.

In our case, the total track current for a typical detected track segment (say 500 feet) is:

• About 1.4 milliamps (ma) when the track is dry and not occupied (calculated track resistance = 3.6 k ohms),
• About 2.2 ma (track 463 ohms) when wet and unoccupied,
• Worst case, about 2.4 ma for an occupied track segment.

Of course, this fluctuates depending on the track construction, type of ballast, etc., but this is typical. This current value is far less than that proposed for typical relay systems … and, if you add a transistor to achieve this in a ‘relay’ system (but remember you still do not have the adaptive signal conditioning) you have transitioned to a system that exposes solid-state logic to the rails (and thus lightning, etc.) so why not keep going and get the added benefits of a fully solid-state system?

Only One Train In A Block At A Time

The system uses “Approach Tracks” (or “Claiming Blocks”) to guarantee that only one train is ever given permission to enter a given block at a time.

When a train approaches a signal, it is detected on the Approach Track just prior to that signal. Upon detecting the train, the system examines the current occupancy status of all of the track segments associated with the block as well as determine if other trains are waiting to access the block at other entry points. If conditions are such that this train can be permitted into the block (block is clear, this is the highest priority train of all trains waiting, etc.) all block signals are dropped to “Stop” and his signal is set to a “Permitted” aspect (either “Clear” [usually green], “Approach” [usually yellow], or “Distant Approach” [usually flashing yellow]*) as dictated by the track conditions ahead.

*(Note: The system installer determines what the actual signal indication is for each aspect.  Those listed are the normal, or default, indications)

The system will never set two signals for a given block to a “permitted” aspect at the same time. Thus, no two trains should ever be in the block at once. If any track segment in the block does become occupied unexpectedly (someone ran a red) all the signals for that block are immediately dropped to “Stop”.

Closer To The Subject … Lightning

This solid-state solution has been in use for over 5 years on a railroad that is in the woods (i.e.: dampness and lightning hitting trees).  In one case the water line and signal conduit were exploded out of the ground when lightning hit a tree very near the track.

In the beginning there were lightning-related issues (Florida is, after all, the lightning capitol of the world). Over time, I have learned a lot about the effects of lightning strikes and how to deal with them.

Depending on soil conditions, lightning can generate from 1 to 10 volts per foot across the ground. If you have two points 500 feet apart connected by a wire, you can get 500 to 5000 volts across that wire/track/whatever in relation to the “local” grounds at the ends.

Beware of power lines near the railroad! The power company places lightning arresters on their poles. These devices are designed to route the lightning from their lines to the local ground at the base of the pole – again, a source of “ground differential”. In addition, precautions must be taken in the system power supply. I discovered that lightning surges were coming in through the commercial power to the railroad – even the neutral when the system was off. This doesn’t usually affect your TV at home because your TV is not in direct contact with the ground. It’s a different story for our railroads where the power supply directly feeds devices that are connected to rails in intimate contact with the ground.

To be fair, my controllers will not survive a direct strike. I doubt if any ride-on-railroad signal system would survive a direct strike, even a relay/switch based system … but, in such a system, you give up the benefits of software logic, etc. … life is about trade-offs …

What About Flexibility?

Once you wrap your head around the fact that the system is just a collection of configured inputs and outputs (both analog & digital) that can communicate long distances, you can start dreaming up all kinds of added features such as:

• A force transducer attached to a short section of track that measures axle loading. It can activate a signal that prevents someone from departing the yard with axle loading that exceeds the railroad’s permitted limit, or
• A device (such as a potentiometer connected to an arm that contacts the back side of the wheels) that measures wheel back-to-back distance and issues a Stop if any axle is out of specification (thus damaging turnouts of causing derailments).
• Etc.

Since every input and output is, in effect, connected to the one data network, the status of any item on the railroad can be used anywhere else on the railroad. Examples:

• The system monitoring program (SComm) installed on a laptop, can be plugged into any controller on the railroad to see the status of every section of track (the actual voltage reading, not just if occupied or not). This voltage can be charted as a train traverses the track segment and you can see if there are ‘high resistance’ joints (i.e.: bad bond wires).
• This same PC program can also be used to present a real-time track display to passengers in a waiting area, a dispatcher in a central tower, etc.

The system can drive a variety of signal heads containing one, two, or three lamps. It also supports full-size “searchlight” signals for one of my customers (the signal head contains a magnetic “slug” motor to change color) and soon, full-size semaphore signals.

What About Traffic Flow Control?

The system currently tries to aid flow control at the block level. In the future it is hoped that the system will be able to manage flow across multiple blocks (e.g.: within a territory).

One thing the system does is that a train is given 30 seconds (default, can be changed) to enter a block after the train has been given a “Permitted” signal aspect. If the train does not enter the block in the required time, and there is another train waiting at a different entry for the same block, the first train’s signal will be dropped to “Stop” and a Permitted aspect will be given to the second train. This prevents a train that has derailed, engineer talking to someone, etc. from preventing other traffic from flowing. After the second train has cleared the block the first train will again (conditions permitting) receive a Permitted aspect.

Another example of flow control, consider the following:

The system will not give a Permitted aspect to Train 3 if there is an opposing train (Train 2 here) at the siding headed towards him and a train (train 1 here) on his “Destination Track” (the track he would end up on when he exits the single track).  This is because, if Train 3 were allowed to proceed there is a possibility that he would not fit into the siding with Train 1 and therefore block the progress of Train 2 needlessly.  Holding Train 3 allows traffic to flow in, for example, and eastbound direction, if traffic in the westbound direction is blocked due to a derailment, etc.

Another option available is to configure the signals such that, if the far siding (where Train 1 is shown above) is full you show Stop (Red) to Train 3 even though the block track is free. This prevents a train from arriving at the west end and possibly fouling the block for east bound traffic if he can’t fit in the siding when he gets there.  In the same setup, configure the signal to show Approach (Yellow) if the siding is 1/2 full and the block is free.  This way, long trains (ones that know that they will not fit in 1/2 a siding) can be told to not proceed on a Yellow even though they normally would.  This will prevent a long train from possibly fouling the block.  Keep in mind – if the train at the yellow does not proceed (such as the long train mentioned) and there is an eastbound train waiting, the first train’s yellow will timeout after 30 seconds and the eastbound train will be cleared to proceed – thus keeping traffic flowing.

Solid-State Logic and Maintainability

I find that 90% of my signal issues are due to broken/improperly installed bond wires, improper insulated joints, MOW crew not replacing bond wires after replacing track, etc. These problems are the same for any signal systems that detect trains via “Track Circuit Detection”, solid-state, relay, doesn’t matter.

One of my headaches is that the motor devices we use (purchased) to actuate turnouts have micro-switches in them that tell the signal system which way the turnout points are set (left, right, neither – e.g.: in transition, rock in the points, etc.). These micro-switches tend to fail. When this happens, the double-headed route signal at the switch point will indicate that neither route is clear because the turnout is constantly “in transition”. Both signals will display a “Stop” aspect even though the engineer can see that the points are hard over. In this case, I will get a call telling me that the signal system isn’t working when, in fact, it is just reacting to the information it is being told (the turnout is not set for either route). Unfortunately, this isn’t an excuse – as far as the engineer is concerned, the signal system is not working for him.

The system displays diagnostic information in the signals (such as when a section of track is in indeterminate state due to a track problem) to help with fault location. This information is carried “on” the red signal (by a specific ‘wink’ sequence, in our case, we have configured that 2 winks means “switch points against” as in the case above). The engineer still sees “Red”, so he stops.

In the case above (failed micro-switch in the turnout motor), when the engineer reports that both signals are winking red twice, the signal maintainer knows that the turnout motor needs to be replaced.

The signal maintainer can use the ‘wink’ information to diagnose the issue (usually a track/turnout motor issue). It is the railroads decision if this diagnostic information is displayed or just “solid” lamp displays are used.  Even if only “solid” aspects are used, the fault information is available to the dispatcher on the SComm Track Display screen.

A wide range of people are drawn to this hobby and they have a wide range of skills and backgrounds. To some, the thought of a signal system that uses “those pesky computers” is frightening. The controllers are user-configurable (currently via a text file, soon via property settings in SComm, the Windows-based monitoring program). There is no programming involved, just describing what tracks are in which block, where signal heads are located, etc.

The “Table Top” railroad hobby has been using PC-based systems for a long time (check out the JMRI and LCC projects). As an aside – our per signal head cost is not much more than many people pay per signal head on table top railroad signal systems.

I think we can all agree that we need to get more young people involved in the hobby. Young people today are very comfortable with “home brew” electronics and micro-controllers – just look at the popularity of the Arduino products worldwide. Anyone with a basic knowledge of electricity can deal with installing and maintaining a properly designed solid-state system.

Is the system perfect?  No, but, its imperfections lie in the firmware which can be fixed or enhanced without changing a single wire in the field.

Engineers – The User/Customer of Any Signal System

I think the best feature of automatic signals is it can be boiled down to very simple rules for visiting engineers:

Rulebook: Green, go, yellow, go, anything else stop .. period.

This greatly reduces confusion at a large meet where you have a lot of visiting engineers who are not familiar with the signals or the railroad – they can just run and have fun.

Conclusion

If properly designed and implemented with the proper precautions, a fully automatic, solid-state signal system that meets all the requirements I mentioned earlier can be built at a cost that compares very favorably to other relay, or module based systems.  At the same time it can offer more features, flexibility and maintainability in the process.

Back to the railroad I mentioned earlier that was the impetus for me starting on this endeavor (not my test site railroad) … Several years ago, they replaced the relays on their engineer-operated button signal system (“capture – Release”) with my controllers (I added support in the firmware for “Button Blocks” for them). They ran that way for a while but they are now in the process of converting the entire railroad to fully automatic. I’m looking forward to a future Saturday night of bi-directional running there where everyone stays out on the railroad and has a wonderful time until the wee hours of the morning.

There is an old saying that “To a hammer, everything looks like a nail”. Some people might say about me: “To an Electrical Engineer and Systems developer everything looks like it needs electronics” … to that I say, “Sometimes that thing that looks like a nail IS a nail!”

Does this mean that this kind of system is the best fit for everyone? No, the needs and desires of a given railroad should dictate the approach to be taken. What I wanted to accomplish here is to dispel the myth that “You can’t build a reliable, cost effective Ride-On railroad signal system with solid-state components”.

I hope I have accomplished that …

(See also: Living With Lightning)