The RR Track Signal Control Board Project

I am (was) a big fan of the Atlas signal system. I believe it had the features you list and also the ability to link the signals together to operate from multiple block inputs. I kind of gave up on them since they have not been available for a while now, but I have heard rumblings that Atlas may be remaking, redesigning, remanufacturing them or something along those lines. The big problem for me with the Atlas signal system was cost, not that it wasn't worth it, just that is was a bit above my price range. But, it really is/was a neat system.

Maybe I can find a feature list from the Atlas signals, like from a listing or catalog I might have around here somewhere? It's will probably be cost prohibitive to do all the features that system had, but I guess you never know? 

Another idea (probably not a good one) would be to maybe have one PCB with different schematics of designs from 'basic' to 'full featured'? Tthe user could then select how far they wanted to take things and how much they wanted to spend? I'm dreaming here, I think...

Also, I have no ideas about any circuits that would be needed here, but I do realize, to quote GRJ, "Nothing is so easy as the job you imagine someone else doing" which is probably what I am doing here.  

Edit: The post below by The Dude about daisy chaining the signals is one neat feature of the Atlas system. 

I really like this idea.  Could the boards have outputs so signals could be daisy chained? 

Example: The down track signal will hold the up track signal on yellow until the down track signal is clear....

Remember, the #1 goal was not expensive!   I'm afraid if we get into daisy chaining signals and all the complexity that involves, we'll defeat the whole purpose of the project.  It this whole project ends up costing more than around $10 total for a board, I'm afraid it's not going to go very far.

After all, Azatrax has one that does all this and also handles signals in two directions for $40 for each board.

What about two light block signals? I see this show three lights.

gunrunnerjohn posted:

Discussions keep coming up about a signal control board, especially now that there seems to be several choices for cheap O-gauge track signals.

That being the case, I figured we'd start a new thread and see what features might be desirable in something that would be in kit form for users to build.  I'm thinking we'd sort out a feature list and then whittle it down so that it could be made in an inexpensive manner with common parts.  I'll start with a few attributes and we'll go from there.I'm thinking a thru-hole PCB design with a inexpensive parts BOM that can be easily assembled by most folks that can solder.  Having a board greatly simplifies the task of assembling one or a number of these.

Let's all join in and toss some ideas around!  

I have an Arduino Nano configured to do some of this.  I use it with the WeHonest 2 and 3 aspect signals.  It is sensitive enough to detect your fingers touching the ground and signal rails. (I have it currently set for 3 rail operation. 2 Rail would need to be converted for current sensing instead of ground sensing.)

• Low cost! (one of the primary objectives)

  About $3 for the Arduino, and $1.50 for the breakout board it plugs into to have a screw terminal on each pin. So $4.50, and each one controls two signals.

• Multiple types of input, i.e. IR, insulated rail, etc.

I use it with insulated rail. I do use IR detectors with the nano for switch anti-derail. It would be pretty easy to add software to detect either ins rail or IR, and use a toggle switch on one of the digital pins to flip which one is being utilized.

• Drives two and three aspect signals with appropriate delays for yellow & green (programmable?)

I do a PWM fade-out/fade-in.  The WeHonest signals have a single resistor connected common anode, so you cant have the multiple led's lit at the same time.  But the fade-out/fade-in under software control looks pretty good.  (It looks hideous on a video at 30 frames per second due to the strobing effect.)

• Drives road crossing crossbuck signals directly.

It could drive a servo-driven crossing gate or wigwag directly without any issue. It would need an fet driver if the mechanism used anything that drew more current , like electromagnets,  or if we wanted it to drive the sound. 

• Direct drive of LED or incandescent lamps.

Led's are direct drive.  Incadescents would need to have logic level fets on the output pins.

 So, you could basically take this setup, add a few fet's for higher current draw items like incadescents, and be pretty close. 

One nice thing about the arduino microcontroller is its ability to add pullup resistors under software control, without the need for discreet components.  That really comes in handy for ground sensing devices.

For my future large layout, I plan on some Arduino Nano's simply becoming block detectors (8 blocks detected per Nano) with these block detecting Nano's communicating to an ethernet nano which sends the block data back to a main system, which then can software control the aspect signals from that data. This would allow easier wiring of the signals, as I wouldnt need to wire the blocks to each signal. 

It's obvious that you would want to include signal aspects for CLEAR, APPROACH, and STOP. But I would suggest, since we're already talking about grade crossing flashers, that this device be able to represent aspects that include flashing as well.

Flashing GREEN for LIMITED CLEAR or whatever you want to call it. Flashing YELLOW for MEDIUM APPROACH as was used by Southern Pacific. And Flashing RED could be a RESTRICTING aspect. Your railroad may use different terminology for the various aspects.

Another thought is a signal that acts as a Control Point (CP) at the start of a siding. In that case, you would want to have a 3 aspect signal head over a 2 aspect head indicating a straight or diverging route for the switch into the siding. Probably GREEN for straight and RED for the siding.

I agree that you want to keep the Signal Controller separate from Block Detection and Switch Orientation devices. For the Signal Controller, it all boils down to inputs driving the signal aspects.

Configurable outputs to support high or low driven signals or accessories.

current or voltage sensing inputs

Selectable latching outputs

Selectable momentary outputs

supports higher current outputs

supports various voltage outputs

I like the activation that is done on some boards that I purchased using photo transitors. S gauge using two rails is not conducive to the insulated rail. The possibility to use it with the block signal and a timer chip for two or three light signals or maybe to input to a relay to operate a semaphore. The photo transitors are quite easily hidden between the rails.

Ray

I had considered using the Arduino Nano as a base for the control function.  It has lots of I/O pins and is dirt cheap. The external circuits would be for input and output signal conditioning and of course a generic source of power.  While you could consider a DC power brick for the power, I think having a bunch of little bricks, one for each unit, may be a bit cumbersome, so I was thinking along the lines of an AC power supply that will work from track power or accessory power from around 12 VAC to 22 VAC.

Some of this is getting a little "over the top" for a cheap signal.  Also, all of those intricate signalling variations have to be accommodated by the logic.  If this starts out so complex that it's a six month development project, it's probably dead already.   Also, if we start with the hardware base to support some of this stuff, the software can be customized in the future to expand the capability of the signal board.

CGWforever posted:

What about two light block signals? I see this show three lights.

You simply don't connect to one of the outputs.  Connect to the red and green only, presto, you have a 2-light signal.

I was planning on doing a full signal system on my layout, but I was unable to get all the equipment I needed to get. Since Custom Signals is pretty much no longer selling anything it seems like.

One thing I think would be useful to have is one that can some how see what direction a switch is thrown and have it reflected on the signals somehow. That may end up adding more complexity than you want to the board.

All  the other aspects listed seem interesting.

My idea is to start out small with the possibility of expansion to handle more features.  As far as actually sensing where a switch is, it depends on the switch.  However, that's mostly a mechanical issue of actually sensing the switch position, and it's not always that easy.

My solution would be to use either Tortoise switch motors with the position contacts or Fastrack that has position sensing.

Alex (Ingeniero No1) was working a whole system that did very sophisticated switch position sensing, and was sensitive enough to catch partially thrown switches, don't know what happened to that project.  I know he showed prototypes, and it looked very promising.

Gunrunnerjohn.....thank you!! Cost is the first consideration followed by simplicity in application. My only suggestion would be to offer simple wiring guides for signals from Lionel and MTH......I am not discounting the Atlas products but cost and availability fly in the face of what you are proposing. I also recognize that there are other companies which offer signals, even some "boutique" companies which offer very detailed handcrafted signals but accounting for all variations again might detract from the primary objective.

Well, I'd leave the wiring guides to folks that actually have the signals.  Since right now this is envisioned as a community project, I'm not going to spend a ton of money to buy every signal possible to document them.

Truthfully, this all grew out of the desire to have inexpensive signals, and in the other signal thread, we were discussing stuff like the WeHonest Signals, they have some decent looking signals for around $4/ea.  The point was made that the control boards for these signals exceed the signal price by multiples, so the idea of an inexpensive board was born.

gunrunnerjohn posted:

As far as actually sensing where a switch is, it depends on the switch.  However, that's mostly a mechanical issue of actually sensing the switch position, and it's not always that easy.

My solution would be to use either Tortoise switch motors with the position contacts or Fastrack that has position sensing.

All I have is Atlas Switches on my layout. So I see if I can figure something out.

Like I said it may add more complexity than wanted right know. Which is way I said all the other features looked like I could use them.. Depending on how they would be implemented.  

tcochran posted:

gunrunnerjohn posted:

As far as actually sensing where a switch is, it depends on the switch.  However, that's mostly a mechanical issue of actually sensing the switch position, and it's not always that easy.

My solution would be to use either Tortoise switch motors with the position contacts or Fastrack that has position sensing.

All I have is Atlas Switches on my layout. So I see if I can figure something out.

Like I said it may add more complexity than wanted right know. Which is way I said all the other features looked like I could use them.. Depending on how they would be implemented.  

For Atlas switches, you can either use the Atlas under-the-table switch machine (which has contacts for indicating switch position) or the Atlas snap switch relay with the above-table switch machine to indicate switch position. That's how the Custom Signals boards handled it with Atlas switches.

Thanks for the information. Lets get back to the discussion John intended this topic to be about. His signal control boards he is contemplating doing.

  Could someone explain why and how crossbuck lights & bars (not track signals) could benefit from a directional detection. I can only seem to focus on the fact that if the space between A&B is occupied, both crossbuck signals should activate. Speed doesn't even really matter; on slow days you wait longer to cross. That is what I've observed on the real rails. I even knew the exact A&B spots for crossings near me; fast or slow they triggered the crossbucks at the same spot every day.

Adriatic posted:

  Could someone explain why and how crossbuck lights & bars (not track signals) could benefit from a directional detection. I can only seem to focus on the fact that if the space between A&B is occupied, both crossbuck signals should activate. Speed doesn't even really matter; on slow days you wait longer to cross. That is what I've observed on the real rails. I even knew the exact A&B spots for crossings near me; fast or slow they triggered the crossbucks at the same spot every day.

The crossbuck signals should activate while the approaching train is some distance from them, but they should stop as soon as the train has cleared the crossing.  The fact that the distances from the crossing for activation vs. stopping are different means that directional detection is needed for this feature.

If you do not like the wehonest signals; I have designed or could design a 3D print signal head of a more common type to fit the same size LEDs that Custom uses.

It's just boxes with holes and shades with some other minor detailing.

gunrunnerjohn posted:

My idea is to start out small with the possibility of expansion to handle more features.  As far as actually sensing where a switch is, it depends on the switch.  However, that's mostly a mechanical issue of actually sensing the switch position, and it's not always that easy.

My solution would be to use either Tortoise switch motors with the position contacts or Fastrack that has position sensing.

Alex (Ingeniero No1) was working a whole system that did very sophisticated switch position sensing, and was sensitive enough to catch partially thrown switches, don't know what happened to that project.  I know he showed prototypes, and it looked very promising.

Alex had a neat way to monitor the positions of Atlas or Ross switches. I was going to order some from him a few years ago then had some health issues, family stuff and other things that got in the way. I am still right about where I left off back then. I don't know the status of his project now either. It was a nice one though. Maybe Alex will be by to comment?

Also Alex's device monitored the 'Actual' switch position at the switch, they did not depend on additional relays that may or may not match the switch position (depending on manual operation of switch).

I also agree with you on the cost factor and figured the daisy chaining was going to be too much. I wasn't aware of the Azatrax boards though, I need to go poke around on their site some more...seems they have a lot of stuff.

I like the idea of the arduino too. MJCat above has done a lot with them and it appears has kept the costs down too. Others here have done a lot with arduinos too. Maybe use a bunch 'off the shelf' adruino hardware, if that is possible? 

GRJ- sounds like a good project. implementing the KISS method applies here for sure.

I have some 2 aspect Dwarf signals from WeHonest. I have built several of them for my switches but have been weighing options for control. A small board with basic functionality for guys who like to have realistic looking signals but don't have fully automated block signaling systems would pique my interest for sure.

Bob

Bob posted:

Adriatic posted:

  Could someone explain why and how crossbuck lights & bars (not track signals) could benefit from a directional detection. I can only seem to focus on the fact that if the space between A&B is occupied, both crossbuck signals should activate. Speed doesn't even really matter; on slow days you wait longer to cross. That is what I've observed on the real rails. I even knew the exact A&B spots for crossings near me; fast or slow they triggered the crossbucks at the same spot every day.

The crossbuck signals should activate while the approaching train is some distance from them, but they should stop as soon as the train has cleared the crossing.  The fact that the distances from the crossing for activation vs. stopping are different means that directional detection is needed for this feature.

Correct, it really gives a much better prototypical operation of the signal and gate.  

I've done this with both insulated rail and IR. I used a Nano to detect the 3 insulated blocks, and used that to directly activate MTH crossing signals. 

Basically, there's 3 blocks (or really sub-blocks) to monitor.  Left approach, right approach, and center.  The left and right approach blocks are longer, and activate the moment we want an approaching train to activate the signal.  The center block would extend to just outside of the crossing, to the point on each side where we would want the signal to deactivate after it leaves that block. 

The nano simply looks for a detection on the left or right approach blocks. When it sees that, it enables the signal. Then it waits until both the initial approach block and center block are both cleared, and when that happens, it disables the signal, but the system remains in "detection" mode until all 3 blocks are completely clear.  This is so that if a train approaches and clears the center block, then backs  up into the center block, it will immediately re-activate the signal.  Once all three blocks are clear, the system resets and awaits a detection from either approach again.  

So for about $9 ($3 for the nano, $1.50 for the breakout board, $4.50 for 3 logical level mosfets )  you can add a really prototypical crossing operation to existing crossing signals/gates on your layout, and each $9 investment would allow you to control 3 different crossings.

gunrunnerjohn posted:

Remember, the #1 goal was not expensive!   I'm afraid if we get into daisy chaining signals and all the complexity that involves, we'll defeat the whole purpose of the project.  It this whole project ends up costing more than around $10 total for a board, I'm afraid it's not going to go very far.

After all, Azatrax has one that does all this and also handles signals in two directions for $40 for each board.

Problem is these use IR, not insulated rail.  But like the Atlas controls, would it be hard to have two inputs to the circuit board.  One will engage the red light (Current block.) and the next would engage the yellow light (Following block.)?  If neither has an input, then the light would be green.  So you would need two sets of boards, one for each direction, which is how Atlas handled it.  And if the boards are low cost kits, I would not mind having two sets, one for each direction of travel.  With that said, you could make it a simple trigger and it's up to us if we attach it to the current block's red light, or the previous block's yellow light.  That would give two boards in each direction, so 4 for one block.  But as pointed out here, the low cost signals use a common, so two lights can't be powered at once. 

How I'd like the board to be is have two inputs (Via isolated rails.), 3 outputs (Red, yellow, green), and power input.  Input 1 is the current block, and Input 2 comes from the following block.  When the board is powered on, it shows green.  When a train entered the block, triggering Input 1, the light goes red.  When the train enters the following block the board is triggered on Input 1 and 2, but still shows red due to Input 1 still triggered.  Once Input 1 is no longer triggered the light goes to yellow as it is still triggered on Input 2.  Once no longer being triggered on Input 2 the light goes back to green.  Perhaps instead of calling it Input 2, it could be Input from following signal.  Then you can have another output on the board, Output to preceding signal, which really is just a pass through for Input 1.

So the logic of the board is I is the Inputs, and on is triggered and off is not triggered:

I1 off, I2 off then show green.

I1 on, I2 off then show red.

I1 on, I2 on then show red.

I1 off, I2 on then show yellow.

But like John says, it's not as easy as someone else doing it, and I'm a mechanical engineer not an electrical engineer.

MJCAT posted:

So for about $9 ($3 for the nano, $1.50 for the breakout board, $4.50 for 3 logical level mosfets )  you can add a really prototypical crossing operation to existing crossing signals/gates on your layout, and each $9 investment would allow you to control 3 different crossings.

Hmm, can you explain the three different crossings for $9 for all three?  Don't you need more sensing at least?

The GN Man posted:

John, would your project work with semaphores as well? (Specifically MTH or Z-stuff scale semaphores, not the Lionel 151’s & equivalents.)

Well, it should probably work with both of those, but the exact capabilities are what we're trying to formulate.  This is just a discussion about desired capabilities at this point.

gunrunnerjohn posted:

MJCAT posted:

So for about $9 ($3 for the nano, $1.50 for the breakout board, $4.50 for 3 logical level mosfets )  you can add a really prototypical crossing operation to existing crossing signals/gates on your layout, and each $9 investment would allow you to control 3 different crossings.

Hmm, can you explain the three different crossings for $9 for all three?  Don't you need more sensing at least?

Ok, you can do TWO crossings per nano.  As I was writing up the below, I caught the fact that I had gotten my arduino boards mixed up on the number of analog pins they have.  The nano has 8 analog pins.  We need 3 per crossing. 

For the insulate rail detection, I use 2 input pins per detection block on the nano; a digitial pin and an analog pin.  

The digital pin is configured as Input_Pullup, which causes the arduino to attach the pin to +5v through a 50K resistor internally. We attach the detection rail to this pin, and also to the analog pin. The digital pin is doing nothing other than allowing us to connect to +5v through a pullup resistor internally, so we dont need to add these components externally.  We can then perform an ADC read on the analog pin.  When nothing is on the detection rail, thebanalog pin would have see the full +5v, and would report back a value of nearly 1023.  If something brings the detection rail down to ground, the digital pin voltage would drop to near zero, and the ADC value would drop. Placing your fingers across the ground and detection rail drops the voltage enough to be detected.  (Digital value drops to just below 1000. )

Do you have any protection for the uP input pins?  Nasty things can happen on the rails, I'd want some protection for low voltage inputs.

Bob posted:

Adriatic posted:

  Could someone explain why and how crossbuck lights & bars (not track signals) could benefit from a directional detection. I can only seem to focus on the fact that if the space between A&B is occupied, both crossbuck signals should activate. Speed doesn't even really matter; on slow days you wait longer to cross. That is what I've observed on the real rails. I even knew the exact A&B spots for crossings near me; fast or slow they triggered the crossbucks at the same spot every day.

The crossbuck signals should activate while the approaching train is some distance from them, but they should stop as soon as the train has cleared the crossing.  The fact that the distances from the crossing for activation vs. stopping are different means that directional detection is needed for this feature.

Thank you, you filled the gap. I hadn't thought of about a good shut off at a slow creep.

But still not really a directional need. A seperate occupancy detection is needed (2 if super fussy), for triggering the same circuit to off.  But I also see that with track signals, the directional aspect is a near must and tieing the gates into that is a no brainer. 

gunrunnerjohn posted:

Do you have any protection for the uP input pins?  Nasty things can happen on the rails, I'd want some protection for low voltage inputs.

Correct. Cause if you allow any nastiness above the 5v to hit one of those pins, the little tiny nano  turns into a highly effective space heater. You wouldnt want to be holding it in your hand when that happens.  Trust me. 

Jumping ahead from the "what" to the "how", I'm curious if you've thought about the ability to re-program (aka add features) to whatever you come up with.  Specifically I think "We" have become accustomed to the idea that our software "apps" in our smartphones, tablets, PC's, etc. are constantly being updated/refreshed with the latest and greatest.

So the hardware becomes the bricks-and-mortar...and the software can be fluid.  That said, there are many options but the two that stand out for a LOW-COST solution:

1. A $2-3 Arduino with a USB loader.  AFAIK, this requires the end-user to download "unique" software.  If functionality is changed you need more than drag-and-drop on your PC/laptop.  I highly doubt the typical OGR end-user will be writing code.  Hence feature upgrades would be done by the handful of guys here on OGR that know how to do it, and the executable would be made public.

2. A microcontroller (it could be an Arduino) that reads a $2 microSD card that contains the software.  So if you upgrade the app, you simply post the new software on OGR and leave it to the end-user to drag-and-drop the new software into the microSD card and then plug that card into the signaling board.  Most people have smartphones and "get" the concept of the microSD/SIM card and should be able to move a file from a PC or whatever to a microSD card without loading custom Arduino "loader" software. 

This is a brave new world.  Again, I realize I'm jumping ahead but I believe this can fall in line with not-to-exceed $10 (or whatever) cost target.

Stan, you bring up a good point.  Given the cost target, I was thinking of the Arduino Nano, but I don't know if there is a variant that has a microSD capability native.  What would be cool is a canned way of just jacking the Arduino Nano into a USB port and running a program that did the load automatically. 

OTOH, I suspect many folks would be able to at least install the Arduino app and upload a provided file, that may be the lowest cost solution.  Adding a microSD seems to run up the cost, and then there's all the programming to actually seamlessly load the program from the microSD.

My vision at this point is to concentrate on the interface capability as the "smarts" would all be in the Arduino.  If we have the ability to accept various inputs and have sufficient flexible outputs, we can do a lot of different things with the same platform.

I like the idea of the grade crossing flashers/gates with 2 directional approach areas and the center section with a microprocessor to control the action. But I think this would constitute a separate project. I would not make this part of the current Signal Controller project. It's a whole different animal.

Looking ahead a bit, I envision a bunch of Arduino based controllers placed all over the layout. A full fledged ABS or CTC signaling system could amount to a microprocessor at each block. Add to that controllers for grade crossings and servo controlled switch machines and there could be more than you would want to disassemble for new software upgrades.

What is needed is a way to communicate between the various microprocessors. The good news is that there is hardware that makes this fairly simple; RS485 multi-drop connections. The bad news is that, while I've tried to work out something on this, I have not had much success.

Still, if the Signal Controllers were connected as addressable units, the chaining of signals for block control could be achieved with messages sent one to another. Software upgrades could also be done using the same communication link so that all units of a certain type could be downloaded at the same time and without being extracted from under the benchwork. RS485 is two wires, usually in twisted pairs.

These are the 8 pin chips that I've been trying out for the RS485 communication bus.

One of the major downsides of a RS485 Type Connection, is it can be slow, since it is a serial type link. I have seen it used in some products I work with, and a 2 MB file can take 30 minutes to send to the target device. That may only because what we use it for is sending images to elevator displays. In what we use it for it has 5 wires. Two for receiving and two for transmitting and a common. Though your mileage may vary.

But we're not pushing 2MB files over a signal network. I'm running my whole layout with JMRI and CMRI over a 485 network with a Raspberry PI and four SMINI nodes with no noticeable lag between the user interface screen and layout response. A signal network should be way simpler than that, and network traffic should be very low given signals don't change THAT fast.

That I can understand, it is just a factor that may have no impact in the implementation at all. Due to it being  very low amount of traffic.

I did say we use it to send images to displays in elevators. 

I think I need to start a new thread.

The original purpose of this thread was a "simple" and "inexpensive" signal system that would address the needs of a vast majority of the users.  I realize that the capability exists to do amazing things with technology, but that runs up the cost and REALLY runs up the complexity!  Once you get into multiple signals, communications, central signal control, etc., it spirals way out of control in both time and money to build it.

I want to start with a stand-alone signal board.  I contemplate the idea of having extra ports to expand on the basic functionality, but when you start talking about linking the whole layout with RS485, the "simple" train clearly has jumped the tracks!  We have to crawl before we can walk.

Things seem to go from simple to complex really quickly on here from what I have seen. I think because we want to do more and more with the layouts as technology evolves and changes, and gets smaller and smaller. I have a project I am going to be doing for school using a Raspberry Pi to write some code to have some lights in buildings do some thing. So I can sort of see what you want to accomplish with this.