The Viability of Solid-State Components for Signal Systems

This forum is dedicated to Riding Scale Railroading with propulsion using other than steam (Hydraulics, diesel engines, gas engines, electric motors, hybrid etc.)

Moderators: Harold_V, WJH

User avatar
ChuckHackett-844
Posts: 80
Joined: Wed May 03, 2017 3:54 pm
Location: Tampa, Florida

The Viability of Solid-State Components for Signal Systems

Post by ChuckHackett-844 » Thu Oct 26, 2017 7:18 pm

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, etc.), 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 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.
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 for about ½ of 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 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.

Image

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.
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 and location, but this is typical. These are far less than that proposed for typical relay systems … and, if you add a transistor to achieve this (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 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).
    • 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 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.
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 users (signal contains a magnetic “slug” motor to change color) and soon full-size semaphore signals.

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.

Conclusion

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!” :D

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.
Regards,

Chuck Hackett, UP Northern 844, Mich-Cal Shay #2
"By the work, One knows the workman"

User avatar
Atkinson_Railroad
Posts: 166
Joined: Mon Jun 08, 2015 6:27 pm
Location: Michigan
Contact:

Re: The Viability of Solid-State Components for Signal Systems

Post by Atkinson_Railroad » Thu Oct 26, 2017 7:59 pm

Excellent Chuck. You're on the right path toward educating the customer.

I'd like to start a separate thread devoted to Track Circuit Occupancy Detection.
Your system certainly covers the main premise of signaling which is/are "the circuits".

"The Rules" are another subject for discussion followed close behind by the actual physical wayside signals themselves
which has been my interest.

Great beginning to a WAY over due subject matter that has long been neglected.

Still reading your post,

John

User avatar
Atkinson_Railroad
Posts: 166
Joined: Mon Jun 08, 2015 6:27 pm
Location: Michigan
Contact:

Re: The Viability of Solid-State Components for Signal Systems

Post by Atkinson_Railroad » Thu Oct 26, 2017 8:48 pm

Noting your system supports full-size searchlight signals, the coil in my searchlight models (wound to operate at 12 volts D.C.) has an average resistance of around 170 ohms. The device functions the same way the prototype does by reversing the polarity to the coil to change the projected aspects.

Is there a provision you’ve made to offset any back EMF that may exist when the coil in a searchlight drops to red, or changes polarity?
There’s a selfish interest in asking the question, but what... if any concern is there related to driving a wayside signal electronically
with an actual coil in it?

Thanks!

John

Post Script: You mentioned my reverse polarity protection diode in the Searchlight Retrofit video posted earlier in the month.
I included it because of my own mistake of applying 24 volts to the LED by mistake. It didn't survive ; )
I figured if I could do that, someone else might too.

User avatar
ChuckHackett-844
Posts: 80
Joined: Wed May 03, 2017 3:54 pm
Location: Tampa, Florida

Re: The Viability of Solid-State Components for Signal Systems

Post by ChuckHackett-844 » Thu Oct 26, 2017 8:57 pm

Atkinson_Railroad wrote:Is there a provision you’ve made to offset any back EMF that may exist when the coil in a searchlight drops to red, or changes polarity? There’s a selfish interest in asking the question, but what... if any concern is there related to driving a wayside signal electronically with an actual coil in it?
There is back-EMF protection on the Base Card for all 16 outputs (actually part of the lightning/surge protection) but the full-size signals I mentioned are driven by a relay expansion card due to the current required by the full-size "slug" motor as well as the requirement for reversal of the polarity of the motor drive (which the PWM outputs can not do).
Regards,

Chuck Hackett, UP Northern 844, Mich-Cal Shay #2
"By the work, One knows the workman"

rkcarguy
Posts: 638
Joined: Tue Aug 22, 2017 10:33 am

Re: The Viability of Solid-State Components for Signal Systems

Post by rkcarguy » Fri Oct 27, 2017 1:33 pm

Chuck, I have been seeing some relay boards with "optic isolation", which I'm understanding that they use the same things like a TV remote to pass the signal without having an actual electrical connection for safety sake between high voltage and low voltage switching. Could something like this be used to prevent or minimize lightning damage?
I forgot if these were UV leds, or what kind they are. IF you could make something like that work, and provide a gapped ground for the lightning to jump to, I think damage could be limited to the "sending" side of the detector...i.e, a relay and a LED and some resistors.

User avatar
ChuckHackett-844
Posts: 80
Joined: Wed May 03, 2017 3:54 pm
Location: Tampa, Florida

Re: The Viability of Solid-State Components for Signal Systems

Post by ChuckHackett-844 » Fri Oct 27, 2017 9:12 pm

rkcarguy wrote:Chuck, I have been seeing some relay boards with "optic isolation", which I'm understanding that they use the same things like a TV remote to pass the signal without having an actual electrical connection for safety sake between high voltage and low voltage switching. Could something like this be used to prevent or minimize lightning damage?
Basically an opto-isolator is an LED and photo-diode/darlington transistor in a single package. since they are only connected by "light" they provide electrical isolation.

I do offer an opto-adapter for the 16 channels of output (usually used to drive signal heads) when used with long cable runs to signal heads (not recommended) in severe lightning locations.

I can't use opto-isolators on the track inputs because those must handle analog voltages over a wide range (and there are other issues) but this is no matter because, with the protection I have in place, I can draw at least a 5,000 volt arc to the track input terminal with no damage.
Regards,

Chuck Hackett, UP Northern 844, Mich-Cal Shay #2
"By the work, One knows the workman"

John Hasler
Posts: 742
Joined: Tue Dec 06, 2016 4:05 pm
Location: Elmwood, Wisconsin

Re: The Viability of Solid-State Components for Signal Systems

Post by John Hasler » Fri Oct 27, 2017 11:09 pm

There are analog optoisolators (and other ways of achieving analog isolation) but I don't think they are justified in this application.

User avatar
ChuckHackett-844
Posts: 80
Joined: Wed May 03, 2017 3:54 pm
Location: Tampa, Florida

Re: The Viability of Solid-State Components for Signal Systems

Post by ChuckHackett-844 » Sat Oct 28, 2017 7:39 am

John Hasler wrote:There are analog optoisolators (and other ways of achieving analog isolation) but I don't think they are justified in this application.
Yes, I didn't mention high linearity optos to keep it simple. To use these would require the track current to be within a specific range or further conditioning requiring an isolated supply, etc. Certainly doable but not cost justifiable here - especially since the current approach has proven to be reliable so far.
Regards,

Chuck Hackett, UP Northern 844, Mich-Cal Shay #2
"By the work, One knows the workman"

hanermo
Posts: 42
Joined: Tue Oct 01, 2013 5:47 am

Re: The Viability of Solid-State Components for Signal Systems

Post by hanermo » Sat Oct 28, 2017 2:00 pm

This is one of the 4 best OP posts I have ever seen on any subject.
Kudos.

The others, +/- chronological,
-5bears cnc. Best early cnc build ever.
-Dan Gilbaert on prototypes, cnc etc. Best shop built cnc ever.
(I am doing similar stuff.)
-Ted Talk by 15 year old who dug up uranium, refined it to yellowcake, and built a working demo fusion reactor, himself.

I agree with *all* your comments, goals, results, methods.

I know nothing about trains, and only a little about electronics, but a lot about high-availability systems I did for a long time in IT/wan/server stuff to Very Large Scale - built very cheaply - following similar approaches with very much out-of-the-field thinking and great results in very large distributed systems with huge numbers of users.

The *best* solution is a suitable electronics box, widely distributed, of modest cost, sw driven, and suitable end effectors as needed, or additional "stuff" where appropriate.
EXACTLY as You described.

I am extremely, extremely, impressed.

The sw methods I had never heard about re: trains (since I do not know trains) re: blocks etc. but seem obvious and clever and consistent to me.
About the only possible ideas I might have to suggest ...
If it is easy to do, sw fallbacks to previous state/version- even better if fallback could be triggered by an outside hw fallback device/timer, checksum validation of builds/configs/changes, and checksum validation of updates // new orders to signals would seem a Good Thing To Do.
As would logserver implementation using a *different* sw build.

As would perhaps scalable logging where log type/size/event detail could be adjusted at need.
This allows capturing some type of events, at high details, when needed, while keeping the logging small, dense, concise and allowing very fast troubleshooting because the logfiles are not gazillion events unrelated from all over the place and all sorts of stuff.

User avatar
ChuckHackett-844
Posts: 80
Joined: Wed May 03, 2017 3:54 pm
Location: Tampa, Florida

Re: The Viability of Solid-State Components for Signal Systems

Post by ChuckHackett-844 » Sat Oct 28, 2017 10:09 pm

hanermo wrote:This is one of the 4 best OP posts I have ever seen on any subject. Kudos.
You are very kind ...
hanermo wrote:As would perhaps scalable logging where log type/size/event detail could be adjusted at need. This allows capturing some type of events, at high details, when needed, while keeping the logging small, dense, concise and allowing very fast troubleshooting because the logfiles are not gazillion events unrelated from all over the place and all sorts of stuff.
Logging is a tricky area - logging enough, but not so much that it's useless because of its sheer volume. We dealt with this in the large banking networks we designed in my professional years.

I had some logging implemented but turned it off because I didn't like it. I plan on re-implementing it to record state changes (track occupancy & signals), track voltage levels (to detect bad bond wires, etc.) as well as error events, etc.

In addition to being able to use it as a system diagnostic tool it can allow you to "replay" events on the track display in real time, fast forward or slow. This would be great for those times when John says "I had a green" and Sam says "No, I had a green" ... somebody's going to the woodshed ... :-)
Regards,

Chuck Hackett, UP Northern 844, Mich-Cal Shay #2
"By the work, One knows the workman"

rkcarguy
Posts: 638
Joined: Tue Aug 22, 2017 10:33 am

Re: The Viability of Solid-State Components for Signal Systems

Post by rkcarguy » Sat Oct 28, 2017 11:36 pm

As I posted in my other thread, I got my "backyard" system working tonight. It's simple in reality, a couple of SPDT relays and a diode. As the relays need a positive switched voltage to energize, I'll be coming up with separate detection relays that are grounded to complete the circuit. Understand though that my RR is going to consist of about 800' of track and 5 blocks, supporting 2 trains at the same time tops.
I have a question for you smarter electronic guys, instead of having a timer set to a couple seconds to eliminate relay chatter and flickering in the case of a poor connection across the rails, could I install a capacitor somewhere that would smooth this out? I've noticed when I plug in and unplug my power "brick" it takes a couple seconds for the signals to go on and go off, it'd be about perfect to have that feature on my detection circuits.

User avatar
ChuckHackett-844
Posts: 80
Joined: Wed May 03, 2017 3:54 pm
Location: Tampa, Florida

Re: The Viability of Solid-State Components for Signal Systems

Post by ChuckHackett-844 » Sun Oct 29, 2017 5:03 pm

rkcarguy wrote:instead of having a timer set to a couple seconds to eliminate relay chatter and flickering in the case of a poor connection across the rails, could I install a capacitor somewhere that would smooth this out? .... it'd be about perfect to have that feature on my detection circuits.
Depending on your exact circuit and coil current a capacitor might work for you. The cap value (higher = longer) and your coil current (more = shorter) will determine the 'timeout'. It's probably impractical to get a long timeout but doable to get one long enough to reduce/eliminate 'chatter'.
Regards,

Chuck Hackett, UP Northern 844, Mich-Cal Shay #2
"By the work, One knows the workman"

Post Reply