Using SkyTools 4 to Image the new Fragment of Comet 73P

I took this series of twenty 40-second exposures on February 13 using iTelescope T30 in Australia. The exposures covered about 15 minutes in total. When made into a movie, they show the comet and its new fragment moving across the sky.  

Not a Fragment of his Imagination

On February 10th Thierry Noel circulated an image that revealed a new fragment ofcomet 73P, apparently trailing behind the main body of the comet. This new fragment was quickly confirmed and designated 73P-BT. 

I set about to observe it myself, with the idea in mind of checking for other possible fragments, and this is how the movie above came about. The seeing was poor that morning in Australia, there was moonlight, and the flat field went awry (I'm still looking into why), but the series of images served their purpose. As far as I can tell from the movie, there are no other new fragments nearby.  On the right is a stack of the same images in the movie, but with the stars trailed. 

How I Planned my Observation using SkyTools 4

When I first saw the post by Thierry Noel, I first did a quick check to see if there were known asteroids or comets shadowing 73P, perhaps posing as a fragment. This was a simple matter of opening the SkyTools Interactive Atlas, centering 73P, and setting the UT date to that of his image. As I suspected, there were no comets or minor planets near the position of the fragment. 

My next thought was to act quickly to confirm his observation. Through my iTelescope.net subscription I have access to 20 different telescopes located around the planet. But this posed a problem that needed a quick solution: which of the 20 telescopes at my disposal was the best one to use? 

Using SkyTools 3 I could switch between different locations in the Nightly Planner, looking for the one that gave the best view. But I still needed to pick a telescope, and that would mean comparing fields of view, resolutions, and sensitivity. Once I picked a telescope, I'd still have to calculate the motion of the comets, in pixels, to determine the maximum exposure I could use before the comets began to trail. That is still quite a bit of work. Ah, but I have an advantage. I am currently the only person in the world with access to the nearly completed SkyTools 4, and it has an awesome new tool to help choose a suitable telescope quickly and easily:

Above is a screen capture from the Compare Imaging Systems tab of the SkyTools 4 Object Info, set for 73P on the Night of February 13/14. The first thing it does is to select the optimum image scale for each Imaging System (telescope+camera) by varying the available focal reducers/extenders and binning. Then it selects the most appropriate filter. Maximum observing times, image scales, and exposures are tabulated, and the list is sorted so that the best systems are put at the top. 

The columns are as follows:

• Observing Time—the total time that the comet is observable from the location of the telescope. This is affected by the latitude of the telescope and how low to the eastern horizon the telescope can be used. T27 in Australia can observe the comet for 70 minutes, but T24 in California offers only 15.
• Exposure Time—This column displays the total exposure time required to reach the target Signal to Noise Ratio (SNR) which I had set to 80. It allows us to compare exposure times between systems. 
• Scale—a parameter that describes the quality of the image scale, from 0-100. Forty is considered good. As you can see, the comet has a poor scale on all of these systems, but some are better than others. Regardless, we aren't likely to detect features in the coma or determine if the new fragment is really a cluster of smaller ones.  
• Size—the size of the coma of the comet in pixels on the image. This is of course related to the Scale parameter. 
• Resolution—the expected resolution of the image in arc seconds. This considers the quality of the astronomical seeing (that I have selected elsewhere as excellent) and the airmass of the comet during the exposures.
• Trail Time—how long you can expose before the comet starts to trail on the image, or if we are tracking the comet, this is how long until the stars begin to trail. 
• Flt—the optimum filter to use. Once you have selected a system you can decide to explore the use of other filters as well, perhaps for a color LRGB image.
• Focus—the selection of focal reducer/extender (not variable for these telescopes).
• Bins—the optimum binning, selected as a compromise between image scale and exposure time.

The available observing time for T24 was too short, and T27 wasn't available. I ultimately chose T30 for my observation. For T30 the coma would cover 24 pixels and it could reach an SNR of 80 in 5 minutes, which seemed like a good combination.

Have a look at T07, which is located in Spain. This system would require much longer to reach the same SNR, likely because there is no Luminance filter available. With twenty telescopes, it is nice not to have to remember things like that.

I knew I wanted to make a movie, so I didn't want to track the comet and trail the stars. Instead I wanted to take a series of shorter exposures, limited by the time it would take for the comet to trail from its motion across the sky. So the next thing I did was to use the SkyTools 4 exposure calculator to make sure that the SNR I could expect in a 40-second exposure, on that morning, with T30, would be high enough, and it was. 

To complete my planning I created a SkyTools 4 Imaging Project that defined what I wanted to do. Then I entered the project into the Scheduler for the night of the 13/14th and it generated a plan for ACP Planner, which is the control system used for the iTelescopes. The observing time was scheduled and the plan was uploaded to the telescope, and there you have it.

I can't wait to share SkyTools 4 with everyone. I believe it will revolutionize the way people plan their imaging, and not just for those who use remote telescopes. What if you only have one telescope? Well, consider this: the same calculations that made the imaging system comparison tool possible can be used to answer other interesting questions. For example, imagine you just bought an OIII filter and wanted to observe an emission nebula. Which ones should you try for? E.g. which nebulae are strong in the OIII and are suitable for your telescope and location?  SkyTools 4 has the answer to that question.

The SkyTools 4 Scheduler

Recently I needed to make a screen capture of the SkyTools 4 Scheduler tool, and thought I would share it with others as well.

Please keep in mind that this is my unfinished working version and that I didn't spend much time creating the example.

So what are we seeing? This is the SkyTools 4 Professional Edition in Imaging mode. When in imaging mode all tools are customized for imaging, from the planner, to the charts, to the Object Info. It is as if there are two separate versions of SkyTools, one for visual observing and one for imaging. In this way the tools can be specifically designed for visual observations or imaging, without attempting to do both simultaneously.

The Scheduler is used to generate a schedule for observations to be made on a given night. The result might be a schedule to be carried out manually, via Real Time, or it can be a formal plan to be used via a robotic telescope.

At the top of the dialog the iTelescope T21 imaging system has been selected. An Imaging System is more than just a telescope. At a minimum it consists of a telescope OTA + camera + mount.  But it also defines filters, acceptable exposure times, an optional fixed location, focal extenders/reducers, slew speeds, camera readout times, etc.

On the left are the imaging projects that have been created for this imaging system.  An Imaging Project defines how we want to observe each target. It is the heart of SkyTools 4 imaging.  I am not quite ready to show The Imaging Project dialog yet. An imaging project describes the filters to be used, what the exposure targets are for each filter, an observing priority, the positioning of the field of view, optional multiple fields of view to form a mosaic, binning, etc. The project is also used to track progress and to archive your observations.

The schedule is built on the right. It can be built automatically or one target at a time. Each observation includes a start time, filter, sub exposure time, and number of sub exposures. The schedule presented in the example is incomplete. Projects would normally be observed for longer periods of time, and normally there would be more of them to choose from, filling the time allowed.

Under the NightBar are two visual aids. The one directly below the NightBar indicates the quality of the imaging opportunity for the selected imaging project, in this case a project called P9 D. Green is the prime time to image it.  Below this is a visual depiction of the schedule. Green indicates observations, red indicates telescope slews. The spaces in between are where additional imaging projects can be scheduled.

The imaging system in this example is a remote robotic telescope that uses ACP planner for control. When you click Create Plan an ACP plan is generated from the schedule. This plan is uploaded and the observations are made accordingly. Time on this telescope is expensive, so normally we would build a plan for part of the night rather than for all of it, and every minute would be used.

All These Worlds are ours to Explore

Pluto is a World

Perhaps people should start thinking about Pluto as a world, rather than a planet. I think that’s what most people really mean anyhow. Our solar system is full of worlds—beautiful and strange places that Captain Kirk might want to beam down to. 

To the ancients a planet was a star in the sky that moved. There were five of these in all: Mercury, Venus, Mars, Jupiter and Saturn. They looked just like any other star, but they wandered around the sky as the days, weeks, and months passed. That alone was enough to make them special.

When, in the early 1600’s, Galileo turned his telescope on the sky, he discovered a sixth planet: the one beneath his feet. Galileo’s observations showed that the earth is not the center of the universe, but just another planet orbiting the sun.

In 1783 the astronomer William Herschel discovered Uranus. Although too faint to be seen by the eye alone, he knew immediately that it was no mere star, because it appeared as a small disk in his telescope. Sure enough, as the nights passed, it too wandered. This was the seventh planet.

In 1801, the Italian priest, mathematician and astronomer, Giuseppe Piazzi, discovered the eighth planet: Ceres. Yes, Ceres. Ceres was heralded as a major discovery, for it was found right where astronomers expected it to be, in the big gap between Mars and Jupiter. A year later another similar planet was discovered, named Pallas. Then came Juno, Vesta, and Astraea. If you had studied astronomy in the early 19^th century you would have been taught of the 11 planets in our solar system. What an exciting time it must have been, with all these newly discovered planets. But there seemed something amiss with these new planets. Astronomers had expected one big planet in the gap between Mars and Jupiter, but they had found five. Based on how faint they were, these new planets also seemed to be quite small. There was some debate as to whether they were planets at all.

It all came to a head in 1846 when Neptune was discovered. Neptune was another major planet that was found way out beyond Uranus. In 1847, after nearly 50 years of being called planets, Ceres and its compadres were redesignated Asteroids. As many had come to realize, these asteroids were more akin to planet fragments than true planets. So once again there were only eight planets, and as the years passed many more asteroids were discovered. They number in the hundreds of thousands today.

Another fifty years passed. School children became used to the eight planets of the solar system. But astronomers wondered if there were yet more major planets to be discovered. They searched ever deeper into the outer reaches of the solar system, and as the 20^th century dawned, Percival Lowell, a man who was flamboyant and wealthy, began a quest to discover what he called, “Planet X.” It took some thirty years, but eventually an astronomer named Clyde Tombaugh, who was employed to pursue Lowell’s dream, found a new wandering star. This was hailed as the first great new planet discovered in the 20^th century. Pluto/Planet-X was expected to have a mass of ten Earths, and it was far beyond the region of the asteroids, so few questioned that it was a planet. But this turned out to be hubris. The calculations that had predicted planet X had been in error, and Pluto had been found quite by accident. By 1940, estimates put it at about the same mass of the earth. By the 1970’s, estimates of its mass had shrunk to 1/10 that of the earth.  Pluto was shrinking, if not in reality, at least in the estimation of those studying it. By 1980 it was a mere 2/1000^th the mass of the earth. Pluto also has a weird orbit that brings it within the orbit of Neptune for part of the time, and is tilted by a whopping 17^o. People started to realize that, like Ceres, Pluto may not be a proper planet, but there was no compelling reason to change its status.

At the dawn of the 21^st century, an astronomer named Mike Brown realized that there were likely more objects like Pluto out there, and much like his predecessors, he set out to find one. He and his team eventually discovered many such bodies, including Quaoar, Sedna, Orcus, Haumea, Makemake, and Eris. Eris is big—about the same size as Pluto, but more massive. By 2006, astronomers realized that the Ceres saga was playing out all over again. Rather than call all of these new Pluto-like objects planets, it was decided by the International Astronomical Union to remove Pluto as a planet in much the same way that Ceres had been. In addition, a new class of objects was created, called Dwarf Planets. These objects include Pluto, Ceres, Eris, and a growing list of others in the outer solar system. 

Once again, there were eight planets.

If you look at the question of what constitutes a planet from an historical perspective, a case could be made for only the original five wanderers. Wandering star is, in fact, what the word planet means. Perhaps it all went wrong with Galileo, when people realized that they were living on a planet. After all, the earth is not a star that wanders in the sky. Or perhaps it went wrong when Uranus and Neptune were called planets. Even though they are both large and massive, they are too faint to be seen wandering with the eye alone. It certainly went terribly wrong with planet Ceres, which would have led us to hundreds of thousands of planets and counting. Alas, Pluto has suffered a similar fate. 

Something profound has happened since people first followed the paths in the sky of planets—these wandering stars. We have come to know them as places--places you could visit, with mountains and valleys. Science fiction has depicted them as places where you can land your ship and walk around. In fact these are all worlds to be explored. These worlds include not only Pluto, but Ceres, and Vesta, our Moon, and many of the moons of Jupiter, Saturn, Uranus and Neptune. Even Pluto’s moon, Charon, is a world waiting to be walked upon. All of these worlds are so much more than wandering stars in the sky; they are places for us to explore.

Perhaps we should start thinking about them as worlds rather than planets, and we can skip the scientific definition. After all, we all know a world when we see one.

Dell Venue 8 Pro Review

Over the summer I purchased a Dell Venue 8 Pro tablet. This is a $200-$220 8-inch tablet that runs full Windows. It is small, thin, and lightweight. I carried it with me on my travels, including campouts, my family vacation and ultimately to the Oregon Star Party, where I used Powerpoint and ran a SkyTools demo on it. It runs SkyTools 3 quite well and, with ASCOM, it will control most any telescope. In fact, there was a gentleman at the OSP using one to drive his 40-inch Dob. He had it attached to the base of the telescope itself, and it was working quite well for him.

It is possible to connect to the telescope via a USB connection, but using a Bluetooth-to-serial adapter may be an even better option, assuming it works (I have not tried this personally).

As others have reported, the Windows touch interface allows SkyTools to work mostly as it would using a mouse (with a few exceptions, such as mousing-over objects on the screen). I must say it's pretty cool to have such easy access to SkyTools in the field.

On the downside, the screen is very small and the video driver does not currently allow you to enlarge the fonts by more than 25%. You need to look pretty closely at it in order to see what is going on, and those with failing vision may find it difficult. In that case, one may wish to go to the larger 11" version. It also can't handle a very heavy load, so it is best to keep your observing lists short, particularly with Real Time, which will keep things rolling along nicely.

It seems clear to me now that this is the future for SkyTools in the field. When it comes to supporting many different mounts, and advanced features, telescope control via ASCOM is difficult to beat, and it runs on Windows. Windows will continue to improve in terms of integrating the touch interface, and there are new processors on the horizon that will be smaller, more powerful, and run longer on a small battery. We may even see some of these things emerge in the coming months. For my part, I am working to make ST4 more compatible with the touch interface, without sacrificing any of the unique capabilities of the mouse.

The Imaging Project and the Oregon Star Party

I was recently invited to be a speaker at the 2014 Oregon Star Party. The story of how this came about began last April. I was thinking about the new astro-imaging features that I was adding to SkyTools 4; things like support of image mosaics, generating scripts for automated telescopes, and some sort of image logging. I had in mind about a half-dozen separate features and I wasn't sure how to put them all together.

So there I was, idly pondering the differences between visual observing and imaging. Visual observing is relatively simple to plan: figure out when the best view is going to be and go look. Unless you are doing a detailed sketch, looking doesn't take all that long. But imaging can entail long exposures in multiple filters and even include different positions in the sky for a mosaic. Imaging an object is less like a casual rendezvous, and more like a project. That's when it occurred to me: visually we simply observe celestial objects, but when doing imaging, we should be observing projects.

This idea of an imaging project was like a revelation. I could see how all the imaging features that I wanted to add to SkyTools 4 could all come together. In fact, I could use this idea to create an observing system for imaging rather than simply present a set of disparate tools.

I was excited to say the least. Ideas that bring everything together don't come along every day. On that same day, I was contacted by Mark Martin of the Rose City Astronomers, asking if I would be interested in speaking at the Oregon Star Party. My first answer was that I didn't have anything to talk about, but when he persisted, my excitement about the imaging project idea got the better of me and I accepted his invitation to talk about it. After all, it was April and the OSP wasn't until late August. I had plenty of time to figure it all out.

First I had things I needed to finish that I didn't want to leave half done. Then summer came along and I found myself spending a week in Texas at a scout camp with my boys, and soon after there was a family vacation. Before I knew it, the OSP was only a month away and I had nothing. Absolutely nothing! Not only was there no code to demo, but I hadn't even figured out the details.

After the panic wore off a bit, I got down to work. I went at it for long hours, seven days a week. I also had to prepare a talk, so I combined my work on the overall software design with developing the notes for my presentation. Doing so was odd, but in fact it worked quite well. I chose one part of the new code to focus all my efforts on so I could demo it, redesigning and coming up with new ideas as I went along. In concert, I worked the ongoing story into my presentation. In the end the talk was probably a bit too ambitious, but overall it seemed to go ok.

I really enjoyed being at the Star Party and meeting lots of new people, although it was rather painful to be there under such beautiful dark skies without my telescope. Fortunately I did mooch some great views, including an unforgettable view of M51 in a 40-inch Dob.

SkyTools and Windows 8

I haven't posted here much recently, but that is likely to change in the coming months. So to start things off...

With the release of Windows 8 it is time to say a few things about the impact Windows 8 will have on SkyTools users, now and in the future.

First and foremost: SkyTools 3 will continue to work on the Windows 8 desktop just as it has with Windows 7. We have found no compatibility issues. If you are still running ASCOM 5, I do recommend upgrading to ASCOM 6 prior to upgrading to Windows 8.

Windows 8 and the Future
Windows 8 brings some major changes. A lot of confusing things have been written and said about them. The difficult thing to grasp about Windows 8 is that it is at once a bold new operating system, and at the same time the old Windows 7 we are familiar with. This is important to keep in mind when you hear or read broad sweeping statements about it.

Imagine if Microsoft released a whole new version of Windows with only one change: a redesign of the Start button. For most current desktop/laptop users this is all the upgrade to Windows 8 will initially represent. The Win 7 Start button opens a menu that lists all of your programs and is used to start them. In Windows 8 the Start menu has been turned into a full-screen with icons that you use to start programs. Once a traditional Windows program is started you go right back to the desktop. What startles people is that they are greeted by this new Start screen when the computer is booted rather than the familiar desktop. By doing this it literally throws the new Windows features "in your face." But rest assured, the Windows desktop is still there.

In addition to replacing the Start menu, the new screen also launches a new kind of Windows program. These programs are optimized for the touch screen, although a mouse will still work fine, and are meant to be used full screen, like a game, the SkyTools Interactive Atlas, or the "apps" that we have become used to on phones and tablets. The point of all this? It enables tablets and other touch devices to run Windows 8.

Microsoft has made new versions of most of their software, such as Office, Mail, etc, that work with the new interface. Many other developers are in the process of creating similar programs. This leaves developers such as myself with a quandary. Some say that this new "Modern UI" interface is the future and the old Windows desktop will ultimately be replaced, in the same way that DOS was replaced by Windows itself. But I'm a little skeptical about that. It may be that the new interface will not be powerful enough for certain types of applications--those driven by the precision that only a mouse can provide.

An example of what I'm talking about is the way that SkyTools identifies objects as the cursor passes over them. This obviously isn't possible without a mouse. On the other hand, a touch-based Nightly Planner would provide a natural jumping off point for opening charts, logs, and other SkyTools functions. It would also provide a great way to control a telescope in the field.

At the moment the way forward for SkyTools is not yet completely clear. Will it continue to be a desktop program or be ported to the new interface? I can say this for the near term: there will be "companion apps" for SkyTools that use the new interface for use in the field on tablets and other touch devices. But only time will tell if the entire program will eventually be ported to the new interface.

New Windows 8 Hardware and SkyTools
If you are purchasing a new Windows 8 tablet, it is important to be aware that there are two "flavors" and what the differences are. The less expensive "Windows RT" tablets only run programs written for the new interface. They will not run SkyTools 3! These tablets will eventually run the SkyTools "companion apps" which will be available for the next full version of SkyTools.

The more expensive tablets/convertibles will offer the full version of Windows that desktop users have. These will run SkyTools 3 on the traditional desktop.

Should You Upgrade?
Some people are going to hate Windows 8. There is no question about that. I think it comes down to how you approach change. An example of something that is bound to drive old timers like me nuts is the way the Esc key doesn't back out of the new-style programs as we might expect it to. Instead, we are going to have to accept that the "Start/Windows" key (which I personally have ignored for years) is going to become our new friend. Still, I did eventually get used to it (after a few hours spent cursing). There are also times when using the new interface that you will think, "I could have done that with a lot fewer movements and clicks!" But I have found that in most of these cases there are ultimately better ways to do the task, such as a keyboard shortcut. It is often my natural desire to do things the way I'm used to doing them that is the cause of most of the trouble.

Some have claimed that Windows 8 will have big problems like Vista did, and it is popular to claim that they won't have things ironed out until Windows 9. The reality is a bit more subtle than that. On the desktop things are pretty solid, although there are some weird issues that crop up. One of my computers didn't shut down properly using the Windows 8 preview version (there was an easy work around) and sometimes system error messages appear on the desktop where you can't see them. But in general I don't believe that upgrading a desktop/laptop to Windows 8 will cause people anywhere near the problems they had with Vista. This is primarily due to the fact that for most users it's really still Windows 7 under the hood. When Vista appeared I counseled people not to upgrade their existing XP machines, but I see little reason not to upgrade to Windows 8, particularly when it can be easily done as a download for $40.

On the other hand, the picture may not be so rosy for the new Windows RT tablets. This is where most of the new aspects of Windows are concentrated and it has had the least testing on this hardware, so this is where people will likely see the most trouble. At the moment there aren't enough quality apps available to make these tablets as useful as they should be. As an example, Microsoft's Mail app doesn't have many of the features people expect, crashes constantly, and I was not successful in getting it to send mail to my outgoing mail server. On a desktop/laptop many other options are available, but I feel a bit sorry for the early adopters of Windows RT tablets. I'm looking forward to owning one of these myself, but I'll wait until things are sorted out.

Although I've been testing the new OS for months, the first computer that I officially upgraded was my laptop. It does boot a bit more quickly and runs a bit faster. Overall I'm happy with it. Multi-monitor support has been improved and I like the new Task Manager. But for many there may not be any compelling reason to upgrade right away. This is the future of the PC, and only Windows 8 will give us access to the new software designed for the new interface. It's sort of like having a new toy added to the old OS. But some will see it as a useless appendage that only gets in their way. There are also the inevitable problems and annoyances that come with any major change to your computer. In the end, the most compelling reason to upgrade an existing desktop/laptop in the next few months is that the $40 upgrade may only be available until the end of January.

Personally, I would certainly go ahead and purchase any new computer with Windows 8 pre-installed.

Regardless, I urge even the most tech savvy to review the basics of the Windows 8 interface before trying to use it. This will make the transition go a lot more smoothly.

Going to NEAF

It's been a while since my last post here. Despite the slow economy SkyTools 3 is still going very strong and I couldn't be more pleased. I am in the final stages of the release of a major update to version 3.1, which adds some minor new features, fixes some annoyances, and makes the program even more stable than it already was.

Yesterday I received my copy of the April 2010 Sky & Telescope, which (finally!) has a review. It was well worth the wait because they did a very nice job on it. In the past they sent a copy out for review to someone who was not familiar with the program and they didn't always get it. Their review for SkyTools 2 was titled, "A 20th Century Log Book." No-seriously! I didn't know about the review before hand and happened to pick up a copy of the magazine. I read past the first paragraph before it slowly dawned on me--with a sick feeling in my stomach--that it was a review of my software. That, and they didn't give it much space. To add insult to injury, the very next issue had a comprehensive review of Megastar (a competitor) written by someone who uses the software regularly--someone who got it. To make matters worse it was a relatively minor upgrade to Megastar whereas I had pushed forward with all these cutting-edge features for SkyTools. Let's just say my blood pressure got a little up over the whole thing. Thankfully this time the review did a wonderful job of describing what SkyTools is.

Mrs. Skyhound and I are going to attend NEAF this year. We only made it out once before, I think in 2001, so it has been a long time. We are really looking forward to seeing everyone. If you attend, please come by and chat.

The Personal Computer Revolution

I was recently asked what my programming philosophy was and it got me thinking. In a nutshell, my philosophy is that, when at its best, the personal computer represents a revolution in how we do things rather than a mere evolution.

A lot of programmers of my generation fell into a trap. They adapted existing paradigms to the personal computer rather than rethink the idea to fit the new paradigm that the computer represented. For me the classic example is Monopoly. Monopoly is a simulation of the world of high finance created for the board game paradigm. Programmers set out to adapt the board game for play on the computer, but to me that was missing the whole point. Why have the computer simulate a simulation designed for another technology? It seemed to me that what you really wanted to do was to rethink a simulation of the world of high finance in terms of the computer paradigm.

My favorite example of this is TiVo. When it became clear that the VCR could be replaced by a basic computer and hard drive, someone needed to create a software interface. Most programmers set out to recreate the familiar VCR, only on a computer. But the programmers who created TiVo took a different approach. They started over from scratch, re-imagining TV as if the VCR had never existed. They asked themselves, "In my wildest dreams what would I want a computer/TV to be able to do?" And in so doing they fundamentally changed the way we watch TV.

I really admire what they did with TiVo. My philosophy has always included a willingness to start over from scratch--to think big--to re-imagine how an existing task can be done on a personal computer. For me this is what makes computers exciting.

This is why SkyTools can't be easily pigeon-holed as a "planner" or "planetarium" or "star charting" program. It's for the same reason TiVo isn't a mere "VCR" program. The "planner" has its roots in the early days of computing when you logged into a large mainframe on a remote terminal and printed out your data on wide sheets of paper that you picked up at the computer center. The Planetarium is a projector that recreates the sky on the ceiling. It is used primarily to educate people about the sky and its motions. And of course a paper star chart is like a road map of the sky.

While there are similarities, SkyTools is more than a representation of these things on a computer. No, it's a suite of software tools designed to help people observe at the telescope. That's why I call it Observing Software.

Success

Nightmare number 1: large numbers of SkyTools 3 CD/DVD packages are ordered costing big bucks. But I made a huge mistake in the installer or I forgot to include some important data file. I am deluged by upset customers.

Nightmare number 2: nobody likes it and large numbers of people want to return it for a refund.

I am happy to report that neither of these scenarios came to pass. I did come across some relatively minor problems, but I had an update ready before the first copies were even shipped, and with our new automatic update system the updates went very smoothly. As with any large complex program suddenly having hundreds of people using it is bound to uncover bugs that had been missed by the much smaller test team. To the enormous credit of the test team only a relatively few issues have been reported and none of them were major. I expect to release another update this weekend.

Perhaps the most complex task in SkyTools 3 was the new Synchronization feature. This feature is among the first things people who are upgrading from SkyTools 2 are going to use, as it allows them to transfer their SkyTools 2 telescopes, observing lists, etc. for use with SkyTools 3. We first tested this with the beta team over a year ago and it broke in about a dozen different ways, seemingly in a unique way for each team member. I had them send me their SkyTools 2 data, one by one, and for each I tracked the problem down.

When we started the Real Time testing in February we added more testers. Again, many of the new testers had an issue importing their SkyTools 2 data. Again, I had them send me their SkyTools 2 data, one by one, and for each I tracked the problem down.

When we started the Pro Edition testing in September we added 20 more testers. Once again, many of them had an issue importing their SkyTools 2 data. I had them send me their SkyTools 2 data, one by one, and for each I tracked the problem down. This time there was a new twist: SkyTools 3 started having trouble syncing to itself. In all this testing only one function worked flawlessly almost from the start: the import of SkyTools 2 observing logs. So guess what broke in the release version?

Several people reported that none of their log entries for planets imported properly. I tried it myself (for the 300th time) and sure enough my planet logs were missing. They were working before... solving this mystery is my project for later today. Fortunately, once the problem is resolved people will merely have to perform the import again. There should be little inconvenience.

The reception to SkyTools 3 has been overwhelmingly positive, which is very satisfying. The following comment in particular regarding the new imaging features brought a big smile to my face:

I'm sending you a copy of the Rosette Nebula (NGC 2237) image I captured on 1-1-2009. It has a SNL of 15 and I used your Exposure Calculator to determine the proper exposure settings needed to capture it. The image came out far better than if I used my stock exposure settings of 4xLRGB @ 600s. So far all the images I've taken that use the SkyTools3 recommended exposure settings have come out very nicely. I know it took as a lot of hard work to model everything needed to make your exposure calculator work so well. The calculator alone is worth the price of the software and as far as I know no other commercial software package has one.

Whew!

The Hurry up and Wait

SkyTools 3 is done. Both editions were completed last week.

It's a bizarre experience. There I am working toward something that has taken four or five years to accomplish, depending on how you count it. As the final months come the days-off get fewer and fewer. As the final weeks come the days-off disappear completely and the work days grow longer. Constant coding turns into creating artwork for the packaging. The last few days become a blur. Code that was prepared months ago that is only used in the final product is at last integrated. The bugs continue to flow in from the test team and must be squashed immediately, even if it means a late night. Plans that were made years ago are put into motion. The website must be updated. Difficult but critical questions have to be answered, such as, "How many of each edition should I have made?" And above all there is that constant, ever present question: "Did I forget something?"

It all builds to that that final day when the final CD master is burned, somehow always only ten minutes before the UPS overnight pickup deadline. The package is sealed and raced to the drop. And then its over.

It will be two weeks of waiting before the packages are returned and we can start shipping.

People keep asking me, "Is it done yet?" and I just stare at them, dumbstruck. Saturday morning comes and I feel guilty for not getting up early to go to work. My desk is a mess. I guess I should clean it off now. The "to do" lists that ran pages every day now only run a page for the week. It is peaceful. Serene. But that constant, ever present question remains: "Did I forget something?"

It's like a Shuttle launch but sort of backward. There is a slow ramp up of thrust that builds to the great deafening explosion of launch, followed immediately by an equally deafening quiet and a feeling of weightlessness... of drifting.

And of course, "Did I forget something?"

Asteroid Excess

We're about ready to start the final testing of the "Pro" version of SkyTools. There are just a few loose ends left to tie up, such as the new serial number code, enhancing the installer, etc.

Oh, and all those pesky asteroids.

When I first wrote the asteroid code for SkyTools there were between 8000 and 9000 known. By the time SkyTools 2 came out there were so many that I only put the first 10,000 numbered asteroids on the CD because there wasn't enough room for them all. Today there are nearly 200,000! That's so many that drawing asteroids on a chart is really bogging down.

Here's how the asteroids that are shipped with SkyTools work: asteroids use osculating elements, which are a sort of cheat. These elements would describe the orbit of the asteroid perfectly if there were no other bodies in the solar system. But with all those other asteroids and planets out there the reality is that each asteroid gets tugged around over time, changing its orbit. So the orbits we use are sort of freshness dated. They are good for about 40 days. What I do is run whats called an "n-body" program that carefully computes the position of each asteroid over many years, including all the tugging. Every 40 days a new set of orbital elements are generated. When you ask for the position of an asteroid SkyTools finds the set of elements closest to your time and uses it to compute the position.

The supplemental asteroids, which are downloaded over the web, work in much the same way. Each new set of elements you download gets added to the database. Over time you will build up a database that covers months and even years.

This all works pretty well, except for how long it can take to run through the nearly 200,000 asteroids sorting out the ones bright enough and within the bounds of your chart. Fortunately I had an idea come to me in the middle of the night a few months ago. It's one of those ideas that I would really like to claim is perfectly brilliant, yet it's so obvious I probably really ought to be ashamed I hadn't thought of it before.

The idea is to store a set of positions and magnitudes along with the orbital elements for each asteroid. Since the elements are only used for a known 40-day period we can compute a list of positions over that period (using the elements). When we want the position we interpolate to get a good idea of the position and magnitude of the asteroid. Only if the asteroid is on the chart do we go ahead and compute the accurate position. Interpolation is cheap so the end result is that the asteroids plot a lot faster. How much faster, I'm not quite sure yet. But I expect it to speed things up a lot.

Unfortunately there is a downside. The positions stored with the elements have to be pre-computed. I just tried downloading and pre-computing all the known asteroids and it took a whopping 8 minutes on my aging computer. In fact, that's why I'm writing this. I'm running another test and it's a long wait...

Fortunately I have some ideas for speeding it up!

P.S. I tested the new asteroid code and it is 12x faster!

Imagining Imaging

I have some great news. But first some background.

Years ago I had a simple idea: extend what SkyTools does for the planning of visual observations to planning imaging sessions. It seemed trivial because the two kinds of planning are so similar. After all, it's still about observing an object high in a dark sky. It seemed that all it would take would be a few tweaks to make the planner more imaging friendly.

In designing the planner for visual observing my approach was to come up with the basic questions that an observer might want answers to, such as, "Can I see this object in my telescope from my backyard tonight?" Or, "Which of these objects in my list should I observe tonight?" And, "When is the best time to observe this object tonight?"

To answer these questions I borrowed, enhanced, and even developed from scratch science-based models for atmospheric extinction, the brightness of the sky, and the visibility of objects in the telescope. In SkyTools 3 these models are now very sophisticated. To make these models work you must teach SkyTools about your telescope, your observing location, and a even a little about yourself. Many people don't realize it, but the ability of SkyTools to compute the optimum time to observe an object is the critical component. I leverage this ability in every way I can think of to create the various visual observing tools. This optimum time computation, along with the quality of observation assessment that makes it work, are the engines that makes SkyTools go.

For imaging support I turned to the very same process: create a list of questions to answer, develop a science-based imaging model, and allow the user to tell SkyTools about their imaging system. I did most of the model last summer and I was pleased with the results. But a nagging question remained: what was the analogue to the optimum times for visual observing that would serve as the engine for planning imaging sessions? And not only that, but in the end would I be able to offer something more than what is already available? Is there a useful niche for SkyTools to fill in the imaging world? These questions have nagged me for over a year now. I knew that at the heart of deep sky imaging is signal to noise ratio (SNR), but how to leverage it? Visual observing is about a brief moment in time, but imaging is about an exposure that can last many minutes or even hours. And unlike visual observing the brightness of the sky is not always critical. So the questions become, "Should I bother to image this object from my light polluted back yard or wait until I can get to a dark site?" Or, "Is it worth imaging when the moon is up?" These questions simplify to, "If I do image in a bright sky, how many more exposures will I need to get the same result?" And, "Is there enough time to make it worthwhile?"

To be honest with you, even as recently as a few weeks ago I didn't know how to best answers these questions. I had most of the pieces in place for planning imaging sessions, but it had yet to come together. Programming for me is a lot like digging a tunnel through a mountain, where you start at each end and hope to meet in the middle. I've been told that a "good" software developer (or team) sits down and designs the entire project in advance. But I have found, at least for me, that in practice this is usually only a good start. Not only do problems emerge that you had not anticipated, but the very act of writing the code often brings new insights. So as I build the code both from the bottom up and from the top down I try to remain as flexible as possible. The process that unfolds feels like a journey. I'm never really certain how it's all going to work out. Where will we meet in the middle? Will the result be useful? In many ways I feel like I'm just along for the ride, following along where the code takes me. Thankfully this creative process has seldom failed me. (Unlike my predictions for how long things will take!)

I am pleased to announce that my ride is almost done. Things have come together. Important questions now have answers, and I look over what I have created and I am excited by the result. The feeling of satisfaction derived from taking an idea from a mere formless seed to fruition is wonderful. This is what it's all about for me!

We should begin beta testing the Pro version (with imaging support) in a few weeks. I am very excited about sharing it with everyone and equally excited about working with the team to put a nice polish on it.

Real (long) Time

It's Monday, I have a headache and I don't feel much like working, so I thought I'd finally post something on my blog. Usually what happens is if I think about writing something I decide that working on the program is a better use of my time. That's why you haven't heard from me much in the last few months.

Before I get to the fun stuff, let me say that "it" has happened again. At every point in the process of developing SkyTools 3 I have run into the very same problem, and even I, head deeply buried in the sand, am beginning to see a trend. I have been operating under a very basic misconception. I know this may sound ludicrous to some of you but I naively thought that SkyTools 3 would be easier than SkyTools 2. My reasoning went something like this: ignoring the database updates, which I know is always an enormous job, most of the actual programming was already in place. To add a new feature or extend functionality would be simple. But that is not the case. Instead, as the program becomes ever larger and more complex, just about anything I do to it becomes more difficult, requiring ever more time and testing. It has become rather clear that the methods I had used up to now, which had served me well, are no longer viable. I have begun to rethink everything with one goal: to release an upgrade every two years. Wish me luck.

Looking at the calendar I can see it is already April and I haven't got the Pro version testing up and running yet. The main reason is that, once again, I have greatly underestimated how much there was to be done. Not to mention all the distractions, like spending several hectic days and late nights last week moving my web site to a more reliable host. And even the testing is proceeding much more slowly than our original Real Time testing did. For instance, I released a bunch of new Real Time features last Friday with the expectation that at least some testers would try them out over the weekend. But so far I have heard nothing. I don't know if it's weather, if the testers have lost interest, or what. Regardless, it is a bit disheartening. I'll have to move on. And when bug reports finally do come in I'll have to go back and figure out what I did, where the code is, remind myself how it all works, and in the process leave what I have started in the meantime half finished. Then I'll have a similar problem when I go back to what I was working on.

But as always, there is a pretty big pot for at the end of this rainbow for SkyTools users. My knack for overreaching means that there are many new features, several of which were unplanned. Here are some of the highlights:

Offset Tracking: telescopes that support this capability can be set to follow slow moving objects. This can be done by entering the R.A. and Dec. rates manually, or by letting SkyTools to it automatically; just target a Comet or Asteroid and the telescope should automatically track its motion. I can't wait to hear from someone how it actually works in the field!

Mount Alignment tool: I have developed a simple, but I think very useful, tool to align your telescope mount via the drift alignment method. SkyTools will pick an appropriate star for you, target your telescope if connected, and display a finder chart. The best part is that the eyepiece view of the chart splits the sky into north and south zones that are labeled by the direction in which you should move your mount. It takes all the guess work and confusion out of the process. I am really happy with it, but again, I'm anxiously awaiting to hear what the testers think.

Native Argo Navis support: in addition to directly supporting the Argo Navis in Pushto mode now you can download SkyTools observing lists to the unit for use in the field. Comet and asteroid orbital elements are automatically uploaded and you will be able to give each list of objects its own identification to help organize your observing.

I have also added support for Pier flipping and selecting basic tracking rates.

Finally, in the process of making charts for finding the exact location of each pole for polar alignment, I realized that SkyTools was somewhat deficient when it came to targeting the poles. So I added a new "object" classification called Reference Points, which includes the Celestial Poles, Galactic poles, galactic center and Zenith. These reference points can be chart targets, added to observing lists, and appear labeled on the charts.

As you can clearly see, I got carried away again.

Time to Get Real

I am pleased to report that the standard edition test/development is finally winding down. There are still some loose ends (there always are) but the vast majority of the program is now in its final state. Man, it's been a really long haul!

The next step is to begin the Real Time testing. I nearly have all the new SkyTools 3 features integrated into the Real Time tab. In the next day or two I'll release it to the team for basic testing, which I have every reason to expect will go quickly. Then the fun begins! I've sketched out the new mounts and ASCOM features that I want to extend Real Time to support. Primarily that will involve adding support for the Argo Navis, Servo Cat, and various push-to devices based on the Tangent chip. Working in tandem with a test team is essential for this next step since I don't have access to any of these devices. Nevertheless, based on previous experience with Real Time, for once I'm confident that this won't take more than a few weeks.

Meet the Nightly Observing List Generator

The new Nightly Observing List Generator finally exists outside of my imagination and has had it's tires kicked around by the test team. It is exhilarating and a bit scary to bring a new feature to life, particularly when I've been thinking about it for a long time. There's just no telling how it's going to work out ahead of time. It's sort of like having children. You do your best and see what happens as they take on a life of their own.

Sometimes things go badly. It may turn out that all the pieces aren't yet in place to really make it work, or that some unexpected development has left the whole idea lame and unworkable. Sometimes I just can't make it all come together to my satisfaction.

But most of the time a new idea soars. I try my best to let it do that, allowing for major changes and redesigns right up to the last minute. Having a sound design going in is very important, but I've found that the best tools evolve in ways that I can't imagine ahead of time. I see it as my job to let them do so. I simply try to hang on for the ride and when we land see where it all ended up. And here we are...


All-in-all I'm very happy with it and the test team is all thumbs up! Most of the concerns I had going in have been worked around to my satisfaction and there were some pretty cool developments along the way. One of my favorites is in the Shallow Sky auto-generated list. Among other things it looks for any fast-moving minor planets that may be visible that night. Another really cool one is in the Interesting Stars feature. As part of its function it looks for eclipsing variable stars with deep eclipses and only lists those that are predicted to be in eclipse that night. Very cool.

Another thing I really like is the ability to prune the list to a small set of randomly selected objects. I enjoy knowing that every time I create an auto-generated list of NGC/IC objects it will give me a unique set of targets for that night. There are so many galaxies and clusters available in my 18-inch. It's like closing my eyes and putting my finger on the atlas to pick my targets. Who knows what I'll find there. Yet with this tool I can be assured that the object will be a reasonably good target that is appropriate for my telescope.

Perhaps the most useful auto-generated list is the one that spawned the idea in the first place: the Showpieces listing. I've already used it myself when I had to be at a star party with very little time to prepare. Recommended targets included the setting moon, Mars, comet 17P Holmes, several nice double stars, and a good assortment of deep sky objects of various types. Planning doesn't get any easier than that!

The Last Piece

For some time now we've been testing/developing the new Database Power Search on a tab-by-tab basis. Last week I released the new Comets search tab to the test group, and the week before that it was the new Asteroid search. Together they should provide a very interesting tool for mining the databases. For instance, you can filter by asteroid type, such as "Aten" or "Apollo" or "Damacloid." Classifying asteroids and Trans Neptunian Objects by the orbit type is one of the cooler things I've added under the hood, and it's been fun trying to make the most if it. The comet search will be useful for finding out which comet your Grandma saw in the summer of '32 or to look for comets with similar orbits. But of course paramount is always the intelligent selection of observing targets. To aid with that I have added a new Visual Detectability filter and for double stars there is a new Splittability filter. These filters rely on the models I developed to predict the visibility of an object in the eyepiece, and how difficult it will be to split a given pair. Visual observers can use these filters to find "difficult pairs" or "easy" deep sky objects based on their inputs such as date, location and instrument.

At first glance the new DPS looks a lot like the old one, but it soon becomes apparent that it's been supersized. I've tried to make small improvements across the board that together add up to something a lot more powerful.

With the DPS done except for a few bug fixes, over the weekend I took up the last piece of the Standard Edition of ST3. I originally called it the Observing List Generator then decided it was an Observing List Wizard. The thing has been evolving so quickly that naming it was a waste of time. It's been part of the Database Power Search, a separate tool, and as late as last night I was considering an entire new tab on the planner for it!

One way or another by the end of this week it is going to exist outside of my imagination. I think you will all like it. Basically it allows you to quickly create a list of objects to observe on a specific night. The gold standard all along has been that it's 4:00 PM and there's a public star party tonight and you are in charge of having something to show people. "SkyTools, help! I'm in a hurry. Just give me a list!" It does more than that, but this particular application has been the driving force behind the tool. Wish me luck!

Now a word about where we are at: after this last tool is released to the testers I'll still have a lot of loose ends to tie up. There are some bugs that still need fixing and a lot of little things that need smoothing over or to be brought up to par with the rest of the program. So my plan is to call a hiatus for the test group for the month of December. I'll go about getting everything finalized and after the first of the year we will have a real beta test. That should not take long. I will also get the Real Time tool ready and we will start a new test as soon as possible, perhaps even concurrently with the other test. When that's done I want to meet with interested imagers and together we will finalize the imaging features for the Pro Edition. The good news is that SkyTools is like a big pyramid and all this stuff is that little part at the top. So I am hopeful we will see a release early next spring.

Crazyness

I've been waiting to have some sort of progress milestone to report, but it's been so long that I felt I had to write something.

How are things going with SkyTools 3? Great! Um... Terribly! I suppose it's the usual combination of the two. The testing end has gone very well, and I am very happy with the program. But this is taking way longer than I had hoped. I mean, it's just plain embarrassing.

I have done this sort of combined development/testing before and it has worked very well. Not only do I fix bugs but I use the feedback from the test group to help me find the rough edges and polish things up. Sometimes I even get inspired and make sweeping changes or add unplanned functionality. This is something that a software engineer under the thumb of management and up against a deadline would not typically be able to do. That's usually a good thing for me, at least from the standpoint of producing the highest quality software possible, which is something that is very important to me. But I'm finding that as SkyTools becomes more and more complex that it is becoming more and more time consuming for me to make sweeping changes. When in the past a major rewrite or unplanned feature might have cost me a few days to a week, this time around it's taking a lot longer.

I have spent the last few weeks redoing the Database Power Search. It started innocently enough: I just needed to work in the new visual detection difficulty filter. That would take a day or two at most. But then I started to realize how much more this tool could and should be doing. Now that dialogs can be larger than 640x480 I had the screen space to make this thing really powerful. Not only that, but I realized that if I split the "Deep Sky" search tab into two tabs (Galactic and Extragalactic) I'd have even more room to add functionality. So first it was this, and then that, and then one more little thing, and all the while the beta test has more or less come to a halt. Like I said, it's embarrassing!

But I keep reminding myself of one thing: a year from now few people will remember the delays. What they will remember is that really cool Database Power Search tool that finally truly lives up to it's name.

That Syncing Feeling

Unfortunately things have bogged down. I could blame it on the kid's school starting, Mrs. Skyhound going back to work, various appointments, etc. But the real problem is that the new Sync feature is, well... out of sync.

The Sync feature allows the user to synchronize their data between two computers. The main point of this is so we can easily move our observing preparations onto our laptop to take into the field, and then easily move the results, such as log entries, back to our desktop. It's a sort of non-destructive backup/restore process, that seamlessly merges the data on one computer into the data on another without losing anything in the process.

Unfortunately, doing that is a huge pain in the ass. Actually, since we are talking about multiple databases here: observing lists, images, logs, notes, telescopes, locations, charts, observers, object notes, web links, etc., it's more like a huge pain in the ass times 50.

I originally did the groundwork for this code last fall. In the meantime, I dramatically underestimated how much of it had been completed back then. Not only that, but changes I have made since have to be folded in and it's been a bit like folding bowling balls into a soufflé. Worse yet, I discovered that I had cheated last fall and much of the code didn't really do what I wanted it to do.

** Sigh **

So while the beta test team is hopefully enjoying some time away from SkyTools I am working hard trying to get, well... back in sync.

The Campground Commute

The Skyhound kids wanted to go camping again before school started, but the Mrs. and I were too busy for a long trip away from home. So we hit on the idea of camping in our own forest here in the Sacramento Mountains. After all, people come from a long way to camp here so why shouldn't we? So we pitched our tent at a local campground less than 0.8 miles away from home! I spent several days commuting to work from the camp site.

I've been hunkered down for the last few days trying to get the next test version ready. The backup and restore functions are finished and they successfully restored my own SkyTools 2 files, which was no small feat. In addition there have been a lot of minor fixes.

The hitch is that I have finally decided to dump the InstallShield installer. Those people are nothing but money grubbers anyhow. Their business model is designed to milk large corporations of significant sums of money. I am not a large cooperation with large sums of money. I wish I had never given them any of mine in the first place; their installer has been nothing but trouble from the start. What really ticks me off is the way they lured me in with what appeared to be a fully functional program, but hidden deep inside were intentional limitations meant to make me pony up more money for a more sophisticated version.

So the next task is to create a new install script using the NSIS installer. But I'm too burned out to start the process... I miss the tent! It kept me from working too much. Time for a break.