TT Electronics' OPB892T55Z

Let me try to explain the application of this sensor.

I have 2 metal frames: the top frame and the bottom frame. The bottom frame hangs from the top frame via 4 steel cables and is moved up and down by a bipolar stepper motor winding these 4 cables around a shaft. The sensor is attached to the bottom frame. There is a “flag”, a metal piece that sticks out from the top frame, that moves between the sensor prongs as the bottom frame moves up and down. As the bottom frame moves, the sensor reads high or low as the flag moves between its prongs. That digital signal is read by a Raspberry Pi via the GPIOD library. This calculates the height of the bottom frame with respect to the table top it sits on based on when the sensor is triggered by the flag.

Here’s the problem.

The sensor is sometimes not triggered at the same point consistently. One other thing that will happen is as it passes an edge of the flag, it flips its logic signal multiple times, at least that’s how the Raspberry Pi reads it. For example, if it is not triggered by the flag, it outputs a high signal. Then when it moves such that the flag goes between its prongs, it outputs low then high then low again at least once and possibly multiple times. I have tried to account for this in the software that reads the output signal, but that hasn’t helped. The error is simply too large. Sometimes there is also what appears to be a small delay between an edge of the flag (where the sensor should change its logic level) and when the software thinks there is an edge of the flag.

It needs to read the presence of the flag to within 0.01 inches.

2 versions of the software by 2 different developers using 3 different libraries and 2 different programming languages output the same result. All the hardware has been replaced on the units that experience this problem. Replacing the sensor sometimes works, but nothing else ever has. This has happened on dozens of units in the past year. Probing the white wire of the sensor reveals >2v for a high signal (when the flag is not between the prongs of the sensor).

An 18kohm resistor is soldered to the green wire. An 82ohm resistor is soldered to the red wire. Red is connected to 3v3 on the Raspberry Pi, black to GND, green to 5v, white to GPIO pin 26. I have tried replacing the 18kohm resistor with 10ohm, 1kohm, and 5kohm. The only change was with a 10ohm resistor when the sensor always output a low signal.

I tried connecting several other sensors that have not yet been used to an Arduino Nano Every and I could not even read a logic signal. It was outputting random analog values from 600 to 1023. Reading digital output shows constant, random logic level switching between high and low regardless if anything was between the sensor prongs. However, this is not always the case. More often than not, the signal appears 100% stable. It is only when it passes an edge of the flag that it appears to flip its signal multiple times and deceives the software.

I have run out of ideas for testing and troubeshooting and can’t begin to imagine what could be wrong other than the sensor itself. Changing resistors didn’t seem to help, though it could be that I just haven’t tried the correct resistors yet. If that is the case, I need help working out which resistors to use.

A few observations:

It would appear that an error was made in the writing here, or that the sensor is incorrectly connected. Interpreting other info provided is difficult as a result. Schematics are worth a thousand words…

It should be appreciated that this sensor is actually analog in nature. Light from the LED shines on the transistor and turn it “on,” and blocking that light causes the transistor to turn “off,” but there is a distinct transitional “in between” region described by the charts on p12 of the datasheet.
In the scenario described by this chart, it takes roughly 0.05" of flag travel for the sensor output to transition between its maximal states. The specs for your logic device (RPi or whatever) will most likely define some mid-supply span as invalid for purposes of digital I/O; operating within that range will generate ill-defined input states and possibly make the processor unhappy if done persistently.

Put differently, this sensor is unsuitable for direct use as a digital device in an application demanding 0.010" positional accuracy. Passing the sensor output through a linear comparator with a decent amount of hysteresis would likely clean things up a lot, though simply switching to a sensor variant with narrower slots (see P/N breakdown in datasheet and associated graphs) might be enough to get by. Both might be even better.

1 Like