Train Detection Sensors and Methods

[Mark W]

Continuing my adventures in Arduino/Raspberry Pi, I'm now thinking about grade crossings and signaling.  This raises the question; What are the different methods of train detection, and what are their pros/cons?

I know there are ambient light sensors, IR Emitters/Detectors, something called "block detection".  Less practically (for N scale at least) there are also force detectors and motion sensors.  Has anyone compiled a full list and comparison? 

[railnerd]

For IR sensors, I like these: http://www.bouldercreekengineering.com/nightscope.php

-Dave

[C855B]

What Dave linked to is a Reflective IR method. Here's a list off the top of my head:

Reflective IR, where occupancy = TRUE if it sees the source's IR beam reflected back at itself off the bottom of rolling stock. Advantage is a one-piece design, problem is you need to keep two holes clear in the ballast. It's also point detection (occupancy at a certain point) rather than block detection.

Transmittive IR, which has the classic emitter/detector pair where occupancy=TRUE if the beam between the two is broken. Also a point detection scheme, main disadvantage is hiding the emitter and sensor.

Ambient Detection, another point detection system, using a photocell between the rails looking for the shadow of trains passing over. Main disadvantage is requiring lights to be on (no "night" operations), although some systems do understand how to detect the difference in low-light conditions. Needs a small hole in the ballast. Circuits are pretty simple for this.

Diode Current Sensing, a block detection system, determining occupancy by using a two pairs of diodes to result in enough voltage drop to easily sense when current is passing through to the track in an electrically-isolated block. It can sense a locomotive or lighting-equipped car in the block but is blind to plain rolling stock. Cars can be detected by using metal wheelsets equipped with a resistor to trickle small currents. Works with both DC and DCC, but DC will have throttle response differences between detected and non-detected blocks.

Toroid Current Sensing is another block detection system, mostly specific to DCC. One of the power leads to the track passes through a current-sense toroid, making a small transformer, basically. Advantage over diode-drop detection is no voltage drop to the track, but with DCC that's really only an issue under full power. Doesn't work with DC unless you have a pulsed DC or unfiltered rectified AC. Also needs resistor wheelsets.

I probably missed something - trained monkeys pushing buttons? - but I think that covers it for N. It might be possible to use force detectors to sense weight, but I haven't seen or heard of anybody doing that in N.

My personal bias is running dual systems - occupancy is occupancy - as nothing is 100%. Toroid current sensing for block detection, transmittive IR for spot detection such as grade crossings. An IR crossing system within a detection block can be an additional occupancy input: occupancy = TRUE for the signal block if the crossing is occupied.

[Mark W]

Thanks for the breakdown Mike. 

Right now I'm experimenting with a photocell and adding a potentiometer to calibrate the occupancy variable.  I think this will be the easiest to set up and maintain.  For me, this is all for Free-moN where night ops will likely never be held anyway, but I'm testing just how low light we can get.  Dusk operations might yet be a possibility.   

I want to experiment with Transmittive IR next and am curious how well it would work with fiber optics, allowing for as small as possible source/target for best concealment.  But this might be quite tricky to install and maintain.   

I'm also going to look into force detectors some more.  I don't expect to get any practical results for N scale, but that will definitely be a great learning opportunity.  And who knows, maybe we'll discover something! 

[Scottl]

The light issue can be taken out of the equation to a large extent with some simple programming.  If the sensor takes a continuous reading of light levels, it is the differential when it is blocked that is important, not an absolute value.  We do this with optical sensors quite a bit to account for sunlight and other light sources.  Stand alone circuits with CdS cells and the like needed some kind of threshold to trigger, while a programmed system can be much more flexible.  Component count should be minimal and very robust.

[jagged ben]

The distinction between block detection and point detection is important.  Generally speaking you need block detection if you want to have a sensibly realistic signal system.   Point detection is good for some other things if you want to avoid the need to have resistor wheel sets on all your cars, but would not be so worth investing in if you are going to go ahead with wheelsets.

Examples of useful point detection:

Could be useful for grade crossings if you can figure out a crafty way to hide the emitters and sensors.  We've considered using a couple diagonal beams across a grade crossing at the club, but have not actually tried it yet.

Can also be good for tunnels and other hidden areas.  For example, if you have a siding in a tunnel, you put IR detectors at both ends of main and siding, and connect them to display LEDs that the operators watch.  When a train enters the siding, that end lights up.  When that light goes out, you stop your train, and as long as the other end doesn't light up then you know your train is in the siding and clear of the switches, and someone else can go around you.

If you go all in with resistor wheelsets then you can achieve the same purposes with short block detection sections and stick with one method. 

[jagged ben]

Also, I recall once seeing some video of a mystery block detection method that works with plastic wheels.  Supposedly the creator had no interest in marketing it and his acquaintance who shared it had no idea how it worked.  Don't know if it was snake-oil or real, but if real and functional would be pretty awesome I guess.

Anyone else remember seeing this?  Probably on Trainboard or the Atlas forum.

[Mark W]

The light issue can be taken out of the equation to a large extent with some simple programming.  If the sensor takes a continuous reading of light levels, it is the differential when it is blocked that is important, not an absolute value.  We do this with optical sensors quite a bit to account for sunlight and other light sources.  Stand alone circuits with CdS cells and the like needed some kind of threshold to trigger, while a programmed system can be much more flexible.  Component count should be minimal and very robust.

I knew this was possible, but I thought it would be much more complicated than it actually was.  I decided to test and it works perfect!  The only downside is if the truly ambient light drops within the detection period, it triggers the signal.  However it automatically resets once the detection is actually triggered.  Realistically, ambient light would never drop off this quick anyway. 

I also tried low light and this baby works with all lights in my room off, using only the ambient glow form my computer screen showing all black.  Any darker and you're just operating with a blind fold. 

[C855B]

Also, I recall once seeing some video of a mystery block detection method that works with plastic wheels.  Supposedly the creator had no interest in marketing it and his acquaintance who shared it had no idea how it worked.  Don't know if it was snake-oil or real, but if real and functional would be pretty awesome I guess.

Anyone else remember seeing this?  Probably on Trainboard or the Atlas forum.

You're remembering correctly. I had some correspondence with the fellow who demonstrated this, but he has since fallen off the planet. In our exchange I did get some information that this might have been a transmittive IR-based system, but beyond that, nothing.

[Scottl]

Mark, sounds like you got it.

[Mark W]

Proof of concept!

Tomorrow I'll add servos!

[peteski]

Proof of concept!

Tomorrow I'll add servos!

Concept proven.  Nice! How about a more advanced version which will have more detectors. 

After all, the crossing signal needs to be activated before train enters the immediate area and needs to stay down til after the train passes. Plus you should to detect the direction of the train travel. After all, the train can be something as short as a speeder or as long as 30 car freight and it can possibly enter the crossing area, then back out without fully traveling to the other side of the detection area.

[wcfn100]

I always wanted to see a version that would vary based on speed.  I think proto signals are 30 seconds.  Using Arduino should make this very possible, you just may need several detectors.

Jason

[C855B]

I always wanted to see a version that would vary based on speed.  I think proto signals are 30 seconds.  Using Arduino should make this very possible, you just may need several detectors.

Jason

Moderately easy, actually. Yes, you'd need six point detectors - a pair on each approach, and a pair bracketing the actual crossing. The approach detectors would be spaced to determine direction and speed, and you base activation timing on the speed. The sensors at the crossing would be placed roughly where the crossbucks are, so anything immediately encroaching (or in) the pavement would be 100% activated.

The speed sensing is generally how the prototype works. This is why you frequently see a short-but-fast train approach a crossing, activate the gates at the speed the train entered the circuit, but the train stops short of the gates... and the gates go up after several seconds. This is a timeout to cover this situation. When the train moves into the "close" detection block, the gates lower. Sometimes if the train accelerates too fast from stop it is in the crossing before the gates are fully down - I've seen this multiple times. IOW, don't over-think this, the 1:1 situation isn't perfect, either.

Direction having been determined from the "close" pair, you then know when it's OK to raise the gates.

[wcfn100]

Moderately easy, actually. Yes, you'd need six point detectors - a pair on each approach, and a pair bracketing the actual crossing. The approach detectors would be spaced to determine direction and speed, and you base activation timing on the speed. The sensors at the crossing would be placed roughly where the crossbucks are, so anything immediately encroaching (or in) the pavement would be 100% activated.

One problem is space.  For a train traveling only 30mph you would need the second approach sensor  8' away from the crossing.  And then the first however much farther you need to determine speed.

I used to think about all of this until I learned all of Waterloo was yard limits and restricted to 10mph.  Much easier.

Jason