ASTRONOMY SOFTWARE: Still in its infancy?

The author wishes he could satisfactorily use his
laptop PC with his telescope, but isn't so sure
that this is really very often possible...

---

This spring and summer [2006], I've had two protracted battles with my PC, and my telescope. I was hoping that, by now -- more than a quarter century after the first primitive home computing experiments -- the personal computer had grown into a reliable, transparent, easily- controllable and conveniently customizable tool for amateur astronomy. But, the reality (at least for me) is that we are still sadly far from this goal. The genre of astro-computing by hobbyists is lagging the world of mature tools used in the office, for financial planning, and for communications. When will the promise of the medium be fulfilled for amateur astronomers?

---

Preface

This essay is intended to be a general analysis and critique of the software developed for observing and telescope control. It is a long and detailed article: not intended for superficial readers with short attention spans, but rather as a thorough discussion of the topic. Unfortunately, we are now in a litigious world where criticism is taken as slander, invective, and unfair sniping: in my own professional field -- music teaching -- a Canadian company producing educational software has repeatedly threatened a legitimate academic researcher with lawsuits, and has succeeded in shutting down his website that contained a lengthy review of software that the analyst found problematical. So, in the article to follow, I am refraining from any specific reference to program titles or developers, and from giving clues to the exact identify of software that has driven me 'up the wall' with frustration. At the very least, I am not anxious for what would necessarily be one-sided criticism by a single individual (me) to turn up in any web search for information about a specific program. Let the developers learn and grow and improve their software, but not be forced to defend it against criticism that they may personally consider pathological!

It can be argued that now computers and software are unbelievably complicated, maybe beyond the scope of the state of the art of operating systems, and the economy of commercial software development of niche products: in today's world of graphical interface OS's, open standards, and a plethora of peripherals, it may be argued that PC's are starting to behave like people do: they seem to be erratic, unpredictable, 'neurotic'. No two systems, even with similar hardware and operating system, act EXACTLY ALIKE. No two users interact the same way with GUI's and program API's. Using a PC has begun to require new, unique techno-social skills, like human encounters. So, perforce: no one single individual is ever precisely right, with absolutely definitive opinions about how software should work, and what its problems might be. Developers can only learn from a wide experience with a large user base, not the anomalous experiences of one or two persons.

---

The Promise

We have all read the advertisements. They all tend to promise at least some of the following (quotes paraphrased from what I've read in magazines, on websites, in reviews, and in promotional announcements on the newsgroup sci.astro.amateur):

• 'Explore without limit 700 million light years of space and view 2,500,000 stars and 40,000+ deep sky objects'
• 'The broad functionality of a suite of integrated functions to make your observing sessions more productive, at a price you can't believe!'
• 'The extraordinary precision of our products successfully combine science and hobby, and help you achieve your most lofty goals.'
• 'Chock full of extensive databases, accessed at incredible speeds on a dazzling graphical display.'
• 'Immerse yourself in the wonders of the universe, with our elegant, easy-to-use interface...easier to select and filter objects for viewing.'
• 'Amazing accuracy, pin-point precision of telescope control for hunting down those elusive objects.'
• 'Universal binary compatible; even runs on older PCs'
• 'Unsurpassed star chart generation, a tremendous leap forward...'
• 'The premier desktop astronomy program for Windows...to the outer reaches of the Universe and back.'
• 'User friendly features consolidate the popular tools on one screen making it easy to navigate.'
• 'For observers at any level, to unlock the dazzling night sky: very easy to learn and use. It's simple, yet powerful...'

On and on. There seems to be no limit to the hyperbole, the nearly gushing and ecstatic poetry of such blandishments. (As a person who minored in advertising at a university, more than four decades ago, I blush. My advertising professors were always reining in students who turned in such purple prose.)

And the enthusiasm is not limited to commercial plugs for products. Reviews in magazines, and even in amateur posts and website articles, often convey unbridled enthusiasm, matching the color and vitality of the advertisements, and often merely rehashing them in nearly-literal litanies of descriptions of the functions, as seen through the eyes of the developers. Such reviews seldom seem balanced, containing honest and thorough criticism and pointing out deficiencies. One might be forgiven for imagining that at least some of them are mere quid pro quo turns of phrase, as payment for free "review copies". And, are many of the critics really qualified deep-sky observers? Or, are they dabblers, dilettante enthusiasts who spend more time contemplating astronomy in front of a CRT or LCD screen, than at an eyepiece?

At any rate, the potential customer is repeatedly assured that:

• The software will function perfectly on her computer, be it new and powerful, old or gutless;
• It will be easy and intuitive, self-contained and requiring no further adaptors, modules, or dongles to adapt successfully to any telescope;
• No prior skills are necessary, as the program will walk the user through its "simple yet powerful" interface without pain or intellectual struggling;
• Telescope control, if offered, will be PERFECT. It will be precise, with remarkable accuracy. Faint, elusive objects -- hitherto unseen -- will be a snap to locate, center, and confirm.
• Databases are all-inclusive. Every conceivable object known to humankind will be contained, intelligently ordered and easily retrieved.
• Customizing options will be virtually unlimited. Screen displays will be elegant and informative, and chart printing will be accurate, legible, and swift, on any conceivable user's printer.
• Such a software purchase will be the ultimate resource, the all-encompassing central storehouse and manager of astronomical data from the user's own drives as well as the Internet, all rapidly accessed by a mere click of the mouse.

What have we to lose? Usually, no more than (say) $45 to $250, depending on the entrepreneur and his/her corporate pretension. At last: ALL THE TOOLS YOU NEED, in one place, at one time, with one credit card purchase.

---

The Reality

Have any of my gentle readers, eagerly anticipating the rewards suggested above, faced the perturbing, frustrating letdowns I've continually experienced, when the stuff is finally, actually, installed on one's home computer? (In some cases, indeed, installation seem almost impossible to accomplish, given the errors and glitches that occur on various systems, unanticipated by the developers.)

Here are merely some of the sad realities:

Note: items in the following list are hyperlinked to my specific comments, below. (After you read each comment, if you press your browser "BACK" key, you'll return to the list.)

• 1. Installation fails miserably on a given OS, requiring fairly advanced-level disk maintenance, program folder and file removal: yes, even Registry editing or "system restoration".

• 2. One immediately discovers that the display adaptor is inadequate, obsolete, and unanticipated by the program author: the fabulous "realistic" sky view shown in the ads is instead ugly, primitive, slow to register, or even unintelligible on our particular computer monitor.

• 3. We discover that we own the ONE scope that the software WILL NOT SUPPORT PROPERLY, not mentioned anywhere in the documentation or the ads encountered when we evaluated the product for purchase.

• 4. Or, something obscure is required to run our software or scope, not mentioned on the box or in the ad, and unknown to our dealer and salesman.

• 5. "Tinkertoy"^[TM] software packages done with Visual Basic often are inefficient, and have problems.

• 6. Execution is S-L-O-W! (We thought that the days of the 286 were long past.)

• 7. The program has errors and bugs that turn up constantly. Things do not work reliably and repeatably, and perhaps the software suddenly terminates with a runtime error at the least provocation.

• 8. Talk about bloat! While we bought the program to create a sky chart, we find that it's next to impossible to do this simple thing with ease, because there are hundreds of sub-functions, menu options, and setup preferences ("Let's see: maybe I can find that setting under the 'Periastron calculation' tab; or is it under the 'Heliocentric axis orientation' menu?")

• 9. Upgrade Hell: Before the program can be used, we have to download a 50-megabyte service pack and a 33 megabyte update patch from the company's website: hard, if not impossible, to do on a dialup connection.

• 10. Data Sets are riddled with mistakes -- and so are "observing plans" made from them, to be used by certain types of telescope control programs.

• 11. Missing Data: Those "40,000+ deep space objects" promised on the box and in the web page ad don't seem to contain the IC, NGC, PK, or Sharpless objects one wants to find, plot, and observe. These objects are common, and known to every good observer: but NOT, apparently, to the program's code writers (who spend their time at the PC, not reading astronomy literature and observing.)

• 12. Program search functions are perversely inadequate -- even useless: Type in ANY commonly accepted syntax, number, name, or description of even the best known objects, and the progam informs you that "the object is not found". Why? What MAGIC technique do you have to learn to intuit the database format used, which is never in compliance with standard charts, observing guides, and astronomy articles?

• 13. Numerical Order is Illogical: Some software has used electronically-gathered object data sets that have NOT been properly ordered into any sensible format that is immediately understood, or used, by humans!

• 14. Connectivity Problems: There's "many a slip 'twixt the cup and the lip"... or, the telescope and computer.

• 15. Plotting & Control Errors: Those who try to point their scopes at the objects shown on the display screen immediately discover systematic errors in the software calculations that send the scope to ANOTHER position in the sky: perhaps so far away that the object is not in the field of the lowest-power eyepiece.

• 16. "Help Me, PLEASE!" Have a problem? You may find that program documentation is inadequate: sketchy, vague, generalized, incomplete, or fragmented. You consult the developer's website and its "Knowledge Base", and get lost in a jungle of bits and pieces of aphoristic and cryptic factoids about various versions of the software that you haven't purchased.

•  17. Night Mode still can wreck your dark adaptation and almost BLIND you!

• 18. The User Is At Fault. Have the temerity to contact the developer by email, or on a program-sponsored forum? You will be answered by a barrage of defensive remarks. Seldom will you get a resolution to your problem; no matter what your own level of PC expertise may be, you'll be told you are an uninformed newbie who lacks skills to set up and use your machine, and their software, correctly.

Below, I give my detailed remarks on each of these problems, as numbered above. The items in the list, above, are hyperlinked to my specific comments, below. (After you read each comment, if you press your browser "BACK" key, after a certain amount of delay for the file to reload, you'll return to the list.)

No. 1: The Installation Fails.

A program I purchased recently behaved badly and unpredicatably on my best computer: my newest machine, only a few months old with every bell and whistle imaginable, intended by me to be the portable PC to be used in the field with my GOTO scope. Since the system was running with XP Home, latest updates and service pack, and with regular anti-virus and spyware checks, and since it also operated correctly and VERY reliably with the 'standard' software (browsers, word processing, graphics editing programs) that were previously set up to complement the astronomy software I intended to use, I had confidence in the machine and its OS, drivers, and setup.

So, a program promoted as a fabulous, complete package of astronomy tools -- charting; omniscient database, spreadsheet and object search functionality; telescope controls; and logging capabilities -- had attracted my attention, as it would seem to fulfill a number of needs in the field, away from my books and the Internet. I expected to be able to use it for finding every "observable" galaxy, nebula, cluster, and stellar object of 15th magnitude and brighter, and to be able to see an accurate chart, as well as a thumbnail sky photo along with pertinent data and descriptions to confirm my observations. Finally, telescope control would align my Celestron NexStar GPS 11 right on the object. Why, I would scarcely need anything else as a reference: surely, no more need for printed star charts, observing guides, object lists, or other astronomy programs. Too good to be true? Sadly, (in my experience), apparently, yes.

Before I could even properly evaluate the program, I encountered problems. Certain functions -- more on this below -- were unreliable, unpredictable, and non-functioning. One -- which was supposed to pass data into an external star chart program -- locked up the program altogether, every time I tried it (even though that external program ran fine on its own.) I decided to see if there was an interaction problem in the complex relationships of all the executable files in the program, the system drivers and peripherals, and the OS. The best way to do this was to install the program on different hardware.

And so, I did. I chose, first, a computer that most closely resembled my intended unit, a desktop that ran XP Pro (Service Pack 2, with all updates) with a huge amount of system RAM, no less than a full gigabyte. Unfortunately, the CPU speed of this older machine was slower than my new laptop, and indeed the program was S-L-O-W. But, in addition to this, it was even less reliable. Functions were hit-and-miss, sometimes working, sometimes not. Screen display objects seemed to vanish when needed. And, now, the program ALWAYS closed with a "runtime error": truly inexcusable, and almost assuredly a problem with the program's internal code.

So, I tried to install it on another machine. On a faster system (though using the older Windows ME OS) it too had the "runtime error" problem on program termination. The response of the author to a comment in his user forum? It was to condemn Windows ME as "junk". I was told not to even attempt to use it on this OS; yet, the same author's OWN program website states, specifically, that it "works on any 32 bit Windows operating system including 98/ME/NT/2000/XP/2003." But, he elaborated on his forum, it would work much better on the older Windows 98SE.

I had one of those systems ready to go: in fact, one of my best "boxes", a Pentium III with a half-gig of RAM on an Intel motherboard, a rock-stable computer that I used in my office for years and years of reliable service for doing audio digitizing. I tried to install the program on that old monster...

I say "tried". What happened was a series of almost comical events that I could not have made up, if I tried. I first checked the hard drive with SCANDISK, and looked at its capacity (at least 4G free space.) So far, so good. Then I started the installation procedure, accepting ALL the program's default paths. Files started flying from the CD-ROM disk onto my hard drive, and I left the office for a few minutes to do something else.

When I returned -- and remember, I had installed it before on three other machines! -- I beheld the following situation: the CRT display was dead black. The hard drive light showed no activity. The keyboard and mouse were unresponsive. Apparently, the system had dropped out of Windows, and hard-locked without even a display cursor, totally dead to the world. I had no choice but to do a cold reboot. After the interminable SCANDISK process, Windows started. I found no icon for the program on my desktop, but the folders were there, in proper order, on the hard drive: and, apparently, ALL files had been copied. I clicked on the main executable, but got immediately -- instead of the program splash screen -- an error dialogue box that said, ominously:

Component 'Actbar2.ocx' or one of its dependencies not correctly registered; a file is missing or is invalid'

followed by a series of cryptic HEX addresses that, of course, are irrelevant information as far as the end-user is concerned.

I had to chuckle out loud at a peculiar occurrence in the installation process when I attempted to reinstall the software in the older version of Windows. On the "front page", the program title is given, in large italicized type: "XXXXX Astronomy Software"; below this is a fancy splash-screen logo image. This was displayed correctly during the installation in XP; but on the attempt to set it up on a W98SE system -- even after a complete cold and clean system and OS reboot -- oddly, the word Software was displayed as So  tware, the "f" being missing! I must admit that in all my years of using programs, this was a first! (This odd anomaly was completely repeatable on that W98SE machine, and occurred each time I started the installer. I was so stunned by this snafu that I took the time to make a screen capture, at left, which I have totally disguised in size and color, though retaining the "missing f".) I should have intuited that something was wrong, for as it turned out, this installation seemed doomed to fail totally. I tried to reinstall OVER the previous existing setup locale; when that failed, also by uninstalling and then reinstalling it. But, various bits and pieces of bad files and Registry settings were left behind, making another installation nonfunctional, and requiring me to do extensive manual editing and tracking down and eliminating stuff from my hard drive that would prevent the program from ever being properly reinstalled again.

And this was on the very version of the OS that the program author insisted would give much more reliable results than "lousy Windows ME"!

To be certain I wasn't just getting an anomalous result on one W98SE system, I went to another office and used a second machine with that version of Windows. This time, the installer would not work, giving an error and terminating.

So, FIVE installs. Five poor results, ranging from 'somewhat unreliable' to 'totally nonfunctioning' to 'will not install'.

In one such case, a program author actually said (blandly, and candidly) words to this effect: "You surely cannot hold me responsible for the bugs of the licensed installation program that I purchased to install my software?" For he was aware that his installation process could and would fail under certain conditions, and managed to "live" with that, stubbornly compartmentalizing himself and making excuses for what he insisted were not his problem. Yet, to the end user, it IS the problem of the program developer, even if the bug is in a program module he purchased from somebody else, to use in part of his software package. The end user, faced with some kind of massive failure to deliver the program's functionality, is not satisfied by such a reply from the putative 'author': "hold somebody ELSE responsible, not me." For, in today's complicated software packages, often MUCH of the total code on the disk is written by somebody or some entity other than the "program author". Various "engines" and "modules" may have been developed -- say -- by Microsoft, Borland, Intellishield, or other companies, and integrated into the software. Bugs and interactive-incompatibilities multiply this way, prodigiously. (There really is very little excuse for a major bug in the installation process, the user's first exposure to the software, setting up the first obstacles and frustration and spoiling one's attitude toward the future of the process.)

So, authors: test, and re-test, the installation. This is where you need the largest effort of investigation, particularly if your program is complex and involves cross-developer components.

No. 2: The Display Adaptor Is Inadequate.

Last year I bought a nice new telescope, and was given a fancy "introductory" version of a highly regarded star chart/planetarium program, one that had received nothing but rave reviews, some analysts regarding it as the "state of the art" and the currently-indispensible, universal computing resource for amateur astronomers. I was eager to try it out.

What happened was a clumsy series of snafus, since my desktop PC's graphics card did not have some sort of recent Open GL capability. Don't ask me what the inadequacy was; I did not write down the cryptic gibberish that appeared momentarily in an error message box. But the program somehow managed to install -- after an interminable series of file copying and folder arrangement processes that seemed to take the better part of an hour, along with Internet-registering just to enable the darned thing to initialize and start up.

What appeared on my CRT was, however, a useless mess. I could see only a tiny part of the proper desktop of the program, as it refused petulantly to switch to a display resolution mode that my graphics card WAS capable of using with other software. I could not use the program, even to test-drive it, for I simply could not get to the radio buttons to activate menus and functions. They were "over there", in another imaginary dimension, about a half-foot "away" from the right and left sides of my monitor. I seem to recall that it was necessary to use the Windows Task Manager to close the program; and I can tell you that not a minute went by, before I had opened the Control Panel to remove the software. Useless.

About a year later I tried again, with a new version of the program, attempting to install it another computer where I do most of my observing session planning: a somewhat simpler machine than my big office system, but within the alleged ratings according to the specifications on the software box. But I discovered in short order that while the outside package said that the program was supplied on "CD-ROM disks", it was actually shipped with DVD disks! My computer only had a CD-ROM drive, though I got past that hurdle by mounting a DVD drive on my network, and installing from there. The process was now very slow, the data trickling at my network's speed; but I persisted and finished transferring all the data in about an hour. All seemed to have gone well, and the installation appeared to conclude satisfactorily. But when I tried to open the program, it informed me THAT THE VIDEO CARD WAS INADEQUATE and required updating. Sadly, the machine WAS indeed using the last available update for its onboard video system. Why didn't the program CHECK FIRST, before installing itself and wasting my time? It is a very simple process to include a check of the video card in the program's installer.

With nowhere to go, I no recourse but to remove the software from the machine, and return it to the dealer, who was stunned by the difference in the medium of the disks, compared to the outside package's erroneous statement: obviously the product had been changed but the company hadn't bothered to reprint the package -- or at the very least to add a sticker -- and to alter its advertisements and documentation.

I talked recently to an employee of the same company that makes the program; he uses it every day to demonstrate it to customers, but had noticed some of the same problems I had experienced. He expressed his own disappointment with the intellectual shortcomings of the program, saying (in effect) that it "looked good" but lacked necessary object data and functions that would be needed by a real, skilled, experienced astronomical observer. And, apparently, it lacked the proper testing required to make it install and work successfully on a wide variety of expected gear in the potential user base.

No. 3: YOUR scope is not supported.

Bah! I had paid more than $150 for a "professional" version of a recent planetarium/scope control program, on the advice of a fairly well-informed, honest, and trustworthy salesman (whose only lack of specific knowledge, here, was that he happened to own another model scope and mount, different from mine.) I was assured that this program would run my Celestron NexStar GPS 11 telescope; point to objects; and accurately sync up its star chart display with the telescope position. He said that he typically achieved an accuracy of positioning that placed objects very near the center of the eyepiece field (or in the narrower field of his CCD imager.) I could do that, too, especially with the aid of the invaluable "Sync" function, which -- he explained -- could correct for systematic and algorithmic errors and re-calibrate my scope position in a localized region of the sky for even closer control precision.

Was this true? NO! For, as it turned out, the program did not offer "Sync" for exactly ONE telescope: the very one I'd recently purchased, along with the software: my GPS 11. Sync was "not supported by this hardware", as I was told by an error message that appeared in the program when I tried to press the "Sync" button; I learned, months later, perusing in depth articles on the Net, that for some unknown reason this crucial function had indeed been left out in the drivers for that particular series of scopes. I made innumerable attempts to try to troubleshoot the typical 8 to 20+ arcminute positional errors I got on every object (often placing it at the very edge, or even outside, the eyepiece field.) The salesman was mystified, and was considerably perturbed himself when I explained the truth to him. He agreed that without "sync", the accuracy went way down. The program's own forum never replied directly to my queries or complaints about this, saying only to "read their website documentation" and offering platitudes about hooking up the scope in accordance to their instructions, implying that it was MY fault.

Well, it turned out that it certainly had nothing to do with my setup and use of the equipment. Finally, a year later, the starchart was updated by a program update patch that supposedly, among many other improvements, added sync for my scope. But, it did not seem to work; pressing the "Sync"button resulted in no 'action' whatever, and no correction of the position offset. When I told them of that fact, on their forum, I did not receive an intelligible, useful reply: I suspect that they chose not to believe me.

At last, I solved the problem -- with no help from the program developers. I discovered that there was a very newly developed driver for the Celestron GPS 11 in the ASCOM control package, available on their website. It had been published in spring of 2006, and could be integrated into the updated star chart program, replacing its OWN driver for the Celestron GPS 11. I set it up. SURPRISE! "Sync" now worked. It proved that the program's error message ("not supported by this hardware") was in fact, specious and misleading. The function was not supported by the driver software, not the hardware. For, with no change to my scope -- the "hardware" -- Sync now worked, and my positional accuracy improved by nearly an order of magnitude due to that, and presumably also to other improvements in the new driver file.

You will note that the program developer offered NO help whatsoever. His non-responses merely suggested, in effect, that I was somehow stupid in not following proper directions for setting up my scope. But the actual fact of the matter was: their driver did not contain the instruction sets, or algorithms, that enabled a crucially important method required for accurate localized positioning. I was not informed that an outside freeware open-source platform driver package existed, compatible with their program, that would solve the problem. Had it not been for my tenacity, over months of time in investigating, cajoling, searching, querying, and "circling the wagons" to run this problem to the ground, I would still not be able to use MY scope with THEIR star chart program. Period.

So, thanks be to ASCOM, and to its contributors and its helpful respondents. Truly, none of these people had the financial incentive to help me and other telescope users; all volunteered to help build the standards that can be used to improve the amateur telescope community.

I can certainly forgive one instance of a merely misinformative error message in a computer program; we users deal with that eventuality all the time. But, when this is confirmed -- implying that only a misconnection would cause the failure -- and when no misconnection is found, the error message takes on new validity: "yes, apparently the hardware won't do that. Its pointing accuracy will always be terrible!" I was ready, and in fact started planning, to scrap the Celestron telescope mount, remove the optical tube assembly, and install it on some other telescope mount -- "hardware that would work". Luckily, the discovery of the ASCOM software driver proved that the hardware did work, when receiving the necessary software instructions; my scope and the star chart program were now working accurately together, fully integrated and supplying me with the performance promised by the salesman, and the advertising literature and reviews for the scope. All of this was achieved with a software function that was probably just a few lines of code... instructions not present in the software driver for my scope that came with the star chart program. And, it took me a year to find out about it, though I had it up and running correctly in just a few moments, after downloading the file.

No. 4: Something obscure is required, but is not supplied.

Have you had this frustrating experience that I have frequently endured? You download a program from the Net -- often a piece of shareware (but it CAN and does happen with some commercial packages) -- and find that it either won't install, or run, after producing an error message that a certain file is missing? How could THAT happen: so often?

Like as not, the nonexistent file is a Microsoft Visual Basic runtime file. I cannot possibly recount the number of times I have been told that "Vb40016.dll" or "Msvbvm50.dll" are missing. This occurs because the incompetent developer assumes that all Windows systems have the required Visual Basic runtime library files (see this webpage for more information.) Perhaps he or she has never tried their software on a system that was "clean", with a default Windows installation (which lacks those files.) So, they blithely package and sell their programs -- created in Visual Basic -- without those essential files. Ah, me: what a bother. I keep them on a hard drive that can be accessed immediately on my network, or on floppies, to copy the missing file into the \Windows\System directory when needed; eventually I think all my machines now have them. Of course, MS constantly changes and updates VB, and creates NEW files -- which then "go missing" when developers forget to include them!

(In a related issue: sometimes, developers write information files with MS Word, and include them with their programs. Unfortunately, they save the files in a late-version Word format that is not supported by the document applet in Windows -- Wordpad -- which reads earlier versions of Word files, but not the fancy late ones. These developers apparently ASSUME that everybody has "Winword" or MS Office, as they themselves have on their development systems. Just today, I tried to open a user information document [.doc] file in a new program I obtained; Windows passed it to "Wordpad", which TRIED but could not open it. This process so badly locked up Wordpad that it apparently corrupted system memory, affecting the ability of the OS to open any other text file, bringing down the whole XP Home operating system! I had no choice but to reboot. This hardly EVER has to be done. But, somehow, the so-called "author" of this program figured out how require it!)

But essential components of the software are not the ONLY things you may find that manufacturers have left out. In relation to No. 3, above, I had the frustrating experience of learning that with my scope, and some other very familiar ones, the cabling and connectors and wiring configurations are NON-STANDARD, even OBSOLETE. Certain companies are selling "computer-ready" scopes that require serial cables... years after commercial PC makers dropped serial ports. Worse, some cables are so fussy that they have to have internal wiring changes, a standard serial cable not having the correct terminations (even risking blowing out gates in the scope control interface.) One prominent star chart company tries to sell its OWN cables, and really -- for all practical purposes -- implies in the program documentation, as well as on their website, that their cables are specifically required. But, they're not! The much cheaper cable from the telescope manufacturer will do. That is, if you can GET one at your dealer.

And, when I purchased my scope, a motivation to do it was a promotional deal from the maker. During summer months of 2005, it was widely advertised that the scope was to be sold WITH CABLE AND SOFTWARE for computer control. So, I finally made up my mind at that point, wanting to save time and money and to take advantage of the offer. What did I discover?

Well, nothing less than that the cable and software were nowhere to be found. These items were NOT packaged with the brand-new scope, purchased during the period of the offer. An email to the maker yielded the amazing reply that "you are not entitled to that offer." Bewildered, I faxed them my credit card slip and store receipt, circling the date, accompanied by their ad. No response.

I told my dealer. HE faxed the same information. HE got no response.

I decided to "up the ante" and started calling them, long distance and on MY dime, since they had restricted their tech support toll free lines to "problems with scopes only". No satisfactory response; they stone-walled me. Then, I had my dealer call them. He apparently got further with them than I did. For, in due course, the material was finally sent to me, as promised by their ads not only in magazines, but also on their website.

I believe that the sum total of man-hours of time expended on this quest -- to get the product promised in their ads -- involved about a whole days' work, divided between two people. So, expect to be let down, and to discover you NEED SOMETHING ELSE to make your scope work with your computer -- something surely will be left out, hard to obtain, and so obscure that it is hard to really communicate your specific needs to other parties.

This is not entirely a problem of astro software, but it is related and encompassed in the totality of your goal to use your telescope and computer together, and -- as such -- surely fits into the discussion.

No. 5: "Tinkertoy"^[TM] software packages often have problems.

As described at the beginning of Item #4, above, software programs that are constructed with the relatively simple programming platform "Visual Basic" by Microsoft are often found as shareware items, or even some low-quality, budget priced commercial software offerings. I have a term for such stuff: ""Tinkertoy"[TM] or "Paint by Numbers"[TM] software. Perhaps if I actually bought a modern copy of VB and started using it, I'd change my opinion and say something less pejorative. But, as it stands, to my "purist" point of view, VB is the 'cheaptone', easy way out. VB developers tend to be novices, and seldom have the debugging skills of programmers who write old fashioned, line by line, code -- and this doesn't even consider the transcendant geniuses, like Gibson, who produce their programs with assembler! Programs written that way can take up as little as 30-40k, while the same thing done in high level programming language would be many times larger. And -- if you could do it at all in VB -- the equivalent thing in that inefficient platform would be, including the library files, orders of magnitude more bloated! This is one reason why a lot of cheap astronomy software is huge in file size, and that it runs so slowly.

But, worse: VB programs tend to be buggy. Don't ask me why; I don't use the platform. I suspect that the novice programmers try to do too much with their software, and lack the skills to do proper debugging. And, I really wonder how much testing is done on a typical inexpensive astronomy program? On how many different systems? Sometimes I darkly suspect that the end-purchaser becomes merely one of the beta testers.

Certain VB programs I've obtained -- produced by a variety of authors, all unrelated to each other -- seem to share common defects. A complicated radio database and control package, and an astronomy program, had many similar functions -- and similar bugs. Win 98 installation was fraught with difficulties (the radio fellow believed me, and fixed his installer; the astronomy developer was incredulous.) In both cases, the program loaded their databases so slowly that one almost gave up in frustration! (The same large shortwave program list of 13,000+ record sets loaded almost instantly in a competing radio database program, written in C.) Functions shelled out to other program elements either died, or locked up the originating software. The radio developer has now given up the ghost, and has gone out of business; he wrote bitterly about Windows, blaming it for much of his troubles (true? Why hasn't, say, Adobe stopped providing software for Windows?) My take on this, however, was that the program marketing was unprofitable; the installation difficulties in ALL supported versions of Windows exceeded the fellow's grasp and available time and resources for testing; and that -- frankly -- the programs he produced just did not offer much value, considering the trouble end users had to expend. Sure, he could write a fancy looking, graphically elegant program in VB; but where was the meat? The utility? The crisp functionality we've come to expect from GOOD, efficient programs?

In case you're a big advocate of such programming tools as VB, please note that I'm not the only one to utter such critiques. Here are some comments I've culled in a quick search on the Net:

As a part of the simplicity of design, there are many features of other similar languages - such as C++ and Java - missing. This allows the language to be easy to use, but as more sophisticated applications are developed, and as the VB programmer grows in skill, the lack of these functions can cause real frustration. In particular, it is possible to turn off many of the compiler time warnings of errors that are so helpful to finding bugs, thus giving the programmer a much harder job to produce clean coding. -- see this page.

C and C++ programmers continued to produce code as they always had: a text editor was used to write source code, the source code was compiled into an executable, and the executable was finally run under Windows. VisualBasicprogrammers, on the other hand, worked in a programming environment that its critics derisively labeled a "drawing program."... The developer would then "draw" the user interface by dragging and dropping controls from a toolbox onto the form. Finally, the developer would write code snippets that responded to particular events, such as the window being resized or a button control being clicked. -- quoted here.

...Visual Basic is underpowered and underdeveloped, critics liked to point to the many things "real" programmers do that Visual Basic programmers cannot. Perhaps the most common limitation that critics continually point to is Visual Basic's inability to create a standard Windows dynamic link library (DLL). -- in this discussion.

...small, GUI-based applications with rather simple functionality (especially those not needing to use much API, COM models or similar) are easier built and maintained in VB than many other languages... [but] Many critics of Visual Basic explain that the simple nature of Visual Basic is harmful in the long run. Many people have learned VB on their own without learning good programming practices... much of the functionality is contained within the individual components and not visible to the programmer. Since it is possible to learn how to use VB without learning standard programming practices, this often leads to unintelligible code and workarounds ... [and] difficulties in finding bugs. -- in the Wikipedia article, and discussion.

No. 6: Your fancy new multi-function program is, in reality, slow and unreliable.

In the days before multidimensional, multithreaded GUI's, plodding old DOS serial computing was simple and straight-forward (once you managed to get it set up, and to wade through the thickets of chosing the right interrupts, memory allocations, ports, and other configuration complexities, of course.) But the software itself was pretty simple, and did ONE thing at a time, step by step.

If the code was tightly and accurately written, programs could be VERY reliable.

Today, programmers have 'piled Pelion upon Ossa' (to evoke an old Latin saying by Virgil to an uncomprehending modern audience lacking in a standard old-fashioned "liberal arts" education, such as your author obtained half a century ago.) In other words, LOTS of things are going on, in the foreground and background, and authors are usually one step ahead of the OS and hardware developers, crying for more and more computer processing power.

Things being the way they always are -- in the ivory-towered world of the computer program developer -- chances are that your typical author is writing and debugging his code on a multi-core, nitrogen-cooled PC that is really an incipient super-computer (a gadget that the NSA would have lusted after just a few years ago.) He does not CARE much about the "civilians" with their 1.4G laptops (that cost $500), and certainly disdains an OS earlier than the latest upgraded edition from Apple or Microsoft. Maybe, he's really forgotten all about "ancient XP" now, as he's busy porting his code to a new version of Vista (successor to XP)...or even some alpha tidbits presaging OS's of the next decade. He probably has never really done any testing of his latest version on the older editions of Windows, other than to make sure it will boot up (even, possibly, theoretically, assuming that the runtime libraries of his developing platform claim to be backward compatible.)

Since he's satisfied with the performance of his software on HIS machines (which might mean a humming monster with a clock speed of 6GHz) he hasn't had the frustration of spending hours and hours watching the "hourglass" as his algorithms crank painfully in the chipset of a Pentium II motherboard.

So, expect his website and program package to CLAIM compatibility with "Windows 98SE and forward" or "Mac OS 9 and later", but don't give much credence to this, as far as functionality is concerned.

And, sadly, it seems to me (in innumerable cases, as related in No. 1, above) that along with SLOW OPERATION in any system or OS deemed "old" -- particularly with software written in Visual Basic -- you also seem to get unreliability and program operating errors, too, for a variety of reasons related mostly to the lack of truly comprehensive testing of every element of the software development platforms with the old gear.

In my testing of one complex program I could find only one out of several supposedly "compatible" OS/PC's that did not choke up on long databases. But unfortunately the program was designed to save the last one used, to speed up re-opening. This apparently explained why, on two computers, the program often just expired when trying to open: that last large spreadsheet used would fail to load, and the "stalled" program would have to be terminated by me, using the Windows task manager. There was no option to "save or not save" the file: you had no choice. This meant that the end user had to intuit the cause of the problem and then to do external file management, deleting the file so that the program could open. Even I, a former software writer myself, took a while to figure this out; finally I wrote a "cleanup" batch file that I could execute if desired, each time I had closed the program, to over-write the saved file with one that contained the program's original first short default spreadsheet file. Otherwise, after I had previously loaded a very large data set, when re-starting the program I might have to wait 10...20...30 seconds while wondering if the program had expired again, or was just "crunching away".

This particular program contains two documentation files that praise its adaptability to old equipment, offering as an example two occurrences of the assertion that it would run nicely on a 333 MHz machine with only 64 MB of RAM. I was having enormous reliability problems on a brand new 1.4 GHz and a somewhat older 800 MHz machine, with much more system memory, so I thought, "well: here is a claim that can be tested!" In my garage I have a maintenance computer that I have been using reliably for several years: an old 350 MHz Pentium II system running with an Intel motherboard, using one of the versions of Windows that the program is rated for. The only real deviation from the claim in the manual is that this computer has according to the Device Manager 448 MB of RAM, and I was hugely reluctant to take it apart and remove DIMMs. So, the machine would have been rather more powerful than the one described in the alleged claims for backward compatibility with old gear. (Furthermore, this machine is so reliable that for years I have been using it to make emergency backup copies of all our business system hard drives, as described in this article I wrote about our music labs. The backups produced are always perfect bit-for-bit copies and run fine, if we need them in a pinch.)

I installed the astro program and TRIED to run it. It took nearly 40 seconds just to open the first time. I used our network to copy over the "plans" I had previously made with my XP machine, employing various sorted and filtered databases in the program. I then tried to open the Washington Double Star spreadsheet (a catalogue which I have in other software and use all the time as a conventional database file.) I timed the delay: it took 231 seconds to open this pre-sorted file. My other database program takes a couple of seconds to load it...

But, when I tried to use several of the program's vaunted charting functions the results were infuriating. Shelling out to an external star chart caused a complete lockup of both programs; when I tried to terminate them by using the Task Manager, one of the crashed programs caused the entire system to reboot suddenly. So I started the program again, with the default tiny spreadsheet it first creates, and loaded the sorted version I had done of the Saguaro Astronomy Club database: this takes a fraction of a second to load on a "big time" commercial spreadsheet program from the Version 7.2 file -- with 10,594 objects -- that I got from the SAC website; but the older, smaller Version 7.1 contained in the astro program -- which seems to have only 5308 objects -- took 24 seconds to load. I closed the program, in the state of having this spreadsheet onscreen so that it would automatically reopen the next time; waited about 30 seconds, and then restarted the program, running my timer. After 55 seconds of elapsed time, my patience ran out and I opened the Windows Task Manager, which reported that the program was "Not Responding". It would NOT open the data "from scratch" at startup, as the author intended it to do, according to the program documentation.

I cleaned up that problem by recopying the default spreadsheet, and opened it with its tiny initial database, and then tried to use the program's plan builder filters to open the NGC 2000 database using "all constellations". After 180 seconds, I got bored and checked the Task Manager: the program was not reported to be locked up, so I waited... and waited... and waited some more. After six minutes, I finally walked away from the computer to do something else, and returned after 9 minutes. I clicked to close the program and got a runtime error: "No. 7: Out of Memory". As I had figured!

Finally, I did one more test. I opened my sorted list of the PK Nebula catalogue, which contained 1302 records. One of the nebulae has a nickname: "Red Spider". I clicked on Database...Find and, following the onscreen directions precisely, I asked the program to find the name 'Red Spider', including the object descriptions, searching all databases, an option for the search. After about 20 seconds, nothing having changed on screen, I checked the Task Manager. Yep: the program was "Not Responding".

Then I repeated the search, using the same database but on my XP machine. The search worked, the program returning two matching records after a few seconds and not freezing. (However, even XP, a very reliable OS, was not immune to other bugs in this program: when I tried to export a database of 313 Sharpless nebulae, using the "Export to ASCII" function, the program not only froze, but could not be terminated by the Windows Task Manager. After waiting many minutes, to no avail, I finally resorted to holding down the laptop's power button until the system shut off completely, necessitating a long tedious file cleanup on the subsequent boot-up. And, yes: the program had failed to create a readable exported text file, which actually crashed Notepad when I tried to look at it!)

The conclusion I was forced to draw from this experiment was that by using a machine that was better by far than the one claimed in their literature -- with 7 times more memory! -- I could not use the software at all. Even databases with only about a thousand records choked up the machine under some conditions; many other functions caused freezing or even lockups of the whole OS. Other programs using conventional database or spreadsheet engines could open huge files with no difficulties -- on this same machine. I wondered why I was unable to confirm the claims made for the software's supposed backward- compatibility on older, gutless computers? It was evident on my tests that the program thrashed heavily, could not load large files or perform filtered searches on various databases -- even the list of the NGC objects -- on a very good but old computer, with lots of RAM. Little wonder, then, that I had so much trouble on other systems: including a nearly brand-new one!

That's the way of the frustrations of the world... you must not be too surprised to encounter them; must expect them, adapt to them, and live with their consequences. Built IN to every new program is a complexity that will sort out the world of home computers into TWO categories: the old stuff (yours!), and the "right stuff" (the author's) upon which the software was developed and debugged and tested. Irritated by this inevitable fact? Well: get over it.

Update, Feb. 2007: A few months after this article was written and posted, I needed to cross-check some numbers of the Principal Galaxy Catalogue, and realized that the only software I had on my best and newest computer, with lots of memory, a fast CPU, and the latest Windows XP updates, was this particular "planning" program. I started it and tried to load just a small part of the PG catalogue. After a while, when nothing seemed to be happening on screen, I checked and found that IT HAD HARD LOCKED WINDOWS XP! The keyboard and mouse were now inoperative. The Task Manager could not be opened. There was nothing I could do but to power off the PC, and reboot. Windows took about six or seven minutes to re-open, while it crunched through all the lost file allocation units and cross-allocated files. I've now learned my lesson, and certainly will not even bother to use the program again with any list of more than a very few objects, perhaps not even all of the NGC! The author told me earlier in an email that "this had never happened before" when it occurred on another of my computers, an old one. But now I know that even my latest system locks when this program misfires: I don't believe I have even one other piece of software that does this much damage to Windows!

No. 7: 'Errors and bugs' -- or 'features'? Function distantly follows form.

The old cliché, like all clichés, is based in fact. For, increasingly there are no real differences between "bugs" and "features" as software complexity rises beyond human -- and compiler -- comprehension. I began to notice this years ago, in the late DOS era, when writing my creaky antique astronomy program "Eyepiece" (which I shamelessly, though embarrassedly, give away on this website, despite its hoary decreptitude.) Even though I mastered pretty well the use of overlays and tricks to push and poke things in and out of extended memory, at a certain point of complexity, as I tried to add new functions, the program would seem to compile correctly into an executable file...but the file would, under many circumstances, start to behave oddly (killing a previously working function here, and crashing under a normal instruction there.) The compiler gave not a hint of having reached a kind of "event horizon" or threshold where instability had set in. But I KNEW, and had to 'back off' and take things out, simplify, re-write, consolidate...or essentially cripple something I had planned to add to the software.

I haven't tried to write any recent type of object-oriented C++ code for 32-bit Windows (gad, give me a break: I'm an old codger by now!) but I can only look at samples of it, and wonder. HOW do these guys figure this stuff out? My learning curve pooped out some time ago. In 1985 I felt as hot as a pistol, while now I'm only a smouldering, drooping intellectual vestige. So I won't try to analyze this issue with any real modern comprehension; but I can intuit that it is likely that astro software is being developed by young people -- and that young people who can write object-oriented C++ code probably aren't terribly critically focused -- pun intended! -- on amateur observation with telescopes. They are EXPERTS WITH SOFTWARE, not EXPERTS IN ASTRONOMICAL OBSERVING.

Furthermore, they are also probably "astronomy guys in theory only".

I cannot for a moment believe that MOST of the people turning out modern Windows or Mac code for cutting-edge applications have the breadth, holistic comprehension, and total commitment to astronomical knowledge that many old-time, tradition telescope users demonstrate.

Well, so what? I can't write 32-bit Windows code. Nor can any of my observing friends. "It takes a village" to make up the world, and specialists are needed to give us complex technological tools.

But, do the specialists have OUR priorities and needs? ("us" being the old geezers who have long experience with star charts, eyepieces, and telescopes, predating PCs.) Most likely, not: as evidenced by the software they provide us with, having such unreliability; being burdened by so many useless gee-gaws; or being almost too darned complex to learn and adapt to -- UNLESS you are a fellow software writer!

In the early explosion of multimedia software for Windows 3.1 (when my wife and I started setting up and changing our music education business to be oriented around computer workstations), I had an "old reliable" star chart program, which even employed the Hubble Guide Star catalog: TheSky 3. It was RELIABLE. But, it was simple. It had the most logical user interface I have EVER seen in a star chart program, and just a few configuration options. It was QUICK. It printed good charts. It was, in fact, foolproof.

I can't even find the disks any more. Have no idea where they went. The machine it was installed on is surely in landfill now. So, when I purchased a new star chart program in the summer of 2005, I had this fond memory of TheSky 3 in mind. What I found was that the modern programs, by everybody, were bewildering, complex, and often very buggy and unreliable.

Lordy, how I wish everything ran like that old program. Gone are the days.

What I do have now, in the modern "state of the art" or "industry standard" planetarium program that I purchased a year ago, is a marvel of clueless, uncomprehending bloat. It defaults to "magnitude 30" for ALL objects. There are no global settings, so you cannot -- as you SHOULD be able to do -- find one box that could set your limiting magnitude to match your telescope. Instead, you have to go through DOZENS of boxes, involving multiple dozens of keystrokes, pulling down one menu, one list, after another; clicking away madly for hours and hours to set the thing to, say, 16th magnitude (something reasonable, and practical.)

And what are the onscreen displays like? Well, as it comes out of the box with default settings, it opens into a breath-taking vista, a depiction of the "real" Milky Way. But, is this useful to a telescope user? Not really. As you zoom in, you see nothing. Increasing the object filter settings, you jump from a dead screen to a screen filled with illuminated pixels and a jumble of overlapped numbers: unintelligible. To try to get a display that looks like an actual printed star chart -- say, a section of a constellation in Sky Atlas 2000, showing the galaxies, clusters, and nebulae in reach of your scope -- you have to tweak and tweak. I've spent WEEKS of my time, in total, over a year: and have not come really close to what I want; or to what I got in no time at all, setting up that ancient Win 3.1 star chart program I mentioned above.

Does it occur to anybody that the reason that world-renowned astronomical cartographer Wil Tirion creates charts that are universally useful, while being graphically elegant, is that he is AWARE of the subject: indeed, he is NOT an astronomically- clueless C++ maven, ignorant of the larger world of celestial objects and lore, though being a prodigy with code. Tirion KNOWS what he is doing. Who, in contrast, in the world of developing astro software, knows what Wil knows? I see no one (yet); maybe somebody lurks in the wings. I hope so. Meanwhile, is there even an attempt by a star chart developer to create a "look and feel" function that can make the display sort of similar to a standard chart? Again, no. Surely it would be intellectually indefensible to "steal", in toto, the objects, look, and layout of Wil's copyrighted, printed charts. But why not come close to them, so that you can go back and forth without finding the computer chart unintelligible?




M101, as displayed by one planetarium program that shows overlapped plots from two
different catalogues, confusing the viewer. It also is not able to differentiate the duplicated
labels, and has covered up M101 and its equivalent number from the NGC (5457) so that
neither number is legible. Even after changing "program preferences", I end up with
either TWO indeciferable, overlapping labels -- or no labels at all.



Why, for instance, do practically all star charts show duplicated data? You can turn on (or off) various star and object catalogues; but many of them have overlapping data -- and the coordinates, numberings, and isophote plot boundaries do not agree. Your screen shows a double display for, say, a single galaxy: two layouts for the galaxy outlines, two sets of numbers or descriptions: it gets confusing. Sometimes you turn off all but ONE of the databases... and yet, the overlapped, duplicated data remain. Or, small objects -- such as narrow angular diameter planetaries -- might be plotted in two different places! (Which is the correct one?) In one astro spreadsheet program, a successful search can yield a whole series of duplicated but subtly different records for ONE single object, and all you can do is sort of "pare this down" to just two duplicates, at best. People complain about this on the company forum; a solution has not been found. Does it not occur to the author to run this through a sub-routine, so that -- at will, and by choice -- the user can opt to "discard" the duplicate information from some obscure catalogue set he or she does not intend to use? I guess not...




Most of my planetarium software programs have this sort of display in default mode:
(left) a narrow eyepiece field shows nearly nothing; (right) a wide field is an unintelligible jumble.
It can take hours to improve this, sometimes involving hundreds of keystrokes and mouse moves.



And you can never seem to optimize ONE field of view, selecting your label font for legibility and your limiting magnitude to toss out impossibly faint objects... and then switch to another field of view, and see something proportionally reasonable. No: zoom out, and the screen fills with overlapped objects and labels until it is unreadable. Zoom in, and you won't gain the right increment of magnitude limit, matching the result you'd get as you change powers with your telescope oculars. Sure, SOMEWHERE in the program is a complicated, confusing, and practically useless setup box that you can use to TRY to set limiting magnitudes for all kinds of objects per a given field width. In a year's time, I've never come really close to getting it right. Cannot the DEVELOPER put in a little time, and create some model setups for varying conditions, close to what one would get when switching, say, from Orion's DeepMap 600, to the Sky Atlas 2000, to the Uranometria, to the Millenium Star Atlas fields? No, that would be too much to hope for. No one REALIZES that this is absolutely necessary; nobody, that is, on the developer side of things. Every USER knows this. Who has ever been able to set it up RIGHT?

While it is no tragedy or waste -- other than your time -- if the onscreen display is a jumble, it's a different matter if you are printing guide charts, especially considering how slow some programs are to accomplish the task, and how much ink is required of some deskjet printers. For instance, I just found this chart of August planetary nebulae on a helpful astronomer's website. It was created in "chart printing mode" by a program that I recognize. Note the jumble of overlapped text near the "teapot" asterism. Can you make sense of this? It would seem to me to be absolutely impossible, especially at night in dim red light.

Update: In January 2008 I came to grips with a problem that I had been only vaguely aware of: the messy data of the Hubble Guidestar Catalogue, which includes a gigantic number of spurious objects. Some star charts wisely allow the user to weed out the worst of the mistaken items; others do not. I have written a detailed article, with examples, that you may read here.

No. 8: Code BLOAT: the curse of modern software and OS's.

As a logical extension of the observations in No. 6, immediately above: "bloat" is surely the most responsible culprit in today's overloaded programs. I gasp to read, on a package, that "500 MB free disk space is required" -- or even more!. On some software, you copy the image folders to your hard drive, which could add GIGABYTES of data. But that in itself is not a big problem, each file being a few thousand k at most. The PROBLEM is the over-complexity.

Over a period of some months, I purchased two "levels" of a highly recommended program, a "suite" of astro applications as described in No. 1, above. All I really wanted was the ability to search through a large database of objects, get little thumbnail photos from the DSS plates, and then send the coordinates to my scope. But, what I got was at first TOO DUMB TO USE, having little more than the Messier catalog. My 'upgrade' supplied two CD-ROMs (actually, home-brew recordable CDRs from this small organization) that contained a lot of the expected and hoped-for data; but along with it, came a LOT of bloat. Now, the program opened up with a panel of stuff that could almost brew the coffee that I needed to take with me for a night of observing, let alone show me stellar data. I turned that off. But, my attempts to use the 'upgraded' software immediately revealed that it was unreliable, having many more frustrating errors and performance glitches than the 'first level' version that I had previously purchased. What I wanted was THE BEST OF BOTH VERSIONS: the simplicity of "level one", and the data of "level two". But what I got was the unreliability and bloat added, along with some more data and pictures. It was "over the top" as far as I was concerned, and many problems forced me quickly to realize that I'd probably never be able to master it. I simply would not have the PATIENCE.

Mastering computer stuff is what I've been doing, for my living, for 15 years; before that, I did it occasionally in my work as a broadcast technical consultant (setting up remote control systems that ran by computer, or computer-based automation systems.) Before that, as an early home computing hobbyist, I taught myself to use CP/M, learned BASIC and Pascal and C and DBASE III programming... and even a little assembler (ugh, brrrrrr!)

So, who's afraid of a little astronomy program? Well -- ME, for one! If not exactly "afraid" of the program per se, I am indeed afraid of WASTING TIME with it... time that I can use observing; time planning effortlessly from printed star charts; time in the field with my scope. I tried the program, spending weeks figuring it out and testing it both day and night: it SLOWS ME DOWN, rather than speeding me up. When do I reach the gratifying point where the learning process intersects with the telekinetic memory capability, when the program operation becomes quick, easy, intuitive? Damned if I know. I suspect it will take a LONG time to get there; and I don't want to go on that journey.

No. 9: It's not ready to use until you upgrade, upgrade, UPGRADE!

Frankly, I haven't found a program in a box -- in recent years -- that is REALLY ready to use. You have to log on to the company website and download... download... download. And, of course, you have to be registered electronically, a tiresome process that does not help the user in any meaningful way, but helps instead the marketing department of the developing company.

When the downloads started to approach the range of 100 megabytes, I began to get CRAZY about this. Luckily, I now have ADSL. But a few years ago I was still stuck in the dialup mode, being just a bit too far from the local telco office for broadband. Downloading a 50 megabyte service pack by dialup was ... impossible. It never worked. It ALWAYS expired somewhere along the line. I could not even do this from Microsoft's servers, which must be the best in the business. Now, with ADSL, this usually works out fairly well.

UPDATE, 4/07:  The bad, unreliable program that prompted me at last to vent my spleen and write this article finally had an update available. Thinking it might solve the worst problems, I tried to get it. But, the 'service pack' was a single file of a whopping 80 megabytes. When I tried to download this, via my DSL connection (usually very reliable), it managed to get only about 65 MB before the process stalled. It would not resume. I closed the browser; tried again: nope. I tried later: nope; now the update page would not even come up. When I tried for the third time, after deleting the messy incomplete one from my machine and changing browsers, and then even using a downloading extension for Firefox, I managed AT LAST to get the update, which (as it turned out) had a grab-bag of stuff that had little to do with the executable file (where all the problems were.) The entire process took me most of a morning to get onto my machine. Oh, the gnashing of teeth, muttering, and grumbling (my wife always knows when I'm using this program, by the ambient sounds...)

When the maker insists that before you can use the software from the installation disk, what it tells you is this: the developer is often too cheap to remake the CD-ROM installation disk, selling you stuff NOW in the store that was put onto disk as far back as perhaps TWO YEARS AGO, or even earlier! Some time ago I had the annoyance of buying a program, based on the functions described on the package, but finding that I had AN EARLIER NUMBERED VERSION on my CD-ROM, one that for some perverse reason would not upgrade, after I had downloaded the supposedly appropriate patch. And, I failed to get the very functions of the later version, not supplied on my CD-ROM edition, that had prompted me to buy the program!

Boy, was I peeved! I have to give the dealer due credit (it was Micro-Center, in Santa Clara): they actually waived their rules and allowed me to return the program for a complete refund, since what the package described was not the product IN the package. This is of course a violation of consumer law; but it is a violation of a law that is, for all practical purposes, moot and unenforceable. You have to rely on a merchant's sense of honor to give you customer satisfaction in such a case, since ALL dealers of software now have a "rule" that an opened package cannot be returned -- copying a CD installation disk is too much of a temptation! I can certainly understand this, and therefore it is a really consumer-friendly dealer who would make an exception to their rule, to keep an honest but frustrated customer happy.

But, what of the situation that happens often -- in reverse -- when the upgrade "breaks" something you need? Or, when an upgrade has a bug-fix that dealt with a problem by eliminating a number of related functions altogether, rather than working out a complex coding issue? You get the upgrade...you lose something...and it's too late. Often, you cannot go back. You're stuck. Nice of the developer to warn you about this; they never do! Why admit that they TOOK SOMETHING OUT? That would be too, too embarrassing.

No. 10: Data Sets Riddled With Mistakes.

After investigating some "planning programs", which promised observers the ease and simplicity of using computer databases to arrange viewing lists, and then automatically slew their GOTO telescopes to chosen items, I discovered a worrisome problem that has not been discussed in reviews, or on newsgroups: data collections are riddled with errors. Some programs have internal databases that simply have WRONG coordinates or other mistakes: so that all plans created from them, saved, and then made available for users, preserve those wrong positions -- no matter whether or not the program database has later been improved! The plans record the object data at exactly one point in time: when the objects are retrieved from an internal list, and then saved in the plan. I checked at random some objects in a specific plan devised around a familiar star chart: the error rate was significantly higher than the errors I found, at random, in planetarium programs. When you use truly to rely on such plans, developed by users of varying levels of skill, experience, and accuracy, you get rather wildly varying results. In my way of thinking, such computerized plans are worse than having no plans at all -- you can have NO CONFIDENCE in them; you waste precious time in the night sky while you try to figure out what went wrong.

Indeed, the website for the main software program that I rely on admits, if you are tenacious enough to look for it, that "The contracts under which S------- B---- provides astronomical databases prevent us from adding to or altering them. If you find any errors or omissions, please let us know so we can report them." The "official" databases usually come with a text file that states something like this: 'permission is granted for using these data if they are not altered'. But, these databases are created by PROFESSIONAL ASTRONOMERS and, at the time, had carefully corrected data that are generally reliable (if the precessing algorithms of the software can plot the objects in the right location.) I don't have a problem with most of the entries in the PK or Principal Galaxy catalogues; what bothers me are the "digests" of data, collected by astronomy clubs or individual observers. Often those lists have a higher error proportion than the original "official" catalogues, and may not have been precessed correctly.

Of course, printed maps and observing book lists can have errors, too. While looking for mistakes in a computer observing plan, I found a rather large mistake in a well-known map and observing list, sold by a large amateur astronomy products company: a declination coordinate for a famous object was given as a "-" while it should have been a "+". Anyone who has spent time looking over astronomical lists will find errors (there was, for instance, a magnitude rating for NGC-891 that was too dim in my OWN program "Eyepiece"; I had accepted the numerical value printed in the book by a famous writer who authorized its lists for my use. Some years later, this was pointed out by somebody who posted the mistake on sci.astro.amateur, and I quickly corrected it: now it's the accepted value.) However, a program that creates exportable PLANS -- based on an internal database of questionable accuracy and exporting those errors along with other information -- creates unique combinations of mistakes.

The resulting issue for users is this: what kind of accuracy do you require? Are you among the novice or dilettante groups who merely look occasionally at the brightest objects, such as the Messier catalogue entries; or are you an advanced user who goes after obscure, faint galaxies and nebulae, in a dark sky, that few other people bother about? If you are in the latter category of observer, your chances of getting reliable plans and data are smaller than the expectations of users of "simple" beginner plans. Many more people will use those, and find that (say) M-42's coordinates are slightly off, than will use a plan for obscure objects, finding that perhaps a fifteenth-magnitude IC galaxy is miscatalogued. Since I have yet to find on the Net any articles, or reviews of substance, pointing out these difficulties, may I not be forgiven for concluding that hardly ANY advanced observers are using such tools? They already know how to find faint objects by the old, conventional means of star hopping and have no need of computers to assist their observing.

But, what of the group of amateur astronomers that I find myself in? This is the perhaps small group of users who try to bridge the gap between "oldtime visual star-hoppers" and "newbie GOTO scope users"? I have done more than my share of "hopping"; now, I would like to have my computer help me get to a whole new layer of faint objects that are incredibly hard to find, for they do not LEAP into view as you swing your scope over the field. Some of these objects take a while to "sink in" and you might have to spend minutes staring at a star field, slewing around a bit and flicking your eye back and forth, to see the boundaries of a low- surface- brightness object that is just above the level of the background light. If the scope is pointed 30 arcminutes away -- or even further, judging from the mistakes I've already found in lists and plans! -- then your precious time at the eyepiece is being totally wasted.

Are you looking for an obscure object? Something that is of interest to advanced observers? Chances are that the data will be incorrect or even contradictory. For example: I wished to look at "Minkowski's Footprint Nebula", a proto-planetary in Cygnus that looks through an amateur-sized telescope like a fuzzy patch resembling a double star. My "professional" planetarium program had two listings for the object: in different places! (And, as usual, it was given varying names, with arbitrary designations that don't agree with the official one found in most observing guides or on the Net.)




Which is the correct placement for the "Footprint" nebula (Minkowski 1-92)?
(Hint: it's the one in the center, not the one to the upper left.) This object
is obscure and hard to discern; wrong placement in the field is sure
to waste your time. Did the software developer care? I doubt it.



As the announcers of infomercials love to say: "But wait -- there's more!"

For, after I suffered through the buggy, turgid, crash-prone operation of one "planning" program that is touted as being the ne plus ultra for today's sophisticated observers, and had spent almost two days struggling to master the creation of elaborately filtered and sorted spreadsheet lists from its voluminous data catalogues, I suddenly jumped up in front of my PC screen with a start. After waiting more than 20 minutes for the program to "crunch" through just a fragment of the Principal Galaxy Catalogue, I realized with dismay that among all the settings one had to alter, I had overlooked the "precession correction": I was creating not a series of useful plans that could send coordinates to my GOTO telescope for trouble-free observing of various hard-to-locate objects; instead I was simply WASTING TIME: now, watching the progress bar s-l-o-w-l-y incrementing, and later when I would have to "hunt and peck" to find the objects that my scope should have located.

For it had suddenly occurred to me that unlike two or three "amateur" database compilations, such as the Messier catalogue that the program defaults to, and the Saguaro Astronomy Club list that I had used during my experimental trials, the professional catalogue I was now sorting had all record sets referenced to 1950, not 2000! The program developer had NOT precessed any of the data, but probably took it (off the Net?) as-is: most of the hundreds of thousands of data records of individual objects were not in epoch 2000!

Furthermore, the very word "precession" was not mentioned in the manual for the software; nor were there any on-screen alerts to remind users about the absolute requirement for precession when those J1950 catalogues were selected. The instructions did however contain four very short sentences about the topic, a total of a few dozen words spread throughout the document, and in my opinion quite uninformative for "newbies".

For those of you who need a refresher here, see this part of a Sky & Telescope article by Alan MacRobert; suffice it to say that the 'precession of the equinoxes', a 26,000 year wobble of the earth's axis, causes a continuous shifting of the celestial sphere. In the fifty-six years between the publication of those 1950 coordinates, and now, at the ecliptic the coordinate grid changes by almost three-quarters of a degree. So, unless I selected objects in those lists that were near the ecliptic poles, EVERY set of right ascension/declination coordinates for each object in all those epoch 1950 databases would be wrong for our current year, sometimes by almost two eyepiece-fields in my Celestron telescope, using a lowish- power ocular (it's a narrow field scope, compared to, say, a "fast" short focal length Dobsonian.) Now that I had worked out excellent positioning accuracy using my hand controller's database, or via a reliable star chart, achieving at best positioning that could be as close as within 2 to 10 minutes of arc, I was at last seeing and identifying reliably those 13th to 15th magnitude objects that I craved: but only if the data were in accordance with the celestial sphere (remember the saying "garbage in, garbage out"?)

So, what would happen if I used this planning program to send epoch 1950 coordinates to my scope? For instance, since I am a tremendous enthusiast of planetary nebulae, and love to view the objects in the P&K catalogue, let's choose a nice 11.6 magnitude planetary in Libra (known as PK 342+027.1 or Me-2.) If I used the coordinates in the catalogue values precessed to epoch 1950, and sent them to my scope, it would point at a spot in space that was about 42 arcminutes away from the actual current position of the nebula (not counting the intrinsic pointing control ambiguities that could, depending sign of the errors, increase the positional error by another 5-10 arcminutes.) Since the lowest power ocular I generally use on this scope gives a total field width of about 27 arcminutes -- but with an aesthetically clear, clean, and bright field diameter of only 18 to 20 minutes -- I would have to move a LONG way to get the object into the "sweet spot".

Precession errors can be even a bit worse. If I had selected PK 12-09.1, a 13th magnitude, stellar-looking planetary in Sagittarius -- perfectly visible in my telescope -- the error would be about 49 arcminutes. In many cases I checked, the objects were entirely outside the field and required great struggle to locate, as electrically slewing a GOTO scope is something of a chore. These are not bright objects and do NOT "leap" out of the star field in an obvious manner; you can sweep back and forth many times and miss some of the smallest diameter ones. To find them you basically have to compare a deep star plot with your eyepiece field, OR use a very accurate electronic pointing method. The use of object lists that were more than a half-century out of date ruins that latter option!

So: one could not merely open one of those catalogues and immediately use it: for it had data that were precessed to 1950 coordinates. WHY did not the "author" of the program correct those data before he folded the contents of all these catalogues into one continuous file of multiple-hundreds of megabytes? It would be practically impossible for the end-user to extract, precess, and then re-insert the corrected values; but the developer could have done it with relative ease: perhaps it would have taken a week's work, but think of the TIME SAVED of all the end users! (I, for one, would have gladly paid, say, $5-10-20 more for the program if it had been done. Accurate planetarium programs in fact precess all the data to the exact date and time selected for display: every star, every galaxy, every nebula; everything, on the fly.)

The software did have a precession function built-in, but it could not be used "real time". One had to set up a new data set, based on one of the outdated catalogues; run the function; and save an "external" file which could be loaded as a new spreadsheet. This could take a LONG time: as much as 20-25 minutes for just part of some large catalogues. But, I knew it would be necessary if I wanted to use the data for accurate GOTO telescope pointing. So I ploddingly precessed about a dozen catalogues -- the Lynds nebulae; PGC, Upsala, and Morphological Catalogues, globular clusters, Sharpless objects, supernova remnants, and my beloved PK nebulae, all recalculated for the first day of 2007 to insure good results for the next year or so. I could not resist the urge to do an experiment, precessing a few of these to 2000 and then looking in alternative printed J2000 catalogues for comparison. Yes: the program fails to agree exactly with certain other trusted references, such as Roger Sinnott's values in the Sky Atlas 2000, some catalogues coming out closer than others. For one collection of objects I chose, since I had previously experienced no problems when using its published J2000 coordinates in my scope, there were deviations of up to 6 arcminutes or more: effectively DOUBLING the positioning error of my GOTO scope, which I had struggled for a year to tweak. Luckily, more catalogues than not came much closer to the published values in respected chart-content reference books. But, these little unpredictable discrepancies certainly go a long way to explain the occasionally erratic results when pointing my GOTO scope, from time to time: one might guess that below the level of professional observatories -- at least Lick, as I explain in the "addendum" to this article -- the whole world of astro-computing is riddled with these kinds of errors and precessional inconsistencies.

For visual observers using star charts and manually slewing their scopes by means of hopping or setting circles, J2000 coordinates would have been satisfactory. So, why weren't they corrected IN the program, to begin with? Why ship it with J1950 catalogues? And not make very much of this important issue in the program instructions?




An aside: do ALL observers need "astro planners"? One developer of a "planning program" told me that some of his users stopped employing printed or computer star charts altogether, using his "plans" exclusively for observing. I tried his program. I discovered that this severely impacted my ability to make spontaneous observations near "planned" objects. If I stuck to the plan, going inexorably from one object to the next, I could "run through" a great number of objects in no time at all. While this might be useful if I were, say, doing a Messier Marathon or a Herschel challenge, I find that it is not the best way FOR ME to observe. Since it is difficult to add objects to the plan at a moment's notice, the onscreen data being loaded in one chunk into memory -- and "evaporating" if I opened an object database list or catalogue -- I found that the use of the program inhibited me. It is somewhat like trying to sit down and plan your Internet surfing: you really should be able to free-associate, and click on links that are of interest to what is going through your mind at the moment. Having interaction opportunities available at all times is an essential part of the normal way the brain operates as we go through our daily activities. We develop new thoughts, plans, curiosities: and act on them. We don't file them away, or structure them into a list, to be acted on later. Frankly -- and this is just my personal opinion, not intended to be applied to any kind of declaration of HOW software should be developed and how people should use telescopes -- I wonder about the creativity and degree of intellectual curiosity of people who try to nail down their actions into such a structured heirarchy? Yes: if you are a professional astronomer or dedicated amateur scientist following a specific project or investigation, a plan is neessary to coordinate your activities. Otherwise, a plan might well be a starting point, a guideline, or merely one of some available tools, to be changed as needed when something unexpected or interesting comes into one's perceptions.

No. 11: Where's My Object?

I have a bunch of astro programs on the desktop of my astronomy laptop system. Some of them are recent updates of current, state-of-the-art software that you would all recognize from ads, from reputation, and from experience. Yet, it's frustrating for me to realize that there are some double stars in MY ancient program "Eyepiece 2.0" that are not in the databases of most of these 'modern, comprehensive, complete' programs.

Furthermore, none of them have ALL of the Index Catalogue objects, not all the "observable" PK nebulae, and many other objects that are viewed by leading amateur observers with scopes of the aperture range of my own instruments. These are objects that are KNOWN to all informed amateur astronomers...since they are MISSING from the computer programs, may I not be forgiven from concluding that the astro authors are uninformed about astronomical objects and beyond a certain point are "in the dark about them"?

It was HUGELY frustrating to pay more than $150 for a supposedly comprehensive package and find merely a handful of PK and a half-dozen Sharpless nebulae; yet, page after page of the Sky Atlas 2000 has them plotted, along with galaxies that are ALSO not in the program data set! Nor are these objects in the allegedly 'voluminous data' in the Celestron NexStar GPS 11.

Worse, still: another such program I recently purchased has a very hit-and-miss set of images. I expected to have DSS thumbnail photos of every IC and NGC object. Not so. They are listed when I call up the function. When I click on many of them, the objects are not found in the data supplied. A deep search of my hard drive folders, and of the installation disks, proved that the files are not supplied. Yet, they are there on drop-down lists you can call up from program menus. I have intuited that the program lists are derived from the next HIGHER LEVEL of the program I did not purchase...but are included in the lower level by mistake. How much work would it have been, for the developer, to EDIT his drop-down menu list so that it was accurate, and to describe accurately the data present in the set he sold at a given price, specifically, so that the user could make an informed buying decision? Just saying that the program has 'huge amounts of data and gobs of pictures of any object you would want to see' isn't really accurate, if much of the IC catalogue and other VERY observable objects -- within the limiting magnitude capabilities of my 10" and 11" scopes -- have been left out.

In Item #2 -- "Display Adaptor" -- of my rant list, I mentioned talking to an employee of the company that develops and markets a fantastically advanced planetarium program. I quoted him as saying it "looked good" but lacked substance. Well, when I was having difficulties with the other competing fancy program that he sold me, along with my Celestron scope, and not finding in its database all the common objects plotted in the Sky Atlas 2000, he offered to let me try out HIS company's offering. We tried in vain to find PK and Sharpless nebulae that I wanted to observe, by means of computerized telescope pointing. The salesman then maneuvered all around the program interface, looking in vain for a menu option that would allow him to scrutinize a LIST of the object data; it simply was not an available function. You could "turn on" or "off" each of several catalogues; but what they contained, and to what depth of inclusion compared to other electronic versions available in competing software and on the Net, was not easily determined. He decided that the only way to find out was to specifically look for EACH object in question, either with the search function or by trying to find it on the star map in the correct region of the sky. The latter option was monumentally difficult, as the limiting magnitude of course changes with the FOV; most of the time, these faint objects (12th-15th magnitude) were simply not on-screen. He was disappointed but had to be philosophical about it.

"Steve, do you remember the days of the early Mac OS, compared to early Windows or late DOS? You could get to the 'works' and the data and files and configurations in the PCs, but all this was hidden to the Mac user. Well, that's kind of similar to OUR program, I guess. The works are hidden from view. You can't examine the catalogues at all, apparently."

Needless to say, I did not purchase one of the versions of that program (which range in price from under a hundred bucks, to over $250.) I apparently have very distinct and different needs and goals, as a trained and experienced observer, compared to the intended market for this fancy software. (But, if I ever NEED to plot a "realistic" 3-D view of the Solar system from Alpha Centauri in the year 5231, I know where to go for the tool.)

Finally, I must point out a contradiction in the development process for this program, which to me is inexplicable. It does not seem to have all the objects visible on Tirion's Sky Atlas 2000 charts (a series of products priced around $50 that form the core standard for many amateur observers' requirements for a printed star chart.) Yet, it DOES have allegedly "one million objects" and "20,000 pictures". You can load the Principal Galaxy Catalogue (PGC) and get 900,000 galaxies, most being utterly invisible in any of the telescopes sold by the same corporation. Yet, oddly, the program LEAVES OUT many of the objects shown in the Sky Atlas 2000...why? (The reason is obvious. The developers haven't a clue about observing. For a related discussion about erroneous or missing objects due to database errors, see this observing report in my "Faint Fuzzies" series.)

More on the related issue of data description syntax vagaries in topic No. 12, below.

No. 12: Program search functions are perversely inadequate -- even useless.

I have one of those expensive programs that you all know about: we could give it the fanciful name "TheHeavenlyOrb" if we cared to do so. It "does everything" and "has everything imaginable" in its data set. Everything...if you accept that it really only has about a half-dozen Sharpless nebulae, and a FEW of the Perek & Kohoutek planetaries. (But, you can find a billion 'invisible' 20th magnitude galaxies if you open up the filters to the "Hubble Deep Field" parameter settings.) Yet, arrayed before me on my observing table is the lowly Sky Atlas 2000...and all those PK and Sharpless objects, ones that I can see with my 10" and 11" scopes -- even many with my 5" refractor -- are there on the page. They ARE NOWHERE TO BE FOUND in the program data set. This even includes perfectly observable objects with sexy names, like "Minkowski's Butterfly" (PK10+18.2 or V92, as it is known in scholarly catalogues.)

Type in "PK10+18.2" in the object search field, or -- using the "common names" list -- "Minkowski's Butterfly" -- I DARE YOU! -- and what does the program tell you?

"OBJECT NOT FOUND".

I could swear that the last time I did this, a faint electronic voice curled out of the little PC speaker, emitting an obscene "raspberry" and snarling derisively, "you dummy!"

Was I asking TOO MUCH of a program that cost me more than $150 and purports to be the "industry standard" of such astro software? The program would make you think so, by its response.

But, after much agonizing and searching, step by step, object by object, going down long pull-down menu lists, I discovered that the problem was frequently A STUPID SYNTAX ANOMALY. And the syntax used was never the name or description or numerical designation you'd get for the object if you looked it up in the reference book for the Sky Atlas 2000 or RNGC or Uranometria, or on the Internet, or in a good observing book. It was ALWAYS peculiarly different, with extra spaces (non-printing, unshown null characters) or with hyphens -- or WITHOUT hyphens -- or with the superfluous prefix "SAC" (for Saguaro Astronomy Club, as if they had any proprietary claim on the object -- they don't!)

PK nebulae numbering would NEVER be in the same syntax as given in Perek & Kohoutek's actual catalogue, which an Internet user can get in a click of a mouse. For instance: on Table Two of that list, a 14th magnitude planetary in the constellation of Cassiopeia is identified with the number "136+04.1". But my "state of the art" expensive star chart program tells me that it is "NOT FOUND" if I type that in to the search field. What IS required? Well, none other than the very peculiar, arbritrary "SAC PK 136  +4.1": note the space before the "+" sign, and absence of zero before 4.1. You have to know the expected syntax; if not, the search FAILS. This space, and the designation "SAC", are (as far as I can tell) just peculiarities of the strange ideas of the software developer, and have nothing to do with ANY OTHER CATALOGUE, star chart, or observing book designation for the object! (For instance, I learned from a friend that the very "left brained", data-intense program GUIDE by Project Pluto correctly accepts the "proper" designation, and immediately displays the planetary in the appropriate star field. Kudos to its author!)

So, can we not be forgiven for concluding that the program developer who "makes up" strange, inappropriate, improper, or arbitrary names and designations really knows very little about (say) PK Nebulae, the PK Catalogue, and what the heck these things are all about -- how they are numbered, and what the original catalogue system calls them. To some gentle readers, my passion about this issue may seem "anal" and a bit obsessive. It's not, really; I only recently came to grips with it, trying to figure out WHY, for months, I got failed searches with this program. I had to spend hours of time examining the databases, line by line, comparing the odd entries with real catalogue listings, to intuit what the heck the weirdo who wrote the program had in mind. In explaining this in detail, it SEEMS very picky and fussy; but as you all know, software IS fussy, and unless it has been written with some form of "fuzzy logic" to cope with human input, such programs won't work properly.

It gets worse. Sometimes it seems that EVERY single darned program uses a different, weird, tortured, proprietory syntax. An extra space, here...a hyphen (or not) there. No two agree; and none seem to agree with any standard source familiar to amateur astronomers, not a single printed star chart.

I'll say it again. May I not be forgiven for concluding that astro program developers are NOT OBSERVERS -- almost NEVER are observers -- and generally they haven't a CLUE about the ways that real observers have come to learn about these objects. There. I've said it. Now, authors: prove to me that it isn't so. Sit down and EDIT your databases and spreadsheets... arrange them intelligently... use standard terms and names, after checking in the "real" world to see what they are called. And, test the software with a somewhat larger group than your friends and correspondents who are glad of a free copy. LISTEN to the complaints of customers (at least the ones who are more polite than I am!) and ADAPT to the "real world". Do not expect the world of astronomy to adapt to you, the software creator.

And, given that there are inevitable discrepancies that are not avoidable (an NGC object is just as often listed as, say, "NGC-xxx" as it is "NGC xxx" or "NGCxxx"), for gawd's sake, put in some code in your search interface that ADJUSTS to this. One program that I gave up on demands that the user "learn SQL" (Structured Query Language), according to what its author told me. This he demands of ME, the paying customer, to be able to find an IC or NGC object in his data. Searches by the "simple" (i. e., not SQL-syntax) process seem doomed to fail most of the time, in my experience with the program on several machines.

I personally dealt with these types of user-input issues back in 1989-90 when Ron Wood and I developed "Scope", which eventually became "Eyepiece 2.0"; I talk about this in the article I have posted about our software development project, which you may find here. I would think that just about anybody who has had anything to do with electronic databases and record-keeping in the last quarter of a century would be cognizant of ways to add at least a vestige of artificial intelligence to search functions... but, apparently, not the developers of some of these "acclaimed" software programs. BAH!

No. 13: Numerical Order of Object Lists Is Illogical.

One program I recently purchased, with high hopes for its usability and allegedly exhaustive data, was ordered in a completely odd, perversely abnormal and illogical pattern, one NEVER used by astronomical scholars. All the program data sets would display an order that was incorrect, causing much extra searching and scanning and cursor movements to pan up and down, to try to find objects that were numerically out of order. If I allowed myself to be darkly negative, I'd accuse the developer of being innumerate (defined by Webster as "marked by an ignorance of mathematics and the scientific approach".) Here, follows a section of the NGC objects, in the EXACT order as shown on screen. Can you explain the thinking that would allow the author to depart from the normal numerical ordering?

NGC 2551
NGC 2552
NGC 258
NGC 2591
NGC 26
NGC 260
NGC 2600
NGC 2602
NGC 2605
NGC 2606
NGC 2608
NGC 2614
NGC 2691
NGC 262
NGC 2629
...etc.

Can you see what he did? Obviously, the sorting is TOP DOWN - LEFT TO RIGHT, from the first of the digits of each description number. The entire number is not evaluated and put into order. Silly; no one orders chart lists that way. It made me laugh, at first: and reminded me of the way file names were ordered in the 'bad old days' of DOS; I laughed, that is, but only for a moment. As soon as I tried to FIND things, I started to suffer. UP, down, UP, down: all over the spreadsheet I had to go, to find objects that should have been in proper sequence.

And, in the list above: what of the missing numbers, such as NGC 2607? That's not exactly an object number that comes trippingly off the tongue, but it IS indeed a real New General Catalogue object, a 14th magnitude galaxy, discovered by John Herschel in 1827, and within the light gathering range of MY telescope, a Celestron C-11. It is an object I would have tried to observe -- that is, would have, if it had been IN this program's allegedly comprehensive database. But it was missing in the program's default settings with the included NGC 2000 spreadsheet data (see "Where's My Object", item no. 9 in my gripe list), as are others in that short sequence shown above. In order to get the missing objects, my modern computer took an incredibly long time to re-sort the data (after I figured out the parameter I had to change): 135 seconds. But, though the missing items were now in the list, the odd numerical order was still in play: for instance, NGC 2609 is followed by NGC 261; then comes NGC 2611, 2612, etc. So I still had to skip eleven lines down, to go from NGC 261 to NGC 262. This means jumping over 7000 lines down, to go from NGC 1 to NGC 999 (the end of the spreadsheet): utterly bizarre, in my way of thinking! I have the same basic data set, in the Saguaro Astronomy Club list, which opens instantly as an Excel spreadsheet, sorts quicker, and is in proper numerical order: and it was available as a free download at the club's site. I am not really tempted to use the much more cumbersome commercial program, after comparing the difficulty of the one, to the ease and convenience of the other.

No. 14: PC - Scope Connectivity Problems.

When I purchased my new Acer laptop, for use as the field computer to control my 11" aperture GOTO telescope, I was aware that for some years, manufacturers of commercial home and laptop PC's have been leaving off serial connectors (as I had discovered to my dismay in 2001, when attempting to find a ready-built machine for use with existing MIDI piano keyboards, employing gameport connectors.) So I obtained a USB-to-serial adaptor from my computer dealer: the only model his company -- a very large US-wide chain store -- sold. However, my telescope dealer used a venerable HP laptop with a standard DE-9 serial port connector; he obtained reliable connections with his telescope, via the star chart software that he sold me with my scope. But, did that mean "jack", as far as my setup was concerned? Nope.

Despite the fact that the software driver for the USB-serial adaptor installed properly, and that the Windows Device Manager showed that it was now registered as an active COM port, on the evening of "first light" with my scope, preparing to watch the "Deep Impact" collision with Comet Tempel on 4 July 2005, the telescope and computer refused to link up. I tried several times, including complete reboots of both the PC, and the scope. When this failed, I asked my observing friend Charlie -- who has many years' experience with computers, and his own GOTO scopes -- to watch, advise, and confirm that I was following directions. No go! I did see the event, but NOT with the aid of my PC, which stubbornly refused to recognize the telescope.

I tried at home the next day. I failed. By now, at least 20 trials to link the scope and the planetarium software had failed completely. After checking everything thoroughly, I decided that I was certainly doing nothing obviously wrong. And so, the scope and laptop went into the car, back to my dealer. The sales manager professed complete amazement, as HIS laptop serial port, serial cable, and GOTO scope worked right, the first time and every time he tried to link them. I brought the equipment into the store, and assembled things into a pile in the middle of the showroom floor. We determined after some further consternation that the exact order of PC and scope bootup seemed to determine the success or failure of the linkage. It turned out that I had to have (a) the scope aligned and running; (b) the laptop had to be connected but powered off; and (c) on powering up and booting the PC, Windows finally recognized the link. But, surprisingly, this was not repeatable!. After several linkages, interspersed with several shut-downs of all equipment, on the fifth or sixth time, the scope would link via, the USB-serial adaptor, to a "hot" computer. Apparently Windows was 'adapting', as it tends to do once some strange new configuration finally "sinks in" and all the settings are at last properly recorded in Registry keys.

Now, months later, I can link the scope without fail, not bothering to worry about the exact connection or booting order. Consulting the telescope manual and manufacturer's online documentation, I found nothing giving any relevant suggestions or advice about this issue; nor from the maker of the star chart. But, as it turns out, such Windows port connectivity problems are indeed well known. One manufacturer of a professional high resolution digitizer, which uses USB to PC com port translation, explains in its troubleshooting guide that "Some of the more common [problems] include the possibility of the USB port being disabled, the PC unable to detect the USB components, or a conflict with another device." The maker of a personal digital assistant explains that you must set correct baud rates for both their portable product and the PC. A search of the Google news archives shows a plethora of queries about problems in setting up a "virtual" com port using a USB adaptor, for various devices such as GPS receivers, modems, wireless adaptors, and networking components. There are also self-help resources such as this webpage on Frank Kime's site, or this comprehensive USB page on the "USBMan" site; and there are a few freeware, demo, and commercial programs available to test the PC and its ports -- such as the Microsoft utility "USBview", available here -- and, when all else fails, see this Google topic search.

Luckily, my particular experience -- repeated failures, followed at last by solid and reliable connections, with NO change at all in hookup configuration! -- required nothing more than just having the connections in place before booting the PC, allowing Windows to "adapt". As Microsoft explains, in the section called "Self-Tuning" in their Knowledge Base article on Windows XP Performance:

Windows XP is tuned to take better advantage of today's hardware. In many cases Windows XP is able to adapt itself, thereby implementing a greater degree of self-tuning. This lets you enjoy better performance with less administrative overhead.

...there are several areas where it achieves a higher degree of self-tuning than previous versions of Windows...Windows XP gauges the capabilities of the system during installation and adjusts the user interface settings accordingly.

In particular, IRQ sharing under different editions of Windows will affect system performance, slowing down the computer or requiring reboots. The older editions of the OS are not as effective at integrating the PCI bus of the motherboard and the OS, allowing components on the Univeral Serial Bus (USB) to share interrupts with system internals via "IRQ steering". (Parenthetically, I seem to have some "worst case" situations here in the machines in use in our own business. Often, USB devices either work only on our XP machines, or are so erratic on earlier editions of Windows that we just cannot rely on being able to use our USB cameras, scanner, or printers, sometimes having to reboot our PCs over and over. It's quite infuriating, so we have made sure never to use USB connectivity for the MIDI pianos we use in our music teaching workstations: see this article for more on the issue.)

To get back to astronomy software product integration: some of the suppliers of telescopes and software seem to act like there is NO PROBLEM or history of connectivity troubles with COM Ports (virtual or hardwired) and USB, under Windows. Either this is really just passing the buck, or it betrays a very minimal experience of testing their own products on a variety of expected user systems.

Two weeks after I first posted the preliminary draft of this article on my website, I tried yet another star chart/telescope control program, recommended highly by a friend, who has used several editions dating back to the days of Windows 3.1. He brought over his laptop so that I could try it. And, I had trouble...

The telescope control function had a checkbox for my particular model of telescope, encouraging me to expect that it would connect and send the proper control data, pointing my scope at onscreen objects. But, sigh: no. Yes, the "telescope panel" opened up, but nothing happened when I clicked the "slew telescope" button. Nothing: not an indication on screen, not a peep out of the telescope control motors. The next day, on the Net, I did some investigation, and found buried in a long, complicated article about updates to the software, an admission by the author that he did not understand how to write the proper code to interface all models of this particular series of GOTO scopes (and that he had trouble getting all necessary technical parameters for the control commands from the maker); and furthermore he knew that users of USB-to-serial adaptors were often unable to get linkage with 'virtual RS-232 ports'. And, he expressed great doubts about the reliability of the exact model of adaptor that was the first recommended choice in the documentation given by the maker of my scope -- an adaptor that I have, and which does work with different star charts and/or the ASCOM scope driver package, using my gear.

I appreciate the candor, but can't be blamed for concluding that if I buy the program, I become a "paid beta tester". It may not work even by now. I could pay -- and try it. If not, I could write and explain my results, and hope for a fix. (Or, I could save my money and look elsewhere, which is probably just what I'll do!)

Update, January 2007: A bit more information about problems with NexStar connectivity was supplied by Robert Shaeffer, author of the "RTGUI" telescope control program, in a post he made to sci.astro.amateur on December 31, 2006. Here is the Google archive of the post, which I copy below in its entirety.

Celestron Advanced GT/Nexstar RS-232?

khobar wrote:

> I finally bought the serial cable for the Nexstar 80GT hoping to use it with Starry Night Pro. However, I can't seem to enable RS-232 on the hand controller. I also have a Celestron CG-5 Advanced GT mount - same problem, no RS-232 option. <

There is some issue involving datacomm problems on some models of the Hand Controller. A an old web page by software developer Andre Pacquette (not up any longer) stated,

"Serial problem with HC:

Not all PC serial ports are made equal. When not in use, most serial ports idle with a stop bit. However, some serial ports send a continuous start bit (break signal) when not in use. If the HC serial port receives a continuous start bit, it gets confused or bogged down and has difficulties sending characters the next time you connect. For instance, if you try connecting to the HC with 'TheSky' you'll get errors 9/10 times. Often, BIOS upgrades are available that will change the serial port behaviour and work around the problem. Also, you could get a serial-to-USB device and hope that it idles with stop bits. Either way, this is a bug with the serial handling on the HC and hopefully Celestron will correct it on the next spin. "

I played around trying to solve this problem with RTGUI, and found that programmed delays between the characters seemed to work around the problem. Try it: http://www.rtgui.com. There's a good chance it may work.
   -- Robert

Followup by Roger Hamlett:

'Break', implies what it says. The link is broken.

Sending a 'break' for a gap in transmission,was commonly done by just one make of PC. Dell. A little while ago, some of their laptops started doing this as a way of saving power. It caused problems , not just with the Celestron HC, but with a huge number of serial communications programs. There were complaints, and a BIOS fix was launched. Oddly, Dell elected to make the fix 'standard' on European machines, and not on the US machines...

This is not a Celestron problem, but a major fault in the PC's concerned. I have two HC's, neither offer an 'enable' for the RS232. It is enabled all the time, if the right cable is plugged in. -- Best wishes

I might add that I too had difficulties using the "Programming Cable", recommended by members of the Yahoo NexStar users group. It would not establish a communications connection to my PC, no matter what I tried. I gave up...

No. 15: Scope Control and Pointing Issues.

I have described, in detail, my frustrations with a particular star chart/scope control program as regards its interface with my NexStar GPS 11 scope, in No. 3 above ("Your scope is not supported.") But, the problem is not limited to ONE piece of software; it occurs with every program plotting a star chart, and sending data to a scope, that I've tried, to one extent or another.

I know what you are going to say, so I'll beat you to the punch. "Well, Steve: if it happens with all the software, then it is likely that YOUR SCOPE IS TO BLAME."

I have an answer that satisfies my sense of logic. When I use the hand controller of my GPS 11 scope, with no connection to my PC, and call up an object from the scope's OWN database, the telescope almost unerringly slews right to the object requested. It's ALWAYS in the eyepiece field, and if I'm careful with alignment, it might be in the near center of the field with an ocular that delivers 150x!

That's accurate. And, some of my programs read out and show the scope axes sensor position data. Those values agree with the RNGC catalogue data in the sofware using epoch 2000 -- sometimes to the arcminute, or fractions thereof. So, the scope's database is good... the scope can point to those positions accurately... and the scope reports THOSE DATA to the computer program. What went wrong?

I do not have a definitive answer, but I have inklings of what I think must be the truth (related perhaps to differences in the calculations of precession, control latency, and rounding-off functions.) Tech support people at Celestron are "off the hook" as soon as I have said to them -- as I have in two long conversations -- "your scope points well using its own hand controller." That's all they need to hear; they tell me "it's not our problem; talk to the people who write the software."

And I have, repeatedly. One of the folks who has responded with useful feedback is Robert Shaeffer, author of RTGUI, a very useful freeware scope control program. He has a Yahoo user group and, in fact, diagnosed and confirmed my observation that the GPS 11 scope sometimes reported spurious years after downloading GPS data: setting my PC clock to "1406" instead of "2006", for example (boy, does THAT cobble up things!) I consider this fellow to be a gentleman, and a very sincere software developer who does it FOR THE LOVE OF IT. He has no financial incentive to fix his free software; yet he takes input and suggestions, and improves his program -- a prince of a fellow! I wish a few of the other developers -- who charge big bucks for their programs -- had the same attitude. But, they simply don't. Their knee-jerk response is to tell the customer that "your setup is wrong" or "you haven't read our instructions." Period. End of story.

I've learned from this, and my interactions with "freeware" and open source astro program developers such as the ASCOM folks, that you get more useful response from the people working for the love of astronomy than from entrepreneurs who make their living from developing and selling software. Is this the slightest bit sensible?

No. 16: Typical astro program documentation is dreadful.

The Help System on one expensive program I own simply refers back to little fragmented bits and pieces of cryptic info on their website, with NO REGARD TO THE PROGRAM VERSION you are actually using. You look up a term; click on "search"; and get back lots of useless information from the documentation of OTHER versions of the program. I went in circles, tearing out my hair, trying to reconcile apparently "missing" functions, not present in my copy's user interface; I even asked questions on their forum without being given the right answer. Turns out that the Help system is simply the same in ALL versions. Some "Help" indeed!

Another program has so many functions that perhaps the author just could not convey all of it in a printed manual, so he supplies some multimedia files on a supplement disk: little descriptive rambles that I found so stupifying that I just could not endure them. The audio was recorded with a mike that overloaded on every "p", popping and blasting. As an audio engineer, hearing all these explosive low frequency eruptions pouring out of my computer subwoofer, and the distortion of overloaded sound files, I cringed in horror, suffering discomfort that could not be overlooked and which did not help induce me to watch the rest of the presentation; in this case, I'd rather read a manual!

Writing manuals requires the employment of a WRITER. Technical writing is a profession, and people are likely to want to be paid the market price for such labors. It is probably too much to expect "Uncle Tom's Astronomy Software" to have a staff of tech writers of the caliber of Microsoft or Adobe scribes. Ah, so be it...but can't we do better than supplying a simple, inexplicit manual -- or none at all -- or putting in a "pretend" help system, just for "form"?

No. 17: "Night Mode" (predominantly red colored display) is still too bright, and can wreck your dark adaptation.

I wonder: have any of these program developers actually USED, say, a 10" scope to look at an object fainter than 8th magnitude, while employing their software on a laptop at night? I sometimes doubt it. Switching some programs to "night mode" still leaves a third of the screen in whatever default desktop colors you've chosen for your regular setup: you may still have a big wide swatch of bright white/gray at the top and bottom of the screen, all pull-down menus being black text on light background, and many other objects not "red on black" as required to maintain dark adaptation. And the text and object label colors are not correctly set up for night mode, with some of the labels disappearing altogether, losing contrast and becoming essentially invisible. So too do some of the icons for object types.

I made myself a large oversized red plastic filter to cover the LCD; but then the result was bad, whether the programs were in "day" OR "night" mode, with many labels disappeari