Kensington Expert Mouse Trackball: Scroll Ring Aperture Alignment

That comment suggested scroll ring failures on a Kensington Expert Mouse (it’s a trackball) might occur when the apertures become misaligned from the IR emitter-detector pair, although later results were equivocal. I tore apart a failed unit to see what the alignment looked like for a known-bad scroll ring.

The right side view shows the receiver roughly centered in an aperture:

Kensington Expert Mouse - Scroll Ring aperture - right
Kensington Expert Mouse – Scroll Ring aperture – right

The left side view shows that the ring is almost flush against the circuit board, with the isolating cutout just in front, and it’s not obvious how to lower it any further:

Kensington Expert Mouse - Scroll Ring aperture - left
Kensington Expert Mouse – Scroll Ring aperture – left

So I think there’s no way to realign this one, other than to raise the aperture ring a bit, but that doesn’t seem like it would make any difference: the detector already has a good view of the emitter.

If your trackball has a failed scroll ring, tweaking the aperture ring’s alignment certainly can’t hurt: try it and report back.

If you don’t expect a miracle, you probably won’t be disappointed, alas.

The pix come from the Canon pocket camera mounted on the macro lens / illuminator, handheld with manual focus. The dust speck on the detector is just slightly out of focus, but you get the general idea.

Update: 2015-07-29 – A success story from Tom:

Hi, I wanted to leave a comment for your page here: [this url]

I’ve got an expert mouse trackball that was having intermittent scroll ring problems, then finally quit working altogether. Dismantled it easily using the instructions on this site.

Cleaned it and it still wasn’t working. Tried changing the alignment of the IR emitter/detectors and it still wasn’t working. Then we kept on fiddling with the alignment and voilà.

Like others have said, the alignment seems to be SUPER sensitive. So if any others are reading this with the same problem, keep persevering.

Thanks to everyone who has posted to help find solutions!

Another update: Seven years in the future, a real fix appears!

12 thoughts on “Kensington Expert Mouse Trackball: Scroll Ring Aperture Alignment

  1. One of the product lines we did at HP/Agilent was a wide series of shaft encoders. It got bad, with more variations in counts and linewidths than a ROM operation. Except for what went in the HP printers, there were few runs of “standard” devices. Not sure what HP is doing for the printers now; we got clobbered by cost issues.

    You might be seeing a more subtle problem here. If the photodiode edges aren’t well aligned with the code wheel, you could be getting a poor transition between states. The devices we did used hysteresis circuitry (on the digital variants) to make this a bit easier, but a dumb detector might pawn the job off on software. This could be the reason why the scroll wheel works better on one distribution than another.

    So it’s not just up and down, but the other axes could be an issue. One of the previous comments mentioned an adjustment in the tilt of the board. Offset parallel to the shaft axis would cause trouble, too.

    1. photodiode edges aren’t well aligned with the code wheel

      That’s the weird part: the emitter and detector seem to have side-by-side elements, which suggests they’re doing quadrature detection, which means the wheel aperture edge alignment shouldn’t matter in the least.

      But something obviously changes and becomes sensitive to fiddling about, without failing hard… at least for a while. Makes no sense to me, even after two of the things went bad.

      1. Sounds like a job for a multi-input scope, and for someone who really needs/wants to know what’s going on. Not sure that’s a fight worth winning. My oldest optical scroll mouse is a 2001 model, and it still works (though more modern desk-rodents don’t mind if they see a shiny surface). I sort of liked trackballs and used one on a Mac, but never bothered for PCs.

        HP’s simplest encoder used two photodiodes, but as best as I can recall, we never bothered with more than one LED, or if multiple, they were used in DC mode. OTOH, the code wheels cost as much (or more) than the emitter-detector package. If memory serves, distributors were charging $50.00 for high count wheels, and maybe $5.00 for the device (in single digit quantities).

        If the emitters are in quadrature, you might be able to go with a cheaper wheel, but it puts the burden on more precise timing, either in the box or in the driver. I can envision lots of things going sour.

  2. Oh damn. I totally forgot to contact Kensington. When you last posted about this a year or so ago I had intended to inquire with them since this is apparently a common defect. By now mine is approaching five years of age. I couldn’t find the manual that came with it (which is strange ’cause I keep all my manuals in two dedicated binders) and the website just would not let me send an e-mail through it, giving out error messages, nor could I find a plain e-mail address nor a phone number.

    Interestingly I did manage to make my computer scroll by cutting squares out of a piece of cardboard and moving it between the sensors, but frankly this whole alignment thing doesn’t make all that much sense. Why would it work fine for a year or two only to give up afterward? To me that sounds more like some kind of electronics defect than a simple mechanical misalignment.

    Anyway, I’m actually considering buying the Slimblade now that prices have come down a bit. The scrollring on the Expert Mouse was great in concept (endless scrolling), but even when working execution was suboptimal. Besides I prefer Page Up and Page Down to mouse scrolling anyway, so I’ve not missed it all that much anyway.

    1. Btw, I’ve been using this in my /etc/X11/xorg.conf since finding out about the EmulateWheel option. I’m posting this because many people might not be aware of it, like myself until surprisingly recently

      Section "InputClass"
      	Identifier	"Kensington Trackball"
      	MatchProduct	"Kensington Expert Mouse"
      	Option		"SendCoreEvents" "True"
      	Option		"ButtonMapping" "0 1 2 4 5 6 7 3"
      	Option		"EmulateWheel" "True"
      	Option		"EmulateWheelButton" "1"

      Note that EmulateWheelButton takes the real button value; not the mapped one. While the button is pressed moving the mouse vertically scrolls. There’s also an XAxisMapping where you can set two buttons to press to scroll horizontally, or you can switch the default with ZAxisMapping. You can find all the info here:

      1. I think that makes it possible to gum up your X session so that the power button will be your only friend…

        1. How would it do that? (And block keyboard access to boot?) In any case I haven’t noticed any adverse effects yet. :)

          1. You know messing around with input devices in X can have strange consequences that resound far from the original change. Not saying you’ll shoot yourself in the foot every time, but your toes are always visible in the sights…

          1. If and only if you’ve both enabled the server and set up your shared keys… [wince]

        2. True, but I have. I suppose in a worse worst case scenario I could use a live CD/USB of some sort. Although in practice messing up my mouse has never disabled my keyboard.

Comments are closed.