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 by 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 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 (simple Occupied/Unoccupied systems cannot do this but I'll leave that for another discussion) … 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-Like) and dispatch (CTC) modes
• “Do the right thing” 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 block entry/exit points
• Support ‘convenience’ items such as: “Approach Lit” signals, dimming of signals at night and allowing the user to define the signal lamps (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.
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 microcontrollers. 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 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 bare cards, 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 (cut traces, 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 add support for new features and the “Base Card” that the controller plugs into and field wiring is connected to. The Base Card contains most of the lightning and surge protection. At this point I can draw a 1/8” to 3/16” arc from a high voltage AC supply near one of the track input terminals with no damage.
Each controller has 8 track inputs (can also be used for contact sensing, etc.) and 16 Pulse Width Modulated (PWM) outputs that can drive 5 three-lamp signal heads or other devices (there are add-on cards for expansion, relays, etc.).
The system is installed by locating the controllers around the railroad close to the items they are connected to.
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 turnout motors, and samples about 100 track segments and other inputs (turnout position, etc.). This system draws 1.9 amps at 16 volts from a single supply located in the dispatch tower.
No additional wires are used to connect the signals at the ends of a given block (there may be many entries and exits, separated over a great 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 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 lightning/surge protection, then through electrical conditioning and to one of the analog inputs on the processor. The raw voltage is then processed by an adaptive signal processing algorithm that is designed to address track condition (wet/dry, imperfect joint bonding, etc.) as well as wheel-to-rail contact issues (oxide, leaves, etc.).
To date I have not encountered any track condition (other than welded ties ) that it 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.
- • 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.
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 permitted into a block at a time.
When a train approaches a signal, it is detected on the Approach Track in front of 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.
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.
For example: 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 arrestors on their poles. These devices 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 unless it’s very simple and uses very rugged relays … but then you give up the benefits of software logic, etc. … life is about tradeoffs …
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).
- • The monitoring program (SComm) installed on a laptop, can be plugged into any controller on the railroad to see the status of every piece 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.
What About 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).
The system currently does two things relating to flow control, first, a train is given 30 seconds (default) to enter the block after it has been given a “Permitted” signal aspect. If the train does not enter the block in the required time and there is a train waiting at a different entry for this block, the first train’s signal will be dropped to “Stop” and a Permitted aspect will be given to the other train. This prevents a train that has derailed, engineer talking to someone, etc. from preventing other traffic from flowing. After the other second has cleared the block the first train will again (conditions permitting) receive a Permitted aspect.
The second thing the system will do is that it will not give a Permitted aspect to a train if there is an opposing train (i.e.: one at the opposite end of the block heading towards him) and a train on his “Destination Track” (the track he would end up on when he exits the block). This allows traffic to flow in, for example, and eastbound direction, if traffic in the westbound direction is blocked due to a derailment, etc.
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 system that detects trains, solid-state, relay, doesn’t matter.
One of my headaches is that the motor devices we use (purchased) to actuate turnouts have two microswitches that tell the signal system which way the turnout points are set (left, right, neither – e.g.: in transition). These microswitches 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 “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 presenting the information it is being told (neither route is selected). 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 2 winks means “switch points against”). The engineer still sees “Red”, so he stops. The signal maintainer can use the ‘wink’ information to diagnose the issue (usually a track/turnout motor issue). It is the signal maintainer’s decision if this diagnostic information is displayed or just “solid” lamp displays are used by options in the configuration text file.
A wide range of people are drawn to this hobby and they have a wide range of skills. 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 the PC-based monitoring program). There is no programming involved, just describing what tracks are in which block and where signal heads are located.
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 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 microcontrollers – 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: Green, go, yellow, go, anything else stop .. period. This greatly reduces confusion at a meet where you have a lot of visiting engineers.
So, 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 and it can offer more features and flexibility 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 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’ve rattled on long enough. I hope it was useful.