Saturday, December 15, 2012

Issues as of 12/15/12

YAY our list is getting much smaller. The big news of this post is rough autofocus is working. It does NOT do "on target" focusing so it cannot adjust for temperature changes as the night cools. Rough  focus only  be performed between targets. An on target focus, finding optimal FWHM of several stars, will be used in the the future (few months if not sooner).

Rough focus script will be added to RTS2 trunk in the scripts folder. 

Focus decent but can be much better, looking for MOFAT and direct <3.0


The other top priority is getting astrometry pointing correction implemented. Once completed we use the images collected for data purposes.

Another issue that came up is determining exposure times for a field. Currently exposure times are entered per target. For our work we expose between 15-45 seconds. This is ok but conditions alter scene quality so for the same target, exposure times may be differ between nights.

Will be working a solution for this and posting our results.


Software
  • Astrometry needs to be brought back into observation procedure
  • In target Autofocus moved to Stage 3, see BORAT status page above. - Currently using rough autofocus, on target focus will hold off
  • Night report, not working...puzzled
Hardware
  • HP Server needs temperature switch rigged for temperatures < 32F or 0C - Fixed by placing sensor on CPU, inline resistor replacement failed...
  • Boltwood sensor reporting clear skies as cloudy - Now showing cloudy when not, back to driver - Fixed, Sky-Ambient temperature threshold set much higher
  • Boltwood sensor 'very windy' threshold set way too low.
 Security
  • Bluecherry kernel module rebooting server - Bluecherry pushed updated - DONE
  • Zoneminder now recording AllSkyCam and cameras - DONE

Friday, December 14, 2012

New SkyCam

We finally bit the bullet and bought something to calibrate our weather sensor on cloud cover. We want to know the difference between very clear, clear, partially cloudy, very cloudy. Few days ago Mike installed the AllSkyCam and it is recording on our capture card via Zoneminder.

Ohh and it happens to make really cool time lapse videos.



AllSkyCam TimeLapse of BORAT from Mr337 on Vimeo.

Wednesday, November 14, 2012

Issues as of 11/14/12

Thing are rolling, just slowly. I have been testing the telescope startup scripts with great success. Now focus lies in working with single object observations and ironing out all the kinks.

Currently single object observations is where RTS2 only has one target to observe. It is much more controlled than just adding a bunch of targets and setting RTS2 lose and hoping for the best.

With single target observations I have came across several problems that I didn't expect. Focus is currently the biggest issue. I didn't realize how badly focus can be set due to temperature at the start of observation. Since Autofocus is one of the complex problems I will write a small script to do rough focus, or close to optimal focus, at beginning of observation. This simply serves as a band-aid for current operations and will be replaced in the future, stage 3.

Another issue that seems simple but turned out to be way more complex is determining exposure time without any manual input. In the end BORAT should be able to slew to a target and within a few images determine the best exposure time, not to bright and not to dim.

There are many end cases where this can fail so we hope to solve this soon. For now an observer, currently me, will manually set exposure times  of 15s.

Next few night will be clear and will be ironing out more bugs. Stay tuned...


Software

  • Modify focus driver to test independent pieces to pinpoint cause of mirror flop - Done and fixed
  • RTS2 LX200GPS driver getting overhauled to actually work, and to support LX200GPS specific features like sleep etc - Done, sleep on standby
  • Astrometry needs to be brought back into observation procedure - TBA
  • In target Autofocus moved to Stage 3, see BORAT status page above.
  • Startup/Shutdown observatory scripts - Done
  • Night report - Testing
  • Filename formats set close to our guidelines - Done
  • On observation focuser receives NaN for TOC_TAR and crashes driver -Fixed
  • Removed post processing script that failed moving images to trash - Done
  • Need to implement log rotations, RTS2 logs getting toooo big- Testing
Hardware
  • HP Server needs temperature switch rigged for temperatures < 32F or 0C
  • Boltwood sensor reporting clear skies as cloudy - Now showing cloudy when not, back to driver
 Security - ON HOLD

Wednesday, September 19, 2012

Fork Jumping Solved?

Last week we performed some test to determine if the mirror flop or jumping is caused by hardware or setup of fork. This was done by simply turning off pointing correction of any sort on the LX200GPS mount.

This included Smart Drive, Period Error Correction, and all motor/sensor training models. Initial tests show that one of these correction features/methods was calibrated incorrectly and was causing the  jump. Which feature we are unsure of, but we simply know things are working much better.

Currently we will operate the fork with these features off. Once we reach the milestone of automatic observing I will turn on one feature at a time and fully configure it, test it, and ensure it doesn't introduce jumps.

Current news is tonight we will be testing the startup/shutdown scripts. Stay tuned!

Thursday, August 23, 2012

Mirror Flop/Motor

In the previous post I displayed some problems we were having in mirror flop.

To test this I performed three tests all while telescope tracking.

1. Take exposures without doing any focusing
2. Take exposures while only locking/unlocking focus knob
3. Take exposures while slightly adjusting focus

Results:
They all had stars dancing between frames. After discussing with Mike we have pinpointed the root issue to something in the sidereal mechanical drive. Mike pointed out that because it is periodic this points to the drive. Our next action is to visit the fork features called Smart Drive from Meade that is supposed to compensate for mechanical defects in the drive.

Now tests 1 and 3 have the same looking drift/jump of stars. Test 2 did reveal that the mirror lock is causing mirror flop. So for now we decided to not use the mirror lock and will revisit the issue soon.

With all this being said, the better news is the starting of observations. At this point all that is needed is starup/shutdown scripts to hammered out and then we can let the observatory run itself. Again being another landmark :)

Stay tuned!

Sunday, August 19, 2012

Issues as of 8/19/2012

Set Back
It seems that as soon as something is fixed another thing breaks. This time it was the CCD. For some unkown reason the CCD failed to readout the image after the exposure. It would only happen to the BORAT server and only with the Debian install. Changing the distro fixed the issue.

I took the Debian install, took an exposure, camera locked up (from the server perspective). Hot swap to another distrobution and magically the CCD works perfectly, without resetting the CCD.

 I think this may have been due to a library update on Debian. Which library heck if I know. The local debian update repo was messed up so instead of fixing (already killed two nights), rebuilt the BORAT server with Ubuntu, which only took about 6 hours. I would have really liked to figure out what really went wrong, but this issue put the entire project on hold.

I do NOT place the blame on Debian, it was some thing messed up with our local install. 


New Problem YAY!
Another issue that is a kick in the groin is the home grown focusing unit may not work for scientific work. Initial test of using the focuser shows that between focus adjustment the stars seem to skip to a new position. If further testing confirms this that is bad, this is really bad. Why you ask?

Focusing Test, tele @ park, focusing between exposures


 Stationary Test, tele @ park, taking exposures

In short when the stars randomly move around it messes with the autofocus. The autofocus expects stars to be in the same position, assuming tracking works and no fork problems, so when the star moves out of it's spot the FWHM for that star is incorrect. Take this and apply to all the stars in a field and this creates a very big problem.

The autofocus script does do radial detection of stars, but if the stars jump a whole lot, like in the video, we can't perform miracles.
 
The astrometry tracking correction, I assume, is also effected. A new pointing model is created with each new image thus a telescope adjustment could become quite frequent. This could become an issue too.


Software

  • Modify focus driver to test independent pieces to pinpoint cause of mirror flop- More testing Needed
  • RTS2 LX200GPS driver getting overhauled to actually work, and to support LX200GPS specific features like sleep etc - In Progress
  • Astrometry - FIXED by using sextractor instead of built in star detection :)
  • Autofocus - Before BORAT rebuilt we got mixed results, main issues due to focuser altering star position (see above)
  • Add user friendly GUI to control primitive features of the system - On Hold 
  • Startup/Shutdown observatory scripts - Done, NEEDS TESTING
  • Night report
Hardware
  • Deadman switch for dome in driver - Done, Needs Testing
  • Motion sensor wiring done, just need to connect each sensor via breadboard/connectors - On Hold
  • Boltwood sensor reporting clear skies as cloudy - Fixed (testing)
  • Fan need to be added to focuser/fan controller box - Ordered
 Security - ON HOLD
  • Motion detectors need to be wired in and fully tested
  • Need some minor integration with IR+ZM+Lights work in combination
  • Bluecherry Capture Card module causing kernel panics, need to grab new version and compile

Sunday, July 29, 2012

Astrometry.net Pointing Corrections

For a while it has been a little mystery on how RTS2 handles telescope corrections. With the help of Wildi it is actually pretty simple.

1. RTS2 takes an exposure, when complete imgprocess.py processes the image
2. This fires up Astrometry.net which begins calculations on the exposure to determine the center of the exposure
3. Once Astrometry.net finds the position a correction is generated by looking at the RA and DEC on the exposure header and calculated the difference from what Astrometry got. Think of it as a delta.
4. RTS2 reads this correction and stores it as WCORR (waiting corrections)
5. During next pointing (between exposures) RTS2 add WCORR  to the target coordinates and tell the telescope to slew to the new position thus correcting the telescope pointing.

RTS2 also has a correction threshold to ensure if the correction is extreme it will simply ignore the corrections. This would only happen if the RA and DEC of the exposure is wrong or if Astrometry.net matches the wrong coordinates (haven't experienced this yet).

In other news Astrometry.net solving in RTS2 now supports the use of Sextractor which seems to be better at selecting objects. (svn up people!)

On a more sour note reviewing the LX200 and LX200GPS driver show the LX200 driver *may* have outdated protocols. Especially for the parking commands. The LX200GPS drivers looks like it is a partial implementation.

With this being said our LX200GPS may still support older protocol commands which would be nice. If not will have to update the LX200 or finish the LX200GPS which might not be bad since the LX200GPS has extra features like sleeping and self defined home/park position.

*sigh*