Mouse Optical Encoders / Wheels

[discman1028]

Anyone ever open up a standard PS/2 mouse? They all have two LEDs with two spinning optical encoder wheels (one horizontal, one vertical -- duh).

I am wondering if anybody has ANY idea about the circuitry that is used to translate the patterns? I can't find any info on the chip that is on the board, so I'm not even sure if it's a microcontroller, or some specific IC meant for the job. (Or, if the logic is handled on a PC motherboard!)

Any ideas? I can't seem to find good info anywhere.

The reason being is I want to use that physical mechanism that is in place, intercept those signals on a microcontroler, interleave some other custom data, THEN send a custom message along to the PC.

Thanks.


Anyone ever open up a standard PS/2 mouse? They all have two LEDs with two spinning optical encoder wheels (one horizontal, one vertical -- duh).

I am wondering if anybody has ANY idea about the circuitry that is used to translate the patterns? I can't find any info on the chip that is on the board, so I'm not even sure if it's a microcontroller, or some specific IC meant for the job. (Or, if the logic is handled on a PC motherboard!)

Any ideas? I can't seem to find good info anywhere.

The reason being is I want to use that physical mechanism that is in place, intercept those signals on a microcontroler, interleave some other custom data, THEN send a custom message along to the PC.

EDIT: May have asked too soon, the last sentence of this page explains the protocol a bit. But I'm still unsure what chip is in there.

[dangus]

It could be a microcontroller; there's an app note at Microchip that explains how to make a serial mouse with a PIC16C54, complete with source code.
http://ww1.microchip.com/downloads/e...tes/00519c.pdf

About the PS/2 mouse protocol:
http://www.computer-engineering.org/ps2mouse/

PIC16F84 PS/2 mouse design:
http://web.archive.org/web/200511040.../ps2mouse.html

[discman1028]

Thanks, these are good! Any other comments/links are welcome.

[SY]

It's definitely a microcontroller. The interesting part is that the wheels usually contain two sources/sensors in quadrature. This enables the controller to tell the difference between motion in opposite directions (e.g., up versus down).

[davidlzimmer]

SY,

Very interesting. I always wondered about that!

[I_Forgot]

The encoder has two lights and detectors that work in quadrature. The output is a 2 bit gray code. Gray code means only one bit changes from one state to the next. There are 4 possible output states, in clockwise rotation order they are
00, 01, 11, 10 ..... repeating forever as you turn clockwise.

When you turn counterclockwise, the order is reversed:
00, 10, 11, 01 ..... repeating forever as you turn counterclockwise.

A microcontroller can determine the direction by comparing the "new" state of the encoder to the previous state. For example, if the new state is 11 and the previous state was 10, the encoder has been rotated CCW. Look at the CW - there is never a condition where CW rotation gives a 10 -> 11 sequence.

In something like a PIC microcontroller, a subroutine containing a lookup table is typically used to quickly and easily determine the direction of rotation. You fill the lower nibble of a word with the previous and new states of the encoder and add that value to the program counter. When the program counter changes to the new address, it encounters a RETLW instruction ("return with literal in W"). A typical example would be that you would want to increment a counter if the encoder is rotating CW and decrement it if the encoder is rotating CCW. The table will be filled with +1 and -1 values in the retlw statements that make up the table and correspond to the different states changes the encoder makes as it rotates.

Note that there are never any state changes in which both bits of the encoder output are changed. For example, the encoder never switches from 00 to 11. The table entries for this condition will be retlw 0x00. A value of zero will be returned so the counter value will not be affected. In theory these states can never occur, but noise or switch contact bouncing can make strange things happen so these states must be accounted for in the look-up table.

Here is a table I use in project of mine:

;*******************************************
; This table returns +1 or -1 to indicate the direction of encoder
; rotation. Encoder state is stored in lower nibble of ENC_TEMP
; Table valid for 7 6 5 4 3 2 1 0
; 0 0 0 0 old B old A new B new A
;where A, B are encoder pins

ENC_TABLE CODE 0x005

enc_table
movf ENC_TMP,W
addwf PCL,F ; Indirect jump
retlw H'00' ; 00 -> 00 do nothing
retlw H'01' ; 01 -> 00 increment
retlw H'FF' ; 10 -> 00 decrement
retlw H'00' ; 11 -> 00 do nothing
retlw H'FF' ; 00 -> 01 decrement
retlw H'00' ; 01 -> 01 do nothing
retlw H'00' ; 10 -> 01 do nothing
retlw H'01' ; 11 -> 01 increment
retlw H'01' ; 00 -> 10 increment
retlw H'00' ; 01 -> 10 do nothing
retlw H'00' ; 10 -> 10 do nothing
retlw H'FF' ; 11 -> 10 decrement
retlw H'00' ; 00 -> 11 do nothing
retlw H'FF' ; 01 -> 11 decrement
retlw H'01' ; 10 -> 11 increment
retlw H'00' ; 11 -> 11 do nothing

After returning from the table you set the old state of the encoder equal to the new state and it is ready for the next encoder turn.

I_F