Scope control system

At present, Guide provides control for the LX-200 and Sky Commander telescope systems. There is also a somewhat clumsy means of using the Mel Bartels ALTAZ system.

More recently, Mel and I have worked on a new method for telescope control. This is the "scope driver" system. The following notes grew out of discussions we had about how the system should work, and are of interest only to people who want to build their own encoder, stepper motor, or DC motor/encoder feedback systems.

Right now, no commercial telescope hardware uses the system described below. Some sample source code in C/C++ and a driver for the NGC-MAX/Lumicon/MicroGuider family of encoders can be downloaded and tested. It's hoped that a "scope driver" for the Tech 2000 Dob Driver product will soon be available; please contact me if you have Guide and a Dob Driver and would like to do some testing.

Also note that this page discusses only the software end of telescope control. The hardware side is discussed in some detail by Mel Bartels.

This page discusses:

  • Reasons for the scope driver system
  • Basic theory of the scope driver system
  • Data provided to the scope driver
  • Data returned by the scope driver to Guide
  • How alignment is handled
  • Mechanical error correction (MEC)
  • Use of the NGC-MAX/Lumicon/MicroGuider family "scope driver"
  • Reasons for the scope driver system

    In the past, adding a new telescope system to Guide required changing the Guide software itself. You could not put together your own telescope control system and automatically interface it to Guide, unless your hardware used LX-200 commands (in other words, your telescope was an LX-200 clone). Guide would then communicate with your telescope using those commands, to "aim telescope here" and to ask the telescope, "Provide your RA/declination".

    The goal of the "scope driver" system is to (a) eliminate the need for telescope control hardware makers to know about celestial coordinates and (b) to allow people to interface _any_ scope with Guide. It also allows people to correct for certain mechanical problems simply by adding more alignment stars.

    I considered the above goals to be important because it allows telescope control hardware makers to focus on what they generally know best, namely: how to get stepper motors to point at a particular position (or how to read optical encoder positions). It seems silly for hardware makers to have to worry about alt/az to RA/dec conversions, refraction, tilting errors, and mount flexure when all of these factors can be accounted for by Guide.

    By the way, for the benefit of people who want to make LX-200 clones, there is a document (XTROL.DOC, in the COMPRESS directory of the Guide CD-ROM) describing the commands used by Guide to do this (and, I suspect, by most other software). You can also click here to read XTROL.DOC.

    Basic theory of the scope driver

    The basic theory of the scope driver is perhaps best illustrated by showing what happens when you click on an object in Guide and then click on "Slew Telescope".

    With an LX-200, Guide simply sends the RA/dec of the target to the LX-200. The telescope converts this to motor positions and points the telescope. No further work is required on Guide's part.

    With the scope driver system, Guide first converts the target RA/dec into altitude/azimuth. Then, Guide uses alignment stars to convert this data into positions for the telescope motors (these positions are called x and y). In doing this, it takes into account many mechanical problems, such as the scope not being level and axes not being perfectly perpendicular.

    Because the earth rotates and the telescope must move accordingly, x and y are functions of time. They can be approximated as cubic polynomials:

    x(t) = x0 + x1 * t + x2 * t^2 + x3 * t^3

    y(t) = y0 + y1 * t + y2 * t^2 + y3 * t^3

    Guide computes x0, x1, x2, x3, y0, y1, y2, and y3 for the target object. It creates a file, SLEW.DAT, containing these parameters (and many others) and then "calls" the program SCOPE.EXE.

    The program SCOPE.EXE is the actual "scope driver" program. It reads the data for the cubic polynomials from SLEW.DAT. Once it has done this, it can compute x(t) and y(t) and perform the following steps:

    (1) What time (t) is it?

    (2) Compute x(t), y(t)

    (3) Where is the scope currently located?

    (4) If it's not at x(t), y(t), move it there

    (5) Go back to step (1)

    You'll notice that this means that only SCOPE.EXE need know about how the telescope is driven. Perhaps it sends a command through the serial port; perhaps it just reads a set of encoders and tells you how far you are from the target. (The very first test of this system, for alt/az setting circles, just had SCOPE.EXE showing x(t), y(t), while the human tried to push the telescope to that setting circle position.) Eventually, SCOPE.EXE might just send all of this information to embedded hardware on the telescope, which would then take over steps (1)-(5) above. In any case, Guide is totally ignorant of the actual hardware.

    On the other hand, only GUIDE.EXE knows anything about celestial coordinates, alt/az, or alignment. If the object is moving, or if refraction is a problem, GUIDE handles all of it and includes these effects when it computes x0...3, y0...3. SCOPE.EXE knows nothing of these matters.

    Some telescope systems (not many) will also want the instantaneous slew rates, x'(t) and y'(t) (also known as dx/dt and dy/dt). This will not happen very often (in actual practice, the "chase x(t), y(t)" system described above will do a much better job.) But if slew rates are desired, one can use basic calculus to see that

    x'(t) = dx/dt = x1 + 2 * x2 * t + 3 * x3 * t^2

    y'(t) = dy/dt = y1 + 2 * y2 * t + 3 * y3 * t^2

    Data provided to the scope driver

    Here's an example of the data in SLEW.DAT:

    R 241.302596 # RA
    D 36.757017 # dec
    t 846628580 2450386.233565 # time in seconds & JD
    x 842.541117 0.149946 0.000030 0.000000  # x cubic coeffs
    y 1301.863943 0.021504 -0.000003 0.000000  # y cubic coeffs
    q 80.153054 0.002144 0.000000 0.000000  # alt cubic coeffs
    p 134.457216 0.015026 0.000003 0.000000  # az cubic coeffs
    r -39.845256 0.012304 0.000003 0.000000  # field rotation cubic coeffs
    s 4 # serial port
    L 44.020000 -69.900000 #lat/lon
    k 0 # keep_going flag

    Each line has a unique letter to identify it. The first two lines provide the RA/dec in decimal degrees. (These will soon be provided using cubic polynomials, to allow for tracking moving targets such as planets and artificial satellites.)

    The third line provides the "reference time" for the start of the slew. In all of these polynomials, t is relative to this time. It's given first in seconds since 1 Jan 1970, then as a JD (Julian Day). The first form is useful to C and C++ programmers; others can ignore it and focus on the JD.

    Most scope drivers will ignore almost all of these fields and will look at only the (x, y) data... which is, after all, all they need to know. A few scope drivers may just want to display the RA/dec, or may want to make sure the alt/az doesn't venture into certain areas (perhaps the telescope will hit something if the altitude is less than 20 degrees in the northwest, for example). A very few systems may add a third motor to compensate for field rotation; if they do, a cubic polynomial is given for that purpose.

    You'll notice, by the way, that the first term in 'q' (altitude) is 80.153054, indicating that we're slewing to an object less than 10 degrees from the zenith. Despite this, the higher-order terms in the polynomials all converge quite rapidly to zero, meaning that the approximation to a cubic is an extremely good one.

    The scope control menu asks you to select a serial port, and that value is passed on in SLEW.DAT.

    Data returned by the scope driver to Guide

    Once the scope driver is done, it is expected that it will return the final position to Guide. The usual method for doing this is to simply write out the encoder position to the file SLEW_OUT.DAT. If, for example, you check out the last few lines of the JMI driver source code, you'll see that just before shutting down, it opens up SLEW_OUT.DAT and writes out the encoder position in ASCII text. The scope driver ought to do this every time it runs, just before returning control to Guide. The purpose is twofold. If the scope driver was called because the user clicked on "Slew Guide", then Guide will open SLEW_OUT.DAT, read in the encoder positions, convert them to RA/dec, and point the telescope there. The data in SLEW_OUT.DAT is also used when an alignment star has just been added.

    How alignment is handled

    In theory, Guide requires you to find only two alignment stars. (To reduce errors and account for mechanical problems, you will probably wish to add more!) The process is a simple one.

    Suppose Capella (Alpha Aurigae) is visible, and you would like to add it as an alignment star. Fire up Guide and center on Capella (perhaps by using Go to, Star, Bayer/Flamsteed, Auriga, Alpha). Next, hit the "Add Alignment Star" option.

    The scope driver will fire up. If you already have two alignment stars entered, that will be enough for it to slew roughly to the position of Capella, after which you'll have to "fine-tune" the position. (If it's one of the first two stars added, you'll have to slew it yourself, all the way to the target.) Once you have the star centered to your satisfaction, you'll hit a key, and the scope driver will return control to Guide, putting the final scope (x, y) into a file, SLEW_OUT.DAT.

    Guide will then know that the scope position (x, y) corresponds to the alt-az position (p, q). Once iit has two such positions, it can take a guess that

    x = Ap + x0

    y = Bq+y0

    where A, B, x0, and y0 are determined from the (x, y) and (p, q) values of the two stars. In short, Guide will be able to take a "Slew Telescope" command and generate the data in the SLEW.DAT file, so that SCOPE.EXE can actually slew the telescope.

    Mechanical error correction (MEC)

    In reality, the simple two-star alignment procedure described above leaves a lot to be desired. There are a host of mechanical problems that can throw it off; for example, if the scope is off-level by about a degree, one will see pointing errors of about a degree. If the altitude and azimuth axes (for a Dob) or the polar and declination axes (for an equatorial) are not perpendicular to within a degree, one will see pointing errors of about a degree. If the altitude bearings are not perfectly circular, or are even slightly off-center, one will see horrible pointing errors.

    Guide can correct for most of these "modelled" problems simply by using a few more alignment stars. With four stars, it can correct for a non-level telescope; with seven, errors in the perpendicularity of axes can be corrected.

    Given several dozen alignment stars, Guide can compensate for "flexure" errors. Flexure mapping assumes that the telescope has a tendency to flex by a certain (repeatable) amount when pointed at a particular point in the sky. For example, suppose that, when pointed 30 degrees above the horizon to your southeast, your telescope tends to sag by 2.3 arcminutes in altitude and to drift 3.1 arcminutes left in azimuth. If Guide knows about this flexure, it can compensate by aiming 2.3 arcminutes above and 3.1 arcminutes to the right of the target.

    To accomplish this, Guide requires that you enter a few dozen alignment stars. (You could get away with only seven, but then the flexure mapping would probably do more harm than good!) At any point in the sky, Guide will then use three nearby alignment stars to compute the flexure at that point.

    "Flexure", by the way, is used here as shorthand for "repeatable error". Since errors due to elliptical or off-center bearings are repeatable, flexure mapping will correct their effects as well.

    Use of the NGC-Max/Lumicon/MicroGuider family "scope driver"

    So far, the only scope driver written for this system works with the NGC-Max/Lumicon/MicroGuider family of encoders. If you have one of these systems and are interested in testing out Guide's interface with these encoders, first download the latest DOS version of Guide. (The software on the CDs predates the scope driver system.) Then download SCOPE.EXE and put it into your Guide directory.

    Fire up WGUIDE (the 32-bit DOS version of Guide) and enter the Telescope Control menu. Hit Alt-J; this brings up a menu of "test flags", all of which are usually left off. The last flag reads "Scope driver OFF"; click on it to turn "Scope driver ON", and return to the main menu.

    Next, hit Shift-F10. This brings up a dialogue box asking you to "Enter scope system #:" Enter a 3 here. (System 0 is the LX-200, system 1 is the Sky Commander, system 2 was a failed attempt to implement the Dob Driver, and system 3 is the scope driver system currently under discussion.)

    Now enter the scope control menu. As with an LX-200 or Sky Commander, you'll now have to specify the serial port to which your encoders are connected. Do this and then return to the main menu. The two items "Slew Telescope" and "Slew Guide" have been added, just as they would be with the "usual" LX-200 setup.

    However, there is a remaining step: alignment. With the LX-200 or Sky Commander, alignment is built into the hardware, and Guide could immediately start communicating in terms of RA/dec. The encoders are a little simpler, and just provide angles; before you start slewing Guide, you need to provide at least two alignment stars. To do this, point the telescope at a bright object (say, Capella) and hit Shift-F5. The screen will clear and the scope driver program will start up, and will read the encoder positions and store them for use by Guide.

    Repeat this step for another alignment star. The stars should be separated by at least ten degrees in both altitude and azimuth. Once this is done, you should indeed be able to use "Slew Scope" and "Slew Guide" freely.

    (I am, of course, aware that the above procedure is convoluted. It will be simplified soon.)