Telescope Control Help and Documentation

Hello! And welcome to the Northwest Astronomy Groups telescope control web site. Here we are engaged in an exciting, new approach to designing and building a remote telescope control system. This web site is being developed to create an interactive and collaborative site on the internet, from which any telescope, and in particular our telescope(s) at the Vernonia Peak Telescope Observatory, can be controlled and interacted with. We believe this is a unique effort, since we have not seen anything quite like this done anywhere else. While there are a number of efforts going on, to remotely control a telescope from the internet, none of these efforts are aimed towards providing a solution that reflects the true nature of the operation of telescopes at most observatories. Instead, these other efforts provide a single point solution, (and often proprietary) i.e. one person in complete control of a telescope, with privileged access to information about or coming from the telescope, from a single web browser or web application. Or these other efforts provide an automated system of queuing requests, to some form of batch processing system, whereby users submit requests for the observations of some object, and receive the resultant image data at some later point in time.

This is NOT the way a typical telescope observatory operates. Instead, the operation of a telescope is usually a collaborative effort handled by a group of scientist, engineers, and telescope operators all interacting together at the same time. Therefore, this web site will be aimed at providing a collaborative environment for the telescope observatorys members and guests. When the telescope is in actual operation we will maintain the paradigm of having a single operator in control of the telescope and cameras, but this web site allows everyone to look over the operators shoulders so to speak, and observe what is happening as the telescope operations proceeds. Visitors and members will be able to monitor what is happening with the telescope, share thoughts and ideas, and watch together as results are achieved.

When the telescope is not in operation, the various applets and webapps can still be used as simulators. This does provide some real functionality, such as for example, generating star charts, or looking at digitized images from a sky survey. However, the real purpose of having a simulation mode is to provide a framework for development and offline testing, and for the education of users in learning how to control and run the various applications

It is true that this web site will not be able to achieve the same level of synergy that can be achieve by a group of people working together in the control room of a telescope. However, we feel that this factor will become less and less of an issue as time goes on, simply because both the internet and computers will become ever more powerful, and we will eventually be able to start using additional technologies such as live streaming voice and video. These technologies will help to create an even better collaborative environment, and thus build even more from this synergy. For now, this is a first step and we plan to provide a way to share the basic tools and information needed for a workable, collaborative telescope operating environment.

It should also be emphasized that this project is not just a simple application or even a collection of stand alone applications. Instead it is a well coordinated system of components that form the front end environment for interacting with a telescope, from the internet. The focus of this project has been to build these components in a way such that they are easily portable to other observatories, and to keep costs and proprietary items to a minimum. All components have been written in the Java programming language (which can execute on any computer system and is highly suitable for internet based applications) or come from free open source projects, such as the ASCOM drivers, the Cartes Du Ciel star chart generator, the Jakarta Tomcat web server, and the Jakarta James email servers. There are applets and webapps that are automatically deployed to, updated, and execute on the users computers; servlets, mailets, and simulators that are executed on the telescopes server; and interfacing code to the ASCOM telescope driver objects, the Cartes Du Ciel star chart generator, the camera drivers, and to the NASA SkyView server. All of these components have been designed using Object Oriented Design (OOD) techniques making them highly reusable, easy to adapt and port to other telescope environments, robust, and easy to understand.

For this first effort, from the users perspective, the web site consists of 4 main applications. The first application will show a sky chart of the sky as it exists at the telescope observatory, in semi real time. Superimposed on this sky chart will be a bull's-eye showing where the telescope is currently pointed. The update rate, at which any one viewer will see this image changing, is of course, dependent upon how much of a load there is on the server which is computing and supplying these sky chart images. This is why we say these images will be updated in semi real time.

The second application is the telescope control and readout app. It is from this section that everyone will be able to monitor the status of the telescope, and see information such as position readouts, whether it is in slew of tracking modes, and other pertinent information regarding the operating state of the telescope. It is here that an interface is provided that allows the telescope to be commanded from the internet by a single designated telescope control operator. This ability will, of course, be limited to the primary members of the telescope group, and by means of a token that can be passed around amongst them, only one member will be able to control the telescope at a time... However, everyone else on the website will be able to monitor the telescope control application and see what is happening.

The third application is the image and CCD camera control app. It is here that acquired images from the telescope will be displayed, again in semi real time. After all, what good is a telescope if you can't see the pictures it is taking, or monitor the results of various experiments that are being done! This section will have the controls for the cameras (or other experimental devices attached to the scope) such as shutter times and filter selections, and will be operated in a similar fashion as the telescope control application.

The last application is a dedicated chat area that will allow everyone who is visiting the site to send messages and communicate both with each other, and to those who may be at the telescope observatory itself. We know this is a clumsy means of supporting a collaborative environment, but for now it is the best we can do on the internet. As we said earlier, other technologies are coming soon, and we can't wait until they get here! ;-) Please be courteous and follow our guidelines... Keep the topic of your conversations focused on astronomy and working with the telescope, and do not engage in flame wars or any other inappropriate behavior.

Currently, this web site is under development and not fully functional... This is a testing area, expect lots of broken links, and functionality for now... But do come on in, look around and feel free to make suggestions if you like. Generally, if an area is documented, it means there is at least simulation functionality available for most if not all of the features of that particular section of this project.

There is NO connections to the actual telescope hardware as of yet. I will remove this notice, or modify it, as actual hardware capabilities and interfaces are implemented.

1.1 Applets and WebApps

There are two different approaches to running the telescope control applications on your system, using applets and/or webapps. With both approaches, to execute the applications, we use a computer language called Java which is interpreted by a special program on your computer called the Java Runtime Environment or simply the JRE. One of the approaches is to execute the application as an Applet. The technology for Applets has been around for awhile now, and they are executed within the context of a web browser. Most browsers come with a JRE already installed within them. When the user brings up a web page that has code for an applet, embedded within that page, the browser will automatically start its JRE and have it execute the applets code. Applets are used for dynamic web page content that requires an extensive amount of programming to control their graphics and/or user interactions. All of the telescope control applications are supplied as applets and can be reached and executed on the Telescope Control web site.

Although applets are easy to start up, i.e. just simply browse to a web page that has them, there are a number of drawbacks as well. Each time a user visits a page that contains them; they must wait while the server for that page downloads ALL the code for the applet to the users browser. For large applets this can take quite a bit of time, especially over a slow dial up line. Also, an applet executes only while the browser which invoked it is also running. This can place heavy demands on system resources and slow down the applet. To get around these limitations, a new emerging technology which supports web based applications (webapps) is now available, and we supply the telescope control applications as webapps also.

WebApps are basically applets that have been wrapped with additional code that allows them to run standalone just like any other application on your computer. But there are differences and all WebApps need some additional supporting functionality. This functionality is provided by a companion program called the WebStart Manager. It provides the JRE that a WebApp needs, and it provides connectivity between the WebApp and the server from which it came. To run a WebApp, you must have an internet connection open and available. When a WebApp first starts up, the WebStart Manager will have it check in with its host server and check to see if there are any updates available for its code modules. If there are, it will automatically download and install them into the WebApp. If there are no updates, then the WebApp can immediately start running without having to wait for any code to be downloaded, since all of its code will already be stored on your computer. This feature greatly improves the startup time of a WebApp.

It is also important to understand that both applets and WebApps are tightly connected to a host server on the internet, and while running they can communicate with special programs, called servlets, that are running on that host server which supports the applets/WebApps. (See the System Architecture description below for more information) This ability of applets and WebApps, to connect to and communicate with servlets running on a host server is what makes the Telescope Control applets and WebApps work. The applets and WebApps merely supply a graphical user interface for you the user to see and interact with. (WebApps and applets, and sometimes along with their associated servlets, are collectively referred to as the Telescope Control applications in this document.)

Currently, the WebApp technology being used by the Telescope Control applications is in a beta testing phase and acquired from Sun Microsystems. (This is not Microsofts equivalent .NET technology.) As of this time, the scripts on the web pages, where the Telescope Control WebApps are deployed from, only support the automated installation of the WebApps and the WebStart Manager to Windows based machines. As soon as Sun deploys a full release of their technology, we will upgrade these scripts so that all platforms and operating systems are supported.

1.1.1 Java JRE Installation

One of the things that irritates me the most about software engineers is that they often do not explain to others what is going on when something unexpected happens... (We are all suppose to "know" everything about computers and how they function, or simply "trust" the software guru to take care of us, eh?) Therefore, I am going to follow my own advice and give you a heads up about the software for this telescope control web site...

The code for the applets and webapps that I have written to control and display the various parts of the web site, are written in a computer language called Java. Java is a universal language which can run on any computer, regardless of what operating system or processor hardware is used. This is accomplished by installing a special software package which simulates a "virtual computer" on your system, and runs as a plug-in into your browser. In a fashion similar to the way that your computer executes normal programs, this virtual computer software program executes Java code. This special software, often called the Java Runtime Environment, or JRE for short, is developed mainly by two vendors, Sun Microsystems and Microsoft, and is available to anyone for free. And as can be expected, these companies have not stopped adding new features and capabilities to their software packages.

Us software engineers, of course, like to take advantage of these new features as they are made available, and develop our software applications, applets, servlets, etc. using them. And true to this spirit, I have been using some of the latest features from Sun's version of their latest JRE, in order to develop this telescope control web site. What this means to you as a visitor to this web site, is that in order for you to see the results from my Java applets or webapps, you are going to have to have this latest version of the JRE installed on to your system and into your browsers, as well. Don't worry, this isn't to painful and has been automated as much as possible! ;-)

When you enter this telescope web site, the code I have written will tell your browser what version of the JRE is required in order for the applets or WebApps to run. If your browser or system does not have that version already installed, then I have written some JavaScript to have your browser notify you that you need a new "plug-in" for the JRE. This script will then redirect you to a location on Sun Microsystems web site where you can get a copy of the JRE plug-in and download it onto your computer. Go ahead an go there, and jump through all their legal hoops, agree to their license terms, and grab yourself a copy of this freebie and download it onto your system. Depending upon what browser you are using, it may or may not automatically install itself into your browser. If it doesn't, then it will come to you as an installation executable file and ask you where you want to put it on your system. Once you have it downloaded, you will then have to exit the browser, go to that directory, and execute the JRE installation program. (Make sure you remember the name of the program, it is kind of weird and not a logical name for this program) If you are on a Windows computer, of course you will have to jump through the usual Microsoft hoops and reboot your system after you have installed the JRE. Sorry about this, but at least this is only a one time hurdle that you have to go through... (Unless, of course, I decide to use an even later version of the JRE, sometime in the future, in order to use even more of Sun's new fancy bells and whistles, on this web site!) ;-)

1.1.2 Java WebStart Manager Installation

To run the telescope control applications as webapps, you will also need to install a utility on your machine for the Java Web Start manager. The first time you attempt to download a WebApp onto your computer, the install process will detect that you do not have the web start manager and it will automatically guide you through the process and install it for you. When finished, for any Java historical buffs, you will have an icon showing the famous Java ring sitting on your desktop. When you execute the WebStart manager, change the View so you see the Downloaded Applications and this will show you the telescope control applications that have been downloaded.

Each of the telescope control webapps must be downloaded separately, but it is only for the first one that you will have to jump through the additional hoop of installing the Java WebStart Manager. All of the webapps can be installed by clicking on the appropriate link on the Telescope Login page, and are shown below. When you install them, you will be given the option of installing shortcuts on your desktop and in your Start menu. (They will always be installed in the Java WebStart Managers downloaded applications section and you can start them from there as well.) The icons which represent each of the telescope control webapps are also shown on the Telescope Login page.

1.2 Login

There are two login points of access to the Telescope Control applications, depending on whether you wish to run applets out of your browser, or webapps off of your desktop. Both accomplish basically the same thing, which is to inform the server that a new user is accessing the web site, and to determine what privileges should be assigned to the user. The user is free to choose whatever identifier he/she wishes, but if the identifier is already in use, then the login server will modify the identifier by adding a numeric suffix to it.

Members who have been given the club password should use it when they log in. This allows extended privileges to be granted to them, such as the ability to become the telescope or camera control operator when the telescope/camera is online. (When the telescope or camera is offline, and simulators are running, then either guests or members may assume the role of being an operator, but members still have the right to preempt a guest and assume operator status.)

Guest visiting the website can use anything for the password field. Eventually if a guest uses his/her email address, then the server will send them an email asking them if they would like to subscribe to the mail list and newsletter, along with instructions on how to subscribe.

1.2.1 Logging in to use the applets

The image above show the section of the login page on the website that allows a user to login an use applets running within a browser for the various application. When the Submit button is clicked, the browser will show a page with buttons that will launch the applets, some information about the privileges assigned to the user, and the actual identifier that was assigned to the user by the server.

Once you have submitted your login information, you browser will be directed to a login confirmation page. Here it will show you the identifier that was actually created and assigned to you, as well as a few words describing your privileges. Also, the login servlet will direct your browser to create a cookie to store the login information and privileges granted to you. This is so all the different applets can find out who you are and what privileges were granted to you. From this page, you can click on any of the various buttons to launch different applets, or to logout of the server.

1.2.2 Logging in using a WebApp

When a WebApp is executed, it contacts the server to see if there has already been a login from the computer on which the WebApp is running. If no login is current, then the WebApp checks to see if a muffin is currently stored on the users computer with the login information for that computer. If neither case is true, then the above shown dialog box is opened and the user is prompted to submit the login information. To login in to this site, members should enter their name and the club password. Guests may simply enter the name or an identifier and for the password field, either leave it blank, or enter your email address. If you enter an email address, I will add it to the club newsletter mail list. (As soon as I develop that feature, it is not yet working...)

When the Submit button is clicked, the WebApp will send the login information to the server, and it will create a muffin on the users computer to store the login information locally. (See below for more information about cookies and muffins.)

Once successfully logged in, you will be shown the above confirmation dialog box. This again shows you the actual identifier that was assigned to you by the server. It may be the login identifier you chose with a numeric suffix appended to it. Also shown is the privileges which have been granted to you. Simply click on the OK button to dismiss the dialog box (it is modal meaning that nothing else can run until you do dismiss it) and your WebApp will start to run. If for some reason, you dont like the identifier assigned to you, you can click on the Cancel button and that will take you back to the login dialog box.

The login dialog box is normally only shown for the very first time you start up any of the webapps on any given day. Subsequently starting up any other WebApp or restarting a WebApp will only give you the confirmation dialog box. This is because the login information is being stored in a muffin and all webapps check for the muffin and will use that information, if found, to automatically log in to the server.

1.3 Cookies and Muffins

Oh, one last thing, we know many people hate cookies, but we do need to be able to set a couple of them on your system. So you will have to enable them in your browser. Don't worry, we don't store any thing bad, just your name and some of your favorite settings for each of the control applets, such as how you like your starchart displayed. This is so that we can automatically restore your favorite settings from one session to the next, and to pass information about you from one applet to another.

Muffins are a lot like cookies and are also used to store a bit of information on your computer for the webapps. If you are prompted to grant permission to create a muffin, then go ahead and allow it. Dont worry, nothing harmful is stored in them, they just make your life a bit easier. They are used to store login information and some of your favorite settings so that again they can be automatically retained from one session to the next. The login muffins will have a lifespan of one day, after which they are automatically deleted.

The lifespan of cookies and muffins that are used to retain settings information is settable by the user from within the appropriate applet or WebApp.

2 System Architecture

This section describes the internal architecture and provides and overview of, and links to the software documentation for this telescope control application. The audience focus is for other software engineers and technically interested people. Most users can skip this section and jump forward to the Telescope Control Applications section below.

This application is a unique effort which will allow users to remotely collaborate and control the Northwest Astronomy Group’s 12 inch and a 24 inch telescope from the internet. It allows a telescope operator to control a telescope and it’s cameras from the internet, and it allows anyone visiting the telescope control website, or using the telescope control web applications, to “look over” the telescope and camera operators shoulders. Users can watch and discuss with each other, and with the operators, what is being done with the telescope and camera. And they can watch as images and data is acquired from the telescope. This allows for a collaborative, internet based, approach to the running and operation of a telescope by groups of researchers and engineers, and by others such as school classrooms. From the user’s perspective, none of the code is proprietary. Instead it is deployed as either an applet or as a Sun Java Web Start web application. To accomplish this, I have written, in Java and JSP, three sets of Java applets/web applications which are tightly coupled with servlets.

The first applet-webapp/servlet pair generates and displays a star chart, which shows where a telescope is currently pointing. It can be used to generate a custom star chart for anywhere on the Earth. The starchart applet-webapp also allows an operator to directly control of a telescope by simply pointing and clicking on an object shown in the starchart. This causes a servlet to generate commands to move a telescope to that position. This servlet controls a star chart generating program, running on the server, and the servlet communicates with it via a DDE interface. A second applet-webapp/servlet pair directly controls the operation of a telescope. This includes a drive paddle applet-webapp with an operations control GUI. The associated servlet couples with a Java telescope simulator, or with ASCOM telescope drivers. (ASCOM is a standardized COM interface for telescope drivers.) A third applet-webapp/servlet pair is used to control and focus the CCD cameras for image data collection, auto guiding of the telescope, and to display images as they are acquired or retrieved from a database. The servlet for the CCD camera controller couples with a Java simulator, an ASCOM CCD camera driver, or with the NASA SkyView server.

Additional servlets and Java class objects have been developed to handle login/logout processes, monitor user activity via separate threads, and monitor/handle communication between the servlets. All applet-webapps use an HTTP tunneling protocol (Java object serialization) to communicate with their corresponding servlet. Support code, which I wrote in Java and some C++, provides communication with custom Java mailets running on a Jakarta James email server, with a MySQL database for the storage and retrieval of messages and images, COM drivers, DDE servers, Java based simulators, and with the NASA SkyView server.

REMINDER TO MYSELF This web site uses a combination of multiple threads, applets or webapps acting as a front end to servlets (thin clients) running on a server, and use a protocol trick known as HTTP tunneling to cause the automatic updates to occur without the need for the user to manually refresh his/her browser.

2.1 Software Documentation

2.1.1 Software supplied to other Open Source projects

Software documentation for the Cartes Du Ciel star chart Java interface can be seen by clicking here. http://www.marcchamberlin.com/CartesDuCiel

Software documentation for the ASCOM Java interface classes and Java telescope simulator can be seen by clicking here. http://www.marcchamberlin.com/ascom

2.1.2 Internal Software

Servlets. http://www.marcchamberlin.com/telescope/doc/TelescopeServlets/index.html

Applets/WebApps. http://www.marcchamberlin.com/telescope/doc/TelescopeApplets/index.html

Data Transporters. http://www.marcchamberlin.com/telescope/doc/DataTransporters/index.html

Astronomy Utilities. http://www.marcchamberlin.com/telescope/doc/AstronomyUtilities/index.html

Utilities. http://www.marcchamberlin.com/telescope/doc/Utilities/index.html

3 Telescope Control Applications

There are a number of common themes which run throughout all the telescope control applications. Instead of describing these features, each time, for each application, they will be summarized here.

All the telescope control applications can run as applets or webapps as described above. For the most part, there is no difference in the GUI or functionality base on how the application is ran. However there is one important exception. Each applications GUI has one button that functions as a Logout command in webapps, and as a Float or Unfloat command in applets. For webapps, the Logout button logs the user off of the telescope control server and terminates all running applications. For applets, this functionality is provided by a regular web button located on the web page from which the applet was launched from. In applets, this button becomes a dual state Float and Unfloat command. The Float command will allow the applet to run in its own window outside of the browsers window. While floating this button changes its functionality to become an Unfloat command. This will return the applet from its floating window back to the browsers window.

Each of the applications has a slide bar that allows the user to set the rate at which the application will send in information and requests to the server. This rate selection is settable in seconds. However, it is only a suggestion and may be overruled by the server. If the server starts to receive too many requests at once, from all the users, then it will command each of the applications to slow down their request rates by increasing the lower limit, or fastest rate, at which a user can set this slide bar.

All of the GUI widgets (buttons, slide bars, toggle switches, pull down menus etc) which interact with, or send commands to the server will turn red after their state is changed. (Such as by clicking on a button) They will stay red until the information associated with them is actually sent in to the server, at which point they will return to their original color. (Eventually I plan to make these widgets also change from red to yellow meaning that the information has been sent in to the server, and the application is waiting for the response back from the server. Once the updated information is received from the server, then the widget will return to its original color.)

Buttons that are always red in color are high priority buttons. If these buttons are clicked on, then the functionality associated with them is immediately sent to the server without waiting for the normal update rate to trigger the next request for information from the server. The servlet responding to these buttons are also designed to respond to such requests immediately. Emergency Stop buttons are an example of this type of button.

All of the buttons, and many of the other GUI widgets, have a tool tip that is associated with it. This helps to remind a user what the functionality of that button or widget is. To see the tool tip, simply hover the mouse cursor over the button or widget for a moment, and the tool tip should appear. Moving the mouse cursor will clear the tool tip text.

3.1 Star Chart

The Star Chart application is designed present a starchart to a user, to show where the telescope is pointing, and to possibly control the pointing of the telescope. The front end of this application runs on a clients system as either an applet or a WebApp. It presents the above shown GUI to the user through which commands that control the creation of a star chart can be entered, and the star chart itself can be displayed. The commands that are entered, or buttons clicked on, are sent back to a servlet that is running on the server. This servlet in turn relays most of these commands on to the Cartes Du Ciel star chart application, which is running on the server, which does the actual work of creating a star chart. Once the star chart image is created, the servlet picks it up and sends it back to the client system which requested it, where it is displayed in its GUI.

The Star Chart application is NOT a simple stand-alone application, as most star chart generating programs are. A stand-alone star chart generating program can generate arbitrary star charts for any given set of RA/Dec coordinates, field of view, time, date, and location of an observer. The Star Chart application can act as a stand-alone application, for a user, ONLY while no user has assumed the role of being the telescope control operator. However, once any user becomes the telescope control operator, ALL of the Star Chart applications are slaved to the telescope operators version of the Telescope Drive Paddle application. This means that the moment someone assumes the role of being the telescope operator, the controls of all Star Chart applications (with the possible exception of the telescope operators own star chart application) which are use to set the RA, Dec, FOV, time, date, star chart characteristics, catalog selection, and observatory location, are disabled. (FOV and star chart characteristic controls are disabled, right now, for performance reasons only. If the star chart servlet proves to be capable of generating customized star charts on a per user basis, while there is a telescope operator, then this restraint may be relaxed in the future.) The star chart servlet receives this information from the telescope operators drive paddle application, instead, and it sends the same generated star chart to all connect star chart applications. Thus the Star Chart application is also used to show all connected users where the telescope control operator is positioning the telescope. (This is true, regardless of whether the telescope operator is working with a telescope simulator or connected to the actual telescope.)

The telescope control operator can also use his/her Star Chart application to actually control the pointing of the telescope. This is done by transferring the control of the telescope drive from the Telescope Drive Paddle application to the Star Chart application. Once control is transferred, the telescope control operator can send commands from the Star Chart application to the telescope drive servlet, either by entering the RA and Dec coordinates directly in the star charts RA/Dec view fields and clicking on the appropriate RA or Dec buttons, or by pointing to an object shown in the star chart image and left clicking on it. This can greatly simplify the job of commanding the telescope to point to a new object.

3.1.1 Star Chart Organization

The Star Chart application is organized into 4 basic sections. At the top is a section containing controls which relate to the status of the starchart application and its performance. The telescope status offline, simulation, or online is displayed. Two slider controls and readouts allow the user to suggest a rate at which he/she would like to send information to the starchart servlet and receive updates from it, and to set the quality of the image for the starchart that is generated for each request. The percent of quality for the starchart is directly related to the size of the starchart (in bytes) that is generated. For slow dialup access lines connecting the application to the internet, this quality should be set as low as is tolerable, otherwise you will be held up waiting for the download of the next starchart image. Note: the timer which controls the request rate for sending information to the starchart servlet does not start until after the completion of receiving all data from the previous request. Therefore the actual rate of updates is the sum of the download time, plus the user requested rate of updating, plus the servlets time to process each request. If the servlet is getting to many requests from all users, it will automatically slow down the rate at which star charts can be requested, thus balancing the amount of bandwidth it has with all the users.

Then next section contains a scrollable panel holding the starchart images that are generated from the starchart servlet. This is the heart of this application. Not only does it display the star charts, but it can also be used to control the telescope if and when this star chart application is placed in control of the telescope. By simply using the mouse to point at an object, and left clicking on it, the star chart application will send those coordinates to the star chart servlet, which will in turn convert them into RA and Dec values and forward them on to the telescope drive servlet. The telescope drive servlet will then drive the telescope to those coordinates, and inform the star chart servlet periodically where the telescope is pointing. This in turn causes the star chart servlet to update the star charts that it is generating, and send those star chart images out to all star chart client applications. Right clicking on an object in the star chart will cause the star chart servlet to generate subsequent star charts with that object labeled, and it will send information from the currently selected catalog, about that object, where it will be displayed in the starchart dialog panel as described below.

The third section contains information that was generated about the starchart that the servlet sent to this application along with the star chart itself. This includes a legend of objects found in the star chart image. This legend may change depending on what underlying catalog was used to generate the star chart images. Next to the legend is a status light for the star chart. When an object in the star chart is clicked on, this status light will turn red and stay red until the information about the object is actually sent to the starchart servlet. At that point it will turn green again. Also included in the third section is basic information about the starchart, such as the RA and Dec coordinated of the telescope eyepiece projection on the starchart (the red bullseye circles), field of view, date, time, size of the starchart (in bytes), and information about the observatory location for which the star chart was generated.

The last section contains a tabbed set of dialogs for setting various different functions of the starchart application, and for getting information and displaying it, from the servlet. Each of these dialogs will be described in further detail, in the next few sections of this document.

Star Chart Status - Displays the status of the star chart. These values include Standalone or Connected (to the telescope drive paddle).

Logoff/Float/Un-Float  Depending on the type of application (applet or WebApp) this button can log the user off the server and shut down all running webapps, or it can float a applet in its own window or un-float it an run it in the browser environment. (see above.)

Help  Brings up a popup menu that allows the user to see the documentation from a browser, supply feedback, or see the version information about this application.

Image Quality - This slider controls the quality of the starchart images that the server will produce and send to this application. Values range from 0 to 100 percent and are displayed both by the position of the movable slider, and by the text field next to the Image Quality label.

Update Rate This slider controls the rate at which the application will attempt to send and receive data to/from its servlet. This is settable in seconds, and is displayed both by the position of the movable slider, and by the text field next to the Image Update Request Rate label.

3.1.2 Star Chart View Controls

The Star Chart View dialog allows the user to set the parameters for a star charts right ascension, declination, field of view, date and time. This information will be sent to the star chart servlet for the generation of a star chart, and if the star chart is in control of the telescope drive, the RA and Dec coordinates will also be sent to the telescope drive servlet to point the telescope at these coordinates. These controls are only enabled if the star chart is operating in a stand alone configuration and no one has activated the drive paddle, or when the user is the telescope operator and has put the star char in control of the telescope.

The date and time can be used to control the generation of the star charts in one of three ways. It can be based on the computer system clock (local time) in which case the entries in the date and time field have no effect. The star chart converts the system time to local sidereal time, based on the information the server is supplying this application about the location of the observatory, and sends it to the star chart servlet for each star chart that it requests. If the user selects the Hold setting, then each star chart is generated based upon the date and time last sent to the star chart servlet. No automatic updating of the time is sent to the servlet which each request for a new star chart. Offset mode is useful when the users computer is set to a different time than the time at the observatory. In this mode, the user enters the time difference between his computers clock and the clock at the observatory. The star chart application then subtracts this time offset from the system clock before computing the local sidereal time for the observatory, and sends this computed value in to the star chart servlet for each request it makes for a star chart.

RA Right Ascension Clicking on this button sends the right ascension information to the star chart servlet. The right ascension is inputted in sexagesimal format using the supplied text input boxes or drop down menus.

DEC Declination Clicking on this button sends the declination information to the star chart servlet. The declination is inputted in sexagesimal format using the supplied text input boxes or drop down menus.

FOV Field of View Clicking on this button sends the field of view information to the star chart servlet. The FOV is inputted in sexagesimal format using the supplied text input boxes or drop down menus.

Date Clicking on this button either registers the date/offset with the star chart application or sends it to the star chart servlet depending on the mode in which time is being used for star chart generation.

System Time This toggle button tells the star chart application to simply use the system clock as the time base for generating star charts. The system time is simple converted to local sidereal time and sent to the star chart servlet along with each request f or a new star chart. Clicking on the Date button and the values in its associated date and time fields do not have any affect in this mode.

Hold This toggle button tells the star chart application to continue to use the time last sent to the star chart servlet, as is, for computing a star chart. Clicking on the Date button updates this reference time with the date and time defined in the associated date/time fields. The system clock does not affect the time that is being sent to the star chart servlet.

Offset This toggle button tells the star chart application to use the last set Date value as an offset from the system clock for computing the local sidereal time to be sent to the star chart servlet for the computation of the next star chart. Clicking on the Date button updates this reference offset time with the date and time defined in the associated date/time fields.

Sync - Initializes all these fields to the values being sent to the star chart application from the star chart servlet. (These values are displayed in the Current Star Chart Information area which is displayed just below the star chart image and just about these control dialogs.)

3.1.3 Star Chart Characteristics Controls

The Star Chart Characteristics controls are used to select and change various characteristics of the star charts which are generated by the star chart servlet. These controls give the user an easy way to do things like change the field of view, add or remove stars and nebulae from the star chart images, control displays of grids, constellation shapes and boundaries, and select between equatorial and azimuthal projections.

Zoom In Decreases the field of view of the next generated star chart image.

Zoom Out Increases the field of view of the next generated star chart image.

More Stars Increases the magnitude limit of the stars shown (if possible) in the next generated star chart image. This is dependent upon the selected star chart catalog capabilities.

Less Stars Decreases the magnitude limit of the stars shown (if possible) in the next generated star chart image. This is dependent upon the selected star chart catalog capabilities.

More Nebulae Increases the magnitude limit of the nebulae and galaxies shown (if possible) in the next generated star chart image. This is dependent upon the selected star chart catalog capabilities.

Less Nebulae Decreases the magnitude limit of the nebulae and galaxies shown (if possible) in the next generated star chart image. This is dependent upon the star chart catalog capabilities.

Grid Values Off, Grid Values On toggles between having grid values shown, or not, in the next generated star chart image.

Equatorial Grid Off, Equatorial Grid On toggles between having the equatorial grids shown, or not, in the next generated star chart image.

Azimuthal Grid Off, Azimuthal Grid On toggles between having the azimuthal grids shown, or not, in the next generated star chart image.

Switch off Constellation Shapes, Switch on Constellation Shapes toggles between having constellation shapes drawn, or not, in the next generated star chart image.

Switch off Constellation Boundaries, Switch on Constellation Boundaries toggles between having constellation boundaries drawn, or not, in the next generated star chart image.

Switch to Azimuthal Projection, Switch to Equatorial Projection toggles between having the next star chart drawn using either azimuthal or equatorial projections.

3.1.4 Star Chart Observatory Settings

The Observatory Info dialog allows the user to set the latitude and longitude coordinates, the altitude, and the observatory name for a location for which the star chart servlet is to generate star chart images. This information may be sent to the various servlets for generation of star charts, observatory information, and fits headers of images.

Note: These controls are only enabled if the star chart is operating in a stand alone configuration and no one has activated the drive paddle, or when the user is the telescope operator and has put the star char in control of a telescope simulator. While the telescope drive application is connected to a real telescope at the observatory, these controls will always be disabled.

Latitude These fields and radio buttons are used to set the latitude coordinates of an observatory in degrees, minutes, seconds and tenths of a second. The toggle buttons allow plus or minus latitude settings.

Longitude These fields and radio buttons are used to set the longitude coordinates of an observatory in hours, minutes, seconds and tenths of a second. The radio (toggle) buttons allow plus or minus hour settings relative to the Greenwich meridian.

Altitude This field is for the entry of the altitude (height above sea level) for the observatory, in meters. (decimal point is allowed)

Obs. Name This field is for entry of a descriptive name of the observatory.

OK Sends this data to the star chart servlet (for the star chart generator and for distribution to the other servlets).

Cancel Resets the various fields to their last settings which were sent to the star chart servlet.

Sync Initializes all these fields to the values being sent to the star chart application from the star chart servlet. (These values are displayed as the Current Star Chart Information area which is displayed just below the star chart image and just about these control dialogs.)

3.1.5 Star Chart StarCharts Controls

The StarCharts dialog allows the user to ask the star chart servlet to find and display objects, and information about those objects from various different catalogs. The returned information about the selected object is displayed in the text display area of this dialog. This feature is not yet complete; to be added will be the ability to move the starchart and/or telescope to the selected object, and to generate star charts based on a selected catalog. Therefore this dialog is likely to change as well.

Find  Send the selected catalog id and the objects identifier to the star chart servlet. The star chart servlet will return the information found about the object in the selected catalog to this dialog where it will be displayed in the text area below the Find button.

Catalog Id  Select from a pull down list of available catalogs. (More documentation about these catalogs will be made available soon.)

Ident Fill in this text field with the name of the object to search for. This is dependent upon the catalog selected. Some examples might be M31, or NGC101. (More documentation on this feature will be available soon.)

3.1.6 Star Chart Users

The Star Chart Users dialog displays all the users currently logged into the Telescope Control web server. It shows members as well as guests visiting the web site, and the current telescope and camera control operator(s.

Camera Operator  Displays the user identifier who has assumed the role of the camera operator.

Camera Status  Displays the current status of the camera, i.e. Offline, Simulation or Online.

Telescope Operator  Displays the user identifier who has assumed the role of the telescope operator. This is visible to all users at all times.

Telescope Status  Displays the current status of the telescope, i.e. Offline, Simulation or Online.

Members On Site  Displays (a scrollable list if necessary) of all members currently logged in to the web server.

Guests On Site  Displays ( a scrollable list if necessary) of all guest identifiers currently logged in to the web server.

3.1.7 Star Chart Misc. Controls

The Misc. setup dialog is a place for features that cannot be categorized as belonging to other dialog groupings. Here the current operator of the star chart application is shown. This may not be this users identifier if someone else is the operator of the telescope. The telescope operator is also the operator of all star charts, and then many of the features of the star chart are disabled for any user who is not the telescope operator.

This dialog also gives the user the ability to save and restore the star chart settings to/from a cookie or muffin. It must be understood that applets save and restore these settings to/from a cookie, and WebApps save and restore these settings to/from a muffin. While they serve the same purpose, cookies and muffins are not stored in the same underlying file. Therefore you cannot save these settings in one type of application, and expect to be able to restore them in the other type of application. Additionally, the user can select the number of days for which he/she wants to save this information.

Star Chart Operator  displays the identifier of the user who is in control of the star chart. If the starchart is running as a standalone application, then this will be the same as the identifier of the user who logged into the server from this computer. If the telescope drive paddle is running, on any computer connected to the server, then the star chart operator becomes the same user as the user who assumes the role of the telescopes operator.

Save Settings  saves the current star chart settings to a cookie or muffin. Select the number of days for which the cookie or muffin should remain active.

Restore Settings  restore the current star chart settings from a cookie or muffin. Note: If the settings were saved from an applet to a cookie, then those settings cannot be restored to a WebApp, and vice versa.

3.2 Telescope Control Drive Paddle

The Telescope Drive Paddle application is designed to allow a user to become the telescope control operator and control the pointing and tracking drives of a telescope from the internet. It also allows users who are not the telescope control operator to monitor the position of the telescope and various characteristics about the telescope and observatory site. The front end of this application runs on a clients system as either an applet or a WebApp. It presents the above shown GUI to the user through which commands that control the currently connected telescope drive (or simulator) are entered or buttons clicked. The commands that are entered, or buttons clicked on, are sent back to a servlet that is running on the server. This servlet in turn relays most of these commands on to an ASCOM telescope driver, or it may execute them directly within a Java telescope simulator, depending on what the telescope control operator has selected to use. As the telescope driver, or simulator, tracks or slews the telescope to a requested set of coordinates, the servlet monitors its position and sends this information back to the various client Telescope Drive Paddle applications that are connected to the servlet.

For most users, the buttons and fields which control the pointing of the telescope, or setup information about the observatory, will be disabled and grayed out. Only for the telescope control operator will these buttons be enabled. Most users can simply observe this application, and monitor its readouts and other information about the status of the telescope, time, other users on site, and select update rates.

The Telescope Drive Paddle application can never be operated as a stand-alone application. All Telescope Drive Paddle applications are slaved to the settings and control of the telescope drive paddle application that is under the control of the telescope operator. If no user has assumed the role of the telescope control operator, then any Telescope Drive Paddle application which are running will be fairly non-functional, telescope position readouts are meaningless and do no update, interface settings and observatory settings are also disable. About the only thing that will work is the time displays, and the ability to select a new telescope control operator. So about the first thing a user should do, upon starting this application, is to check to see if there is a current telescope control operator, or to coordinate with other users on site to determine who should assume this role. However, DO NOT assume the role of a telescope control operator, without notifying other users of your intention. To do so will disable the stand along capabilities of the star chart applications and the camera and image viewer application. The chat application is a good way to coordinate with other users on the Telescope Control web site.

3.2.1 Drive Paddle Organization

The drive paddle is organized to show a number of readouts, the state of the telescope drive, and it allows the telescope operator to control the pointing of the telescope by using a standard paddle style interface to fine control the direction of telescope movement. Two additional buttons are available at all times, one allows the user to invoke the setup dialogs where further information about the telescope can be seen and set/changed. The other is an application dependent button. For webapps it allow the user to log out of the server and shuts down all running webapps. For applets, it allows the user to float the applet out of the browser in its own window or to un-float the applet and put it back in the browser environment.

The N, S, E, and W buttons are enabled only if the user is also the operator of the telescope. When enabled they are a teal blue color, when disabled they are gray. When clicked, these buttons will send a command to the telescope drive servlet to move the telescope a delta amount along the axis that the button represents. Multiple clicks on a button are accumulative and will increase or decrease the delta amount as appropriate. To view the delta amount that will be sent to the telescope drive servlet (when the drive paddle application next contacts the servlet) hover the mouse over the button and wait for the tool tip info to pop up. The tool tip will show the current delta for the axis that the button controls.

The amount of delta applied to a drive by clicking on these control buttons (N, S, E, and W) can be further augmented with the use of the Control and Shift keys. Simply clicking on one of these buttons will cause the telescope to change positions by the smallest delta amount that its driver allows. Holding down the Control (Cntl) key, while clicking on a button, will increase the delta by a driver dependent rate for slow slew rates. Holding down the Shift key, while clicking on a button, will increase the delta by a driver dependent rate for medium slew rates. And holding down both the Control and the Shift key simultaneously, will increase the delta by a driver dependent rate for fast slew rates.

LST Displays the Local Sidereal Time for the telescope observatory.

RA Displays the current Right Ascension position of the telescope.

Dec Displays the current Declination position of the telescope.

Az Displays the current Azimuth position of the telescope.

Alt Displays the current Altitude position of the telescope.

Tracking Green light indicates the telescope is in track mode. White light indicates it is not in track mode.

Slewing Green light indicates the telescope is in slew mode. White light indicates it is not in slew mode.

N Moves the telescope by increasing its declination.

E Moves the telescope by decreasing its right ascension.

S Moves the telescope by decreasing its declination.

W Moves the telescope by increasing its right ascension.

Stop This button sends a high priority message immediately (does not wait for the normal timer) to the server to stop all movement of the telescope.

Setup Opens the Setup dialog window.

Logoff/Float/Un-Float Depending on the type of application (applet or WebApp) this button can log the user off the server and shut down all running webapps, or it can float a applet in its own window or un-float it an run it in the browser environment. (see above.)

Help  Brings up a popup menu that allows the user to see the documentation from a browser, supply feedback, or see the version information about this application.

3.2.2 Setup Dialog

The Setup dialog is divided into four parts. The first part shows the site information about the observatorys latitude, longitude, and elevation and allows the telescope operator to set these values for the simulators, or for example, if the telescope is connected to the server, then this shows the position of the Telescope Location1 (fill in later) Location2 (fill in later) observatory.

The second section summarizes information about the telescope to which the drive paddle is currently connected to. Here it displays the aperture and focal length of the telescope, the site latitude, longitude and elevation, and the name and version of the telescope driver that is being used to connect to, or simulate the telescope. For the simulators, the operator can also set the alignment mode of the telescope to simulate. If the drive paddle application is connected to a real telescope, then the alignment mode is not settable, it simple shows the type of alignment used by the telescope.

The third section shows the ASCOM telescope drive capabilities that the current telescope driver has. There are not directly settable, but for a simulator are changeable via the telescope simulator interface setup dialog.

The last section shows the time zone for the telescope observatory, and again shows the ASCOM telescope driver version and name.

Latitude sets or shows the latitude position of the telescope observatory to which the drive paddle is connected to.

Longitude sets or shows the longitude position of the telescope observatory to which the drive paddle is connected to.

Elevation sets or shows the elevation (in meters) of the telescope observatory to which the drive paddle is connected to.

Close Convenience button to close the Setup Dialog Box.

Cancel click to cancel any changes made and restore them to their previous state that was last sent to the server.

Alt-Azimuth toggle button which sets (simulator) or shows (actual) the alignment mode of the telescope.

Equatorial toggle button which sets (simulator) or shows (actual) the alignment mode of the telescope.

German Equatorial toggle button which sets (simulator) or shows (actual) the alignment mode of the telescope.

Can Find Home checked if the telescope driver can execute a command for telling the telescope to find its home position.

Can Park checked if the telescope driver can execute a command to tell the telescope to go to its parked position.

Can Set Tracking checked if the telescope driver can be told to set the telescope to tracking mode.

Can UnPark checked if the telescope driver can execute a command to unpark the telescope.

Can Slew checked if the telescope driver can execute a command to set the telescope to slew mode.

Can Slew Asynchronous checked if the telescope driver can execute other commands while the telescope is slewing.

Can Sync checked if the telescope driver can synchronize its position with a target position. In other words, it can change/synchronize its position readouts with/to a target position.

3.2.3 Drive Setup Dialog

The drive and simulator setup dialog provides a set of controls for selecting a telescope driver for connecting the drive application to. Currently, the user can select between one of two simulators or the actual telescope drive at the observatory. The primary purpose of having the two simulators is to provide an infrastructure for the testing and development of the software for the telescope control applications. However users can also use them for learning how to use the applications without having to worry about doing any damage to a real telescope. The simulators are designed to simulate, as realistically as possible, the driving of a telescope including ramp up and down rates, slew speeds, and tracking.

The simulator interface capabilities are only enabled when a simulator is being used. They are disabled when an actual telescope is connected. These checkboxes allow the user to turn on or off various capabilities of a simulation of a telescope driver. Be warned, turning off some of these will result in error and warning messages showing up in the server messages dialog, and that is to be expected. Dont worry no real harm is being done; this just confirms the proper operation of the telescope drivers and servlets.

The difference between the Java simulator and the ASCOM simulator is in how each was implemented. The Java version is a simulator that was written strictly with the Java language and runs entirely within the context of the telescope drive servlet. The ASCOM simulator is a COM object that was supplied by the ASCOM development group and was implemented in another language (probably Visual Basic). The telescope drive servlet communicates with the ASCOM simulator via a special software dispatcher and the ASCOM simulator (DLL file) handles the actual tasks of simulating a telescope. When the drive application is connected to a real telescope at the observatory, the telescope driver will also be written as an ASCOM object and communications between it and the drive servlets will also be handled by this same software dispatcher. Thus the ASCOM simulator allows testing and development to take place using the software dispatcher in the telescope driver servlet on the server.

When the actual telescope driver is written, and communication between the telescope and the web server is developed, then the user will also have the ability to connect to the actual telescope at the observatory and control it from this application. This connection process will not be instantaneous and the user will have to monitor the server messages dialog to see when the connection is completed.

Note: These controls are enabled only if the user is also the current operator of the telescope.

Equatorial Coordinates check if the simulator should be able to understand equatorial coordinates. Uncheck if you dont want the simulator to understand equatorial coordinate.

Alt/Az Coordinates check if the simulator should be able to understand altitude and azimuth coordinates. Uncheck if you dont want the simulator to understand altitude and azimuth coordinates.

Lat/Long/Elevation check if the latitude, longitude, and elevation can be changed in the simulator. Uncheck if you dont want the simulator to handle changes to these values.

Date/Time (UTC) check if the date and time can be changed for the simulator. Uncheck if you dont want the simulator to handle changes to these values. (Simulator will run on the servers clock instead)

Sidereal Time check if the simulator should be able to handle sidereal time values. Uncheck if you dont want the simulator be able to calculate sidereal time.

Set Tracking check if the simulator should be able to receive a command to put it in tracking mode. Uncheck if the simulator cannot be commanded to go into tracking mode. (the simulator determines automatically when tracking mode is on.)

Slewing check if the simulator should report when it is slewing. Uncheck if you dont want the simulator to have the capability of reporting when it is slewing.

Asynchronous Slewing check if the simulator can take other commands while it is slewing the telescope. Uncheck if you dont want to simulator to take other commands while it is slewing. Note: this is only a performance enhancement for the servlets, in Telescopes case, users cannot send commands from the applications to the servlet asynchronously.

Coordinate Matching (sync) check if the simulator can move the telescope automatically (synchronize) to a given target coordinate. Uncheck if the telescope must be commanded using a slew command to move the telescope to a target coordinate.

Parking/Unpark check is the simulator should be able to understand a Park or Unpark command. Uncheck if you dont want the simulator to understand a Park or Unpark command.

Alignment mode check if the simulator should simulate a telescope that has an alignment mode setting. Uncheck if you dont want the simulator to simulate a telescope with this capability.

Focal Length and Aperture check if the simulator can report the focal length and aperture of the telescope. Uncheck if you dont want the simulator to have the capability of reporting the focal length and aperture of a telescope.

The Java Version of the Simulator check this toggle button if you want to use the Java simulator on the server.

The ASCOM Version of the Simulator check this toggle button if you want to use the ASCOM simulator and COM dispatcher on the server.

The ASCOM Driver for the telescope at Vernonia Peak check this toggle button to connect the application to the real telescope driver at Location Peak.

Close Convenience button to close the Setup Dialog Box.

Cancel click to cancel any changes made and restore them to their previous state that was last sent to the server.

3.2.4 Time Dialog

The Time dialog is pretty much a self explanatory display of looking at time in various ways. These displays are provided simply for the users convenience and are based on the time settings of your computer. The Local Time and the Telescope Time are based on a time zone and have little to do with the pointing of a telescope. It the telescope is located in a different time zone than the one the user is, then select a city from the pull down list that resided within the telescopes time zone and the application will show the Telescope Time for that time zone. Solar Time is provided for interest only, and shows what is the real sun based time for the observatory, at its given longitude. UTC and Telescope Sidereal Time are the only useful times used in the software for pointing and tracking with the telescope. From these values, actual star positions can be obtained.

In the future, I plan to synchronize these with a web based atomic clock, but that is a low priority project for right now.

Close Convenience button to close the Setup Dialog Box.

3.2.5 Control Setup Dialog

The control setup dialog provides a set of control inputs for managing the telescope drive. Here the user can input right ascension and declination coordinates or altitude and azimuth coordinates, slew the telescope to those coordinates, move the telescope to a park position, and attempt to immediately stop the telescope should an emergency arise. Also, this dialog provides the ability to switch the control of the telescope drive between the star chart and this drive paddle application. With the drive paddle in control of the telescope, the user has the ability to use the coordinate input fields in this dialog or the paddle application buttons to control where the telescope is pointed. With the star chart in control of the telescope, the user will also have the ability to input coordinates for where to point the telescope via the star charts view controls. Additionally, with the star chart in control of the telescope, the user has the ability to control where the telescope is pointed, simply by pointing and clicking on objects within the star chart view itself.

Note: These controls are enabled only if the user is also the current operator of the telescope.

Right Ascension these input text fields allow the user to input the right ascension coordinates of where he/she wishes to slew the telescope to. These fields can be directly edited, or the user may use the pull down menus which supply the valid range of values and select the appropriate value.

Declination these input text fields allow the user to input the declination coordinates of where he/she wishes to slew the telescope to. These fields can be directly edited, or the user may use the pull down menus which supply the valid range of values and select the appropriate value.

Sexagesimal Format This toggle button changes the Right Ascension and Declination inputs fields to allow the user to input these fields in hours, minutes, and seconds or degrees, minutes, and seconds respectively. The image below shows this layout.

Decimal Format This toggle button changes the Right Ascension and Declination input fields to allow the user to input these fields in a decimal format. (with 4 decimal places) The image below shows this layout.

Altitude these input text fields allow the user to input the altitude coordinates of where he/she wishes to slew the telescope to. These fields can be directly edited, or the user may use the pull down menus which supply the valid range of values and select the appropriate value.

Azimuth these input text fields allow the user to input the azimuth coordinates of where he/she wishes to slew the telescope to. These fields can be directly edited, or the user may use the pull down menus which supply the valid range of values and select the appropriate value.

Sexagesimal Format This toggle button changes the Altitude and Azimuth inputs fields to allow the user to input these fields in degrees, minutes, and seconds. The image below shows this layout.

Decimal Format This toggle button changes the Altitude and Azimuth input fields to allow the user to input these fields in a decimal format. (with 4 decimal places) The image below shows this layout.

Slew Commands the telescope to slew to the target coordinates.

Paddle Control This toggle button places the drive paddle (this application) in control of the telescope drive. When this is selected, many of the control functions in the star chart will be disabled.

Star Chart Control This toggle button places the star chart application in control of the telescope drive. When this is selected, many of the controls in this dialog and within the rest of the drive paddle application will be disabled.

Park Moves the telescope to its park position where it is normally stowed.

Emergency Stop This button sends a high priority message immediately (does not wait for the normal timer) to the server to stop all movement of the telescope.

Close Convenience button to close the Setup Dialog Box.

3.2.6 Message Dialog

The message dialog box is used to display important telescope status messages and other server side events which may arise. Such events as the change of operators, telescope modes, and errors which may occur in the telescope drivers may be displayed here. All messages are delivered with the highest priority to the user with operator control privileges, and to all other users on a time and bandwidth available basis.

Close Convenience button to close the Setup Dialog Box.

Clear Clears all messages from the message display area.

3.2.7 Users Setup Dialog

The Telescope Users dialog displays all the users currently logged into the Telescope Control web server. It shows members as well as guests visiting the web site, the current telescope and camera control operator(s), and it allows for the selection of a new telescope operator. The telescope control web servlet uses the following set of rules to determine when the ability to select a new operator is enabled, and it determines what names will be added to the pull down menu for the selection of a new telescope operator.

Observatory members are always added to the list of allowable operators. If the telescope is connected to a simulator, and no member is logged into the website, then guest names are added to the list of allowable operators. When a member logs in, then the ability for a guest to select a new operator is disabled. The members will still see a list of allowable operators that is composed of both other members and the guests. A member can assume the operators role at any time, and can transfer the role of the operator to another member or a guest. If the operators role is transferred to a guest, while members are also logged in, then the new operator selection will be enabled for that guest only, but the guest will only see a list of allowable operators that are members, to which he or she can transfer control back to.

It is important to remember that once someone assumes the role of the telescope operator then a number of changes occur, throughout all the applications that are connected to the server. The functionality of all other drive paddles applications, that involve the telescope control and movement, is disabled, except the Emergency Stop function on members drive paddle applications. All star chart applications are immediately slaved to the telescope control application, and all controls within those star chart applications, associated with telescope control and movements, are disabled. (The telescope control operator can transfer the ability to control the telescope to his/her star chart application, or back again.) The camera controls also are disabled until there is both a telescope operator and a camera operator. The telescope supplies position information to the camera application, so thus it must be either in simulation mode or online.

Telescope Operator Displays the user identifier who has assumed the role of the telescope operator. This is visible to all users at all times.

Camera Operator  Displays the user identifier who has assumed the role of the camera operator.

Members On Site Displays (a scrollable list if necessary) of all members currently logged in to the web server.

Select New Operator A generated pull down list of user identifiers that the user may transfer telescope control to. This may be disables under certain conditions, as described above.

Guests On Site Displays ( a scrollable list if necessary) of all guest identifiers currently logged in to the web server.

Close Convenience button to close the Setup Dialog Box.

3.2.8 Misc Setup Dialog

The misc setup dialog is a place for features that cannot be categorized as belonging to other dialog groupings. Currently it has a slider which can be set to suggest an update rate at which the user would like to send information to the telescope drive servlet. (And get updated responses back from the servlet) However, this is only a suggestion to the drive servlet, if the drive servlet is getting overwhelmed with update requests, it may automatically increase the lower bounds at which the fastest updates can be made. The default lower bound is 1 second, and the default rate it is set to at startup is 10 seconds. I dont recommend trying to run it faster, unless you are the telescope control operator and need the increased speed for some extraordinary reason. (Eventually I will give the telescope operator special privileges to lower this setting at the expense of all other users who will then have their update rates automatically increased to accommodate the telescope operators increased need of the servlets bandwidth.)

Soon to be added to this dialog will be the ability to save and restore the drive paddle settings to/from cookies and muffins.

Close Convenience button to close the Setup Dialog Box.

3.3 Camera Controller and Image Viewer

The Camera Controller and Image Viewer application is currently under development. Therefore, all images and documentation in this section is highly subject to change. As I get this application working, this section will stabilize and I will remove this notice.

3.3.1 CCD Camera Controller and Image Viewer Organization

The CCD Camera Controller and Image Viewer application is organized into 4 basic sections. At the top is a section containing controls which relate to the status of the camera application and its performance. The camera status offline, simulation, or online is displayed. Two slider controls, and readouts, allow the user to suggest a rate at which he/she would like to send information to the camera servlet and receive updates from it, and to set the quality of the image that is generated for each request. The percent of quality for the image is directly related to the size of the image (in bytes) that is generated. For slow dialup access lines connecting the application to the internet, this quality should be set as low as is tolerable, otherwise you will be held up waiting for the download of the next camera image. Note: the timer which controls the request rate for sending information to the camera servlet does not start until after the completion of receiving all data from the previous request. Therefore the actual rate of updates is the sum of the download time, plus the user requested rate of updating, plus the servlets time to process each request. If the servlet is getting to many requests from all users, it will automatically slow down the rate at which images can be requested, thus balancing the amount of bandwidth it has with all the users.

Then next section contains a scrollable panel holding the images that are generated from the camera servlet. Clicking on an object in the image will cause the camera servlet to compute and generate the RA, Dec, and CCD pixel value for that coordinate in the image. This information will be displayed in the CCD Camera Messages area of the CCD Camera Exposure Control dialog area, and in the CCD SkyView dialog for the RA, Dec, and Value readouts, if the image was generated from the NASA SkyView server.

The third section contains information that was generated about the image that the servlet sent to this application. This includes a progress bar that indicates the percentage of bytes received for the image as it is being downloaded from the server. Next to the progress bar is a status light for the image. When an object in the image is clicked on, this status light will turn red and stay red until the information about the location and value of the object is actually sent to the camera servlet. At that point it will turn green again. Also included in the third section is basic information about the image, such as the CCD exposure time and type, filter identifier, size of the image (in bytes), the server supplied name for the image, and the users (or operators) name for the image. A Capture Image button is also provided here for the users convenience. This button commands the server to send an email to the user with the currently displayed image as an attachment.

The last section contains a tabbed set of dialogs for setting various different functions of the camera and image viewer application, and for getting information and displaying it, from the servlet. Each of these dialogs will be described in further detail, in the next few sections of this document.

Camera Status - Displays the status of the camera. These values include Offline, Simulation, or Online.

Help  Brings up a popup menu that allows the user to see the documentation from a browser, supply feedback, or see the version information about this application.

Image Quality - This slider controls the quality of the JPG images that the server will produce and send to this application. Values range from 0 to 100 percent and are displayed both by the position of the movable slider, and by the text field next to the Image Quality label.

CCD Exposure Time - This displays the amount of time the CCD camera was exposed for generating the displayed image. If the image was generated from the NASA SkyView server, then this field will be set to unknown.

CCD Exposure Type  This displays the type of the CCD exposure for the generated image. Normally this will be set to Object.

Filter  This displays the type of filter that was used for the generated image. If the image was generated from the NASA SkyView server, then this field will display the name of the survey that was used to generate the image.

Image Size  This displays the size of the displayed JPG image sent from the server.

Image Name  This displays the server generated name for the displayed image. This name may be selected by the operator, come from the FITS header of the image, or may be an autogenerated image name.

User Name  The name of the generated image assigned by the user. This reflects the settings as chosen in the CCD Camera Image Control dialog.

Capture Image  This sends an immediate request to the server to have it email the generated image to the user. The settings for the emailed image are controlled in the CCD Camera Image Control dialog.

3.3.2 CCD Camera Exposure Controls

The CCD Camera Exposure Controls dialog allows the user to setup the CCD camera for taking an exposure, the type of exposure, select filters if any are available, read messages from the server, and to actually command the CCD camera to expose and take a picture of the object in the sky where the telescope is currently pointing.

A good short description on CCD camera techniques can be seen at http://www.astrosurf.com/prosperi/ccd/calibra.htm

Note: These controls are only enabled only for the user who has assumed the role of the camera control operator. For all other users, these controls will be disabled, but messages from the server will still be displayed, and the Exposure Type section will show what type of exposure the CCD camera is taking.

Exposure Type Object the CCD is cleared, the shutter is opened for a defined amount of time, the shutter is closed, and the CCD is read out. This is the typical exposure for taking an actual image. When the exposure is completed, the raw image data is displayed in the image view area.

Exposure Type Light the shutter is opened for a defined amount of time and then closed, but there is no clear or read out of the CCD.

Exposure Type Bias the CCD is cleared, and immediately read out with out opening the shutter (effectively, a 0 time DARK).

Exposure Type Dark the CCD is cleared, there is a delay for Exposure Time amount of time, during which the shutter is kept closed, and then the CCD is read out.

Exposure Type Flat the CCD is cleared, the shutter is opened for a defined amount of time, the shutter is closed, and the CCD is read out. It corresponds to the image of a uniformly illuminated field which is the clear sky background (near the Zenith) 30 ' - 60 ' after the sunset.

Exposure Time sets the time the shutter is opened for Object, Light, and Flat exposures, and the delay time for Dark exposures.

Delay Time if non-zero, this starts the camera to take a repeat sequence of exposures, and this sets the delay time between each exposure. To stop the repeating sequence of exposures, simply set the delay time to zero.

Filter if a filter wheel is attached to the CCD camera, this allows the operator to select a filter to use for the exposure. The values in the pull down menu are dependent upon the values defined in the underlying CCD driver.

CCD Camera Messages text area where messages from the CCD camera servlet are displayed.

Expose click to start an exposure.

STOP emergency high priority button which immediately stops the current CCD camera operation.

3.3.3 CCD Camera Modes Control

3.3.4 CCD Camera Focus Controls

3.3.5 CCD Camera Image Controls

The CCD Camera Image Controls dialog allows the user to setup parameters for capturing an image off the server and having it emailed. Here the user can define file naming conventions, select a format and quality of the image, attach notes to be emailed along with the image (and possibly inserted into a FITS Header), as well as the email URL where the image is to be sent. We use this method of capturing images from the telescope, since Java applets and applications do not normally have permissions to write directly to a users disk.

The server will capture and temporarily store each image from the camera (or the SkyView simulator) to its local disk, and uses a date/timestamp naming convention for each image file. When the user selects to send an image to some URL, he/she has the option of simply using this server generated file name for the image file that will be sent. Or, the user can define a filename for the each image that is captured, and optionally append an incrementing suffix to the name to differentiate them.

Be absolutely certain the email URL addresses you enter are correct. Multiple email addresses can be entered, simply separate them with a semi colon. There is no way the mail server can inform you or the camera servlet if an email address is incorrect, and the mail server will simply drop any bounced or return emails into the bit bucket. Also, try to capture and send any images you want quickly. Even if you select to hold an image for viewing, the server will only retains the images, actually captured from a real camera, on its disk drives for a short period of time, then automatically deletes them in order to recover the disk space. Images that are captured from NASAs SkyView, while the camera is in simulation mode, are deleted as soon as the next image is acquired. (A future feature may have the servlet send you a confirmation or error message to the CCD message text area, if it was able to hand off the image to the mail server successfully, or not. However, this feature is very difficult to add at the current time, so is on hold. )

Use Server generated filenames  toggle button that will cause the servlet to send you the image using the automatically generated filenames for each image it sends.

Use User generated filenames toggle button that allows the user to enter their own file names in the Name field located just below this button. Each time the user captures an image, this name (with an optional auto incrementing suffix will be sent to the server to use for the file name that it emails out. Dont enter a file type suffix; this will be done automatically for you.

Auto generate file suffix check this box if you want the automatically generate an incrementing suffix for the name of each image that you capture.

FITS toggle button to select sending files in the FITS format.

JPG toggle button to select sending files in the JPG format.

GIF toggle button to select sending files in the GIF format.

Enter Email URL the email addresses of where you wish to send the images as they are captured.

Notes Free form text area where you can enter any notes you wish about the next image you are capturing. These will be sent along with the image email, and placed in the comment area of the FITS header if you select to send the image in that format.

3.3.6 CCD Camera Status

3.3.7 CCD SkyView Controls

The CCD SkyView Controls are activated, for all users when the camera is offline. They are always activated for the camera operator. These controls allow the user to use the NASA SkyView server as a source for images, instead of a real CCD camera. To use the SkyView controls, the user must select and set a number of options which the NASA SkyView server needs in order for it to generate an image. These options include the selections of a survey database, a projection to use for the image, the coordinate epoch, what form of image intensity scaling to use, the RA/Dec coordinates or object name to center the image on, the field of view size in degrees, and the generated image size in pixels. All of these options must be selected before the Submit button will be activated. Once activated, the user can click on the Submit button, which will then cause this application to retrieve all of these settings, pass them on the camera servlet, where it is relayed on to the NASA SkyView Server. When the NASA SkyView Server has completed the generation of the requested image, it will pass it back to the camera servlet, where it is than passed back to this application for display.

The current settings for the Survey, Projection, Coordinate Epoch, and Scaling are selected from popup menus associated with the corresponding buttons, and these selections are displayed in a corresponding text field area within the Current Selections: panel. The Image Selection text box area shows this information about the currently displayed image, if it came from the NASA SkyView server, regardless of whether the user or the camera operator requested the image.

(Not yet implemented) If the user uses the mouse to click on an object in the image, then the RA, Dec, and image pixel value of that location will be calculated and displayed in the area below the Image Selection text box. An additional button will be added to allow the user to select a catalog to base the computation of these coordinates on.

Survey  Brings up a set of popup menus from which a SkyView survey can be selected for generation of an image.

Projection  Brings up a popup menu from which a projection type can be selected for generation of an image.

Coord. Epoch  Brings up a popup menu from which an epoch can be selected upon which to base the coordinated of the generated image.

Scaling  Brings up a popup to select the type of intensity scaling to use for the generated image.

Coordinates  Brings up a dialog box (shown below) which allows the user to input the RA and Dec coordinates to center the generated image on. This dialog box allows the user to enter these coordinates in sexagismal format or in decimal format.

Name  Brings up a dialog box (shown below) which allows the user to input a name of an object upon which to center the generated image on. The NASA SkyView server will attempt to resolve the name using common catalog designations. Typical names that I know work are common star names, Messier names, and NGC names. WARNING If the NASA SkyView server fails to recognize a name, there is no image generated, an what is worse, no indication that a failure occurred. Therefore the user may be left waiting for quite some time before realizing that a problem has occurred.

Size in Degrees  The sets the field of view size, in degrees for the generated image. This value must be in decimal notation such as 1.5 and is passed directly to the NASA SkyView server without doing any format checks. WARNING if the NASA SkyView server fails to recognize the value, there is no image generated, and no indications that a failure occurred. ALSO some bit of common sense is required in selecting the field of view size, as it is based on the type of survey is being used. For example a 10 degree field of view generated from the Digitized Sky Survey is going to take an extremely long time to generate (hours) while for one of the radio or XRay surveys it may be a reasonable value. If you dont know what is a reasonable value for the survey, check the default box next to this field and let the NASA SkyView server figure out a reasonable value for you.

X Pixel in size, Y Pixel in size  These fields allow the user to input the size of the generated image in pixels. These must be integer values and again reasonable common sense should be exercised.

Current Selection Coordinates  Displays the selected epoch basis used for the SkyView server to use in understanding the RA/Dec coordinates inputted by the user.

Current Selection Projection  Displays the selected type of projected requested by the user.

Current Selection Survey: - Displays the selected survey requested by the user.

Current Selection Scaling: - Displays the selected intensity scaling requested by the user.

Image Selection  Displays information about the currently displayed SkyView image.

RA: - Displays the computed Right Ascension of an object in the image that was clicked on by the user.

Dec: - Displays the computed Declination of an object in the image that was clicked on by the user.

Value: - Displays the pixel value at the location clicked on, in the image, by the user.

3.3.8 Autoguider

3.3.9 Setup

3.3.10 Image Sharing Controls

3.3.11 Camera Users

The Camera Users dialog displays all the users currently logged into the Telescope Control web server. It shows members as well as guests visiting the web site, the current telescope and camera control operator(s), and it allows for the selection of a new camera operator. The camera control web servlet uses the following set of rules to determine when the ability to select a new operator is enabled, and it determines what names will be added to the pull down menu for the selection of a new telescope operator.

Observatory members are always added to the list of allowable operators. If the camera is connected to a simulator, and no member is logged into the website, then guest names are added to the list of allowable operators. When a member logs in, then the ability for a guest to select a new operator is disabled. The members will still see a list of allowable operators that is composed of both other members and the guests. A member can assume the operators role at any time, and can transfer the role of the operator to another member or a guest. If the operators role is transferred to a guest, while members are also logged in, then the new operator selection will be enabled for that guest only, but the guest will only see a list of allowable operators that are members, to which he or she can transfer control back to.

It is important to remember that once someone assumes the role of the camera operator then a number of changes occur, throughout all the applications that are connected to the server. The functionality of all other camera applications, that involve the camera control, is disabled, except the Emergency Stop function on members drive paddle applications.

Camera Operator  Displays the user identifier who has assumed the role of the camera operator.

Select New Operator A generated pull down list of user identifiers that the user may transfer camera control to. This may be disables under certain conditions, as described above.

Telescope Operator Displays the user identifier who has assumed the role of the telescope operator. This is visible to all users at all times.

Telescope Status  Displays the current status of the telescope, i.e. Offline, Simulation or Online.

Members On Site Displays (a scrollable list if necessary) of all members currently logged in to the web server.

Guests On Site Displays ( a scrollable list if necessary) of all guest identifiers currently logged in to the web server.

3.4 Chat, Message Board, White Board

The applet which supports the chat, white board and message board was developed by a third party called GroupBoard. It is an evaluation copy (shareware) which I have installed for the group to use and evaluate. If we like it, and wish to purchase it, then we will have access to all of its features, and they promise to disable the annoying advertising popups that go along with the free version of their product. Rather than document this here, just click on this link and read the documentation they supply at their web site. http://www.groupboard.com/user.html Like all the other applets for the telescope control web site, this one supports the ability to float it off of the web page an run it independently from the browser. It also automatically logs you in to their chat server, using the id that was assigned to you when you logged into the website.

While not directly related to the control of the telescope or its instruments, it is a good idea to bring this application up first so that you can see who all is on the web site and find out what they are up to. It also lets other users know that you are on site. If you become an operator of either the telescope or the camera, then it is almost mandatory that you bring up this application and monitor it, so other may communicate with you, if need be. Otherwise you risk making some other users very irritated with you. As with all chat rooms, observe common etiquette rules, and please keep the subject of your conversations focused on the telescope operation and related topics.

There is no WebApp version of this yet. I plan to develop a WebApp that will simply launch this applet within your browser. This is not as good as a real WebApp, but it is a reasonable workaround. (Maybe I can talk the folks at GroupBoard to create a WebApp version of their code.)

Included on the web page that launches this applet are links to the documentation, and a link that can bring up the admin panel shown below. This admin panel is password protected (contact me if you want the password) and can be used to ban or ignore objectionable users. Again refer to the documentation at the GroupBoard web site for further information.

4 To Do

We are using Bugzilla to serve as a holder for tasks, bugs, milestones and other goals that need to be accomplished in order to call this project complete. It is a dynamic list that will grow and shrink over the course of time, and hopefully will one day no longer be needed. Some of the items are simple, others difficult, some overlap, some need money, some are dependent on hardware devices, and a few are just whines and wishes These are just a free think mind dump and it is not really meant to be understandable, but it does give some feeling for what still needs to be done. If you are curious and want more information, just ask and I will fill your head with geek speak! Feel like volunteering?

Click here to go to Bugzilla!

Good luck and I hope you will enjoy our website, working with the telescope(s), and your browsers new capabilities and desktop applications that we provide! If you encounter any problems or got a wish for a feature not covered above, in the To Do section, send me an email. Marc (Telescope Org's webmaster...)

Last Updated On: Sun, April 10, 2005