Rarely-asked questions for Guide users

There is an FAQ for current Guide users on this site. This list is the opposite of an FAQ; the questions have sometimes been asked only once. But the answers may be of wider interest, and/or may be asked again.

Note that many of the questions apply only to problems encountered with Guides 1.0 through 8.0. Most are fixed in the current version, Guide 9.0.

Getting photometric extinction and sky brightness level data from Guide: As you may have noticed, if you center on a given part of the sky in Guide and ask for "Quick Info", Guide shows the current limiting visual magnitude for that part of the sky. This takes into account relative humidity, altitude, temperature, sky brightness contributions from the Sun and Moon, and more, using a method provided by Brad Schaefer in the May 1998 issue of Sky & Telescope.

As part of that process, the extinction coefficients and sky brightness levels, in five photometric bands (U, B, V, R, and I) are computed. This data will be essentially useless, unless you're doing photometry, when it could be a godsend. If you edit the text file GUIDE.DAT, in your Guide directory, and add this line:


then when you ask for Quick Info, the sky brightness and extinction coefficient, in each band, will be shown.

Swapping the azimuth to have South=0 instead of North=0: By default, Guide measures azimuth using the convention that North=0 degrees, East=90, South=180, West=270. There is an alternative, rarely-used convention that sets South=0, West=90, North=180, East=270.

To switch to this convention, edit the text file startup.mar and look for this line:

30 az convn 0

and change it to read:

30 az convn 1

In Guide 1.0, there was a menu option available to handle this. Jean Meeus, in his Astronomical Algorithms, discusses the fact that there are two standards for measuring azimuth: one with north=0, one with south=0. Guide 1.0 defaulted to south=0.

The problem was that almost no one else had heard of this convention. Most people just assumed Guide 1.0 was buggy, even though there was a way to switch back to north=0. In Guide 2.0, the north=0 convention was made the default and the menu option was removed. But a sufficiently determined person can still set the south=0 system, as described above.

When Guide finds a conjunction, is it a conjunction in RA, ecliptic longitude, or the closest approach? Depending on what source is used, a "conjunction" has been known to mean any of these three. It would seem, though, that most people would really want to know when the two objects are closest to one another, and this is the definition used in Guide. The only reason I could see for saying a conjunction occurs when the RAs or ecliptic longitudes are equal would be to simplify the math.

How can I set a grid, or tick, or side label spacing that is not one of the spacings given in the Spacing dialogue? Basically, you can't. But there is a clumsy sort of workaround that lets you change the spacings given in the dialogue box. Edit the file STRINGS.DAT and you will find, starting at line 46, the text used in the Spacing dialogue box:

    1'        2s
    2'        5s
    5'       10s
   10'       30s
   20'        1m
   30'        2m
    1z        5m
    2z       10m
    5z       30m
   10z        1h
   30z        2h

(The 'z' is converted to a degree symbol in the dialogue box.) You can change these values, as long as they remain in ascending order. The most common change is to replace '5m' with '4m'. This can be useful in making markings that match those on Uranometria or Millennium Star Atlas.

Why isn't the Help system more "Windows-like"? When Guide was ported to Windows, I considered using the built-in Windows help system. But it has so many disadvantages that I had to shelve the idea.

  • First, Guide dynamically "builds" new Help sections whenever you ask for "more info", or build a table, or enter several other parts of the program. Windows Help doesn't allow such things to happen; you build one Help file and you're stuck with it.
  • Second, Windows Help is Windows-specific; you can't use it in any other operating system.
  • Third, Windows Help is not very friendly to the idea of switching to other languages. Sales of Guide outside English-speaking countries are very important.
  • When I get a list of comets, there are sometimes some asteroids mixed in. Why? Guide makes comet lists as part of four points in the program ("Extras... Edit Comet data", "Tables... Current Comets", "Help... Quick Info", and "Go To... Comet".) And at all four points, you may see some asteroids in the list.

    This happens if you have used the "Add MPC comets/asteroids" option. When Guide was first written, the asteroid database was fixed, and you could only add comets. There is still one list of user-added solar system objects, COMETS.DAT, and anything you add to Guide ends up in that list.

    Obviously, at some point, I'd like to fix this so that comets and asteroids are more logically distinct. It's a sufficiently messy programming task that I've delayed it for some time now.

    What are the 'codes' of the colors used in transit maps, such as for the transit of Mercury on 15 November 1999? Guide uses a rather complex set of colors on its eclipse/occultation/transit charts (hereafter, we'll just call them "eclipse" charts.) The color used for a given point on a chart tells you what the event will look like at maximum "eclipse".

    If, at maximum "eclipse", the nearer object is totally surrounded by the farther object, the light green is used. (This happens during an annular eclipse, or when Venus or Mercury transit the sun and are fully on the disk of the sun.)

    If, at maximum "eclipse", the nearer object totally blocks out the farther object, a light gray is used. (This happens during a total solar eclipse, or when a star is occulted, for example.)

    If the event is an occultation of a star, there can be no "partial eclipse", and you get only the light gray band that tells you where the eclipse is total. But otherwise, there will usually be places where the nearer object partially "eclipses" the farther one. These areas are shown in ten bands, running from "0% eclipsed" to "10% eclipsed", "20% eclipsed", and so on, up to "100% eclipsed".

    The bands that indicate a partial event are shades of gray if the maximum "eclipse" occurs with the sun well below the horizon. These bands are shown in shades of light blue if the event occurs with the sun above the horizon. (For example, solar eclipses always show up with the partial eclipse zone in shades of light blue... after all, to see a solar eclipse, the sun has to be above the horizon!)

    The shades of blue vs. gray for partial eclipses are helpful for events such as lunar and asteroid occultations. If you see a bluish shade, you know the event will occur with the sun above the horizon, and you probably won't really see it (unless it's something like the moon occulting Venus.) If it's a gray shade, you probably _will_ be able to see it; if it's in between, the event will occur during twilight, and it may not be easy to see.

    Q: When I try to run the Charon astrometry software, I get a error: "Stub exec failed, dos4gw.exe: No such file or directory".

    A: This is the result of a blunder on my part, but is fairly easy to fix.

    DOS4GW.EXE is a file used by Charon and the DOS version of Guide; it is a DOS extender, allowing these programs to break the old 640K barrier that used to be such a problem in DOS. You can find it in the WATCOM directory of the Guide CD-ROM. Copy it over to the Guide directory on your hard drive, and the 'stub exec' will no longer fail.

    Once upon a time, Guide's installation process didn't ask you which flavor of Guide you wanted (Win 3.1, DOS, Win 95/98/NT). It just copied all three over, all the time. The result was that DOS4GW.EXE would always be present, as part of DOS Guide. Obviously, that's no longer the case, and this problem can crop up.

    Q: When I try to use Guide to slew my Gemini telescope, I get an error message.

    A: Turns out that, while the Gemini mount is indeed LX-200 compatible, its timing is not always as fast as Guide would like. Guide will issue certain commands and assume a reply within 100 milliseconds; when it doesn't get it, it "gives up" and shows an error message. This is plenty of time for Meade scopes; the Gemini is a little slower. But you can persuade Guide to wait a little longer by editing the file startup.mar in Guide's directory, and looking for a line such as this:

     49 lx delay 15 100 9600 0 2400 

    The second number, 100, indicates that Guide should wait 100 milliseconds for a reply to an LX-200 command. Set this to be, say, 300 milliseconds, and the computer and scope may have enough time to get the data through. For the three LX-200 commands involved in slewing the telescope ("set RA", "set dec", and "slew"), this will mean a total wait of .9 seconds. (A longer delay may be necessary; a little experimenting may be involved here.)

    Incidentally, should you be curious as to what the other data in startup.mar mean, there is mostly complete documentation of the .MAR format available. (In truth, most of it controls items best set via Guide's user interface.)

    Q: On the screen, all of Saturn's moons appear as symbols with names attached. In printouts, Titan vanishes. (Or similar problems with satellites of other planets.)

    A: The problem was fixed in an update to Guide 8.0 (and doesn't exist in Guide 9.0). You can click here to visit the update page.

    The problem involves objects that are almost large enough to be shown as a disk (instead of as a symbol plus name). In some cases, when printing them, Guide decides there are sufficient pixels (at the higher resolution used when printing) to justify turning an "almost disk-like" object into a disk-like one. You may even find a very tiny disk plotted on the chart in the correct location for Titan.

    The general idea had some merit, but in practice, the disk can be so small as to be invisible. So Guide now follows the rule that if a satellite is shown as a symbol plus name on-screen, it will show up that way on the printout as well.

    Q: I can't install DOS Guide 8.

    A: I learned of this a couple of months after Guide 8 was released. If you've actually got Windows on the machine, you can run the setup utility and tell Guide to install both the Windows and the DOS software at the same time. Once you've done that, you can start up in DOS and run DOS Guide without trouble. This also lets you fire up Windows Guide on an as-needed basis.

    The problem comes up when you're running on a DOS-only box, and therefore can't run setup. Instead, you have to run install, the DOS version of setup. Then you find that install doesn't work.

    The way around this is to click here to download an install.com in which this bug is fixed. Put it on your hard drive, and run it with a '-c(drive letter)' option to tell it where the CD-ROM is. For example, if the CD is hooked up as drive d:, you would use

    install -cd

    so that INSTALL would know where to look for files.

    Once you have DOS Guide up and running, I would recommend downloading the current version of the software. A while back, I made many improvements to the DOS software. It doesn't get it nearly in line with the Windows version, but at least some of the improvements made in Windows are now reflected in the DOS software, too.

    Q: When I attempt to run DOS Guide, I get scrambled video on the screen.

    A: This is all too common a problem. DOS support is not a big priority for most video card manufacturers.

    The first thing to try is to run DOS Guide with a '-vv' switch:

    dosguide -vv

    This forces it to start in "standard VGA" mode, 16 colors, 640 by 480 pixels. It's not very attractive, but you can run Guide in this manner, and this particular mode is the highest that is truly "standard". All the higher-resolution, higher-color modes are implemented differently on different video cards, which is why DOS Guide may succeed on one and fail on the next.

    The next thing you can do is to try all five of the higher-resolution modes supported by DOS Guide. Depending on your card, anywhere from zero to all five may work. The success or failure of any one of them tells you virtually nothing about the others, so don't give up if the first one fails. The commands are:

    dosguide -vV (256 colors, 640 x 480)
    dosguide -vs (16 colors, 800 x 600)
    dosguide -vS (256 colors, 800 x 600)
    dosguide -vx (16 colors, 1024 x 768)
    dosguide -vX (256 colors, 1024 x 768)

    Sometimes, you can persuade DOS Guide to work in a given mode by adding a '-w' switch on the command line. For example:

    dosguide -vV -w (256 colors, 640 x 480)

    This causes DOS Guide to initialize the video card in a slightly different manner, one that sometimes works where the default one fails. (And sometimes failing where the default method works! Video cards are weird things from the viewpoint of DOS software... one reason the availability of decent video drivers in other OSes is so useful.)

    Incidentally, users of truly antique computers with EGA cards (predecessor to VGA!) can use the following:

    dosguide -ve (16 colors, 640 x 350)

    But be warned that computers that old frequently don't support CD-ROM drives or have enough computational power to get current versions of DOS Guide to run.

    Q: Variable stars and some deep-sky objects vanish at fields of view wider than seven degrees. Can this be fixed?

    A: By default, at wider fields of view, Guide switches to a dataset that contains only NGC and IC objects. All variable stars and most DSOs are omitted. It does this for reasons of speed: handling all those objects in a truly wide field of view bogs the program down a bit.

    However, you may have some purpose in mind where you're willing to tolerate the slowdown, if only for the moment. To change Guide's behavior, edit the file startup.mar and look for this line:

    75 panning  0.500000 7.000000 0

    The middle "7.000000" number is the one you want to change; it sets the field of view where Guide switches between the detailed data and the "NGC/IC only" data. Set that number to, say, 120, and Guide would only use the less-detailed data at fields of view greater than 120 degrees (usually, level 1 only.)

    Q: I want to re-install Guide, or move it to another machine. What file(s) containing my personal settings (lat/lon, time zone, etc.) should I keep from the previous install?

    A: I would recommend that once you have Guide set up the way you want (data shown, location, etc.), you should go into File... Save Mark, and save a mark file called "Personal Defaults". This can be useful if you find that Guide has gotten in some state you dislike. Perhaps you've turned grids on, or some dataset, or changed the color of something, and can't figure out how to undo it. In such cases, it can be very helpful to simply click on File... Load Mark, then on "Personal Defaults" again.

    (Alternatively, you can recover from minor disasters using the File... Load Mark... Factory Defaults option. But this will cause Guide to reset its location to Bowdoinham, Maine, its time zone to Eastern US, and so on. In short, it may reset more than you would actually like.)

    You can then copy or back up the file personal.mar from your Guide folder, and use this in a re-installed Guide. If you've not made a personal.mar file, I'd recommend that you make use of the file startup.mar. Copy this to the new name personal.mar in the new Guide folder.

    Other files of importance are toolbar.dat (contains your toolbar settings), maximum.dat (fonts and screen positions for dialog boxes), overlays.nam (display of user-added overlays, constellation lines and labels), *.uov (your user overlays), and *.tdf (user-added dataset files.)

    Be warned that if you're doing all this because Guide appears to be corrupted in some way, there's a danger that the "corruption" in question resides in one of these files. If so, I'd recommend reinstalling (including the updated software from the Web site), then copying in a few of the above files. That way, you can narrow down which file is causing the problem. (And then, please send me the file in question!)