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:

http://siliconventures.net/images/Revolution%20Counter.png

On Sat, 29 May 2021 05:57:59 -0700 (PDT), "rhor...@gmail.com"
<rhorerles@gmail.com> wrote:

>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:
>
>http://siliconventures.net/images/Revolution%20Counter.png

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.

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

On Saturday, 29 May 2021 at 05:58:03 UTC-7, rhor...@gmail.com wrote:
> 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:
>
> http://siliconventures.net/images/Revolution%20Counter.png

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.

https://ibb.co/74wzvSt

On Saturday, May 29, 2021 at 5:58:03 AM UTC-7, rhor...@gmail.com wrote:
> I am using a TCRT5000L photo-interrupter ...
> 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

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.

On 2021-05-29, rhor...@gmail.com <rhorerles@gmail.com> wrote:
> 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 a
liasing 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:
>

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.

> http://siliconventures.net/images/Revolution%20Counter.png

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.

--
Jasen.

On Saturday, May 29, 2021 at 4:49:51 PM UTC-5, ke...@kjwdesigns.com wrote:
> On Saturday, 29 May 2021 at 05:58:03 UTC-7, rhor...@gmail.com wrote:

> You may want to think about doing it mostly digitally in a microcontroller.

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 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..

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).
> The phototransistor had series resistor that was selected so that the phototransistor never saturated, the LED emitter was controlled from the MCU.

Hmm. I like the idea of controlling the LED current. It could be done either by a microcontroller or an amplifier. Hmm.

> 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.

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.

> The A/D results were compared, averaged and thresholded. I didn't need to do 150Hz but it could probably do it.

This is not A/D, in the normal sense. It's just counting pulses. No time component.

> With an MCU there you could even do the frequency counter in the same MCU..

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.

> 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.

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.

On Saturday, May 29, 2021 at 7:00:48 PM UTC-5, Jasen Betts wrote:
> On 2021-05-29, rhor...@gmail.com <rhor...@gmail.com> wrote:
> > I am using a TCRT5000L photo-interrupter to drive the input of a bank of 74LS90 decade counters to make a rotation counter.
> >
> 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.

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.

> At high rates you want to run the LED at fixed current and use a
> data-slicer to process the output.

The rate is not going to be very high - at most 2000 RPM (33 pulses persecond), and probably a lot less.
> The fact that they stopped making the CD4553 and 14553 cuggests that discrete
> counters are no-longer a good idea.

I'm not sure what your point is, here.

> 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'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.

søndag den 30. maj 2021 kl. 04.15.11 UTC+2 skrev rhor...@gmail.com:
> On Saturday, May 29, 2021 at 7:00:48 PM UTC-5, Jasen Betts wrote:
> > On 2021-05-29, rhor...@gmail.com <rhor...@gmail.com> wrote:
> > > I am using a TCRT5000L photo-interrupter to drive the input of a bank of 74LS90 decade counters to make a rotation counter.
> > >
> > 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.
> 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.
> > At high rates you want to run the LED at fixed current and use a
> > data-slicer to process the output.
> The rate is not going to be very high - at most 2000 RPM (33 pulses persecond), and probably a lot less.
> > The fact that they stopped making the CD4553 and 14553 cuggests that discrete
> > counters are no-longer a good idea.
> I'm not sure what your point is, here.
> > 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'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.

what do you need 42 line for?

On 2021-05-30, rhor...@gmail.com <rhorerles@gmail.com> wrote:
> On Saturday, May 29, 2021 at 7:00:48 PM UTC-5, Jasen Betts wrote:
>> On 2021-05-29, rhor...@gmail.com <rhor...@gmail.com> wrote:
>> > I am using a TCRT5000L photo-interrupter to drive the input of a bank of 74LS90 decade counters to make a rotation counter.
>> >
>> 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.
>
> 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.

If you know it's easier to count them reliably.

>
>> At high rates you want to run the LED at fixed current and use a
>> data-slicer to process the output.
>
> The rate is not going to be very high - at most 2000 RPM (33 pulses persecond), and probably a lot less.

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.

>> The fact that they stopped making the CD4553 and 14553 cuggests that discrete
>> counters are no-longer a good idea.
>
> I'm not sure what your point is, here.
>
>> 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'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.

It's not hard to multiplex LEDs, or do you need blinding brightness in
your application?

--
Jasen.

On 30/05/2021 02:55, rhor...@gmail.com wrote:
> On Saturday, May 29, 2021 at 4:49:51 PM UTC-5, ke...@kjwdesigns.com wrote:
>> On Saturday, 29 May 2021 at 05:58:03 UTC-7, rhor...@gmail.com wrote:
>
>> You may want to think about doing it mostly digitally in a microcontroller.
>
> 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 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.
>
> 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).
>
>> The phototransistor had series resistor that was selected so that the phototransistor never saturated, the LED emitter was controlled from the MCU.
>
> Hmm. I like the idea of controlling the LED current. It could be done either by a microcontroller or an amplifier. Hmm.
>
>> 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.
>
> 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.
>
>> The A/D results were compared, averaged and thresholded. I didn't need to do 150Hz but it could probably do it.
>
> This is not A/D, in the normal sense. It's just counting pulses. No time component.
>
>> With an MCU there you could even do the frequency counter in the same MCU.
>
> 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.
>
>> 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.
>
> 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.
>

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.

piglet

On Sunday, May 30, 2021 at 1:45:40 AM UTC-5, piglet wrote:

> 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?

Yes, it is absoltely a one-off, or at most a two-off.

> (BTW some LED room lamps can have plenty of 120Hz
> depending on the design.)

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.

> 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.

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 guess getting the sensor close is a vital factor.

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.
>
> If you decide to explore the modulated IRED emitter scheme beware the
> photo-transistor is very slow.

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.

This is for a transformer winder.

On Sunday, 30 May 2021 at 05:56:45 UTC-7, rhor...@gmail.com wrote:
> On Saturday, May 29, 2021 at 9:12:41 PM UTC-5, ke...@kjwdesign.com wrote:
> > 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.
> 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.

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.

> > > > The A/D results were compared, averaged and thresholded. I didn't need to do 150Hz but it could probably do it.
> I am still very concerned about aliasing and masking.

See above - the rates are such that it is not an issue.

> > 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.
> I am afraid I don't follow. How is a repetative change in signal levels not a chain of pulses?
> > The software determines the optimum threshold.
> Yes, of course.
> > An analog signal goes into the MCU, pulses come out.
> 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.

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.

> > Whether it is indicating RPM or counting rotations is pretty much the same requirement. The only difference is whether the time is involved.
> 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.
> > I was thinking of displays like this. It has just two wires for input; clock and data. No I2C multiplexing etc.
> >
> > https://www.aliexpress.com/item/1005001471048548.html?albpd=en1005001471048548&acnt=708-803-3821&aff_platform=aaf&albpg=743612850914&netw=u&albcp=1582410664&sk=UneMJZVf&trgt=743612850914&terminal_id=1bb4c0df3b9842ed8636cbd7c9ccf18d&tmLog=new_Detail&needSmbHouyi=false&albbt=Google_7_shopping&src=google&crea=en1005001471048548&aff_fcid=573c48c596a849fa8da8fda56beea4e6-1622340593353-04022-UneMJZVf&gclid=CjwKCAjwzMeFBhBwEiwAzwS8zNFYeu6XHhZcCPKB7hYTJtjmeV3J_vrAestW9bUXLm6IdIIZAqyM_BoCLjUQAvD_BwE&albag=59754279756&aff_fsk=UneMJZVf&albch=shopping&albagn=888888&isSmbAutoCall=false&aff_trace_key=573c48c596a849fa8da8fda56beea4e6-1622340593353-04022-UneMJZVf&device=c&gclsrc=aw.ds
> 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 implemented it in an 8-pin device with plenty of room to spare.
> 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.

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.

https://www.arduino.cc/reference/en/libraries/tm1637/

> > 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.
> 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.

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.

Have you read this app note? https://www.vishay.com/docs/80107/80107.pdf

kw

On Sunday, May 30, 2021 at 12:21:40 PM UTC-5, ke...@kjwdesigns.com wrote:
> On Sunday, 30 May 2021 at 05:56:45 UTC-7, rhor...@gmail.com wrote:
> > On Saturday, May 29, 2021 at 9:12:41 PM UTC-5, ke...@kjwdesign.com wrote:

> 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.

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.
> There is nothing magic about 1kHz.

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.

> 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.

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.

> > > An analog signal goes into the MCU, pulses come out.
> > 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.
> The Schmitt tigger will be in software

Pretty neat isn't it? Emulating hardware using digital signal processing, I mean.

> so it can have an adaptive threshold. I would give a small amount of capacitative filtering on the input, that's all.

That (or inductive filtering) is always a good idea, whether the circuit is analog or digital, and whether low speed or high speed.

> The Arduino is a good choice, I did my initial development on an Arduino as proof of concept and for ease of software development.

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.
> 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.

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.
> Ok, the 74LS90 is about 15 years younger but those older parts require much more wiring and board space.

At $5 per square inch, board space is indeed a real issue. The wiring not so much. They are just traces, after all.

> Although you say you don't have much ambient light that does reduce contrast. Agreed LED lights have less infra-red than incandescents

A WHOLE lot less. Close to 80% of a standard incandescent bulb's output is IR. The LED is closer to 5 - 10%.

> but it is not zero.

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.

> I can saturate my solution with an LED flashlight.

Oh, well, of course. I sell a 100 Watt (600 Watt equivalent) LED flashlight that can burn one's hand.

> 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.

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.

> Have you read this app note? https://www.vishay.com/docs/80107/80107.pdf

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.

In article <1d23db6e-ce1b-4fbd-bc60-08d5a5160b02n@googlegroups.com>,
rhor...@gmail.com <rhorerles@gmail.com> wrote:
>>
>>
>https://www.aliexpress.com/item/1005001471048548.html?albpd=en1005001471048548&acnt=708-803-3821&aff_platform=aaf&albpg=743612850914&netw=u&albcp=1582410664&sk=UneMJZVf&trgt=743612850914&terminal_id=1bb4c0df3b9842ed8636cbd7c9ccf18d&tmLog=new_Detail&needSmbHouyi=false&albbt=Google_7_shopping&src=google&crea=en1005001471048548&aff_fcid=573c48c596a849fa8da8fda56beea4e6-1622340593353-04022-UneMJZVf&gclid=CjwKCAjwzMeFBhBwEiwAzwS8zNFYeu6XHhZcCPKB7hYTJtjmeV3J_vrAestW9bUXLm6IdIIZAqyM_BoCLjUQAvD_BwE&albag=59754279756&aff_fsk=UneMJZVf&albch=shopping&albagn=888888&isSmbAutoCall=false&aff_trace_key=573c48c596a849fa8da8fda56beea4e6-1622340593353-04022-UneMJZVf&device=c&gclsrc=aw.ds

6 digit 7 segment LED display for around one euro.
This is quite enough url, thank you.
https://www.aliexpress.com/item/1005001471048548.html

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Sunday, May 30, 2021 at 6:41:19 AM UTC-7, rhor...@gmail.com wrote:

> This is for a transformer winder.

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.

On Monday, May 31, 2021 at 6:26:30 PM UTC-5, whit3rd wrote:
> On Sunday, May 30, 2021 at 6:41:19 AM UTC-7, rhor...@gmail.com wrote:
>
> > This is for a transformer winder.
> 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.

'Good point.
> 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.

'Also a good point. It's a bit harder to implement, however, and less flexible in terms of the target.

On Tuesday, June 1, 2021 at 6:23:25 PM UTC-7, rhor...@gmail.com wrote:
> On Monday, May 31, 2021 at 6:26:30 PM UTC-5, whit3rd wrote:

> >...do what old mice did; use two sensors, in quadrature, to sense steps in
> > forward and/or backward direction.

> > Rather than reflective, slotted wheel with transmissive sensors are the common approach here.

>'Also a good point. It's a bit harder to implement, however, and less flexible in terms of the target.

If you could ensure the target (presumably a rotating cylinder) was , say, 1" diameter,
you could blacken it and apply a 1/4" strip of aluminum tape for the mark. It should
be possible to get quadrature with two sensors at 1/8" shift in the circumferential
direction. The coil winders I've used had a Jacobs chuck for a holder,
and such chucks have a cylindrical girth available.