It has been a busy 4 weeks for releases at Knightware. A new product, SQM Reader Pro, was released in mid-February followed by the release of updates to SQM Reader and Deep-Sky Planner. SQM Reader Pro introduces a new capability for Knightware - digital delivery of purchased software. It will be interesting to see how digital delivery compares to delivery of physical media (CD.)
The early March update to Deep-Sky Planner addressed a problem with using TheSky6 to control a telescope while using the 'Slew To' feature in a Deep-Sky Planner report. This problem was critical for users of Software Bisque's Paramount ME because it can only be controlled by TheSky. With this update, users of TheSky6 should be squared away.
That brings us to mid-March and the second update to Deep-Sky Planner in 4 weeks time - a record for the product. The need for a second update came out of the blue, but was nonetheless worthwhile.
A new version of Redshift was released recently (Redshift 7 Premium) and Deep-Sky Planner needed a minor change to support interoperation with it. Deep-Sky Planner 4 has supported Redshift 6 Premium since Oct 2007.
Redshift 7 Premium is already available (starting in December in Europe and in January in the US market where version 6 was never officially sold), and it is an 'IYA2009 Official Product' - see http://www.astronomy2009.org/resources/products/redshift/ Furthermore, Redshift 7 Premium and Deep-Sky Planner 4 will be demonstrated working together at a star party hosted by United Soft Media (publishers of Redshift) and Baader Planetarium in Munich in early April. Catch that if you can - the event is a part of the worldwide "100 Hours of Astronomy".
And finally, an apology for update madness...
As a customer of many software products, I might find updating my product twice in one month to be excessive, but this has been an unusual situation that I believe merited quick attention. It's too bad that release timing wasn't a little different: testing updates is very time consuming and ranks high in tedium. Hopefully this will be it for a while!
19 March 2009
17 February 2009
SQM Reader Pro 1.0 is released
SQM Reader Pro has been released, giving owners of the Sky Quality Meter with Lens and Ethernet a new tool to read their meter. If you own an SQM-LE and use Windows, this software really can do a lot for you. You can check it out at http://knightware.biz/sqm/readerpro.htm
This project has been one of the most efficient in my 27 years of software engineering. The beta test went extremely well thanks to responsive, thorough team members. Even the resource and memory leak testing went without a hitch.
This has been a special project as it has brought together 18 years of experience in reading and managing data from meters, and the opportunity to empower people to argue the light pollution point with hard facts. It's also intriguing to be able to know how dark the sky is at any location in real-time - a boon for astrophotographers working remotely.
This project has been one of the most efficient in my 27 years of software engineering. The beta test went extremely well thanks to responsive, thorough team members. Even the resource and memory leak testing went without a hitch.
This has been a special project as it has brought together 18 years of experience in reading and managing data from meters, and the opportunity to empower people to argue the light pollution point with hard facts. It's also intriguing to be able to know how dark the sky is at any location in real-time - a boon for astrophotographers working remotely.
02 February 2009
SQM Reader Pro entering beta test
Over the past few months I have received a number of requests for enhancements to SQM-LE Reader (released Sep 2008.) As a result, I have added these enhancements to a new product that will be called SQM Reader Pro. SQM-LE Reader will continue to be available for free, although the title will be changed to SQM Reader.
SQM Reader Pro will most likely be available in March. Details of the product's features will be announced on knightware.biz after the beta test is complete, but generally you can look for a Windows program that reads an SQM-LE device, displays the latest reading, a graph of recent readings and some elementary statistics (min, max, mean and standard deviation.) The product will include the ability to send an image of the latest reading or the latest graph as a JPEG file to a web site using FTP, or to a processing program, script or batch file.
This project has married together my years of experience in developing software for the electrical power metering industry and my interest in quantifying the darkness of our night sky.
SQM Reader Pro will most likely be available in March. Details of the product's features will be announced on knightware.biz after the beta test is complete, but generally you can look for a Windows program that reads an SQM-LE device, displays the latest reading, a graph of recent readings and some elementary statistics (min, max, mean and standard deviation.) The product will include the ability to send an image of the latest reading or the latest graph as a JPEG file to a web site using FTP, or to a processing program, script or batch file.
This project has married together my years of experience in developing software for the electrical power metering industry and my interest in quantifying the darkness of our night sky.
30 January 2009
Logging Standard Update
In my last few posts, I've talked about logging standards and a promising project under development that may bring a common observation exchange format to the astronomical community. This project has moved forward and has undergone some changes recently. The project described on this blog and formerly known as COMAST has been renamed to OpenAstronomyLog - or <OAL> for short - and it has a new home on the Web at http://groups.google.com/group/openastronomylog . Although the website is under construction now, it is a repository for developer information and discussion among users and developers.
There are a number of participants in the project that are working toward an upcoming release of the standard that will encompass several enhancements to the previous release (COMAST v1.7) and will, of course, sport the new project name <OAL>. Deep-Sky Planner does not yet support <OAL> but will do so in a future release. Considerable R&D time has been spent over the past months preparing to support the standard and making minor contributions to it. In-house tools have been developed for converting existing DSP4 observations to and from the standard format, so the concept is proven.
Hopefully the issues that arose for this developer can be addressed in material on the OpenAstronomyLog website so that other developers can adopt the standard easily. I invite you to visit the website and consider how saving your observations in an open exchange format might benefit you and the astronomical community at large.
There are a number of participants in the project that are working toward an upcoming release of the standard that will encompass several enhancements to the previous release (COMAST v1.7) and will, of course, sport the new project name <OAL>. Deep-Sky Planner does not yet support <OAL> but will do so in a future release. Considerable R&D time has been spent over the past months preparing to support the standard and making minor contributions to it. In-house tools have been developed for converting existing DSP4 observations to and from the standard format, so the concept is proven.
Hopefully the issues that arose for this developer can be addressed in material on the OpenAstronomyLog website so that other developers can adopt the standard easily. I invite you to visit the website and consider how saving your observations in an open exchange format might benefit you and the astronomical community at large.
02 December 2008
The Case for a Logging Standard, Part 2
In my previous post, I stated several arguments for a standard file format for holding astronomical observations. The arguments fell into 3 categories: data preservation, flexible access to and presentation of the data. This time, I'll describe a candidate that solves many of these requirements that is available now. Better yet, it is open source and free.
A year or so ago I stumbled upon something that really solved the aforementioned requirements well - an open source XML based standard for recording observations called COMAST. The advantages of recording observations in an XML format are that the content of an observation can be defined clearly for any interested party (program) to produce or consume. XML also lends itself well to reformatting into different file structures or visual presentation. All of this presents in a platform independent context. If you are keeping tally, that's open source, free of charge, platform independent, flexible access and flexible presentation. Hmmm, cool.
The COMAST effort is led by a small number of developers from Germany and Belgium. Fortunately for me, there is English documentation (my German is pathetic.) If you would like to read about the COMAST XML Schema, you can visit the web site at http://observation.sourceforge.net/en/index.html Beware if you aren't an XML techie.
After studying COMAST for some time, I decided that it described observations well enough and generally enough to be a very good candidate solution to my perceived requirements. I decided to put it to the acid test - try to import and export observations from Deep-Sky Planner using the COMAST format. After some discussion with the founding designers of COMAST, I have succeeded in transferring COMAST formatted data into and out of Deep-Sky Planner. There are idiosyncracies, but it works. Double cool.
COMAST does a thorough job of describing your observing site, equipment, time of observation and visual results. It can currently accommodate imaging equipment and results, but not as thoroughly as I would like. Deep-Sky Planner continues to provide storage and reporting of imaging observations. I suspect that the COMAST standard will catch up and I hope to take part in that effort.
COMAST does include some data that is more relevant to German observers, like one's Deep-Sky Liste (DSL) ID number and a DSL object rating code. I'm sure that observers elsewhere have familiar rating systems, association IDs and the like. These items reveal the roots of the COMAST project but they aren't required. They probably should migrate into an extension for German observers from the basic standard, but for now they can be ignored if desired. The nice thing about the COMAST design is that it makes extensions possible with predictable results. For example, should there be an extension developed that describes imaging observations, older software could accept and produce legal files with no changes - it would simply not support imaging extensions.
So what can COMAST do for you? At present, it can provide you with a observation data migration path between a couple of software products. Should that number increase, we may just have ourselves a viable world standard for sharing and preserving observations. Very cool indeed.
A year or so ago I stumbled upon something that really solved the aforementioned requirements well - an open source XML based standard for recording observations called COMAST. The advantages of recording observations in an XML format are that the content of an observation can be defined clearly for any interested party (program) to produce or consume. XML also lends itself well to reformatting into different file structures or visual presentation. All of this presents in a platform independent context. If you are keeping tally, that's open source, free of charge, platform independent, flexible access and flexible presentation. Hmmm, cool.
The COMAST effort is led by a small number of developers from Germany and Belgium. Fortunately for me, there is English documentation (my German is pathetic.) If you would like to read about the COMAST XML Schema, you can visit the web site at http://observation.sourceforge.net/en/index.html Beware if you aren't an XML techie.
After studying COMAST for some time, I decided that it described observations well enough and generally enough to be a very good candidate solution to my perceived requirements. I decided to put it to the acid test - try to import and export observations from Deep-Sky Planner using the COMAST format. After some discussion with the founding designers of COMAST, I have succeeded in transferring COMAST formatted data into and out of Deep-Sky Planner. There are idiosyncracies, but it works. Double cool.
COMAST does a thorough job of describing your observing site, equipment, time of observation and visual results. It can currently accommodate imaging equipment and results, but not as thoroughly as I would like. Deep-Sky Planner continues to provide storage and reporting of imaging observations. I suspect that the COMAST standard will catch up and I hope to take part in that effort.
COMAST does include some data that is more relevant to German observers, like one's Deep-Sky Liste (DSL) ID number and a DSL object rating code. I'm sure that observers elsewhere have familiar rating systems, association IDs and the like. These items reveal the roots of the COMAST project but they aren't required. They probably should migrate into an extension for German observers from the basic standard, but for now they can be ignored if desired. The nice thing about the COMAST design is that it makes extensions possible with predictable results. For example, should there be an extension developed that describes imaging observations, older software could accept and produce legal files with no changes - it would simply not support imaging extensions.
So what can COMAST do for you? At present, it can provide you with a observation data migration path between a couple of software products. Should that number increase, we may just have ourselves a viable world standard for sharing and preserving observations. Very cool indeed.
22 November 2008
The Case for a Logging Standard
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.
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.
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!
Subscribe to:
Posts (Atom)