[Rajendra Bhatt] writes in to let us know about a nice simple IR bounce tachometer. The project uses a startUSB for PIC board and a 16×2 character LCD with a very basic Infrared bounce circuit. Measuring either a reflective or non reflective spot in the rotating object, in this case a bit of white paper, the micro is supposedly capable of measuring up to 99,960 RPM (we think the paper might fly off at this point) with a resolution of 60 RPM. This is the same concept as a beam-break style tachometer but keeps all your electronics on one end of the spinning hazard.
The article also goes into detail about setting the PIC18F2550’s Timer0 register to enable 16-bit resolution. The PIC is configured to turn on the infrared LED for one second, measure the number of pulses (through timer registers), and multiply that value by 60. We would be more careful with the TMR0H and TMR0L counters as they have to be read and written in a certain order to preserve their values, but you’d need to be measuring upwards of 15,360 rpm to run into that error.
It is a quality writeup for anyone interested in learning about the start USB for PIC board, tachometers, or a new project. Thanks [Raj]!
I’m glad i didn’t buy a turbocharger tachometer from Garrett, seems now i can build my own for $30 or less..
On question though, why does the RX pin have to be switched to high using the PNP resistor saturated by the IR photo detector. Couldn’t the whole thing be simplified by going +5v->IR Detector->RX pin (not including whatever resistors are required)
-Jacob
Just use liquid paper instead of the regular kind for the reflector.
@Jacob Looks like a debounce circuit to me. Maybe the photodiode was too noisy because of ambient IR.
Would it not be more accurate to use the timer to calculate the time in between pulses and use that value to find the RPM? It would allow far finer resolution and measurement of speeds less than 1 RPM.
do you think this will work with a turbo?
@BGH for speeds less than 1 rotation per minute you better use grandpa clock and coffee
@turbochris
I would think it would. Ill end up building something like this now this summer, ill probably paint a portion of the compressor nut to get a pulse. Only thing that has to be addressed, which i don’t know the answer too, is the timerol and timeroh issue mentioned where they say rpm reading would show up above 15krpm, which will be an issue because my turbo should be around 85k
-Jacob
i agree with BGH. the used method here goes up to almost 4 million RPM, which is ridiculous and wastes a lot of resolution.
@BGH: Not necessarily. There is no “better” way to measure RPM – counting number of pulses works better for high RPM (many pulses), measuring length of pulses works better for low RPM (long pulses). The only significant difference is really that the second method is the only way to get RPM down to the unit without actually waiting for a minute.
So, assuming we would consider a turbocharger as application, let’s see what the precision would be with the second method.
First, consider ~10000 RPM (~166.6666 pulses per second). If you want to at least match the precision of the first method, you have to be able to tell 10000 RPM from 10060 RPM. That would mean being able to tell the difference between a 1/166=6 mSec and a 1/167=5.9642 mSec long pulse, a difference of about 36 uSec. This implies that you are using a clock that will tick at least once during this period (so you can tell the two values apart), which yields a 1/36=0.028 MHz=28KHz clock. This is easily achievable in the hardware used, therefore it would easily and greatly surpass precision for this range.
Now let us consider a ~100000 RPM situation (this supposedly being a turbocharger after all). The frequencies become ~1666.6666 and ~1667.6666, or 0.6 mSec and 0.59964 mSec, with a difference of 0.3597 uSec, or a clock of ~2.77 MHz. The maximum obtainable clock on hardware used is 12MHz – so yes, the method is still more accurate, but only about 4 times. And doing the same math for the hypothetical case of measuring 100000 RPM down to the UNIT, the required clock would be about 166 MHz (!) which is way beyond PIC range.
So there you go – it all depends on RPM range and desired precision, but it’s not as straightforward a thing as it might seem.
As for sensors, I have a small turbine that does 160,000, it uses a spinning magnet in the nut on the compressor. Another good method is to drill a cross hole in the compressor shaft and shine a laser through the hole onto a detector. if the hole is the right size it makes a nice square wave with close to 50/50 duty cycle. I tried a laser on a reflector and the pulse was way to narrow. Using an IR emitter/receiver worked better this way. I successfully measured up to 130,000 rpm using an IR emitter/receiver bouncing the light off the flats on the nut that held the compressor wheel on. I ran this into my freq counter and got RPM
I wonder if that could be precise for low speed application? Because, i would like to monitor the exact speed of my press Drill. I have seen some ir or laser contact less unit on ebay for about 20-30 $. So i don’t know which option could be the best.. as knowing the drill goes not up to 3500rpm around. Any hints ?
And i think it might be better than an external rpm pulse counter…
@Max: I suppose you are right if you want to measure rates approaching a million revolutions per minute. But maybe at those speeds one would like to invest in a pro system. I guess I would prefer to have a system that can tell me the RPM with resolution finer than 60x, and I cannot point to an application where 1,000,000 RPM is going to come up in a DIY hack. But thanks for doing the math to prove my point – I was just too lazy…
@BGH: No problem, I did the math just because I got curious myself about where the limits would start to apply.
I only went up to 100,000, but as it turns out, precision pretty much gets equal with both methods around there (with this hardware).
There would be a way to cheat this though. The RPM signal could be divided by, say, 10 externally (or possibly even using one of the micro’s internal timers in counter mode). This in itself would not reduce precision at all. Then, the resulting (much longer) pulses could be accurately measured using a still high (but much lower) clock. In the example above, precision down to the unit at 100,000 RPM would be achievable with a 16.6MHz clock (or divide by 100 -> 1.66MHz clock). “Update” rate would still be practically instantaneous, and you get some filtering (averaging of the jitter) as a bonus.
Just goes to show, pro-level results can still be achieved cheaply if one uses one’s head as intended…