# The Case for Locomotives with Tachometers



## RT_Coker (Dec 6, 2012)

Pros:
1.	Low additional parts cost ~$5.
2.	Precision scale-distance-control.
3.	Precision motor-speed control that is load independent.
4.	No need for multistep locomotive-speed-matching.
5.	Reliable magnetic-uncoupling movements.
6.	Much simpler layout automation possibilities.
7.	Synchronization output for steam-locomotive-chug-sounds.
8.	Others?

Cons:
1.	Complex retro fit for existing locomotives.
2.	No available commercial decoders with this tachometer control.
3.	Not the way things are currently done.
4.	Others?


----------



## CTValleyRR (Jul 26, 2014)

Con #4: Pro's 2-7 are irrelevant to me, and maybe many other hobbyists.

Not trying to be flippant, but before we go here, what's your market, really? I don't find speed matching locomotives to be enough of an issue that I'm going to chase a solution to it. This may be a solution in search of a problem.


----------



## RT_Coker (Dec 6, 2012)

Pros:
1.	Low additional parts cost ~$5.
2.	Precision scale-distance-control.
3.	Precision motor-speed control that is load and track-voltage independent.
4.	No need for multistep locomotive-speed-matching.
5.	Reliable magnetic-uncoupling movements.
6.	Much simpler layout automation possibilities.
7.	Synchronization output for steam-locomotive-chug-sounds.
8.	Others?

Cons:
1.	Complex retro fit for existing locomotives.
2.	No available commercial decoders with this tachometer control.
3.	Not the way things are currently done.
4.	No market among most current hobbyists.
5.	Others?


----------



## tkruger (Jan 18, 2009)

This may not help with speed matching unless the two locomotives used the same gear rations. A tach would measure the motor's RPMs. If you tried to match two different brands then the final gearing may be different making the motor RPM's irrelevant. An easier solution I have is on a loop of track place the two 18 inches apart. Have them run a loop. If they are more than 18 inches apart then they are not speed matched. After a while a little experience will tell you what is slower or faster. The run in a loop method is free.

Other issue is that there is not much room in the shell now with decoders, speakers, weights etc.


----------



## RT_Coker (Dec 6, 2012)

tkruger said:


> Other issue is that there is not much room in the shell now with decoders, speakers, weights etc.


The tachometer hardware (that I use) only needs a small space around the drive-shaft (or flywheel). Space that is usually unused.

Without a tachometer speed matching is a multi-parameter adjustment (at least in DCC). The tachometer makes it a (speed independent) single parameter adjustment for each locomotive type.
Bob


----------



## gregc (Apr 25, 2015)

RollBy OnBoard Speedometer

uses bluetooth


----------



## RT_Coker (Dec 6, 2012)

gregc said:


> RollBy OnBoard Speedometer
> 
> uses bluetooth


Interesting thank you!

The tachometer-wheel-IR-sensor is the low-cost tachometer solution. It is amazing what a locomotive “brain” can do when it has a tachometer-input. Also more precision is generally archived when the sensor is on the motor as opposed to a wheel
Bob


----------



## gunrunnerjohn (Nov 10, 2010)

A tach sensor needn't be that large. I didn't go out of my way to make mine super-small as there was no need in the O-scale world, but it doesn't take much space. I have all the logic I needed right on the sensor with a uP and support circuitry. For speed control and distance measurement, you really only need the sensor mounted on the motor, the rest of the logic can be anywhere it fits. As far as gear ratio, once you have the tach pulses that are slaved to the wheel rotation, adjusting the speed control to a standard is not difficult.


----------



## RT_Coker (Dec 6, 2012)

Thanks for the tach-sensor example!

I did a lot of experimenting to find a low-cost tach-sensor. It consists of a flat-tach-wheel, IR-source-senor-IC (HLC1395), and two resistors. Three connections, ground, 5V, and tach-output. The tach-output drives a standard processor input. The tach-wheels are made using a “silver”-label that is a very-good-IR-reflector. The correct alignment of the sensor to the tach-wheel is important, but not so critical that my not-so-good-eyes and shaky-hands can’t do it.

Bob


----------



## gunrunnerjohn (Nov 10, 2010)

I use the Fairchild QRE1113 Reflective Object Sensor for my Chuff-Generator. It drives a PIC input pin directly. With 1mm spacing from the flywheel tape, it works great. The tape is printed on gummed shipping label stock. I use a thru-hole part because for larger motors, the sensor has to extend down to allow the correct spacing for the flywheel tape, and it's also pretty cheap.


----------



## RT_Coker (Dec 6, 2012)

The basic specifications of the two tach-sensors are very similar. 

For some reason I could not directly get a reliable digital-on/off-state-signal-swing without the flat-“silver”-label. I used the tach-“tape”-setup that gave the strongest IR-reflection (biggest static-voltage-swing) I could find. But understand that I have limited test resources and now also abilities.

Part of my background experience is in radar-systems, so I am very familiar with the effect of the shape of reflective-surfaces. The optimum surface for the curved-flywheel-surface would be 90-degree-V-shaped-groves in the surface. They would need to be very precisely cut and polished 90-degrees, but could be very dense.

Bob


----------



## gunrunnerjohn (Nov 10, 2010)

I camped on it with my 'scope until I got a nice waveform. It took a little tweaking of components and loads to get a reliable trigger. I actually had to dial back the LED current in the sensor to get the best performance. With more current, it was not seeing black stripes if there was any shininess on the tach tape. At 1mm, I get about one volt of margin between on and off states, plenty for the first 100 or so that have shipped. The spacing is fairly critical, you get about +/- 25% or so to play with, but if you're farther than that away, you get missing triggers. Closer is the same issue.


----------



## RT_Coker (Dec 6, 2012)

I am using 220 Ohm on the source and 2200 Ohm on the detector (determined mostly by the specification-graphs). The voltage swing is from ~Vss (~5V) to ~2V. (I only have a slow multi-meter for the measurements.) I am mostly interested in low speed operation, so have not checked for a top-rotation-rate-limit yet. But will eventually do so when I have enough locomotive resources to take the risk.
Bob


----------



## gunrunnerjohn (Nov 10, 2010)

Well, since my unit has to generate the chuff pulses at any motor rotation speed, I have to have good high speed rotation to generate at any possible motor speed. With those values, I have been able to run a locomotive at full throttle on the blocks and see proper pulse generation, so I think it worked out.

The HLC1395 looks to be a very similar sensor as the one I'm using, and specifies the same 1mm sensing distance. You might consider trying black and white with a non-gloss finish for the sensing, it works better for me than a foil based tape.


----------



## gregc (Apr 25, 2015)

have you seen these types of encoders. I pulled something similar from an HP printer.



MABUCHI Standard 130 motor encoder photoelectric encoder DC motor as low as $1.70

while I can see the value for such a device in accurately determining wheel angle or position/distance, not sure it's worth the trouble for velocity that i believe BEMF measurements can provide.


----------



## RT_Coker (Dec 6, 2012)

Thanks for adding the example and yes.
This is probably the best tach-sensor approach (pass-through). The other reflective approaches are probably the best way to retrofit existing HO locomotives.

I also have a couple of surplus HO size motors with magnetic-hall-effect-tach-sensors coming for some experimentation. 
Bob


----------



## gunrunnerjohn (Nov 10, 2010)

I've seen and used those encoders in avionics, a number of panel instruments used that type for the control knobs and for precise rotation data. We used the gray code encoders for shaft position sensing.

That type of encoder isn't really practical for most of our model train use as we don't have a convenient place to stick the encoder disk. The tach strip on the flywheel doesn't really take up extra space.


----------



## RT_Coker (Dec 6, 2012)

gregc said:


> ...while I can see the value for such a device in accurately determining wheel angle or position/distance, not sure it's worth the trouble for velocity that i believe BEMF measurements can provide.


In my mind the tach-sensor is primarily for precision-distance-control, and motor-speed-control is just a very nice side benefit. The inclusion of BEMF hardware is usually insignificant so I usually include it in what I do.
Bob


----------



## Lemonhawk (Sep 24, 2013)

If your counting the pulses inside the computer no need for gray code, if your reading an external counter gray code solves a lot of problems. One of those subtle solutions to a nasty problem.


----------



## gunrunnerjohn (Nov 10, 2010)

Well, the code was so we knew which way the wheel was spinning.


----------



## Lemonhawk (Sep 24, 2013)

An integer subtract of the same work length of the previous reading will also get you the direction. the reason for doing the subtraction at the same word size as the counter is to avoid having to worry about overflow correction.


----------



## gunrunnerjohn (Nov 10, 2010)

You can't determine direction with a single sensor, how do you know if the motor reversed?


----------



## Lemonhawk (Sep 24, 2013)

Yes its a speed detector, the counter will only go up! I'm too use to the stuff I work with that used up/down counters so you could get direction (accels and gyros).


----------



## RT_Coker (Dec 6, 2012)

I just found this information on speed matching DCC, http://www.barstowrick.com/wp-content/uploads/2015/02/David-Eatons-Speed-Matching-Paper-v211.pdf. Can’t imagine why anyone would want a locomotive with a motor-tachometer and have only one parameter to adjust per locomotive type. Where is all the user-fun and manufacturer-profit in that?
Bob


----------

