Wednesday, August 17, 2011

The Instrument

Our system will be using an instrument composed of a custom focuser, filterwheel, and CCD. These pieces must be assembled each time we attach it to the telescope. When the security system matures and we have the fence installed we will be able to leave it at the site in one piece.

The focusing device is essentially two motors on a specially constructed piece of metal to operate the telescope's focus knobs. It's in the upper right of the photo.

The filterwheel is a USB Apogee AFW50-9R. It takes 50mm round filters (we have U, V, B, R, and I). The driver had to be tweaked a bit but now it works well in RTS2.

Our CCD is an Apogee Alta U47. For all the details you can see their official specs here. We have three of these devices at our observatory and use them in several projects. We're currently having some issues with the RTS2 integration (some binning issues) but expect to have it sorted out soon. 

The actual assembly of this instrument takes about 15 minutes to an hour, depending the experience of the person doing the assembly. It takes a total of 5 different hex wrenches to complete! The CCD connects to a mounting plate and then to the filterwheel. The filterwheel is screwed into an adaptor plate and this is bolted to the focus ring. After this, all you have to do is carefully screw it onto the back of the telescope and attach the cables and belts. I personally can't wait until we can put everything together and leave it at the observatory.

The completed instrument with all the rings and equipment connected weighs about 10 pounds. Our counter weight system only went to 6 pounds and this proved to be a problem when it comes to tracking on the Meade forkmount. That is a problem for another post, though!

Sunday, August 7, 2011

Nagios Implementation

With the observatory being at a remote location we would like to know if anything interesting happens. At the current time would just like to monitor servers and switches to make sure they are up. This can be done with Nagios. Nagios is a neat open source solution to monitor any equipment that sits on a network.

After a couple of hours of fighting Apache rules and writing own configuration scripts got the remote server and switch working with local mail notifications.

The really neat feature of Nagios is it can be highly customized and extendable. This also includes devices that generic templates don't exist such as our remote power switch. With a little time I would like to add RTS2 integration to make sure RTS2 is running and if it encounters any problems can be forwarded to our cellphones.

Lightning Speed To Observatory - Think NOT!

Currently we have a microwave based internet at our observatory location. It is used by observers but the rest of the time it is used for the roboscope. Either transferring files or us administrating remotely.

A fast internet connection is nice but sometimes we feel the pinch. Here is a plot of our ping times over a week. Ping test performed every hour. Something to keep in mind is this data is when DNS resolved. Some pings tests couldn't even be carried out due to complete loss of connectivity.

SSHing becomes impossible with high ping times. Also average download speed is ~25 Kbps, scared to test upload.

RTS2 UPS

Sooner or later, especially where our telescope is located, we are going to have power problems. At our location the main problem is dirty power or lack of power. We run two UPS in parallel, one for the dome and the other for the rest of the electronics.

The UPS for the dome is a large 220V which should be overkill for the dome and have long run-time. The UPS for the electronics is much smaller thus having the least run-time of either UPS. RTS2 monitors the smaller UPS via NUT. This will allow for the PC to start shutting down and can even be off/UPS dead and as long as dome has received the "close" command it will continue to close regardless of the PC or the smaller UPS.

The hardest part in allowing RTS2 to monitor UPS systems is configuring NUT. This lead to a wild goose chase in finding the USB path. Udev wasn't creating a symlink so a udev rule wrote for the UPS generated symlink of /dev/upsCP1500.




For those with a CyberPower CP1500C use this udev rule
SUBSYSTEM=="usb", ATTRS{idVendor}=="0764", ATTRS{idProduct}
=="0501", SYMLINK+="upsCP1500"