14

Up front I must admit to little hands-on knowledge of modern microcontrollers and their software - I know power engineering and big motors much better (45 years of it).

Now, my question: Trying to get grandchildren enthused about electronics. They love model railroads, so we are building a train monitoring system bit by bit.

Current problem: To detect distance (optionally speed) of a locomotive from a specific track location, without messing with track power.

Control platform: Stellaris Launchpad

Options considered:
* TSOPxxxx with "dumb" fixed frequency oscillator and RF LED on loco - How do I get speed info?
* TSOPxxxx and emitter at trackside, reflection from loco - can get speed by time-of-flight, maybe
* 5 Volt red lasers and break detection by red LED as sensor (the kids love the lasers, so...) - no speed detection without multiple devices per detection location
* RFID tags and a coil at trackside (will identify the specific loco which is a plus) - no speed info
* Ultrasonic distance sensors - Ubiquitous and well supported by netizens, but too broad a coverage angle I suspect
* One of many readymade model railroad products - counter to the purpose of this exercise

So, which of these approaches, or any others, will give me the least grief at the software end, and yet will involve sufficient opportunity to engage 8 to 12 year olds in hands on electronic design with results they can experience? What are the pitfalls to watch out for (besides spilled cola)?

The trains are N-scale (1:160 scale).

Anindo Ghosh
  • 50,188
  • 8
  • 103
  • 200
Seemingly So
  • 592
  • 1
  • 4
  • 14

3 Answers3

8

If I were automating a model railroad I would put barcode labels on the bottoms of the train cars. Then spread throughout the track I would place barcode readers, facing up from between the rails.

With this you can detect the position, speed, and identity of the cars. Each car would have its own unique barcode, not just the locomotive.

The position sensing of this method is very course, since it relies on when a train passes over a sensor. But it should work fine for most things. You can always put more sensors at important points in the track and less sensors where it doesn't matter so much.

A huge advantage of this method is that the price per train car is very low, only a label that you can print up on your laser or ink-jet printer. The complexity per train car is very low. And the weight added to each car is super low as well.

I would implement this by using an IR LED and Phototransistor as the sensor (there are components with both of these built in), and connect these to a microcontroller. Each sensor has its own microcontroller. The different sensors can then be connected together using a simple network (like an RS-485 bus). With IR LEDs, the sensor would be difficult to see with the naked eye. Total cost per sensor+MCU could be under US$3, not including a small PCB.

  • That's the same idea I immediately thought of when I read the question. The one slightly-tricky issue I see would be that having the barcodes hanging down at axle height would probably look a little ugly, but if they're higher than that one would need to have sensors which are designed to focus on objects beyond contact distance, which may be harder to find. For best results it would almost certainly be desirable to decide upon a certain fixed height above the track for the labels, and have all the labels be mounted at that height. – supercat Nov 29 '12 at 15:54
  • Since I am looking for a single location sensing (station approach), this might be an idea. However, I'm a bit confused about the speed and distance sensing aspects - how do those work? Identification, yes, perfect! Also, no way I can hold the kids' attention long enough for making a half dozen devices - it will have to be 2 devices, 1 which I make for them and 1 they make themselves. One for approaching and one for leaving trains. This isn't serious layout control, it's a "gateway" to get them into electronics. – Seemingly So Nov 29 '12 at 16:01
  • If you have different widths for the stripes at either end of the bar code, you can determine direction. The speed can be calculated using the distance between the stripes. – tcrosley Nov 29 '12 at 17:19
  • @tcrosley There are many ways to encode the data so that direction and speed can be determined-- along with some error detection. –  Nov 29 '12 at 19:58
  • @supercat Label height might be tricky. Using a laser instead of an LED could make the usable distance quite nice, but it would have to be a super low power laser and focusing would be difficult. –  Nov 29 '12 at 20:00
  • @DavidKessner: To determine direction, one would have to place the sensor nearer a particular rail (e.g. north) and have each piece of rolling stock have two barcodes, one nearer each rail, with each barcode having an identifiable east and west end (the east end of each barcode would be near the west end of the other). – supercat Nov 29 '12 at 20:07
  • @tcrosley: One should assume that black-white transitions may be delayed relative to white-black transitions, or vice versa. One should not make assumptions about the width of a bar unless one has a wider or narrower *bar* to compare it to; likewise with assumptions about the widths of spaces. A good pattern may be to define the format so that there are never more than four equal-width bars in a row, nor more than four equal-width spaces. Reading from one end, have eight equal-width bars/space pairs followed by a wide bar; from the other, eight equal-width pairs, narrow bar, wide space. – supercat Nov 29 '12 at 20:13
  • @supercat Barcodes often have a fixed strip pattern at the beginning and end, and this fixed pattern is different at each end. The purpose of this pattern is to give the decoding software something to easily recognize as a code, and to determine the "bit rate" to do the decoding at. You detect the direction based on which preamble/postamble you get first. You get bit rate based on the "speed" of the preamble/postamble. You also get the speed of the train based on bit rate. –  Nov 29 '12 at 20:18
  • @DavidKessner: The pattern I described was different at each end, since one end had a bar as the first "wide" element and the other had a space. It's useful to have start sequences (reading either direction) that differ from any sequence of bars and spaces that can appear within the code. – supercat Nov 29 '12 at 21:22
4

I would start with the optical interruptor or reflector method on either side of Road crossings to signal approaching trains and turn on a flashing RED LED. Remote tracking can also be wire to a trainmap with indicators of trains crossing and direct and speed.

Bar-code scanner is deceptively simple until you have to deal with laser beam safety, label speed tracking rates and computing bar gap interval time to compute speed and validating contents of code to determine direct ion in software.

Breakdown the project into;

  • system functional design
    • inputs , processes, ouputs ( include false trigger rejection)
  • electronics design
    • schematic, BOM, layout
  • optical path design
    • emitter & detector paths and range, frequency response, noise rejection
  • construction & testing
    • wiring with power off the track, noise filtering and mechanical, electrical details

IR can detect interruption of signal on either side easiest or reflection of signal from the same side with a wider range of detection. THe sequence to two adjacent detectors tells which direction and the time interval indicates the speed. This can be measured with either analog or digital methods.

IR barcode scanners either rely on the code going past the detector at aconstant speed or the emitter being reflected past the barcode to be detected by scattering of light or absorption of black carbon. Steady laser beams facing up would need to be optically changed to lower the power to a safe level or spread and then focused for a short path length to reduce power density of stray light.

Tony Stewart EE75
  • 1
  • 3
  • 54
  • 182
  • Barcode sensing could probably be simplified if one designs the barcode format around the application. If one uses a pair of sensors side by side (one nearer to each rail), and designs the barcode format so that one side is a fixed-pitch sequence of black and white bars, while the other side holds the actual data, it should be easy to identify which side is the fixed-pitch side; if all barcodes use the same pitch, that would instantly say how fast the train was going, and which way the car was facing. Further, it would allow decoding even if the train changes speed. – supercat Nov 29 '12 at 17:37
  • good idea clock and data – Tony Stewart EE75 Nov 29 '12 at 17:42
  • One could probably figure out direction and speed using only a single sensor if the barcode sensors were mounted nearer the north rail, each car had two barcodes, and there was enough redundancy in the barcode format (e.g. use Manchester coding, and ensure the underlying data has a good mix of "1"'s and "0"'s. One could then arrange things so that each barcode would have an east and west end (those definitions being correct when the barcode is nearer the north rail). – supercat Nov 29 '12 at 18:13
  • Hey, this is getting very interesting! Thanks, useful insights on the bar code scanner (in comments), and @Richman, I am beginning to like the IR idea, it is what we do in real life a lot: Transmitter and receiver in a single package, embedded in the transit path, or in this case, between ties of the track. The barcode solution isn't looking so attractive now because the software is going to become my problem, and I don't speak software too good, so to say! – Seemingly So Nov 29 '12 at 18:22
2

Other answers have provided excellent inputs your requirement; My answer concentrates purely on proximity (and presence) sensing of model trains, no identification, in the scales which I take interest in, the tiny N and T scales.

Keeping in mind your need for software simplicity, a chopped-infrared transmitter / sensor combination will be easiest. Your mention of the TSOP devices indicates you are already evaluating that path. Consider instead the TSSP4P38 which is designed specifically for proximity sensing using 38 KHz chopped IR:
TSSP4P38

Stating what may be obvious to you already: Distance sensing through time-of-flight of electromagnetic waves (IR, radar etc) is impractical for your purposes: Given the speed of light, resolution in femtoseconds or lower is needed for the 0 to 10 centimeter target distances you are probably working with (1:160 N-scale). In the "real world" transit paths you mention in a comment, distances may be larger, I speculate.

An IR reflective sensor mechanism used in model railroads typically involves, instead, intensity of the reflected IR signal, which would increase per inverse-square law with locomotive approach.

Your device would need to have an IR LED like the TSAL6200 and the TSSP4P38, housed in something like the diagram on Page 5 of the TSSP datasheet. The combination would be mounted between ties on your track, one facing each way. If you mount it low enough and pointing almost parallel to the tracks, external object reflections will be minimized, the tracks working as blinkers.

The output of the TSSP is a logic-level pulse of duration proportionate to the reflected IR. As a locomotive approaches, successive pulses get longer, so readings of at least 2 consecutive pulses, preferably several more, will provide a set of pulse durations and thereby a speed indication. From the datasheet:

The output pulse width of the TSSP4P38 has an almost linear relationship to the distance of the emitter or the distance of an reflecting object. The TSSP4P38 is optimized to suppress almost all spurious pulses from energy saving fluorescent lamps.

If you stay with practicable precision requirements for your device, "fast" versus "slow", "approaching" versus "receding", and of course presence of a locomotive within sensor range, are feasible.

You will have to baseline the system to account for static reflections e.g. from scenery. Also, calibration of actual speed versus consecutive pulse lengths will provide the "fast" / "slow" range mappings.

Pulse duration can be measured using a timer/counter input on your microcontroller of choice. There are several examples on the web for doing this on the Arduino, but as you have mentioned using a Stellaris Launchpad instead, some research may be needed for it.

This is a high-level overview of a solution, please feel free to ask if specific aspects need clarification. At a guess, given your stated background, this won't be an overnight project, but is achievable within a holiday season. Some of the readymade model railroad products you mentioned use this mechanism.

For a more general distance-sensing discussion, please look at this answer from an earlier question.

Community
  • 1
Anindo Ghosh
  • 50,188
  • 8
  • 103
  • 200
  • Thanks for pointing out what should have been obvious to me but wasn't, that EMF time of flight is too short for my distance of interest. +1 for being the best and simplest fit so far for my purposes, will accept if nothing even better comes up. – Seemingly So Dec 01 '12 at 07:58