Almost all encoders are "Tangent Instruments boxes". This includes the Lumicon, Celestron Advanced AstroMaster, Orion SkyWizard, Ouranos, MicroGuider III, DeepSpace Navigator, JMI's NGC-Max, B-Box, and probably some others. These boxes have different prices and built-in object databases. Some will let you do things such as locate planets and asteroids, read out RA/dec coordinates, and so forth. Some can be aligned by sighting on one star after leveling the mount; others require two stars, but you don't have to level the mount. If you plan to use one of these devices in "standalone" mode, without a PC, these differeces will probably be quite important to you. If you instead expect to use the device with Guide, though, none of these things matter, because Guide will be handling all these things anyway.

Therefore, for people who will always be using their Tangent Instruments box in conjunction with Guide, you have only two concerns: the resolution of the encoders, and the price. On the latter point, the Ouranos and MicroGuider boxes should be of great interest. They are "bare bones" units, with no built-in database or display; they are expressly designed for use with a PC.

Devices such as the Sky Commander and Meade Magellan I and II each use different protocols (but are still supported by Guide). I've heard some good things about the Sky Commander, but aside from that, I really can't comment on any of these boxes (except to say that they work with Guide.)

"Go To" systems, such as the Dob Driver, NexStar, LX-200, Meade Autostar, Mel Bartels' "motorized Dobsonian", and Celestron Ultima 2000 use really different commands, mostly because they have motors to push the scope around. They are therefore fundamentally different from encoder based solutions. Again, the only comment I can make about these systems is that they work with Guide. (I can say that Mel's system looks very good indeed, but requires at least some mechanical and electrical talents.)

For the moment, only the Tangent Instrument-like devices are discussed here. Eventually, some text describing communication with other devices may be added. Click here for details on communicating with the LX-200.

These devices are commonly referred to as 'stupid' devices. This is not really a slur; it just means that about all they do is to count encoder units and send them to the PC. The PC is expected to convert this positional data into angles, then handle tasks such as alignment and figuring out that "encoder position +23453, -01287 corresponds to such-and-such an RA/dec". These devices don't have built-in hardware to do alignment and so forth (well, more accurately, they don't communicate any of that to a PC). This contrasts to 'smart' devices, such as the Meade Magellan I, LX-200, and Ultima 2000; these do understand the idea of RA/dec coordinates.

The result is that the protocol, and the devices themselves, can be really simple. The only downside is that the programmer has to do some extra work, as you'll see.

First, the communications protocol. You hook up to the device, via serial port, at 9600 baud, no parity, one stop bit. You have a grand total of two possible commands to send to the device:

COMMAND #1: SET THE DEVICE RESOLUTION

R(x resolution)(y resolution)<carriage return>

This 'set resolution' command is usually sent to the device once, to initialize it. Encoders come mostly in 2000 and 8192 counts/rotation varieties, with some at 4000. Some people gear them up, though, resulting in assorted oddball ratios... the hope being that you get finer resolution that way. Anyway, here's an example: if the encoder on your azimuth (or RA) axis has 8192 steps, but the encoder on your altitude (or declination) axis is oddly geared up to 7921 steps, you would send the device the following eleven bytes:

R8192<tab>7921<cr>

The device will send an 'R' to confirm receipt.

Note that some devices, such as the Celestron Advanced AstroMaster, don't support this command. They will either fail to reply or reply with a '?'. All of these have hard-wired resolutions, so they don't need to support the 'R' command.

COMMAND #2: GET THE DEVICE POSITION

Q

That's it. Send the single byte 'Q' to the device, and it will spit back a string of thirteen bytes:

<encoder X position><tab><encoder Y position>

Each position consists of a sign (+ or -) character plus five digits. Something like, say,

+04512<tab>-01297

Most devices will send a fourteenth byte, usually a carriage return, but this is not particularly dependable.

That's all there is to it. Once you set up the resolution with the 'R' command, you get the position using the 'Q' command, and multiply the encoder units by (360/resolution) to get degrees. Let's call those angles 'theta' (RA or azimuth axis) and 'phi' (dec or altitude axis).

There are a couple of problems remaining, though. First, you don't know the zero point. For an equatorial mount, you know that...

(1)  RA = theta - theta0
(2)  dec = phi - phi0

Or do you? We don't really know which direction the encoders are reading. People mount them clockwise or counterclockwise with total lack of concern for how messy this makes things. The above could read:

(1b)   RA = theta0 - theta
(2b)   dec = phi0 - phi

In either case, we don't know theta0 or phi0.

Guide, and some similar software, handles this by asking you to align on at least two stars. If both RA and theta increased (or if both decreased) from the first star to the second, we know we should use (1). If RA went up and theta went down, or vice versa, we should use (1b). Similar games with dec and phi give us the choice between (2) and (2b).

Say the first star was at celestial coordinates (RA1, dec1), and we got the angles (theta1, phi1) out of the encoders. And then we went to the second star, at (RA2, dec2), and got (theta2, phi2). Assume we're using (1) and (2), just for the sake of discussion. With perfect alignment:

theta0 = theta1 - RA1
theta0 = theta2 - RA2
phi0 = phi1 - dec1
phi0 = phi2 - dec2

We've got things "overconstrained" by two parameters. Those parameters happen to match the polar alignment error; our polar axis might be, say, EW_err degrees east/west in error, and NS_err degrees north/south in error.

For an alt/az mount, EW_err and NS_err match what you might call a "zenith alignment error", meaning the scope isn't perfectly level. In that case, EW_err and NS_err correspond to "tilt angles"; they're zero if the mount is perfectly level, but EW_err is nonzero if the telescope tilts a little to the east or west, and similarly for NS_err.

Once that's taken into account, we're solving for four unknowns (theta0, phi0, EW_err, and NS_err), and we have four equations. Given more stars, we would have more equations, but we could do a least-squares solution, finding the values for the four unknowns that give the best fit to the observed data.

A mathematician can simply say: "We have four equations in four unknowns, and have demonstrated that a solution exists." Actually getting that solution is less pleasant, getting you into the ugly details of the method of least squares. I have written a program, ALIGNER, which does this; using the same basic idea, it also handles other odd errors, such as the axes not being perpendicular (a common problem) or being not perfectly on-axis or eccentric (not so common, but it does happen with sloppier mounts). It's basically the same thing the TPoint software provided by Software Bisque does.

By the way, one simple way to improve scope errors, without needing to contemplate anything involving abstruse mathematics, is to have the user align on plenty of stars. Then, in a particular piece of sky, pick the alignment star currently nearest to that point. Say it's star #n; then you just compute

theta0 = theta(n) - RA(n)
phi0 = phi(n) - dec(n)

...that is, your pointing is that primitive two-star alignment, but is based solely on the nearest star. This is really a pretty neat trick, in my humble opinion. It can correct for "irregular" errors that the TPoint approach can't handle. For example: a few years back, I visited Perkins Observatory in Columbus, Ohio. These folks have a rather nice 33" classical Cassegrain scope, with serious pointing errors in one direction (I think it was something like a dip of about one degree when the scope was pointed to the southwest). Assuming these errors are consistent, this approach would fix them handily.

Special comments about the Celestron Advanced AstroMaster: This device does not support the 'R' (set resolution) command. Apparently, it's not considered to be necessary, because the resolution can be hard-wired into the device. However, the AAM does have a 'P' command to check the status of the device. Sending 'P' to the AAM causes it to return a three-digit status code. The first digit gives the number of altitude encoder errors. The second gives the number of azimuth encoder errors. The third is '0' for low battery, 1 for OK battery. Thus, you ideally get a reply of '001' (two ASCII 48s, plus an ASCII 49).

The 'Q' command works as mentioned previously.

(Added 1 August 1999) I've gotten occasional inquiries about how to set up the cable for the AAM. A day or two ago, I got into a conversation about the subject with Phil Deines-Jones, in which I mentioned that I ought to document this on my Web site. He sent the following e-mail to me:

I enjoyed our conversation this morning -- here's the data for the
Celestron Advanced Astromaster serial connector.

The connector is a 6-pin modular connector (RJ-11).
Here are the pin assignments looking at end of the plug (the connector
on the cable, not the receptacle on the Astromaster):

                  __________
                 |          |
                 |  ||||||  |
                 |  123456  |
                 |__      __|
                    |____|


If you want to connect to a 9-pin connector on your computer, the
cabling is:

DB9   Signal      Signal    RJ-11
2       RX     -    TX      5
3       TX     -    RX      4
5       GND    -    GND     3

If you want to connect to a 25-pin connector on your computer, the
cabling is:

DB25   Signal      Signal   RJ-11
3       RX     -    TX      5
2       TX     -    RX      4
7       GND    -    GND     3

(I have only tested a DB9 cable, but I believe the DB25 information is
also correct.)

The communications protocol is 9600 baud, 8 bits, 1 stop, no parity.

Regards,
Phil Deines-Jones