Logging astronomical observations is a very personal thing, and not all observers keep a log. Perhaps visual observers are the least likely to record observations but many do. Most imagers at least keep records of their exposures, and the end product - an image - serves as excellent documentation. Sketchers probably keep the best records of all since their work is, by definition, recording detail manually. With observers' logging habits so varied, why do we want or need a standard?
From an observer's viewpoint, it may be less than apparent. Many of us record observations so that we can refer back to them and determine whether we've seen something before, or how it looked in the past, or when and where we saw it. Others collect observations and present them for an award. Still others want to publish particular observations on a website or blog. This really defines 3 different usages: searching, managing and reporting. There are, of course, many ways to meet these use cases: using pen and paper, a word processor, a spreadsheet or a database are the usual suspects. Any of these work well as long as we want to stay within the same process - a closed system in the algebraic sense.
So what if we want to venture forth from our tried and true logging practice? Perhaps we want to contribute an observation to a scientific collection (e.g., AAVSO), or publish them onto the web, or enter them into a program that offers a new, desirable capability? These cases require re-entry of the logged data to some extent, a tedious process at best. Worse yet, what if your log becomes inaccessible? Think of a hard drive crash, lost installation disc and a program that is no longer supported. Yuck.
Enter a standard file format for observing logs. The first three cases mentioned above are likely to be solved by having a standard because the more common the use case, the more likely that someone can, or will, solve the problem at least once. As a developer, I would be happy to support one exchange format, but supporting one for every file format requested by users is hard to justify.
The disaster scenario described above is perhaps the best reason for users to demand a standard log file format. I like to think of it as a warranty for the observation data I have spent years accumulating. If a program I have used to record observations either stops being updated or becomes less appealing, at least my data can move forward with me via a standard format file.
Developers will only support a standard if it is a marketable feature. That means that users will have to demand it as a must-have feature for a standard to gain the traction that makes one ubiquitous.
I wonder how many more observers would record their observations if they could enter them once and be assured that they wouldn't have to re-enter them time and time again. I also wonder how many scientifically valuable observations are lost because they can't get out into the astronomy community.
Until there is a standard available for users to demand and for developers to support, the arguments above are just conversation material. Fortunately there is a candidate under development. More on that next time.
22 November 2008
07 October 2008
Updated SQM-LE Reader
In my last post, I mentioned the imminent release of a new model of Sky Quality Meter. Unihedron released the new product on time and it is shipping now.
Since that post I've had some time to use the meter with SQM-LE Reader software. One of the first questions a friend asked was 'what does the reading really mean?' He was looking for a way to relate the reading in magnitudes per square arcsecond to something more familiar - like visual limiting magnitude. Fortunately, the Unihedron website has a link to such a computation.
It became apparent quickly that SQM-LE Reader should include this computation along with other reading data. Furthermore, the ability to write readings to a comma separated value file was needed; whence, SQM-LE Reader v1.1. The CSV file format is easily imported into a spreadsheet for further analysis, or browsed with a text file utility such as notepad. These capabilities will appear in a future release of Deep-Sky Planner, but in the meantime they are available for free in SQM-LE Reader.
With these tools in hand, I hope to quantify the darkness of observing sites over the span of an evening, and over the span of seasons. I'd also like to determine whether the visual limiting magnitude computation is accurate (at least for my eyes.) I look forward to collecting and analyzing data over the coming months.
Finally, I've compared readings from the new model with those taken simultaneously with an SQM-L model device. The readings are consistently within .01 of each other, well within the stated accuracy of the device. How about that - delivered on time and functioning to specification!
Since that post I've had some time to use the meter with SQM-LE Reader software. One of the first questions a friend asked was 'what does the reading really mean?' He was looking for a way to relate the reading in magnitudes per square arcsecond to something more familiar - like visual limiting magnitude. Fortunately, the Unihedron website has a link to such a computation.
It became apparent quickly that SQM-LE Reader should include this computation along with other reading data. Furthermore, the ability to write readings to a comma separated value file was needed; whence, SQM-LE Reader v1.1. The CSV file format is easily imported into a spreadsheet for further analysis, or browsed with a text file utility such as notepad. These capabilities will appear in a future release of Deep-Sky Planner, but in the meantime they are available for free in SQM-LE Reader.
With these tools in hand, I hope to quantify the darkness of observing sites over the span of an evening, and over the span of seasons. I'd also like to determine whether the visual limiting magnitude computation is accurate (at least for my eyes.) I look forward to collecting and analyzing data over the coming months.
Finally, I've compared readings from the new model with those taken simultaneously with an SQM-L model device. The readings are consistently within .01 of each other, well within the stated accuracy of the device. How about that - delivered on time and functioning to specification!
18 September 2008
Pacific Astronomy & Telescope Show
The First Annual Pacific Astronomy and Telescope Show (PATS) was held in Pasadena, CA on Sep 13-14. There were a few new wares to be seen which was exciting and fun. The long trip from North Carolina to California, coupled with intermittent Internet service at our hotel, has resulted in a delay in posting this report. Having returned to the office now, here are some highlights of the show.
Saturday was the busier day by far and included the big announcement from Tele Vue of yet more Ethos eyepiece models. Knightware joined the new product fray by announcing SQM-LE Reader, a free program that can be used to read and display data from Unihedron's new Sky Quality Meter LE. The new device is scheduled to begin shipping at the end of this month but the software is available now (http://knightware.biz/sqmreader.htm). To get an idea of how the meter looks, note in the photo below the small black box in front of yours truly, attached to the yellow cable. That's an engineering sample but the shipped version will look the same.
We had the pleasure of talking to many, many interested attendees and met some long-time users of Deep-Sky Planner. It's wonderful to put faces to names. In addition to attendees, we spoke with several product engineers, software developers and store owners. It's always good to get a read on the astronomy product marketplace from the perspective of suppliers. Further, we had some detailed discussions of ideas for new features for Deep-Sky Planner. Explaining the software's capabilities now, and exploring new ideas for it in the future are helpful ways of defining the product.
This show has all the promise of becoming an annual destination for amateur astronomers on the west coast. The organizers obviously did a huge amount of work bringing this show together.
All photos by Mark Lang
25 August 2008
Command & Control
Knightware has been working recently on providing support for a new partner's upcoming product. While the official announcement will have to wait a bit longer, I can divulge that this bit of work has allowed me to return to my roots - back into the realm of data acquisition and control work.
Maybe it's a summertime thing...
The last data acquisition and control work that came through the office was about 15 months ago when support for DSC and telescope control was added to Deep-Sky Planner. Testing different ASCOM driver implementations was a reminder of how differently device manufacturers design their products' communication and control capabilities. Synchronous telescope control? Yuck.
For most of the first 20 years of my career, I worked on data acquisition and control with various devices ranging from the US Navy's NavStar satellite navigation system (a predecessor to today's GPS), to F-14 air combat simulators, to electronic power meters. Fortunately, the 'control' part of my experience applied only to power meters. Power usage and substation relays are not as exciting (grin) as F-14 weapons systems and navigation satellites.
Although working with telescope control was fun, testing this upcoming product has been a joy. Communications are very clean and stable. Torture testing has been a real disappointment - no big hang ups even with Vista. A little more testing and we'll call this a wrap.
More to come!
Please tune in to this blog Sep 13-14 or visit the Knightware booth at the Pacific Astronomy and Telescope Show. We'll be talking about Deep-Sky Planner and putting it through its paces, and we plan to announce support for the mystery product too.
Maybe it's a summertime thing...
The last data acquisition and control work that came through the office was about 15 months ago when support for DSC and telescope control was added to Deep-Sky Planner. Testing different ASCOM driver implementations was a reminder of how differently device manufacturers design their products' communication and control capabilities. Synchronous telescope control? Yuck.
For most of the first 20 years of my career, I worked on data acquisition and control with various devices ranging from the US Navy's NavStar satellite navigation system (a predecessor to today's GPS), to F-14 air combat simulators, to electronic power meters. Fortunately, the 'control' part of my experience applied only to power meters. Power usage and substation relays are not as exciting (grin) as F-14 weapons systems and navigation satellites.
Although working with telescope control was fun, testing this upcoming product has been a joy. Communications are very clean and stable. Torture testing has been a real disappointment - no big hang ups even with Vista. A little more testing and we'll call this a wrap.
More to come!
Please tune in to this blog Sep 13-14 or visit the Knightware booth at the Pacific Astronomy and Telescope Show. We'll be talking about Deep-Sky Planner and putting it through its paces, and we plan to announce support for the mystery product too.
20 July 2008
Apollo's Legacy
When Apollo 11 landed successfully on the moon 39 years ago today, my life changed. I was allowed to stay up past bedtime that night to watch the murky pictures of Neil Armstrong stepping onto the lunar surface and uttering those now famous words. He chose them well as it was truly 'a giant leap for mankind.' Watching the events unfold reaffirmed my fascination with science and space exploration. At that point in my life, I was sure that I would be the first person to set foot on Mars. I took another road more traveled, and NASA lost focus on that very difficult goal, but the impact of that successful moon landing has never left me. Even now when I see that video from the moon I get goosebumps and a tear, emanating from several things: relief that the astronauts came back safely, a deep appreciation for the science and engineering that was required and pride in America.
I wonder how many of today's scientists were pushed into their fields by the success of Apollo, and what the value of their contributions to mankind might be. Maybe the Apollo missions were a bargain in terms of money. If you think of the role that technology plays in society now, it's hard to imagine where we would be if technology had not developed quite to the point that it has.
A couple of nights ago, I watched a particularly favorable pass of the ISS with my son and husband. As husband took photos, my son asked whether the ISS would be a resupply station for missions to the moon. While I didn't say it, I was thinking that my teenage son's generation just might be affected by a return to the moon as mine was nearly 40 years ago. I hope that it works out that way, and that society can benefit from another burst in technological innovation. Maybe ISS will resupply more than just materiel.
Photo courtesy of NASA
02 June 2008
What to Call Them?
As far as Deep-Sky Planner is concerned, minor planets shall henceforth be called asteroids ...
While implementing support for minor planets in late 2006 for Deep-Sky Planner, I had a real dilemma as to whether these objects should be called 'minor planets' or 'asteroids'. The IAU meeting in Prague the previous summer had just brought the term 'dwarf planet' onto the world stage, and demoted Pluto to some mysterious status that still befuddles me. The term 'minor planet' seemed a little like damaged goods.
On the other hand, the Minor Planet Center was the purveyor of orbital elements for these beasts, so the term 'minor planet' must have been the best moniker. So 'minor planet' stuck.
In the November 2006 issue of Sky & Telescope, Editor In Chief Rick Fienberg wrote about the IAU shenanigans in his Spectrum piece. I read it and agreed with his argument against redefining Pluto and the confusing term 'dwarf planet'. At that time I thought about asking Rick about the term 'asteroid' as opposed to 'minor planet', but I pressed on with development, and so it was.
Fast forward to 2008, and a bit of serendipity. I ran into Dr. Fienberg at NEAF in April. I asked him about my dilemma and whether he still felt as he did when he wrote that Spectrum piece in 2006. His feelings hadn't changed, and he liked 'asteroid'. That clinched my decision to make the change to 'asteroid'.
As for Pluto, it never got demoted in Deep-Sky Planner. I hope the IAU reinstates its planet-hood when they next meet in 2009. That seems befitting for the International Year of Astronomy.
While implementing support for minor planets in late 2006 for Deep-Sky Planner, I had a real dilemma as to whether these objects should be called 'minor planets' or 'asteroids'. The IAU meeting in Prague the previous summer had just brought the term 'dwarf planet' onto the world stage, and demoted Pluto to some mysterious status that still befuddles me. The term 'minor planet' seemed a little like damaged goods.
On the other hand, the Minor Planet Center was the purveyor of orbital elements for these beasts, so the term 'minor planet' must have been the best moniker. So 'minor planet' stuck.
In the November 2006 issue of Sky & Telescope, Editor In Chief Rick Fienberg wrote about the IAU shenanigans in his Spectrum piece. I read it and agreed with his argument against redefining Pluto and the confusing term 'dwarf planet'. At that time I thought about asking Rick about the term 'asteroid' as opposed to 'minor planet', but I pressed on with development, and so it was.
Fast forward to 2008, and a bit of serendipity. I ran into Dr. Fienberg at NEAF in April. I asked him about my dilemma and whether he still felt as he did when he wrote that Spectrum piece in 2006. His feelings hadn't changed, and he liked 'asteroid'. That clinched my decision to make the change to 'asteroid'.
As for Pluto, it never got demoted in Deep-Sky Planner. I hope the IAU reinstates its planet-hood when they next meet in 2009. That seems befitting for the International Year of Astronomy.
23 May 2008
Unit Tests & XP
Back from the fun at NEAF, I'm back to the usual routine. Lately I've been making some fundamental low-level changes so I'm writing unit tests to keep things under control. Following the eXtreme Programming paradigm entirely really doesn't make sense to me, but using it in select areas does.
Case in point: I have a class for an equatorial coordinate position, including computing star atlas chart cross-references. Writing tests that make sure the correct chart reference is computed is pretty straightforward and allows testing along chart boundaries. On the other hand, the class has a couple dozen methods so writing tests for the really mundane methods (e.g., copy constructors) is a little torturous. Further, some of these methods have been around for north of a dozen years, so I have a good comfort level with them.
While at NEAF, I mentioned unit testing to Steve Bisque. He said he doesn't use them. I told him they can take as much time to write as the code under test. I think that sealed the deal for him - no time for all that. Ultimately we as programmers need to be aware of unit testing and what it can do for our products, but the extent of their use really depends on schedules and other testing procedures in place for the product. I suspect that Software Bisque has a pretty solid system test procedure, so I guess they cover QA that way.
For me, using unit testing judiciously is the way to go. It gives some assurance for the low level stuff while system testing addresses the higher level. System tests are presently done with a combination of manual testing, Python scripts, and a test team (in that order.)
PS, in the true story category:
I once interviewed a young man for a programming position with my employer. The interview process placed the interviewee at a conference table with 3 staff programmers for what we called "the inquisition". The guy told us that he had never written code with a bug in it. There was a pause as we shot glances of astonishment around the table, and we politely continued the interview for about 20 more minutes. The guy had absolutely no chance of getting the job after that. If you've ever written a program, I bet you're laughing - loudly...
Case in point: I have a class for an equatorial coordinate position, including computing star atlas chart cross-references. Writing tests that make sure the correct chart reference is computed is pretty straightforward and allows testing along chart boundaries. On the other hand, the class has a couple dozen methods so writing tests for the really mundane methods (e.g., copy constructors) is a little torturous. Further, some of these methods have been around for north of a dozen years, so I have a good comfort level with them.
While at NEAF, I mentioned unit testing to Steve Bisque. He said he doesn't use them. I told him they can take as much time to write as the code under test. I think that sealed the deal for him - no time for all that. Ultimately we as programmers need to be aware of unit testing and what it can do for our products, but the extent of their use really depends on schedules and other testing procedures in place for the product. I suspect that Software Bisque has a pretty solid system test procedure, so I guess they cover QA that way.
For me, using unit testing judiciously is the way to go. It gives some assurance for the low level stuff while system testing addresses the higher level. System tests are presently done with a combination of manual testing, Python scripts, and a test team (in that order.)
PS, in the true story category:
I once interviewed a young man for a programming position with my employer. The interview process placed the interviewee at a conference table with 3 staff programmers for what we called "the inquisition". The guy told us that he had never written code with a bug in it. There was a pause as we shot glances of astonishment around the table, and we politely continued the interview for about 20 more minutes. The guy had absolutely no chance of getting the job after that. If you've ever written a program, I bet you're laughing - loudly...
Subscribe to:
Posts (Atom)