Wednesday, October 12, 2011

Problems of 10/12/2011

Finally our list is getting smaller and smaller. Some of the items have to be performed on site like dome driver fixing. Another thing to add to the list is much testing. This weekend hopefully should be able to get first light.

Software
  • AstroHaven dome driver needs update to stop spamming error messages and to add feedback from new dome control hardware
  • Add user friendly GUI to control primitive features of the system - Starting
Hardware
  • Buy cabling management for inside of dome
  • Repair crack on AstroHaven Dome
  • Still need to spec out computer capable of extreme temperatures. Computer still needs to have PCI slots and serial ports. Don't want to use USB<->Serial
  • Add lens heater on LX200GPS to reduce night dew.
Long Term
  • Possibly add Android app interface/add
  • Draw a plan for UPS during extreme temps

Monday, October 3, 2011

Telescope In Dome

Finally after several months of writing driver and hoping political messes the telescope is finally in. Not yet tested hopefully little testing has to be done and lots of trial runs.








With the telescope pointed at zenith with dome closed only two inches of clearance. You might wonder where am I in the pictures. I am just the guy taking the pictures. ;)

BigNG vs Insect

After four months of running our fan controller suddenly stopped responding in RTS2. Direct serial communication produced nothing either. Getting frustrated I took it from the dome to campus to work on it. By chance I happen to inspect it and noticed corrosion on some if the ICs.

On the lower left black chip the corrosion is the worse. Several pins on the IC are simply gone. This chip happens to be the USB controller hence the bad USB communication. There was some bug poo on the IC chips themselves that I scrapped before taking picture. Next fan controller I will put in an enclosure to prevent this.

Monday, September 26, 2011

Problems of 9/25/2011

Got a lot accomplished since last list but as usual more problems creep up over time.

Software
  • Focus driver - implementing in RTS2 - DONE
  • AstroHaven dome driver needs update to stop spamming error messages and to add feedback from new dome control hardware
  • TBan driver needs code to handle when device is not there rather than spam messages - DONE
  • Add user friendly GUI to control primitive features of the system
  • Possibly add Android app interface/add
Hardware
  • Ordered another Webswitch, they are so cool - DONE
  • Mount Telescope and pier - DONE
  • Buy cabling management for inside of dome
  • Repair crack in AstroHaven Dome
  • Still need to spec out computer capable of extreme temperatures. Computer still needs to have PCI slots and serial ports. Don't want to use USB<->Serial
  • Draw a plan for UPS during extreme temps - put off
  • Add lens heater on LX200GPS to reduce night dew.
  • Corrosion on BigNG board - ordered new one - DONE

Wednesday, September 7, 2011

Binning and RTS2

Recently we've been having some troubles getting binning to work under RTS2 with our Alta CCD. Binning is a technique that can be used to speed up the dead time spent reading an image from the CCD - something that is very useful for the kind of high frame rate we wish to achieve with our system.

During testing a month or two ago we found that our Alta U47 would become unresponsive after setting the binning to 2x2 in the RTS2 monitor. The camera essentially stops responding to commands and needs to be power cycled to come back to life. I've been debugging the Apogee drivers forked in the RTS2 codebase for a while until I stumbled onto a quick fix: simply set the binning in the CCD script instead of directly in the monitor! I'm not sure why I didn't try this earlier. Here's an example:

rts2-scriptexec -d C0 -s 'binning=1 E 2 E 2'

This script sets the binning and then exposes twice for 2 seconds each. The readout time is about 0.5-0.8 seconds for each frame. Note that 1x1 binning is actually selected as "binning=0" and 2x2 is "binning=1" in the script.

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"

Tuesday, July 19, 2011

BigNG sensor fix

Originally the BigNG fan controller/sensor was reporting 0s for all the analog sensors. After double checking to make sure the sensor were plugged in correctly it was back to the driver to see what was going on.

Again it pays to read the documentation very closely. The BigNG has it's own subset of function to poll analog data. After simple fix temperatures came in correctly. Small post but also gave me an excuse to post how we work with RTS2.

Monday, July 18, 2011

Fixing AstroHaven Enterprises dome driver

Timing is everything and especially so when it comes to computers.

When issuing a command the dome controller will run the command exactly for one second. So when writing the driver the code to open and close the leafs were dead simple. Or so I thought so......


cmdSent=0;
response = '\x00';

while(response != POLL_B_OPENED && cmdSent < MAX_COMMANDS)
{
sconn->writePort(CMD_B_OPEN);
sconn->readPort(response);
cmdSent++;
}

if(cmdSent < MAX_COMMANDS)
{
return 1;
}
else
{
return -1;
}


This code simply sends the command and keeps sending till it gets the wanted response. There is a upper limit set in the header file. The variable cmdSent is incrementing to the limit. The limit is just in case something might happen we can report a fail to open or close. A question might come up why we can't simply hard code a number?

Two reason, first is the controller and motors isn't exact. I can't say opening the dome will take X amount of seconds because with age the time to open and close will change. Second this driver will work for all three sizes of AHE domes with same controller. (Heard AHE now ships with different controller) Make it versatile as much as possible.

The problem started when converting the AHE driver from a custom serial driver to the standard RTS2 ConnSerial driver. So simply replaced write and read with the functions of the ConnSerial and tested. Everything worked except the opening and closing.

I worked on this problem for several hours. Mainly it took so long because it was super late and debugging abilities lessen with lack of sleep. :) Can you spot the problem? Hint: readPort() is non blocking......

Originally the serial read function of the custom serial was blocking. So when I replaced with the new code forgot it was non blocking. When this code runs it will reach the upper limit before the leaf started to close or open thus throwing an error and quitting. Quick fix is to sleep giving time for dome controller to move.


while(response != POLL_B_OPENED && cmdSent < MAX_COMMANDS)
{
sconn->writePort(CMD_B_OPEN);
sleep(1); //simple fix here
sconn->readPort(response);
cmdSent++;
}


Lesson learned, never assume anything and RTFM!

Thursday, July 14, 2011

Dome Wiring

Our wiring is out of control! We can't make anything permanent yet because we still have to install major things like the telescope pier. Not to mention we still have some repairs/updates that need to be done to the dome motor system.

In any case, I've cleaned things up a bit and zip-tied some of the longer cables. In the future it would be good to have some shelving or mounting for some of the boxes as well as more tubing or clamps to hold wiring against the wall. On another note, there are some interesting creatures living in the cabling - maybe I'll post a few photos in the future.

Problems of 7/14/2010

In an effort to try to keep on top of issues I have decided to post them. As we solve each problem will write a follow up post explaining how and why we solved it.

Here is a current list the developers (Matt and I) are working on.

Software
  • BigNG sensor has analog sensor dumps but libtban does not return a temperature when calling analog sensor individually. - fixed
  • Apogee Alta CCD camera driver is currently not working. Problem lies in setting binning other than 1x1 will cause camera to hang on next exposure.
  • RTS2 UPS integration has not been started yet. - fixed
  • Convert RTS2 driver to use general SerialConn versus Vermes template. - fixed
  • Meade LX200 driver not talking correctly to LX200GPS - fixed
  • Filter driver - done just needs ported to RTS2 interface
  • AstroHaven Enterprises dome driver not working correctly - fixed
  • Add udev rules for all the USB devices
Hardware
  • Still waiting on AstroHaven Enterprises dome motor replacement.
  • Webswitch III died last weekend. Waiting for support to call use back. Maybe defect/warranty case.
  • Still need to spec out computer capable of extreme temperatures. Computer still needs to have PCI slots and serial ports. Don't want to use USB<->Serial
  • Draw a plan for UPS during extreme temps
  • Add lens heater on LX200GPS to reduce night dew.
We certainly have plenty of things to do and to fix. There are also some problems we don't have solutions for quite yet. Any ideas welcome!

Tuesday, July 12, 2011

Summer Temperatures

A major concern of ours is internal dome temperatures. Right now we have a small ventilation system, but no cooling or heating system. Extreme temperatures will pose a problem because most UPS (uninterrupted power supplies) and computer systems are not designed to handle freezing or extreme heat.

On the left is a plot of our recorded temperature over a few months. The dome doesn't seem to be trapping heat or cooking our components yet. The dome currently houses an experimental computer with no special cooling and most of our required equipment (UPS, weather station, etc). So far the only casualty has been a remotely controlled power strip, but this is probably a defect and not a result of heat.

Sunday, July 3, 2011

Basic Overview

The autonomous telescope we are constructing at Missouri State University (I'll call it "roboscope" for short) has a couple important goals. These include:
  • User friendliness. Students should be able to schedule an observation as a part of classwork.
  • Dependability/Autonomy. If you schedule something and the weather is good, you should have results as soon as you wake up the next day with no user intervention required.
  • Modularity. Components should be easy to switch out. This is good for the long term operation as parts will inevitably wear out or become obsolete.
  • Economics. Most telescope systems of this scale are out of reach for many schools because of cost. We aim to develop a system that other institutions can afford for themselves.

The hardest part about a project of this magnitude is stepping back and looking at all the components as a whole. This post is a sneak peek of some of the components making up our robotic observatory.

Prototype diagram
Our telescope system is composed of many parts. At the heart of it all is a computer running RTS2 software (among other things). This computer gathers information from a weather and temperature sensors and sends commands to hardware inside the dome. This includes dome motors, a telescope/mount, filterwheel, focuser, and ventilation. Not pictured in this diagram is surveillance and the security system protecting the equipment. Further posts will talk about each of these components in greater detail.

First Post

Just testing out the syntax highlighter...

#include <stdio.h>

int main(int,char**)
{
    printf("Hello, world!\n");
}