Using an slotted optical disk with a slotted disk.

[kcsl]

I'm in the middle of a project, and this one part, that I thought would be the simplest part, is driving me crazy and I'm looking for any ideas as to what might be wrong.

I have a stepper motor, glued to the side is a slotted optical switch (the type that has a small IR LED shining through a tiny slot into an IR receiver. I've 3D printed a 20 slot optical disk, mounted it on the shaft and it's currently rotating around 30RPM... and I'm getting what can only be described as bounce on the output. Most of the time it's fine, but then you will see what just looks like switch bounce on a transition.



The top trace shows the regular pulse stream from the optical switch, and the lower one shows a zoomed in section. The very narrow pulses can be < 100ns.

I thought this was because I'd 3D printed the encoder disk and the PLA is shiny so maybe was causing problems, so I sprayed it (and the slots) matt grey. I've tried wide slots, narrow slots, making the disk thicker and thinner and I keep getting these glitches.
They don't seem regular and happen at all speeds from snails pace to full speed.

I thought that perhaps I was picking up some weird noise from the stepper motor or driver, so loosened the disk on the shaft and moved it by hand and I got the same problem; see second image.


I'm using a H22A1 slotted optical switch and I've not tried another one as it's the only one I had in the junk box, but it seems to be working; it detects when the IR beam is broken ok.

Has anybody ever experienced anything like this or got any ideas.

Thanks,
Joe


 

[rick.curl]

Hi Joe- Is that scope trace directly off of the interrupter, or is there any input processing circuitry?
I don't know what is causing the problem, but the glitchy part is such a small proportion of the overall signal, that a very small capacitor across the photodetector will likely make a big difference.
Any chance some ambient light from a fluorescent or LED light fixture could be getting into it?

-Rick

[John Lawton]

Possibly you are getting crosstalk between the channels?
This device doesn't have a built-in schmitt trigger, so what is your application circuit?

[kcsl]

Hi Rick,
Yes, I'm monitoring the output of the photo transistor directly which also has a 4.7K pull up resistor.

I too thought that it was a problem with ambient light. The position and orientation of the sensor means my bench light shines right into it, however, I later tried it in the dark with the same results.

The capacitor idea is something I'm been thinking about. My main problem here is that I need to be able to run the motor from around 0 to 1200 RPM and I'm thinking it may be a challenge to find a suitable value capacitor. Plus I'm puzzled why I'm getting this problem.

Joe

[kcsl]

Hi John,

Hummm.... it never occurred to me that it's possible everything is actually working ok, and it's a monitoring issue.
As far as I know, I've never had cross talk issues before using this kit, but I suppose it's possible.
The frequency is really low and the other input channels are disabled; though they are still physically connected to other parts of the circuit so maybe that's having some weird affect.

But this has got me thinking, maybe I should change the layout somewhat.
The sensor is fitted to the stepper body and a piece of 4-core screen cable (around 8" long) runs back to a breadboard so I can experiment.
Maybe I should move the current limiting resistor for the IR Led and the sensor pull up resistor closer to the sensor.
I'm also wondering if this is some weird metastability issue with the sensor. Maybe I should try using a more modern sensor rather than this antique.

Maybe today with a fresh brain inspiration will strike.
Why is it always the simple things that take all the effort.
Joe

[top204]

As John mentioned, maybe you need a Schmitt trigger between the photo sensor and the microcontroller, or you can enable the Schmitt inputs on the microcontroller, if it is suitable one, or use one of the comparator peripherals for the input and add hysterysis to it with a few external components. Then when the comparator is triggered, it will also trigger an interrupt.

Also, make sure the photo-sensor you used is capable of higher frequencies, and does not have a limit to it. A lot of photo-sensors have a slow change rate, which will make the logic level crossover a bit blurred and cause noise.

[trastikata]

I think the H22A1 transistor is too fast for the slowly rotating disk which forces the transistor to be in a transient state between ON and OFF for too long.

Instead of adding a capacitor you can add a delay of few uS in the interrupt handler before clearing the flag, giving enough time for the transistor state to stabilize.

[david]

I think adding a software adjustable dead time as trastikata describes is the best way to go.  It behaves similar to a low pass filter but is "brick wall" in nature and not rpm dependent.  This issue sounds like the classic case of a relatively slow ramping signal triggering a logic input that is spending too long in a linear region.  Adding a downstream Schmitt trigger will only further square up the multiple, full level signals that are there already and the hysteresis function needs to be in the sensor itself - i.e the receiver would need to trigger on at one strongish level of light and only drop out when that level had significantly reduced.  This is similar to the way digital output Hall sensors operate - they turn on at say 5mm from the magnet but only turn off when 8mm away - no linear region.
Without knowing the application, the use of a Hall sensor is a great hedge against dust build up on both the light receiver and transmitter and it also avoids saturation/desensitizing from other light sources.
First step - try trastikata's idea by setting a dead time just a bit longer than the longest glitch observed.

Cheers,
David

[top204]

A dead gap will work if the input is purely software related, but if you are feeding directly in a Timer's pin or an INTx pin, there is no real control, and the timer may be incremented, or the interrupt may be triggered with the extra 'bounce' noise as it rapidly changes state.

With an INTx pin input, you can add some extra code within the interrupt's INTx section to give it a form of debounce, but this will slow down the interrupt, and you could miss the next, valid, pulse. However, directly into a Timer has no pre or post software manipulation for the pulses.