Using a butchered serial mouse to interface to shaft encoders
Reverse engineering a serial mouse
The crystal
The mouse buttons
The interface to the computer's serial lines
The interface to the X and Y wheels
Connecting the mouse chip to your own circuit
The serial mouse protocols
Initially, I was hoping to use a butchered mouse from a PC to collect the data from the shaft encoders and feed the information back to a computer. A mouse contains two shaft encoders, just as I've described for the telescope, and by disconnecting them and using external encoders instead, I had hoped to save quite a bit of effort in designing a circuit that can count the direction and number of steps without loss.
I actually did go to the trouble of butchering a mouse, removing the mouse chip and designing it into my telescope controller. I did connect a shaft encoder to it and write some simple software to test it. This is what I learned....
I had thought that because serial mice operate at a certain bit rate, it would be feasible to reverse engineer the maximum step rate that they can handle before their counters overflow and information is lost. The trouble I discovered is that mouse chips can lose counts at pulse rates significantly lower than the rate at which its counters will overflow. Because the common serial mouse protocols are simple (read below), you get no indication that there's been an error.
Specifically, I found that if I strictly limited the angular velocity of the shaft encoder (that is, made sure that it only turned slowly), then the mouse chip worked just fine. But if I tried to turn the shaft a little faster, the mouse chip repeatably lost counts.
Slow angular speeds are OK when your telescope is tracking the sky because the earth turns only once in a fraction under 24 hours. Your telescope does not need to track quickly to follow the rotation of the sky. However when you're slewing from one object to another, you actually want your telescope to move as quickly as practical so that you don't waste observing time. At an angular velocity typical for a slew, I found that my mouse chip always lost counts in one direction: I could turn the shaft one revolution clockwise and then one revolution anticlockwise and I found that different numbers of counts were registered for each direction. Bummer. Losing counts is absolutely unacceptable for this application.
My free advice for you is this....
If you plan on using shaft encoders which have high counts per revolution (such as the 512 count per revolution encoders that I purchased), then you should forget hopes of using a chip from a butchered mouse to interface the encoders to your telescope controller. Shaft encoders with lower counts per revolution, say 128 or 64, should have a better chance of working error free, at least with the mechanical design I present in these pages. In all probability, your computer controlled telescope will perform just fine if you make allowances for the lower pointing resolution in the software. Remember that an encoder with a 128 count disc in it still has a slightly higher resolution than a stepper motor with 400 half steps per revolution.
Despite my disappointment, I've still "successfully" taken an old serial mouse, reverse engineered it and learned a good deal which you might find of use. So I'm going to tell you about serial mice chips anyway.
Serial mice, generally, are based on a rather simple design and the mouse contains only a single chip, a crystal oscillator and some other components that are not necessary for the telescope shaft encoder interface.
Although serial mice are rather simple in design, there are many serial mice on the market and thus many serial controller chips used within them. Rather than tell you the exact pin outs I found on my device, I'll tell you how I derived them. If you have an old serial mouse of your own, you'll almost certain to find that your particular mouse chip works largely the same as mine. Reverse engineering the pin outs will take you less than an hour if you're canny.
Serial mice communicate with a PC at 1200 baud. In order to generate the 1200 baud clock, my mouse contained a 32 kHz crystal which connected directly to two of the mouse chip's pins. This part is easy to reverse engineer. In building your telescope controller, just desolder the crystal and mouse chip from your mouse Printed Circuit Board and build them into your microcontroller. Easy.
Several other pins on the mouse controller chip are dedicated to the mouse buttons. There's one pin per button on my device and as my mouse supported three buttons, that's a total of 3 pins. Wow. Not so hard so far, is it? For my device, the pins are left open circuit when the buttons are released and the pins are connected to ground when the button is pressed. As I did not need buttons in the telescope shaft encoder interface, I just left these three pins disconnected.
(Now if you need some general purpose logic inputs and can't find pins to provide this function elsewhere on your microcontroller, I can think of three ways you could solve your problem....)
Most serial mice seem to interface to the following serial lines on the computer.
On my serial mouse, the CTS line was used to select the mode of operation. When high, the mouse operated in "Microsoft" two button mode, and when low, it operated in "Mouse Systems" (sometimes called Logitec) 3 button mode. There's a difference in these protocols as discussed below. I chose to use the Microsoft mode for my telescope mouse controller but you could use the Mouse Systems mode if you need to use three instead of two button inputs.
For the power supply and logic inputs to the mouse chip, I found that my mouse used resistors and capacitors to provide some small level of filtering.
Here are the serial port pin outs....
9 pin Signal Name Comments connector 2 RD Serial data from mouse to PC 3 TD Only used for power 5 Signal Ground 7 RTS Only used for power or control 8 CTS Only used for power or control RTS = Request to Send CTS = Clear to Send
Assuming that your serial mouse is the mechanical type, you'll find that it contains a heavy rubber coated ball along with some mechanical arrangement to rotate two slotted plastic discs. The slotted discs will each have about 50 or more slots in them and will be mounted between a funny little assembly of an LED and photo transistors. There may be two LEDs of differing non-visible wavelengths too.
In the mouse, the LED and photo transistors are arranged so that as the wheel rotates uniformly, the transistors turn on and off with a duty cycle of approximately 50%. However, rather than both turn on or off at the same time, the transistors and / or LEDs are arranged so that they turn on and off in quadrature with each other (one transistor turns on or off at exactly the mid point of the other transistor's state). You will find that the outputs of commercial shaft encoders are arranged to switch in the same way - in quadrature.
These inputs from the phototransistors thus account for four more pins on the serial mouse chip. Two inputs from the X encoder and the other two from the Y encoder.
When you move the chip from its original PCB to your microcontroller circuit, you can leave behind all of the LEDs and photo transistors and connect the TTL outputs of your shaft encoders directly to the mouse chip.
If you were expecting more information about other pins on your serial mouse chip, there isn't any more information! When you add up the pins I've already mentioned, you'll find that you're already at 14 or more. My mouse chip had 16 pins because it had three button instead of two. There's not really that much to it in the end.
To interface the mouse chip to your microcontroller, you need to decide whether you'll be interfacing using RS-232 levels or using TTL levels. Generally, it's going to be easiest for you to interface at quasi RS-232 levels, but if you want to save yourself an RS-232 interface device and use a transistor inverter in its place, TTL levels are the way to go.
If your microcontroller already has an RS-232 level serial input, the mouse circuit that you've freshly reverse engineered will bolt right up to it without further ado. Recall that your serial mouse was designed exactly for this purpose.
In its original state, your mouse chip was line-powered from the host computer's RS-232 output interface. By having the software driver for the mouse set various control signals to various levels, a computer can provide a split rail supply quite easily. However, split rail supplies are not often required for a microcontroller and so powering your mouse chip using a split rail arrangement might not be convenient. Bother.
But wait! There's a clever trick you can pull to avoid the need for a split power supply and it will cost you no additional components.
You may already be aware that RS-232 line voltages are defined such that anything below -3 Volt is a "1" and anything above +3 Volt is a "0". But are you also aware that most RS-232 line receiver chips on the market will accept a 0 Volt input to be equivalent to a "1"? This means that you can transmit pseudo RS-232 signals in the range 0 Volt to +3 Volt to the RS-232 line receiver and the line receiver will translate these levels to their correct TTL equivalents.
Here's the trick. (But double check with your reverse engineered mouse circuit to make sure it will work with your chip.)
Connect your mouse chip's negative supply input to your 0 Volt rail, connect the mouse chip's zero Volt line to your +5 Volt rail and connect the mouse chip's positive supply input to your unregulated but capacitor smoothed positive line (I had an 8 Volt line handy). Now simply connect the serial output from the mouse chip directly to the RS-232 line input of your microcontroller's serial interface.
The thing you'll need to check is the signal levels that the mouse chip expects to receive on the two X and two Y wheel inputs. On the serial mouse chip I used, these inputs were switched between the mouse chip's negative rail and its zero rail. When the trick above was applied, the X and Y inputs switched between the 0 Volt rail and the +5 Volt rail and so was perfectly compatible with the TTL level shaft encoders I was using. Cool eh?
To instead interface your mouse chip to your microcontroller at TTL levels, you can check to see whether the power supply trick described above is going to work for you and if so, simply use a transistor inverter between the mouse chip's serial output and your UART's serial input. The reason that you need to invert is because a negative RS-232 level means "1" and a positive level means "0".
If you find that for one reason or another, you cannot use the power supply trick above, you'll just need to find a split rail power source to power your mouse chip and be done with it.
As I mentioned above, there are two protocols in common use: the Microsoft protocol and the Mouse Systems protocol. You need to decide which one of these you're going to use for your telescope. I've copied some of the information below from this web site if you want to see more details.
Both of these protocols operate at 1200 baud. However the Microsoft version uses 7 bit, no parity transmission and the Mouse Systems version uses 8 bit, no parity transmission. This means that when in Microsoft mode, your serial mouse will be sending slightly more characters per second than when it is in Mouse Systems mode.
The format of the data bytes is quite different between the two protocols. The Microsoft protocol is arranged so that the mouse always sends groups of three characters. The Mouse Systems protocol is arranged so that the mouse always sends groups of five characters. In both cases, the characters are truly binary in nature, not ascii, and they can take on any value between 0 and 127 (Microsoft mode) or 0 and 255 (Mouse Systems mode). You need to remember this if you've using a serial port driver that can be configured in ascii mode (sometimes called "cooked") or "raw" mode. You need to be using the "raw" mode with a serial mouse.
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 X 1 LB RB Y7 Y6 X7 X6
Byte 2 X 0 X5 X4 X3 X2 X1 X0
Byte 3 X 0 Y5 Y4 Y3 Y2 Y1 Y0
LB = Left Button RB = Right Button
Xn = bit n of the X delta Yn = bit n of the Y delta
Because Microsoft mode uses only 7 bits, you need to be careful that you always AND the values you read from your serial port with 0x7f. The top bit from your UART often reflects the state of the stop (or parity) bit.
Now you can see that the first of the three bytes in the Microsoft triplet always has bit 6 set to '1'. Your software can easily synchronise itself by reading bytes until it sees a byte with bit 6 set to '1'.
The X and Y deltas are signed bytes. Values between 0 and 127 indicate that the mouse moved in the positive direction. Values between 128 and 255 indicate that the mouse moved in the negative direction. The value 255 means -1 and the value 128 means -128.
D7 D6 D5 D4 D3 D2 D1 D0
Byte 1 1 0 0 0 0 LB CB RB
Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
Byte 3 Y7 Y6 Y5 Y4 Y3 Y4 Y1 Y0
Byte 4 X7' X6' X5' X4' X3' X2' X1' X0'
Byte 5 Y7' Y6' Y5' Y4' Y3' Y4' Y1' Y0'
LB = Left Button (0=pressed, 1=released)
CB = Centre Button
RB = Right Button
Although the format of the five bytes is different than the Microsoft format, I think you'll get the drift. A special point to note is that there are two sets of X and Y delta values in the Mouse Systems protocol. The X and Y values indicate the mouse movement since the last set of X' and Y' values were sent. The X' and Y' values indicate the delta since the X and Y values were sent. Why did Mouse Systems do this? I've no idea. Perhaps it was to reduce the likelihood that one of their counters would overflow (indeed the X' Y' arrangement has this side effect).
If you're careful, you'll notice that the Mouse Systems method is not foolproof when it comes to synchronisation. It is possible to incorrectly synchronise onto one of the bytes 2 through 5 instead of the first byte. Normally, you'll notice the error when you check sync next time around. In your computer telescope controller, you'll be in trouble if you lose a character anyway because you're computer will have lost alignment with the sky when this happens. So on the assumption that your computer is fast enough to never lose characters, the false alignment problem with the Logitec protocol is of no real concern.
Contact me
Return to my design notes page.
Return to my telescope page.