Help with vintage mouse encoders

[rea5245]

Hi,

I have a mouse from an A&T Unix PC, circa 1985. It mostly works: button clicks are received by the PC, and mouse moves cause the cursor to flicker, indicating the PC is receiving messages.

Decoding the mouse's output, I see that for every +1 mouse movement, it sends a -1 that effectively cancels it out. This happens on both the X and Y axes.

Inside, the mouse has two encoder wheels (it's a ball mouse, of course) and each wheel has two LEDs and two phototransistors. There's a 28 pin, 0.6" wide IC labelled Motorola SC87347P. Google does not offer up a datasheet for it (though it does find me and one other guy asking about it).

What could cause a mouse to fail in this way, sending negative movements that offset every positive movement?

Thank you,
   Bob

[aqibi2000]

Check pull up resistors

[rea5245]

Check pull up resistors

There are only two resistors, 150 ohms each, which appear to be current-limiting resistors for the LEDs.

There are 4 LEDs in all, two for each encoder wheel. The two LEDs for an encoder wheel appear to be wired in series, allowing only one resistor for each pair.

I'm a little surprised there are no pull-up for the buttons. But the buttons are working fine, so I won't worry about that.

- Bob

[rea5245]

There's a 28 pin, 0.6" wide IC labelled Motorola SC87347P. Google does not offer up a datasheet for it

Duh! The second line of text on the IC says "R6-6805". So it's a Motorola microcontroller.

[Twoflower]

A wild guess. As that happens on X and on Y direction that points to the chip. But since everything else works and even it sends the right messages I would say that the controller is also working as expected. At least to some degree. Can you check the supply voltages? Is there some noise/ripple if you rotate the encoder wheels?

My guess is that the controller has some noise problems. If the encoder toggles and the controller send a message causes the supply drop and the controller resets/enter unknown state. If there are electrolytic caps used on VDD-GND add temporarily one in parallel to see if that helps. De-solder on these old PCBs should probably avoided as there's a chance to damage the traces.

[rea5245]

Can you check the supply voltages? Is there some noise/ripple if you rotate the encoder wheels?

The 5V is rock-solid, measured with a scope at the IC's Vcc pin.

[screwbreaker]

Try to clean it.
Usually there are some little slots on the plastic holder for the leds.
Try to spray some air on it to remove all the dust.
Clean also the wheels for each axis.

It happen when there is some dirt on the infrareds, that the cursor don't move properly or start to act weird.

[coromonadalix]

Or the ball get very crusty    lolll

[rea5245]

Or the ball get very crusty    lolll

I took the ball out and I'm rolling the wheels directly.

[rea5245]

Try to clean it.

OK. I blew air on the encoder wheels and inspected them; I see no dust. I wiped the LEDs and phototransistors with a cotton swab dipped in rubbing alcohol.

Still no joy.

[Manul]

If you have two channel scope, probe both detectors at the same time and look if they produce a valid quadrature encoder signal (phase shifted square waves). Post how it looks.

[rea5245]

If you have two channel scope, probe both detectors at the same time and look if they produce a valid quadrature encoder signal (phase shifted square waves). Post how it looks.

Each wheel has two photodetectors on it. On each wheel, one of the detectors works (sends out a stream of pulses) while the other doesn't (remains flat-lined). So that explains why the mouse is misbehaving.

All the IR LEDs work: I can see them lit through my cell phone camera.

The photodetectors look like phototransistors, but they're something more. They have three leads. One is connected to +5V, the second is connected to the microcontroller, and the third is connected to ground. The microcontroller line toggles between 5V and ground. There's no biasing and no pull-up resistor: whatever this component is, it's a sweet, digital, optical switch. I fear it's not manufactured any more. And of course, there's no part number on it.

- Bob

[ledtester]

The photodetectors look like phototransistors, but they're something more. They have three leads.

Post a pic!

You might be able to replace it with a conventional phototransistor and add your own pull-up resistor.

[rea5245]

Post a pic!

You might be able to replace it with a conventional phototransistor and add your own pull-up resistor.

Pic posted.

The detectors are not flush with the board. Since quadrature encoding requires precise placement of the detectors, I wonder if they had some sort of spacer they used during assembly to ensure they were at the right height.

[ledtester]

Perhaps it is a "photologic" sensor like the OPL550:

https://www.digikey.com/en/products/detail/tt-electronics-optek-technology/OPL550/498718

[rea5245]

Perhaps it is a "photologic" sensor like the OPL550:

Wow! Yeah, I think you're right. Thank you!!

[Manul]

Each wheel has two photodetectors on it. On each wheel, one of the detectors works (sends out a stream of pulses) while the other doesn't (remains flat-lined). So that explains why the mouse is misbehaving.

So you  say, that both X and Y axis have one failed photodetector? Seems strange. I guess the fault is somewhere else.

[BrokenYugo]

Is it possible the LEDs have just gotten weak?

[Manul]

I would try to investigate optical alignment. If it is ok, then the output. Is it open collector with pullup, is it totem pole? Is pullup internal to detector, or MCU? Is it shorted to ground or maybe +5? Is it just somehow missing pullup?

[rea5245]

So you  say, that both X and Y axis have one failed photodetector? Seems strange. I guess the fault is somewhere else.

Yeah, it's suspicious. But the circuit is so simple, there's nowhere else for the fault to be. The detectors are wired directly to power, ground, and the MCU. The detectors' outputs are not shorted to ground. There's no pull-up resistor; if the detectors are OPL550s, like ledtester thinks they might be, there's no need for a pull-up.

[rea5245]

Is it possible the LEDs have just gotten weak?

They looked OK when I viewed them through my cell phone's camera.

[Manul]

Yeah, it's suspicious. But the circuit is so simple, there's nowhere else for the fault to be. The detectors are wired directly to power, ground, and the MCU. The detectors' outputs are not shorted to ground. There's no pull-up resistor; if the detectors are OPL550s, like ledtester thinks they might be, there's no need for a pull-up.

The MCU could be faulty, maybe the detectors are wired to different ports and one is bad. So it is not necessarily faulty detectors. There are many variants similar to OPL550, so we don't know which one it is exactly, until some testing of the output is performed.

Are not working detectors' output sitting at 0V or 5V?

[rea5245]

The MCU could be faulty, maybe the detectors are wired to different ports and one is bad. So it is not necessarily faulty detectors. There are many variants similar to OPL550, so we don't know which one it is exactly, until some testing of the output is performed.

Are not working detectors' output sitting at 0V or 5V?

The non-working outputs are at 0V. But with power off, a multimeter shows no continuity from those pins to ground.

So if the problem is in the MCU, it would be on two pins, and it would be forcing them to 0V only when the MCU is powered on, and it wouldn't be affecting anything else in the MCU. It seems unlikely.

[Manul]

So if the problem is in the MCU, it would be on two pins, and it would be forcing them to 0V only when the MCU is powered on, and it wouldn't be affecting anything else in the MCU. It seems unlikely.

Well, MCU port failure would be one failure which explains it versus two failures if we consider detectors. Single failure is more likely then two.

Anyway, you need to think of a way, to verify one or another. The most straightforward way would be to try to make one axis good by changing the bad one with a good one from another axis. But this is soldering and might be difficult to align good. Another way could be to cut traces, maybe both good and bad detector. Then you can observe how detectors work on their own, separated from MCU and also simulate switching to MCU to verify that it reads signals if needed. This would probably be my choice.

[rea5245]

Well, MCU port failure would be one failure which explains it versus two failures if we consider detectors. Single failure is more likely then two.

Except that it would be two different ports on the MCU that both failed in the same way, while the rest of the MCU was undamaged.