by Jay Reynolds Freeman
By choice, I don't often mix my profession with my hobby; however, I do work as a programmer, and my career has included everything from microcode on a super up through high-level applications and their user interfaces. I tell you these things by way of introducing and perhaps justifying some extended remarks about Celestron's NexStar software, as perceived by a jaundiced and cynical computer geek.
I should state clearly, that NexStar 8 software mostly works, and is mostly easy to learn. I do have complaints, and I am going to discuss them, but the length of my subsequent remarks should not obscure the bottom line: The software is pretty good. Notwithstanding, its designers seem to have missed a few key points that would make the system more robust, more useful, and more friendly, all for very little extra effort.
First, let's consider the algorithm for finding targets; that is, for driving the motors to get to a particular right ascension and declination. I don't know what the algorithm is, but I do know that it lacks an obvious good feature: It will not accurately find the last reference point -- the last object selected to update the alignment. That is, suppose I am examining epsilon Bootis, and decide to update alignment using that star. Following the instructions, I press buttons, carefully center it, press more buttons, and see a display confirming that the alignment has been changed. Then suppose I tell the telescope to find epsilon Bootis again. The telescope slews away from the star and sneaks back toward it -- that's fine, what it is trying to do is carefully take up slack in the gear train. Unhappily, it doesn't put the star back in the center of the field. It finds it, all right, but the error in finding is comparable to the error in finding any other object I might choose to slew to.
The problem persists even when I am particularly sneaky about aligning. I had best results when I aligned on two stars in the usual way, then went back to each of the two stars in turn and used it to update the alignment, replacing itself as an alignment target. I would watch through the eyepiece carefully, as the NexStar slewed to the star, keep track of which direction it approached from, and when I recentered the star to update the alignment, I made sure to use the keys to move the star in from the same direction that the NexStar itself had chosen. That was an attempt to take slack out of the gears during alignment, the same way the NexStar itself did when finding the star. (Celestron recommends approaching alignment targets from those directions, in a note in the back of the manual, but I hadn't found the note when I improvised this procedure.) I figured that would at least get rid of errors in finding due to gear-train slop, and it did make the NexStar have better luck when asked to find targets near either of the alignment stars, but the errors were still uncomfortably large.
It would almost certainly have been possible to choose a finding algorithm for which the errors diminished in proportion as the new position was close to the last alignment point. In effect, the software merely needs to remember "the gear positions for epsilon Bootis were thus and so", and correct them for the Earth's rotation. It would have been desirable to select such an algorithm, because one of the most common and best ways to use a telescope to find difficult targets -- ones hard to see unless you know *exactly* where to look for them -- is by making small offsets from a known object. Unless the finding algorithm is good at small offsets, that mechanism doesn't work. This poor choice of finding algorithm is the most important failing of the NexStar 8 as a serious telescope, that I have yet encountered.
Second, speaking of small offsets, why doesn't the telescope have a mode where the "arrow buttons" move the telescope north/south/east/west, instead of up/down/right/left? That would help enormously in finding things by small offsets, because none of my charts show which way is up/down/right/left, yet they all show north/south/east/west. There might be a case for not having such a mode if Celestron had done a determined job of implementing a modeless user interface, but they didn't -- the NexStar 8 has more modes than a Swiss Army Knife. So why not another one, particularly one that is very useful?
Third, still on the subject of finding and alignment, there is a very simple omission in the interface design. The telescope can *only* align with targets listed in one or another of the built-in catalogs. You'd think that if I had spent time finding something not in one of those catalogs -- perhaps a comet, or an object from the IC, UGC, MCG, or ESO catalogs (there are plenty bright enough to see with an 8-inch), that I should be able to use its position to update the alignment, if I wished, before going to the next object. The telescope probably already knows the position, because the likely way I found a non-cataloged object was by entering its coordinates and telling the telescope to go there. Yet if I try to update the alignment once such a position has been found, it doesn't work. It doesn't even work if I store the coordinates as a user-defined object. It ought to, in both cases.
Fourth, the telescope does not deal gracefully with gimble lock -- the property of a two-axis pointing system that makes Dobson-mounted telescopes hard to use when pointing near the zenith, and that makes equatorially-mounted telescopes hard to use when pointing near Polaris. Now, gimble lock is a mechanical phenomenon that I do not expect Celestron to be able to solve with software -- it does not surprise me that the NexStar 8 has difficulty dealing with objects that require pointing the OTA at right angles to the bottom of the drive base. But I expect the telescope to do something sensible when faced with this difficulty, and it doesn't. Operating close to gimble lock sometimes results in the telescope not being able to track the object, or tracking the wrong way. What is worse, it sometimes results in a system crash, in which no buttons on the controller do anything, with the only way out being to turn the power off and back on.
There are many possible underlying causes of such behavior. Perhaps the telescope can't send pulses to the drives fast enough to make them swivel at the appropriate rates, and merely refuses to do anything else until it has caught up. Perhaps it is enmeshed in some mathematical conundrum, such as a sequence failing to converge, or an attempt to calculate the arc sine of 1.02. Perhaps it's something else. I don't care, that sort of behavior is inexcusable. Software can calculate that the telescope is close to gimble lock, can predict that the anticipated drive rates are too large, can perform range checks on trigonometric and other arguments before calling the functions that use them, and can deal with out-of-range or indeterminate results when they occur. In every programming job I have ever had, if I had not been able to avoid software crashes due to something as simple as trigonometry, I would have been out of work the next day.
What I might have expected of Celestron, is that NexStars identify potential problems with gimble lock, make the display read "too close to zenith" or "too close to celestial pole" (depending on whether the telescope is in altazimuth or equatorial tracking mode), and stop trying to drive. The software will richly deserve hoots and catcalls from programmers until it behaves sensibly in such simple error conditions.
This particular problem is an example of failing a more general system design principle: "The controls shouldn't be able to get you into any situation they can't get you out of." Perhaps that should be "The system should protect users from their folly." To be fair, that principle is difficult to implement -- cars and airplanes can be made to crash all too easily by improper use of the controls, and I don't just mean their software. But telescopes? Please!
Fifth, I am not done complaining about alignment. Suppose you turn on the telescope, bypass the alignment, and start looking at things just by using the controller arrow buttons. Perhaps you are looking at the skyline while waiting for the sun to set. Later you decide to try a celestial object, and the telescope quite properly reminds you "no alignment" -- it cannot do what you ask.
What you are supposed to do in that case is turn the power off and back on, which brings up the menus for alignment. That's not a terribly bad solution. Many gadgets require a power reset at times. Yet the NexStar controller has an "align" button. If the system is not already aligned, why doesn't pressing the "align" button bring up menus for doing so? It could be confusing to a beginning user, who might think, "Gee, the controller says 'no alignment', and when I press the 'align' button, it still says 'no alignment' -- something must be broken."
This is an example of failing another more general system design principle: "The controls should always do something predictable and useful." The "align" button should help you do an alignment when you need one.
Sixth, still on alignment: In the June, 2001 Sky & Telescope, Gary Seronik comments that what really counts in a NexStar alignment is not getting the telescope level, but pointing it at right angles to the azimuth axis. If so, that's fine with me, but why doesn't Celestron just paint alignment marks on the fork arm and say "Align the marks" as part of the set-up procedure? That would be lots easier and more accurate than trying to guess which way is horizontal.
Seventh, there is a menu item for setting the date and time. As far as I can tell, it is used when you have aligned by the two-star method, and then decide you want to find a planet. The system has no way to tell where on the celestial sphere the planets are unless it knows the date and time, and the menu item lets you tell it.
Fine, but suppose you have aligned by the fancier method, and so have already provided the date and time. The menu item is still there, but as far as I can tell, it does absolutely nothing. I have tried to use it, providing a time a few hours different from the time the system already knows, but after doing so, when I try to find, say, Vega, the system still thinks that Vega is where it was before I provided the different time -- it does not go slewing through several hours worth of right ascension to look for Vega in a different part of the sky.
I don't have a big problem with not being able to change the date and time, but an inoperative menu item is confusing. A user might think, "Gee, I tried to change the date and time, and it didn't make any difference -- something must be broken."
The general principle here is "When the system can't do what you want, it shouldn't just sit there, it should tell you." The NexStar 8 does a good job advising when objects are below the horizon, and a similar "can't do that now" message would fix the problem with the date-and-time menu. Even better would be to have the menu item not appear on the scrolling list when it can't do any good -- why put something on the menu if it isn't really available?
Eighth, the telescope occasionally hangs -- no button pushes do anything, and there is no recovery short of cycling the power -- even when it is not near gimble lock. The problem has occurred for me most often when interrupting a slew to get the instrument to do something else. That kind of thing shouldn't happen, period. It is perfectly reasonable practice to design software which *must* check for a button-push every so often, and to make certain button pushes override anything else the system may have been trying to do. With such design, only a hardware failure can hang the system completely.
Ninth, there are errors in the databases. I found three that mattered in my first three nights' viewing. M2 and NGC 4666 had the signs of their declinations wrong, and M10 was shown at the position of NGC 6253, at more than 50 degrees south declination -- but M10 is not NGC 6253, it is one NGC catalog number away -- NGC 6254. I suspect these are human errors made during data-entry. That error rate is about one percent, which seems small, but errors like this will be very confusing to beginners, and surely it makes sense to double-check something that is going to be burned into ROM and distributed world-wide. There is perhaps a relevant general principle: "Writers of application software should be familiar with the application domain." I suspect that most amateur astronomers would have become suspicious if a "Messier object" turned up in central Ara. Yet I must say "perhaps", because there are all too many amateur astronomers who have never even seen M10, much less have any idea what constellation it is in.
Tenth, one possible technical explanation for these problems deserves to be addressed. Perhaps the amount of memory available for the NexStar control program was small enough to limit the ability of programmers to do their job. Perhaps Celestron decided not to spend money on more capacious memory chips. If so, then the programmers who created this code are not to blame. Celestron is to blame, though, for having made a bad choice in allocation of resources. The current on-board memory wastes lots of memory -- probably at least 50,000 bytes -- with a catalog of over 10,000 stars which are not identified. This catalog is only useful if you download and print out more than 200 pages of text data from Celestron's internet web site, and even then, it's not good for much. I would gladly give up some or all of that catlog in return for software that worked better, and I am sure that 50,000 bytes more for program memory could make a big difference.
I will close this part of my report as I began it, with the comment that nerd's-eye view notwithstanding, the NexStar 8 software is pretty good. It just makes my teeth itch to realize that for only a little more effort, Celestron could have put a professional software product in the NexStar line of telescopes.
| Prev | I | II | III | IV | V | VI | VII | VIII | Next |