Train Detection Sensors and Methods

[sizemore]

Beat me to it! (from comment on other thread!).


The S.

[eric220]

Petski- I think you're missing a sensor somewhere. A basic crossing needs four sensors, two on each side. One further out to trigger the gates, and one close in (on the opposite side) to indicate when the crossing is clear. In order to get speed information, you need a pair of sensors in the further out position instead of one. That's three sensors per direction for a total of six.

[peteski]

Petski- I think you're missing a sensor somewhere. A basic crossing needs four sensors, two on each side. One further out to trigger the gates, and one close in (on the opposite side) to indicate when the crossing is clear. In order to get speed information, you need a pair of sensors in the further out position instead of one. That's three sensors per direction for a total of six.

You only need 2 detectors (on each side) to determine the train's speed direction and occupancy. A delay could be added before closing the gates if the train travels slow.  It is not a perfect solution since the train could change speed between hitting the sensors and getting close to the gates, but if the train is operated in a realistic manner (momentum) this should not be a problem.  Sure, adding a 3rd sensor (per side) would be beneficial, but is is really needed?  It to me just adds wiring and complication in the programming.

I'm curious how the real railroads do this on their automated crossings.

[eric220]

OK, I see what you're getting at. Since trains are different lengths, I presume the programming would look something like:

When occupancy is tripped, calculate speed.
Given speed, calculate delay until activation.
Activate gates so that they are closed X seconds before train arrives.
When occupancy clears, calculate speed (or if you want to risk it, just use previous speed)
Given speed, calculate delay until deactivation.
Deactivate gates so they they do not open until just after train is clear.

Interesting. I guess that just goes to personal preference, and whether Mark wants to code it or build in the sensors. Assuming train speeds are relatively consistent, the four-sensor version should work. That all depends on how the layout runs, and how much flexibility Mark wants in the system.

[peteski]

Yeah, that's pretty much Eric.  4 sensors should be enough to work with trains which are very short, or enter the crossing then back out of it before tripping the sensors on the other side of the crossing.

[Mark W]

Has anyone experimented with a Hall effect sensor, aka, magnetic field sensor?  This has me intrigued.  How sensitive is the sensor, and how far does it detect.

Imagine the ability to just tape a pre-wired sensor to the underside of a module, allowing you to add a sensor to a neighbors module without modifying anything at all.  Then simply stick one of those tiny rare-earth magnets  to the weight or trucks of every car (RadioShack's tiny REMs could be glued to the bolster pins).  Train goes by, magnets trip sensor, stuff happens.

Adding the magnets to not only your own equipment, but equipment of anyone who runs the layout (thinking Free-mo) would be quite tedious, mildly expensive, but very doable.  Especially since this would non-destructively solve the "How do I get my sensor X feet away from the crossing?" problem. 

[Scottl]

HE sensors are quite sensitive and can be adjusted with circuitry.  Some have digital outputs which would be ideal for interfacing with the controller.  I'm not sure of the advantage over light sensors.

I've often thought ultrasonic sensors could be used in some situations like a crossing.  Positioned correctly, they could sense a train in either direction, speed, and when the train has passed.  They are pretty simple to interface as well, and with some programming a good response to motion could be achieved.

[wcfn100]

Has anyone experimented with a Hall effect sensor, aka, magnetic field sensor?  This has me intrigued.  How sensitive is the sensor, and how far does it detect.

For me the question would be what's the advantage of a Hall Effect over a Reed switch.

Jason

[peteski]

I'm not too keen about any detection method which requires modifying every piece of rolling stock. Way too much hassle to be worth the trouble.   My favorite method is using IR emitter/detector.  Ambient light is not required and the components are small enough to be easily hidden.  The only caveat is that they need to be installed at the right height to detect all rolling stock (flat cars for example are usually the ones to watch for).

[Scottl]

Hall effect switches give clean output without ripple and you can also use hysteresis to further clean up the signal.  Nice for interfacing with a microcontroller.  Reed switches are really noisy and subject to sticking- HE are solid state.

[jagged ben]

OK, I see what you're getting at. Since trains are different lengths, I presume the programming would look something like:

When occupancy is tripped, calculate speed.
Given speed, calculate delay until activation.
Activate gates so that they are closed X seconds before train arrives.
When occupancy clears, calculate speed (or if you want to risk it, just use previous speed)
Given speed, calculate delay until deactivation.
*
Deactivate gates so they they do not open until just after train is clear.

Doesn't work if the train stops (or slows way down) where I put the asterisk.

Personally I care quite a bit less about the timing of it going down than about it staying down until clear, regardless of what happens.  Which is why I would want at least one optical detector for the crossing itself, regardless of the method used to detect the approach.

[peteski]

Doesn't work if the train stops (or slows way down) where I put the asterisk.

Personally I care quite a bit less about the timing of it going down than about it staying down until clear, regardless of what happens.  Which is why I would want at least one optical detector for the crossing itself, regardless of the method used to detect the approach.

Looks like I missed that step when reading Eric's description.  To me the deactivation would happen immediately  after the train exited the pair of sensors past the crossing gates.

Still, it would be interesting to know how real railroads deal with automatic crossing gates.

[eric220]

I saw that same issue, which is why I'd personally prefer the third sensor.

Pete, the problem with using the opposing sensor is that it's far enough out to trigger the gates for a train coming from the other direction. The gates would stay closed for several seconds after the train cleared the crossing. Prototypically, they should open almost immediately after the train clears.

[jagged ben]

Here is what we're thinking of at our club, which we haven't done yet but which we'll get to when the block detection reaches an area with an operating grade crossing.  It's pretty simple, no speed calc involved in our plans yet, works decently with or without resistor wheelsets.

We'll use existing block detection sections on approaches, along with an optical sensor (or two) only at the grade crossing itself.

-When an approach occupancy is triggered (JMRI can detect from which direction), gates to go down and a timer starts.
-If the timer expires before the grade crossing (or other approach) sensor is triggered, gates go up.
-Optical sensor at grade crossing triggers gates to go down/stay down in all circumstances, not subject to any timer.

In one of our cases there are going to be a plethora of block detection sections on each side of the crossing due to a multitude of turnouts, as well as our overall scheme.   So it would be no problem to program multiple timer triggers for all of these sections.    Calculating speed would also be possible but I think we probably won't bother unless we are unhappy with the results after the first go.

The only case that this won't deal with so perfectly is a shoving move with a train that does not have resistor wheelsets on the rear.  For that, the engineer will either have to proceed at restricted speed until he triggers the optical sensor, or use the 'manual backup' option (i.e. buttons on the fascia, which is our current method until this all gets installed). 

[nscaleSPF2]

Proof of concept!

Tomorrow I'll add servos!

Mark, I am following this thread with interest, as I would like to do something similar.  If I may ask, what happens when you apply ballast over the sensor?