I am using a TCRT5000L photo-interrupter to drive the input of a bank of 74LS90 decade counters to make a rotation counter. I will be biasing the diode transmitter at 20mA. Obviously, I will want to use something like an analog comparator or an op amp to make the detector more sensitive and a schmitt trigger to prevent instability. The question is, how can I optimize the sensitivity? Nothing about the rotating material will be known, including its IR reflectivity, except that the surface will have a well defined mark that does allow the reflected light to vary by a significant amount. If the collector resistor is too large, then the phototransistor may easily saturate, and the sensor voltage will never go high enough to set the comparator on each revolution. If the resistor is too large, the sensor voltage may never drop low enough to reset the comparator. I am trying to think of a simple way I could actively normalize the collector current so the sensitivity is right in the nominal range whenever the material and sensor gap change. Of course, this circuit would have to be relatively slow acting, or else it will change the collector voltage too quickly, either causing aliasing or lost data. The incoming pulse frequency may vary between 0.2 Hz and 150 Hz. I am thinking something like the following might work, but I am far from confidant:
Run the photodiode in linear mode so it never saturates. Then a TIA and AC amplify the signal, lowpass filter, and zero-cross detect. That will work better if your target is about 50% duty cycle, rather than a narrow strip.
You may want to think about doing it mostly digitally in a microcontroller.
I implemented a sensor recently using a TCRT5000L and an AVR microcontroller with just a handful of discretes.
I needed to reject ambient light and especially 60(120)Hz modulated light as well as accommodating fairly small reflectance from the detected object.
The phototransistor had series resistor that was selected so that the phototransistor never saturated, the LED emitter was controlled from the MCU so that using the A/D converter measurements were taken at about 1kHz with the LED on and then with it off to discriminate the reflected return from the background ambient light. The A/D results were compared, averaged and thresholded. I didn't need to do 150Hz but it could probably do it.
With an MCU there you could even do the frequency counter in the same MCU. Just connect up one of the very cheap serial driven LED displays that are available and the whole thing could be implemented in one IC and a few other parts.
If you can make a known duty cycle, the comparator output can be filtered to make a reference voltage (for the comparator input) rise when the duty cycle is high, and drop when the duty cycle is low.
Since the comparator senses near ground, consider bypassing the phototransistor collector (capacitor to ground) and taking input from an emitter resistor (this makes a faster risetime because the emitter resistor can be circa 100 ohms, has a lower RC time constant with the capacitive transistor).
And, consider adding a few connectors so an oscilloscope can be easily attached to aid in offset/hysteresis/diode current setting. Consider, also, getting some reflective tape and dark paint markers, for situations where you want more reflection/absorption control.
At low rates you want to modulate the LED current and use a lock-in amplifier to discriminate the output, possibly feed that to a slow data slicer.
At high rates you want to run the LED at fixed current and use a data-slicer to process the output.
The fact that they stopped making the CD4553 and 14553 cuggests that discrete counters are no-longer a good idea.
The ATTINY2313 MCU has a counter capable of almost 10Mhz counting (with 20MHz clock) 24 bits worth of hardware counters and enough spare pins to drive at-least 6 7-segment LEDs. there's probably better suited microcontrollers out there, that's just one that I'm familiar with.
I considered doing that. I would either have to multiplex the output lines of the MCU, or else employ an I2C driver such as SAA1064 or PCA9532. With six digits, either one is a bit of a pain.
I don't think ambient light will be an issue. My shop is lighted with 100% LED lights, which produce very little IR, and probably almost no 60 / 120Hz, plus the device will mostly shadow the target. Varying reflectivity is the big issue. The surface may be mirrored or dull black (in infrared).
Hmm. I like the idea of controlling the LED current. It could be done either by a microcontroller or an amplifier. Hmm.
Turning the LED on and off would be highly problematical. It would tend to be taken as a count, especially at 1 KHz. A few MHz might work.
This is not A/D, in the normal sense. It's just counting pulses. No time component.
This is not a frequency counter. I don't care about how fast the shaft turns. I care about how many turns, total, between 1 and 10,000. That's why decade counters driving BCD decoders are ideal. There is no computation involved, only pulse counting.
A bit more than that, no matter what, not to mention a fair bit of code for either line multiplexing or I2C multiplexing. Costs are similar.
The LED is modulated synchronously with the measurement. It wouldn't be taken as a count as the MCU software is in control of it. It is implementing a lock-in amplifier as one of the other posters mentioned.
The A/D is in the MCU to do the adjustable threshold of the detected light. It hasn't been turned into pulses at that stage.
The software determines the optimum threshold.
An analog signal goes into the MCU, pulses come out.
Whether it is indicating RPM or counting rotations is pretty much the same requirement. The only difference is whether the time is involved.
I was thinking of displays like this. It has just two wires for input; clock and data. No I2C multiplexing etc.
formatting link
I implemented it in an 8-pin device with plenty of room to spare. If you want it could just send pulses to the counter you are referring to but using 50-year-old 7490s to do the counting is very wasteful of components.
No, again, this is not a frequency counter. It is a rotation counter, a simple pulse counter. I don't need to know how fast the pulses are coming, only how many of them have happened, irrespective of the time period.
The rate is not going to be very high - at most 2000 RPM (33 pulses persecond), and probably a lot less.
I'm not sure what your point is, here.
I'm not familiar with that chip, but the datasheet says it only has 18 I/O lines (20 pins total). That's plenty with multiplexing, but nowhere nearly enough to drive 42 lines directly.
In that case just pulse the LED at 125 Khz or something like that and look at the AM signal you pick up on the phototransistor, that'll make you pretty-much immune to ambient light sources.
It's not hard to multiplex LEDs, or do you need blinding brightness in your application?
You mentioned your shop lighting which makes me wonder if this is a one-off tool for your own use instead of a product for use by the unskilled mass market? (BTW some LED room lamps can have plenty of 120Hz depending on the design.)
I built a very similar coil winders turn counter years ago for in-house usage and simply used a trimpot and schmitt/comparator on the reflective sensor - despite differing target contrasts it was not hard to find a sweetspot and I don't recall having to readjust the trimpot. I guess getting the sensor close is a vital factor.
If you decide to explore the modulated IRED emitter scheme beware the photo-transistor is very slow.
So what happens when an LED modulation event is concurrent with a reflected light transition? The MCU can't detect a drop in reflectivity when the LED is shut down, and an increase in reflectivity coincident with an increase in the emitted light is difficult to distinguish.
I am still very concerned about aliasing and masking.
I am afraid I don't follow. How is a repetative change in signal levels not a chain of pulses?
Yes, of course.
How is the analog signal not a set of pulses? The amplitude of the signal is changing due to pulses sent to the LED and due to sharply changing reflectivity. Admittedly, the pulses are probably not anything like rail to rail, nor are they particularly clean. That's why I added the Schmitt Trigger.
In practice, maybe yes and maybe no. A frequency counter can miss an occasional transition or register an occasional spurious one - especally if it is random - and still come up with a correct answer. The errors simple represent noise, and can readily be accounted for by averaging over a significant time period. Counting has no such luxury. Not even a single missed or spurious pulse is acceptable.
Oh, wow! I'm sold. One of those and an Arduino it is. I have a bunch of Arduinos coming in from Ali Express on the way already. Where can I find the communications protocol, or better yet, some sample Arduino code for driving one of these displays?
Thanks a ton, by the way. This advice will save me a fair bit of cash, at the cost of a small amount of simple code writing. I can live with that.
I have no doubt of that. Those displays are golden. In my case, I think I will stick with an Arduino Micro Pro. I will have them on hand in a couple of days, they are cheap enough, and I am already familiar with writing code for the Arduino. If I were building this as a commodity item for widespread sale, I probbaly would use some other controller, but this is a one-off for my own machine shop.
I don't really see the point, here. How old the device design might be is irrelevant. To a significant extent, so is the parts count in and of itself. The decade counters are less than $0.50 each. Six of them cost less than the Arduino. It's the display drivers that are expensive, not to mention the pain of having 42 resistors with 96 traces on the PC board, which by the way needs to be a fairly large 4 layer board, twice as expensive as a 2 layer board. No, you have absolutely convinced me, but not because my proposed design employed LS7490s.
The displays have 7 lines each (8 if one uses the decimal point, but this case does not do so). Six digits require 42 controls. If one is not multiplexing on some way, then the MCU must have 42 I/O lines. If the MCU is doing the muxing, that means more complex code. If one is doing line multiplexing, then it also requires a number of external transistors. Kjwdesigns's suggestion makes the question moot.
Yes, it is absoltely a one-off, or at most a two-off.
Oh, I imagine so, but I would expect them to be in the minority. These days, a transformer and a rectifier are not any less expensive than a simple switching supply. I may actually have to check one day, if I get up the gumption.
Of course, I also considered doing that. In fact, little off-the-shelf boards with a TCRT5000L, a potentiometer, and a comparator are selling for under $1 on ebay.
I exxpect so. The data sheet says, "0.2 to 15mm". I expect more than 10mm would possibly encounter issues. Maybe I am just borrowing trouble, but it seemed to me any system without some sort of feedback would require constant fiddling.
I have no doubt. The datasheet doesn't give a bandwidth or slew rate, but I would expect a 30 milisecond period to be well within its capabilities. If not, I can always turn the spindle more slowly. Turning at 600 RPM would only produce 100 msec pulses, and would be more than acceptably fast, perhapos even still too fast.
You mentioned 2000RPM as the maximum speed That is 33Hz or about 30ms per rotation. If you have 180 deg of the shaft black and the rest whit then there will be ~15ms to sample the returned light. Even if modulated at 1kHz that is 15 hits. That is fast enough to allow some averaging and still guarantee that the white portion can be seen.
There is nothing magic about 1kHz. It could be a bit higher. I just ran my software task of a 1kHz timer interrupt and it was more than fast enough. One version I made serves two TCRT5000L sensors with the same processor.
See above - the rates are such that it is not an issue.
The Schmitt tigger will be in software so it can have an adaptive threshold. I would give a small amount of capacitative filtering on the input, that's all.
The Arduino is a good choice, I did my initial development on an Arduino as proof of concept and for ease of software development.
The standard Arduino toolset comes with a driver for the TM1637 displays. I have used a different 4 digit display to that 6-digit one but they use the same driver.
formatting link
Ok, the 74LS90 is about 15 years younger but those older parts require much more wiring and board space.
A couple of other points:
Although you say you don't have much ambient light that does reduce contrast. Agreed LED lights have less infra-red than incandescents but it is not zero. I can saturate my solution with an LED flashlight.
I found it useful to shield the photodetector so it does not pickup light from anywhere other than the moving part - light from the emitter that gets reflected from other parts of the machine will reduce contrast. Although there is some directivity with both the emitter and photodetector I did have issues with light being reflected from other fixed parts of my system. Painting them black helped as did putting a black tube over the detector that finished close to the object being sensed.
Actually, in practice probably considerably slower. Your point is taken, however. This is certainly anything but a high speed application. You are correct anti-aliasing in software should not be difficult under these circumstances. One should merely require a number of input values to be equal(ish) before taking the result to be a 1/2 count. The duty cycle of the data pulse won't be 50%. It will likely be more like 20% or so, but your point still remains valid.
No, of course not. As long as the modulation rate is high compared to the pulse period, everything should work. If we take a very conservative pulse period of 3ms, a 1KHz modulation will probably not be quite good enough (at least not for me - I'm pretty paranoid about such things). A modulation rate of 5 - 10 KHz should be fine, however, allowing 15 - 30 timing pulses over the length of the mark transition. Of course the space length will be something like 100 - 300 pulses.
As I say, I'm pretty paranoid about such things. I always like to have an extreme margin of safety, unless cost or other considerations make it unreasonable. Upping the modulation rate a bit costs nothing.
Pretty neat isn't it? Emulating hardware using digital signal processing, I mean.
That (or inductive filtering) is always a good idea, whether the circuit is analog or digital, and whether low speed or high speed.
Yeah, exactly. If this were to be a production item, then I would definitely look to using a less expensive MCU, but for a one-time use, the difference of two or three dollars isn't much of a hit. Not only that but the Arduino Pro Micro (and others, as well) has a built-in USB port both for power and programming. That tends to offset the slightly higher purchase cost. Connectors are outrageously expensive.
Thanks. I found it. Some individuals have reported issues when using the library with 6 digit displays, but that was a couple of years ago. Hopefully those issues hav e been resolved.
At $5 per square inch, board space is indeed a real issue. The wiring not so much. They are just traces, after all.
A WHOLE lot less. Close to 80% of a standard incandescent bulb's output is IR. The LED is closer to 5 - 10%.
Well, there is zero and then there is Zero. Of course the LED does produce some IR. Anything carrying electrical current does. In this instance, I am fairly confidant the level of IR won't be significant.
Oh, well, of course. I sell a 100 Watt (600 Watt equivalent) LED flashlight that can burn one's hand.
The case will do that to a significant extent. It will surround the sensor, blocking off ambient light, although with a 30 degree acceptance window for the phototransistor, it may not make all that much difference, actually. Perhaps more significantly, the entire case is going to put the shaft into a shadow, the lights being behind the bench. If need be, I could simply take a tube and surround the entire shaft where the sensor will lie. A hole cut in the tube could admit the case, attaching the case to the tube. 'Not a bad way of mounting the counter, actually.
I have now. 'No big surprises. Aluminum is an excellent reflector, so the shaft will be made of Aluminum (usually - it may vary depending on the project). The "hot spot" will be a mirror polished flat on the shaft. The rest of the surface will be knurled and maybe dyed. Blue layout fluid might work well, although one can neve be sure how reflecive a colored dye is in infrared. I also have some Black 2.0 that might work exceedingly well.
Then you don't want a single sensor; it won't know forward from backward, and if it ever stops near a transition, it could count many transitions, you'd never know.
Instead, do what old mice did; use two sensors, in quadrature, to sense steps in forward and/or backward direction. Maybe, too, you could count partial rotations. Ten steps per revolution would be useful sometimes, like for ensuring entry/exit on the same side of a pot core for a given winding.
Rather than reflective, slotted wheel with transmissive sensors are the common approach here. The light intensity is independent of wheel offset, and you KNOW the transparency of a hole or slot.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.