Saturday, December 28, 2013

Weird, wild rotating of the Mach1 mount ...

Last night, when I started my imaging session, I noticed that my handcontroller didn't work. I pressed various buttons (trying to indicate my location), but nothing worked. Checked if the handcontroller plug was firmly in the control box. I finally decided to leave it alone as I'm using plate solving anyway for slewing to my targets. So, I synced the scope from TheSkyX to a star and then started my imaging session.

At some point later (more then an hour) I could hear my mount. When I checked it, it was spinning around the DEC axis. It would stop for a short moment at the north pole and then do another round. Luckily the scope was in a position where it didn't hit the mount!

I powered down the scope immediately. Started it back up. I then tried to use the handcontrol again. And noticed that if I pressed buttons often/hard enough at some point they would work. So, I did that and then continued my imaging session. But soon after the same spinning happened again.

I suspect that the hand controller is faulty. Tonight I'll use the mount with the handcontroller disconnected and see what happened. I also posted on the ap-gto mailing list - maybe anyone there has an idea.

---

I followed up directly with Astro-Physics support and they also suspected that this was the motor itself. But because I'm mostly imaging, they gave me some useful advice:

  • Set AutoConnect=EXT (meaning, the external controller aka my computer has priority over the keypad)
  • Don't use Park 1, use park 2, 3 or 4 (I did use park 1, now I'm using park 3 which I like most during the day anyway)
  • Be sure that the AP V2 driver is set to convert all Sync commands to ReCal
  • Be sure to NEVER GoTo with the Keypad and ReCal (or Sync) with the computer or vice versa

I did all that and since then didn't encounter any issues.

---

A friend of mine gave me his AP keypad and I tried it out. And it didn't create any issues (tried several times). So, there is clearly something wrong with my keypad - not sure if it is the cause for the wild slewing.

Checking focuser slip

There were many reports around that the focuser that comes with Takahashi scopes isn't great and slips. I asked Richard Crisp how to measure it. He recommended to put the scope in focus, point the scope up and then move the focuser all the way out and back to the focus position and check if the scope is still in focus.
For this, I could use the Bahtinov mask and Bhatinov Grabber to measure exact focus. Luckily Capella was almost in the Zenith which made a clear Bahtinov pattern.
Here are the results (I moved the focuser several times to check if there would be small slippage over time):

1.0.10
2.-0.10
3.0.03
4.0.03
5.-0.08
6.-0.04
7.0.01
8.0.06
9.0.00
10.-0.31
11.-0.10
12.-0.06

Looks as if there isn't any noticeable slippage. Good!

Friday, December 27, 2013

Temperature Compensation

I noticed that the TOA scope shrinks quite a lot during the night when it gets colder. When I focus my scope first thing in the evening, it has to move almost 100 steps(!!) to regain focus (the last position was the focus point at the end of the previous night).

So, I used the TEMPer device to measure temperature and then the Bahtinov grabber do determine exactly the focus point:
1. Evening - 11.98 degrees - 29296
2. 1am - 6.91 degrees - 29224

That means I have to adjust 14 steps for each degree!

I entered this in SGPro. Next night, I checked but it didn't look as if SGPro adjusts the focuser (unless I run autofocus again). I checked in the log file and found a lot of lines like this:

[12/27/2013 4:34:31 AM] [DEBUG] [Sequence Thread] Temperature compensation: Adjusting for 0.0 degrees (end: 100.0; end: 100.0; coefficient: 14) for 0.0 steps...

Seems as if SGPro is not using the TEMPer device for compensation but the built-in Robofocus temperature (which always returns 100 degrees!) I asked on the mainsequencesoftware mailing list and was told that this wasn't implemented so far, but that the code is ready and will be in one of the next updates!

---

Checked the fix, but it seems as if the 100 degrees still come in from somewhere. Waiting for the next fix.

---

Release 2.3.1 seemed to address this! Worked perfectly the first night. But next night, the temperature was shown as NA. After some trial and error, I found out that I first have to disable this setting (Tools->Options->Other Equipment Options->Use a TEMPerHUM device) and then re-enable it. Then the temperature would be read properly from the TEMPerHUM device.

Thursday, December 26, 2013

Trying to use "Plate Solve and Blind Sync" in SGPro

I found out about the "Plate Solve and Blind Sync" functionality in SGPro. Instead of pointing the scope to a particular star, then centering it and syncing on that star, I could just point the scope somewhere in the sky, SGPro will do a plate solve and use the coordinates for the telescope sync.

Tried it out right away. And it worked "almost". I could see that the sync told the scope the correct direction (I could see in TheSkyX that the scope pointed into the right direction). But when I then tried to slew to a different location, the mount would run the telescope into the pier...

Asked on the mainsequencesoftware mailing list, but couldn't get a good answer :-(

Well, not the end of the world - but it would have been nice to safe an additional 10 minutes of setup time.

---
12/29/2013:
I got some more ideas how to make this work!
When my Mach1 mount started to slew erradically, I posted to the ap-gto mailing list. And from that discussion came several ideas how to make this work. Will try this when I'm back home next week!

Tuesday, December 24, 2013

New Scope #4 - Robofocus

I finally received the Robofocus stepper motor back (great x-mas present! :-) and could connect the Robofocus. With the bracket for the TOA 130 scope it was quite easy:

Connected it - worked immediately.

I then had to reconfigure the Robofocus module: change the step size, reverse direction (so that "out" means "out"!) But for some reasons, I could not connect the Robofocus control program anymore. I always got an error that the serial device is already in use. I remembered that I didn't use the control program for quite some time - maybe it was the new USB-Serial converter? I tried one of the cheaper ones (which doesn't keep its serial port) ... and it worked right away. Well, I only needed it to configure the Robofocuser and then could switch back to the newer adapter.

I set the step size to 1 (now the entire range of the focuser is ~5000 steps!), reversed the direction. And was done.

Same night, I configured the auto focus routine of SGPro. I used step size 10 and 15 data points. And it worked beautifully. I also finally understand why it's called a "V-curve" (with the EDGE scope it barely resembled one):


Saturday, December 14, 2013

New Scope #3 - First imaging experience

I am still waiting for the FLI camera and filter wheel, so I am using the H694 from Starlight Xpress for now. I had to get an extra connector from preciseparts from it :-( They aren't cheap, but it so worth it - very stable and robust!

First, I had to focus the scope. Without the Robofocus I had to focus manually. And I could even use my old Bahtinov mask - I bought it for my 6" SCT. And it fits quite well on the TOA 130.

Next, I wanted to adjust the red dot finder. I do remember that this was a major pain in the a... But with SGPro, I could use it's center function to center the scope on a bright star (Deneb) and then adjust the red dot finder until it was over Deneb. Wow - that was easy!

Then I wanted to do some basic curvature analysis. After all, that was one of the main reasons to switch from an SCT to a refractor. Took some random images and analyzed them with CCDInspector:

Not too bad! The remaining tilt could be with the imaging train. I'll investigate this more when I get my FLI camera.

Next on my list was to calibrate SGPro to take flats with my flip-flat. Took me a while to figure that out. But now I have all my filters calibrated. But the flats look like this:

Yikes! Seems like I got a lot of dust into the imaging train when I assembled it. Will fix that with the new camera too.

At some point when the scope pointed almost straight up, guiding became VERY shaky. Pretty much unusable. When I checked the scope, I noticed that the filter wheel was hitting the Mach1 keypad - which was dangling loosely. See these image that I took the next day:
 

Seems like I will have to move all the cables and everything to the front or back to the scope. This is certainly a problem that I didn't have with the shorter EDGE scope before.

Finally, I took some images just to see how they look like:

This is a simple Luminance image (10 subs a 10 minutes) of M31. Only stacked no processing whatsoever. Very impressed with the amount of detail that I can see here. Can't wait to take some real images!!!

Sunday, November 24, 2013

New Scope #2 - Cabling

I had to order 2 more counterweights to mount the Takahashi scope (it's so much heavier then the Celestron EDGE scope!) Once I had those, I could work on mounting it and connecting it. I wanted to move all the equipment boxes (Robofocus box, Dew Heater box, Power distribution, USB hub). Then I only have 2 cables through the mount which should make this easier. Also, when moving the scope outside or back, I would have to carry the mount and the scope separately - and that would be much easier if I only have to connect 2 cables.

Went to Home Tepot to buy fitting screws and some metal sheets. I screwed them into the bottom of the accessory ring:

And then mounted all boxes on the side with velcro tape:
 

The metal is a little too flimsy and bends slightly. Either I have to buy thicker sheets or alternatively I could try to 3D print a perfectly fitting piece. But for now, all boxes are now on the scope - and they are on the axis, i.e. don't contribute too much to the momentum of the scope.

When I used the scope, I noticed that I couldn't pull out the focuser enough - the cables were too tights. Of course, with this focuser I have to leave some slack in the cables:

I never had that issue with the Schmidt-Cassegrain scope ...

Friday, November 15, 2013

New Scope #1

I finally decided to get a new scope. There are too many issues with the Celestron EDGE to make it a fully-automated imaging platform with minimum maintenance. After a very long search, I finally decided to get a 130NFB Takahashi refractor. Together with a FLI 11002-2 MLI camera, larger filters, filter wheel, OAG and other necessary equipment (new mounting plate, clamshell, red dot finder, Robofocus bracket...) A BIG thanks to Chris Hendren from Opt Telescopes. He and I exchanged countless emails to figure out which scope and equipment I need. He never got tired of helping me to understand different scopes and equipment and how I could integrate them.

While I was on a business trip, I found this scope (with a Scope Guard case, clamshell and an accessory ring) on Astromart. I bought it and on my return the shipped scope was waiting for me. I also bought all the other equipment from Opt Telescopes (plus the Robofocus bracket from Technical Innovations and Flip Flat panels from Optec) - unfortunately it will take a little while until all of it arrives.

When I came home, the new scope was waiting for me. So, well packaged! I took it out and the first thing I noticed was how big and heavy this beauty is. From the pictures, you don't really get this. And also how BIG a 4" focuser is!
(see my feet on the left hand side, to get an idea of the size!)

First thing I did was to install the Robofocus bracket, so that I can use my Robofocus unit with the Rack&Pinion focuser. Took me a little while to figure out how.
1. Had to remove one of the focus knobs
and then install the bracket on the focuser with the Robofocus motor on top.

The bigest problem was how to remove the wheel from my Celestron focuser that was on the motor shaft:

I emailed Jeremy from Technical Innovations Robofocus and he offered to remove it for me. So, I sent it off...

But I could put the red dot finder on the scope. I mounted it to the focuser:

Although I might want to move it to the accessory ring too - it's made out of metal, i.e. not super light weight. And the less weight I have at the end of the scope the better. But for now I can use it.

Sunday, October 13, 2013

Collimation and imaging train tilt

After the CalStar desaster, I decided to try to improve focus, collimation and imaging tilt.

First, I wanted to improve collimation. In order to remove as many sources of errors as possible, I started just with eyepieces.

1. Visual
First using the 40mm eyepiece and then the 4mm, I collimated to scope as good as possible out of focus. Seeing wasn't great - when I tried to use in-focus collimation, I could hardly see any Airy disk.

2. Camera directly on scope
I removed the focal reducer, spacers, filter wheel, OAG. I couldn't get the scope to focus anymore, but that was OK. I used CCDInspector's out-of-focus collimation. I used Î¶ Cygni - it was very high up and has no other bright stars around it. Used 30 sec exposures to minimize atmospheric and other distortions. And always waited at least 3 images with similar errors.
I started with a 16" collimation error! I turned the camera around to make sure that the error that I'm seeing is purely the scope and not the camera. Moved it slowly down to 4". Then it changed direction. And then it got funny: for the other 2 collimation screws, the star moved away from the screw when I tightened it. But for the third, it moved towards the screw when I tightened it. That certainly explains the difficulties that I had to improve collimation earlier. After I figured this out, I could bring collimation below 1" (then it changed direction from picture to picture).
Also, at this point the image had no tilt at all!

Now I could have slowly added equipment to it.

... but instead, I'd rather focus on Hyperstar imaging. I know now that the camera is completely orthogonal, so I can use it for collimation of the Hyperstar lens. So, reconfigure the entire scope (cables, secondary mirror, hyperstar lens).

Collimating the Hyperstar lens turns out to be a major pain in the ...
I have to use multi-star collimation - because of the wide field of the Hyperstar lens, I couldn't find a brigh enough start that didn't have other stars in its vicinity. Furthermore, to defocus a start enough for out-of focus collimation with CCDInspector is outside of the range of my focuser!
Because of stray light and the moon light, I have to use a shield on the scope to get correct collimation. But that means that I have to take the damn shield off whenever I need to adjust the Hyperstar lens, then put it back on.
This is the initial state:
Tilt and quite a large collimation error.

This is the final result:

Almost no collimation: good!
Almost no image tile: good!
But look at that curvature!!! I have absolutely no idea what to do about that...

Sunday, October 6, 2013

CalStar - 3rd night

After last night, I had high hopes to make good progress on imaging. First to finish imaging the Fireworks Galaxy. And then start imaging the Trifid of the North.

Setup went well. Starting taking the remaining images of the Fireworks Galaxy. Then I woke up in time to check if SGPro started imaging the Trifid. Looked good. Went to bed.

Next morning, I checked the images. Fireworks looked good. Luminance of Trifid looked good:


But the RGB all looked like this:


I guess, the battery that powered the imaging equipment and the laptop wasn't fully charged and the camera or the USB hub dropped pixels.

After something major went bad every night, I decided to call it quits and not stay for a fourth night. Also, I was really yearning for a warm bed!






Saturday, October 5, 2013

CalStar - 2nd night

I spent the day trying to figure out what is wrong with my scope:

  • I checked the flatness of the image - minimum tilt
  • Cleaned the OAG prism
  • Cleaned the corrector plate (very careful - there was a lot of sand and dust on it)
  • Took exact latitude and longitude from the GPS system
  • Checked all mechanical connections on the mount
Then at the beginning of the night, I continued to focus on improving the guiding (if I can't figure it out, I could go home).

I used AlignMaster for polar alignment again. I did 3 iterations and in the last iteration, the correction was minimal. Verified collumation - good (below 1").

Mark Scrivener and John Wainwright gave me a couple of good tips:
  1. Use the ASCOM driver for guiding - not through the RJ45 cable
  2. Disable guiding commands in PHD and just see where the guidestar moves
  3. Guide (or test) with the main camera - not the Lodestar. This rules out any issues with the OAG or such.
I calibrated PHD near the equator and ran it without guiding. It showed an almost perfect polar alignment - even after 10 minutes, the trendline looked completely horizontal. And the RA trendline went up very straight and smooth. So, the scope is fine, polar alignment is great. Repeated the same with the lodestar - same result. So, the OAG is fine too.

When I was almost ready to declare defeat, one of my neighbours came over to me and asked what was wrong. I walked him through everything. He then wanted to look at my PHD parameters. And he pointed out that my "Max Duration" was too low (I had it at 200). He recommended to set it to 800...
... and voila! Suddenly guiding errors dropped below 0.2 arsec!!! AAAAAHHHHHHH!

I then started guiding again. Watched it for a little - looked really good.

I woke up at 1am to check if SGPro started imaging the 2nd target - worked!!!

And then in the morning, I found out that at 2am guiding completely stopped!!!!!! NOOOOOOOOOO!!!

But the images from the first target were now MUCH better:
This is much better. Although for a 1x1 binned luminance subframe it's still a little blurry.

Friday, October 4, 2013

CalStar - 1st Night

I arrived at 4pm, setup my tent and my scope - all without a hitch. Yes - all ready to get going once it turned dark.

When I connected the Mach1 scope, I couldn't remember which location number was CalStar - it would be awesome if I could assign names... Next surprise: the Mach1 mount can't run off the same battery as the rest of my equipment! The motors sounded horrible and slews stopped half way there. So, I needed to use one battery for the mount. And the other battery for the rest of the equipment. Had to improvise to connect the second splitter to the second battery. And I hope I can recharge both batteries enough tomorrow.

Next, I did a rough polar alignment with the RAPAS, star sync and then wanted to do a more accurate polar alignment with PEMPro. But it complained that my camera was rotated in a bad way and that it couldn't do it. No idea where that came from.

So, I used AlignMaster instead. Not sure how exact this was as I needed exact longitude and latitude of the place.

Next, I wanted to work on collimation with CCDInspector. I could improve it, but at some point the results didn't make sense again. I think I got it somewhere below 1" - good!

And finally PHD...
... complete desaster! I have no idea what was going on with that. I could barely get the accuracy below 0.6" and very erratic. In San Jose in my backyard, I could get it below 0.4". At some point - it was almost midnight by now- I got too tired and too irritated to continue trying things out. I setup the scope to start imaging anyway. Maybe guiding would improve later that night.

I got up in the middle of the night when SGPro had to slew to the next object. And PHD could not resume - didn't find a guide start. I checked everything. Finally I took new darks for the autoguider (this time from a REALLY dark side) - and that fixed it! Guiding by now was a little better - but not by a lot.

Next morning, I checked the images - they were all very bad.
This is a 1x1 binned luminance subframe :-(

Clearly the guiding is not suitable. Need to figure out what to do about PHD. I compared my guiding graphs from last night to guiding graphs at home - they don't look that much worse. But much more erratic.

Now I had to use my solar panels for the first time. Needed to cut some cables and make some connectors and got one battery to recharge. I hope that the other (the one that powered the mount) doesn't need recharging.

Oh, and: IT WAS REALLY COLD! I do remember that I was camping once in England when it froze and snowed. But last night felt worse. I guess after 20+ years I need a new sleeping bag :-S

Saturday, September 14, 2013

New Focuser

Somehow the Robofocus controllbox broke - can't use it manually anymore, can't use it remotely anymore...

I was pretty annoyed by Robofocus (too many cables, fragile cables, the bulky motor construction in the back of my scope, backlash) anyway. So, I used this as an opportunity to switch to a MicroTouch controlled Feather Touch focuser. The other advantage of this is that I have a great manual focuser if the motor or motor control fails.

I ordered it from Starizona and it arrived some 10 days later (if you order Starizona, don't try to use their order status to understand the status of your order - it doesn't get updated!)

Installation was a breeze. First I installed the Feather Touch focuser, then I removed the turning nobs and installed the MicroTouch focuser on top. Took me a little over an hour! And now I have just a little knob back there and not the whole Robofocuser arm!
The red circle shows the focuser + motor. Compare this to the clunky Robofocus arm in this post.


Next, I wanted to install the MicroTouch control software and ASCOM driver. Installing the MicroTouch control software was easy. But I could not use the ASCOM driver - I always got this error message when I tried to select the MicroTouch focuser in the ASCOM chooser:
"Incompatible Driver (microtouch.focuser)
This driver is not registered for COM (can't find ProgID), please reinstall."

I tried various combinations:

  • Installing the MicroTouch control program first or later
  • Installing the driver as admin or not
  • Disabling User Account Control
Nothing. Mailed Dean from Starizona and received the following instructions:

Make sure you run the installation MicroTouchUSB2 setup by right clicking and running as admin.  Then run the MicroTouch the application not the setup itself by right clicking and run as admin (required first time only).


Did that - and now I could use it from SGPro!!! Yei!
But not from TheSkyX :-( I could select not the MicroTouch focuser in the ASCOM control box, but couldn't click "OK" (it was disabled). When I selected "Settings" - I always got an exception.

Searched the TheSkyX forum and found this post: http://www.bisque.com/sc/forums/p/18147/76294.aspx#76294. I downloaded the zip file mentioned which contained a native driver for the MicroTouch focuser.

After I installed it, I had a "Starizona" entry in the focuer chooser dialog. But when I selected it, I received another error message.

... strangely enough, when I went back to the Ascom focuser and chose MicroTouch focuser in it's chooser, it worked (the only strange thing was that I got a popup asking me if I have a USB or USB2 controller - and that popup box opened BEHIND TheSkyX). Well, I take it!!!

Next, I played with the automatic focusing routing in SGPro. I got really weird results: my graph always looked very flat with some ups and downs. Took me a while to realize that the step size is set by default to 1, i.e. there is VERY little focuser movement compared to the Robofocus (where I had set the step size to 8!). The MicroTouch focuser has 60000 steps. I.e. with a step size of 1, I won't be able to move the focus all the way in and out - but I pretty much never need that anyway. So, I cold keep this step size and allow for very small adjustments (could be handy when I image with the hyperstar lens which has a very small critical focus zone) or I could set it to a higher value and allow for wider range.

And then I wanted to train the temperature compensation. From the manual, it looked VERY easy: focus, start training, wait until the temperature drops, focus again, stop training. Now I have a compensation ratio that the MicroTouch controller would apply automatically when the temperature changes.
... but the temperature did not change during training! Well, it went a little bit up and down, but it did not change significantly. And I started the training at 9pm and waited until midnight - and it was definitively cooler then. 

Friday, August 30, 2013

First narrowband image

I tried to capture the veil nebula from our backyard, but the noise level was just very bad. So, I tried to take the same images with my Ha, SII and OIII narrowband filters. There are various formulas out there how to combine these, e.g:

R: 0.8*Ha + 0.2*SII
G: OIII
B: 0.85*OIII + 0.15*Ha

another formula that I found:

R: 0.4*Ha + 0.6*SII
G: 0.4*OIII + 0.3*Ha + 0.3*SII
B: OIII

Guess, I'll have to play with these.

I wonder if I should create the 3 color channels in CCDStack with the respective weights and combine them there. Or if I should just stack the individual images and then combine them in Photoshop. I'll try CCDStack first. An email to the CCDStack support mailing list pointed me to File Math or Combine with Pixel Math or Weights.

First, I calibrated all frames. Because I took them over several nights, I used a different strategy:

  1. Calibrate all images per night and store the calibrated frames
  2. Rotate (if necessary), align, correct and stack all subframes
  3. Align all 3 resulting frames and store the aligned frames
  4. Now, I can load Individual aligned frames into CCDStack to combine them. E.g. for the first hubble palette, I load the aligned Ha frame and the aligned SII frame. 
  5. With pixel math, I multiply the Ha frame by 0.8 and the SII frame by 0.2
  6. Combine-Sum the resulting frames for my red image
  7. Repeat for the other colors
  8. Finally combine the 3 frames to a color image.
Here are the resulting images:


I also tried to just use the individual images for individual colors: OIII=Red, Ha=Green, SII=Blue:

I like the last one the best, it shows lots of fine details in the nebula.

I processed the other image in the same way:

So far so good...

Now, I have to do some more processing:
  • there is still a lot of background noise
  • need to calibrate both images to make them blend better together
  • and then I need to stitch them together

Sunday, August 25, 2013

Another imaging automation program: Sequence Generator

By chance I read about Sequence Generator Pro. It's another imaging automation program - for WAY less then the programs that I looked into before. One of the most interesting features for me is that it integrates with PHD guiding. I was always struggling with TSX guiding. The other interesting "feature" is its price: $99!

I downloaded SGPro, installed it, read the helpfile and watched some of the tutorials. It has a very different concept then CCDAP:
  • It's based on profiles which describe the system setup (scope, camera, guiding, plate solver, filter wheel...) This is actually very good for as I will image with at least 2 configurations (hyperstar and focal reducer).
  • It doesn't integrate with TheSkyX which means that object selection isn't through a planetary software, but the "Frame and Mosaic Wizard" is actually really good.
It's definitively somewhat rough around the edges - many things have to be manually configured or installed. It took me a week to configure and setup everything:

  • The frame wizard relies on an external service (which was down for a day). But the good news is that it caches all downloaded data and images, so I can use those later again.
  • Automatic focussing: it's a very straightforward process. It took me a while to find the right step size though. I ended up running the focus routine with a step size of 2 and checked how many points were in the critical focus zone (the plateau of the curve).
    I then had to play with each filter to figure out which exposure time to use. I increased the exposure time step-by-step until the focus curve was smooth.
    I had to set "stop guiding during focus routine" - because I'm using an OAG, autoguiding is naturally severely affected if I change the focus too much. The last remaining issue is, that SGPro instructs PHD to select a guide star before the focus routine, then it stops guiding, runs the focus routine and restarts guiding with the previously selected guide star. But now, the guide star isn't in the same location anymore and PHD has to do some crazy guiding to get it back into center. I asked on the mailing list. Jared (one of the developers - they are both crazy active on the mainsequencesoftware mailing list) didn't have an idea how to accommodate for this, but will think about it.
  • I used this as an opportunity to start using PHD2 - which works very well. To avoid guiding on hot pixels, I have to use darks. A great advantage of PHD2 over the previous version is that it can re-use darks for subframes and doesn't try to take a new one. I had to set the threshold after which SGPro starts taking images to 0.5 - that's already pretty low for my backyard conditions.
  • SGPro uses plate solving for every slew - which is great. Makes it very reliable. Initially, I tried to use Elbrus, but it didn't always work. I then switched to astrometry.net which works great. But now I am relying on an external service - which is bad when I take the scope out. Fortunately, there is a local astrometry.net setup that I can use.
  • It was strange that I had to set the "auto meridian flip" bit - I had expected that it is set by default.
  • SGPro reads the configured ASCOM devices and offers these directly. That avoids the popup when connecting where you have to choose the ASCOM device. Nice!
  • Naming of the images is great!
  • I tried mosaics, meridian flips during imaging, multiple targets - all works very well.
  • The built-in Image Grader is great for a quick analysis of acquired images.
The only missing thing (for me) are dusk/dawn flats. It was very convenient with CCDAP to just setup the scope, rough align it and then start the CCDAP flat routine. It would wait until it's dark/bright enough and run through all the filters, dither and adjust exposure times. I wish SGPro would implement this as well.

Friday, August 23, 2013

CalStar 2013

After I had such a great experience at GSSP, I want to attend CalStar 2013 (Oct 3 - 6).

I want to image with the f6.3 setup, but also with the hyperstar lens (f2). I will have 9.5 hours of imaging time (20:10 - 5:40. For images with the focal reducer I'll need 6.5 hours (10x10min Lum + 10x7.5min RGB), for the hyperstar lens, I'll need 1.5h (10x3min Lum + 10x2min RGB). So, in two nights I can capture 3 images with the focal reducer and in the other 2 nights, I can capture 9 images with the hyperstar lens (each night 2 different filters - taking flats for one filter in the evening and the other filter in the morning). I will definitively need to get my automation nailed for this - otherwise, I'll stand at my scope the entire night...

Some Objects:

f6.3:
f2: (rotate to 114 degrees)
  • Gamma Cygni Nebula - one image - (too low at end of the night) (transit: 20:29)
  • IC1340 (Veil Nebula) - mosaic of 6 too low at the end of the night? (transit: 20:50)
  • M31 (Andromeda) - mosaic of 4 images (or three if I rotate the camera) - take multiple exposures and HDR (transit: 0:47)
  • IC11 (Pacman Nebula) - one image - (transit: 1:01) 
  • IC63/IC59 - one image - (transit 1:07)
  • M33 (Triangulum Galaxy) - one image (1:42)
  • IC 1795 - mosaic of 4 (transit; 2:34)
  • M45 Pleiades - one image - (need to start late as they are low in the evening) (transit: 3:53)
  • NGC 1499 - mosaic of 6 (3 with rotated camera)- (transit: 4:11)
This would mean 25 images - need to get it down to 9 images: M31(3), IC11(1), IC63/IC59(1), M33(1), NGC 1499 (3)

---

I did not find the time to work thoroughly with the Hyperstar lens (focusing, guiding, exposure times, flats...) So, I'll just take some images with the f6.3 setup. Maybe some other time.

Tuesday, August 20, 2013

Weird optical artifact - caused by OAG

Yesterday, when I took flats, I noticed a weird artifact:

I've spent the last couple of weeks mostly with the new mount and didn't take any flats, so I don't know what change this caused. My first thought was that maybe the filter wheel isn't lined up correctly. But I checked it, and nothing was wrong. So, I checked all elements of my optical train starting from the back:

1. Vent
I recently installed the cooling enhancer from Starlight Xpress to make sure that I can cool the CCD camera down to -10 Celsius - even when it's very warm outside. I turned it off and took another flat:
Clearly that wasn't it.

2. CCD Camera
Next, I rotated the CCD camera by 90 degrees to check if it's the cause of this:
If it were the CCD camera, the artifact would have stayed in the same corner. So, next:

3. Filter wheel + OAG
I turned the CCD camera back and turnd the filter wheel + OAG:
Aha! It's the filter wheel or the OAG!

4. OAG
Just because it's easier, I pull out the OAG:
Gone! So, it is the OAG. Maybe I can push it back in:
half in:
Good! 3/4 in:
Yei! And once more, all the way in:
OK, I know how to fix this. But where did this suddenly come from???

Monday, August 19, 2013

Non-parfocal filters and OAG

I wanted to start using the Astronomik OIII and SII filter. And then I realized that I can't use them with my off-axis guider. Stupid me - never thought or realized that!

... guess, I should try to sell the Astronomik filters and get Baader filters instead.

Tuesday, August 6, 2013

No more reflections

I tried out the brand new Celestron focal reducer. And behold: no more reflections!!! Of course, I can't be sure anymore if I don't have any tilt anymore. But because the Celestron t-adapter get screwed in, it's way less likely.

Now, I have to try to sell the Lepus reducer ...

Sunday, July 28, 2013

Mach1 GTO from Astro-Physics - Guiding

I spend some time on the PHD parameters to improve guiding. With the default values of PHD, I can get my combined RMS error easily below 1 arcsec. Doesn't sound like much, but with the CGEM that was already a struggle. Good.

After some more optimization, I ended up with graphs like this one:
RMS error: 0.56 arcsec (peak 1.39)

RA RMS error: 0.12 arcsec (peak 0.3) 
DEC RMS error: 0.16 arcsec (peak 1.06)

And very often I got graphs like this one:

Something is clearly wrong with DEC guiding...

I asked on the ap-gto mailing list and received a number of good suggestions:
  • Calibration isn't correct which leads to an overcorrection in DEC
  • Lower aggressiveness, so that PHD does not overcorrect
  • Make sure that the guide stars are not distorted
  • Make sure that the OAG is pushed in as the stars in the outer areas might be too dim
  • One user has the exact same setup that I have - except that he does not use a focal reducer. He sent me his settings:
    RA Aggressiveness: 60
    RA Hysteresis: 10
    Max Dec Duration: 75
    Min Motion: 0.70
    Calibration Steps: 125msec
    Auto/Resist Switching
    Extreme dithering and Settled at < 0.5
    3 - 4 sec guiding exposure.
    I could remove my focal reducer and try these out.
Last night I tried these out:
  • Lowered my calibration step size - now PHD needs 20+ steps for a calibration run
  • Played with aggressiveness
  • Checked if the OAG is still parfocal, pushed the OAG all in
But with the same results. I then updated PHD to the latest version and even installed PHD2 (alpha) to check if this is some PHD bug. But same result.

I then tried out some things:

First, I took an 5 min image of the Eagle Nebula unguided. Here is a magnified version:
The stars are elongated mostly in RA direction.

The same image with PHD guiding - DEC set to auto:
Now the stars are mostly elongated in DEC direction - RA seems to be fixed.

Now with PHD guiding - DEC guiding off:
Very round stars.

The with DEC only North:
Also, very round stars.

So, RA guiding really seems to be good, but the DEC=auto guiding is a problem. Now, in PHD2, there are more possibilities for DEC guiding (identity, resist switch, lowpass, lowpass2, hysteresis). I played with those, but couldn't improve DEC guiding. And then I read in the release notes, that in the current version of PHD2, calibration only works with DEC=auto. So, I had to run all these experiments again. But it got very late again and I went to bed...

I wanted to make sure that my scope is not out of balance. The Mach1 is quite sticky, so balancing isn't easy. So, I removed my OTA from the scope and balanced it on a pencil. I noted that point on the OTA and made sure that this point is in the middle of the dovetail saddle.

Next, I removed the focal reducer, so that I could try out the parameters (above) that I received. Here is the result:

Another idea that came from the ap-gto mailing list was that the DEC gears might be meshed too tightly. This pointed me to checking my cables that are now routed through the mount - maybe they are getting stuck somewhere. I just moved them out of the mount and tried again:

Hmmm, still no luck. Well, the good news is that I can move the cables back inside, but I should take a closer look on the DEC gear...

I followed the instructions on how to remesh the gears. Tried again ... same result :-(

Now, I'm sending an email to tech support at astro physics...

Thursday, July 25, 2013

Mach1 GTO from Astro-Physics - Cabling

One of the main reasons why I bought the Mach1 mount is the ability to move all the cabling inside the mount. And have no dangling cables on the side or such. In total, I need 8(!) cables to run through the mount:
  • 3 USB (filter wheel, ccd, guider)
  • 1 power (ccd)
  • 1 serial (Robofocus)
  • 1 Autoguider (guider)
  • 2 dew shield (main scope, guidescope)
That's a lot of cables - especially considering that they will run through both axis, i.e. partially block the polar alignment scope.

First, I ordered 2 tray holders to put the 4 boxes on: Robofocus, USB hub, Dew Shield Controller, Power distributor. After a little bit of fiddling around, I found a page from astro physics that shows the different possibilities to mount the holder to the pier.

I ended up mounting the dew controller and Robofocus controller on the pier and the power distributor and USB hub on the leg next to it. Routing the cable through the mount wasn't too hard. It's just awesome having them completely out of the way! But they are now in the way of the polar alignment scope! Hmmmm, couldn't really figure out how to avoid that and asked at the ap-gto mailing list. Two good ideas:
  1. Fit a PVC tube around the polar alignment scope to go all the way through the mount
  2. Press the cables to the outside with a sheet of plastic that I roll and then put inside the housing.
First, I needed to find flat USB cables:
  • 1 Mini USB cable - 6 ft
  • 2 A/B USB cable - 5 ft
  • 1 Anderson power cable - 5 ft
And I found them on eBay (A/B, Mini). With some tape, I made sure that all cables are flat next to each other:

Then I took some plastic sheet, rolled it up and moved it inside the polar scope housing:

You can see the cables in the upper left side of the housing.

And with that, I can easily insert the RAPAS and have a completely unobstructed view! Awesome!

Friday, July 19, 2013

Mach1 GTO from Astro-Physics - Night 2

I wanted to focus on polar alignment and setting up my polar alignment scope. I got some good advice on how to use it on the ap-gto mailing list.

So, I started with the Polar Alignment from PEMPro. I could never get it to work with my CGEM scope. But with the Mach1 it wasn't a problem at all. I spent 1.5 hours trying to get polar alignment as accurate as possible. With our seeing conditions (starts flickered a lot) I could not get it below 0.1 arc mins.

Here is a 10 min unguided test shot:

There are some traces, but not a lot. Seems as if the polar alignment went very well.

Then I aligned the polar alignment scope such that Polaris was in the place that was indicated in the AP app. That will allow me to get very good polar alignment in the future just with the polar alignment scope.

And finally, I pointed to scope somewhere (Deneb) and started guiding to see if there is a difference.

Here is the best guiding graph from the best night at GSSP (i.e. near perfect seeing conditions):
RMS Error: 0.69 arcsec
Peak Error: 2.26 arcsec

And here is the guiding graph from tonight - without doing any any adjustments to the PHD parameters:
RMS Error: 0.40 arcsec
Peak Error: 1.15 arcsec

I can't wait what guiding I will get after I spend some time working on those PHD parameters!

Tuesday, July 16, 2013

Mach1 GTO from Astro-Physics - Night 1

And of course, tonight it's NOT clear. Clouds moved in!!! But at least there were enough holes in the sky until 11pm to try some things out:
  • Get outside, rough polar alignment (turn mount on top of eagle pier such that it points to north when I align the eagile legs with our pavement - that will make setup faster!)
    Worked really well.
  • Polar alignment through polar scope
    Worked not so well :-( I have to move the scope all the way to the grass - otherwise Polaris is just below the roof of our house.
  • Polar alignment with 2 star alignment
    Not so successful. I tried to follow the instructions, but couldn't get polar alignment really close. This will probably require more practice.
  • Sync
    Easy
  • Try some slews
    Not so good - I guess I need to do a better job with polar alignment.
  • Check orthogonality (cone error)
    Couldn't do without a good polar alignment.
  • Use with TheSkyX
    Worked really well.
The mount was pretty loud indeed, but also very fast to slew. And no wobbling or such. I can't wait to use it for real!

New mount: Mach1 GTO from Astro-Physics

After I tried everything this year to make my CGEM work, I finally broke down and bought a new mount. I did some research and it seems as if the Mach1 GTO from Astro-Physics is one of the best portable mounts. I could not get it in the US anymore, but luckily Baader Planetarium in German still had one. It was in their showroom and they gave me 10% off!
Took a few days to get the money transferred (first from our US account to my German account, then from there to Baader). And then it took 2 weeks to ship the mount here (1 week for US customs).
But today, it finally arrived.

I unpacked everything. I read so much about the quality and the finish of Astro-Physics products that I expected only awesomeness. And I wasn't disappointed. The mount itself, the control box, the counterweight bar... everything felt robust and very high quality. The assembly was great - the pieces are all so well made and exact. A few times, I used the wrong size screw or such. And each time, I noticed it immediately: if it doesn't easily and smoothly fits, it's probably the wrong piece. Finally, I had the mount assembled on the Eagle Pier. I attached the impressive control box to the pier. And then connected the cables. For now, I'll route all the cables on the outside. But I really want to move them inside the mount (and with that move all the control boxes from the OTA to the pier). I also installed the polar scope.

Finally, I connected the scope to my laptop. Downloaded and configured the ASCOM driver from the Astro-Physics site. I tried both, the native and the ASCOM driver in TheSkyX - they both seem to work. Asked on the ap-gto mailing list which one to use.

... and then it was WAY past midnight and it got foggy. Time to go to bed.

Things to try out tomorrow night:
  • Get outside, rough polar alignment (turn mount on top of eagle pier such that it points to north when I align the eagile legs with our pavement - that will make setup faster!)
  • Polar alignment through polar scope
  • Polar alignment with Polaris alignment
  • Sync
  • Try some slews
  • Check orthogonality (cone error)
  • Use with TheSkyX

Sunday, July 14, 2013

More CCDAP evaluation: taking images

Back from GSSP, I want to evaluate CCDAutoPilot more. It was VERY handy at GSSP to take dusk flats. Although the problem that it automatically kicks in and starts taking dusk flats is still not fixed, it's still a very comfortable way to take flats.

I now wanted to try taking images. My first challenge was to set a target. There isn't an "add target" or such button on the main screen :-( After reading the manual, I found out that I can select (and center!) a target in TheSkyX and then with the "Get" button get it into CCDAP. That sort of works. It's just weird, that I have to center it (so that it is in the FOV). And then CCDAP labels the object FOVCenter - even in the image name.

Then setting all the parameters (binning, focus...) was very easy. I then started taking images:
  • The precision slew was working - but I think it shows the inaccuracy of the CGEM mount. Here is a sample log output:
    03:46:41 Precision slew try number 1
    03:46:41 Plate solving...
    03:46:41 Telescope RA: 22 37 45.3, Dec: +34 28 46
    03:47:29 C:\Users\Mark\Documents\CCDWare\CCDAutoPilot5\Images\SyncImages\Sync_20130714_034641.fit
    03:47:30 Stars: 86, FWHM: 2.7 arc-sec.
    03:47:30 Solved RA: 22 36 57.3, Dec: +34 26 48, PA: 172.0
    03:47:35 Sync'd to RA: 22 37 36.6, Dec: +34 31 03
    03:47:36 Telescope RA: 22 37 36.7, Dec: +34 31 03
    03:47:36 Telescope reports RA: 22 37 36.7, Dec: +34 31 03
    03:47:36 Plate Solve Time: 54.5 sec.
    03:47:36 Pointing error (arcmin): RA 2.0; Dec -1.6
    03:47:36 Telescope connected
    03:47:36 Slewing scope...
    03:47:44 Slewed to RA: 22 37 44.4, Dec: +34 29 28, Jnow
    03:47:44 Mount settling for 3 sec. after slew.
    03:47:49 Telescope tracking on
    03:47:49 Sync'd
    03:47:49 Plate solving...
    03:47:50 Telescope RA: 22 37 45.4, Dec: +34 28 46
    03:48:00 C:\Users\Mark\Documents\CCDWare\CCDAutoPilot5\Images\SyncImages\Sync_20130714_034750.fit
    03:48:01 Stars: 76, FWHM: 3.1 arc-sec.
    03:48:01 Solved RA: 22 37 05.5, Dec: +34 24 25, PA: 172.0
    03:48:07 Sync'd to RA: 22 37 44.8, Dec: +34 28 41
    03:48:07 Telescope RA: 22 37 44.9, Dec: +34 28 40
    03:48:07 Telescope reports RA: 22 37 44.9, Dec: +34 28 40
    03:48:07 Plate Solve Time: 17.2 sec.
    03:48:07 Pointing error (arcmin): RA -0.1; Dec 0.8
    03:48:07 Try 1 slew error: 48.1 arc-sec
    03:48:07 Precision slew try number 2
    03:48:08 Telescope connected
    03:48:08 Slewing scope...
    03:48:16 Slewed to RA: 22 37 44.4, Dec: +34 29 28, Jnow
    03:48:16 Mount settling for 3 sec. after slew.
    03:48:22 Telescope tracking on
    03:48:22 Sync'd
    03:48:22 Plate solving...
    03:48:22 Telescope RA: 22 37 45.4, Dec: +34 29 22
    03:48:33 C:\Users\Mark\Documents\CCDWare\CCDAutoPilot5\Images\SyncImages\Sync_20130714_034822.fit
    03:48:34 Stars: 87, FWHM: 2.8 arc-sec.
    03:48:34 Solved RA: 22 37 05.4, Dec: +34 25 09, PA: 172.0
    03:48:39 Sync'd to RA: 22 37 44.7, Dec: +34 29 24
    03:48:40 Telescope RA: 22 37 44.8, Dec: +34 29 24
    03:48:40 Telescope reports RA: 22 37 44.8, Dec: +34 29 24
    03:48:40 Plate Solve Time: 18.1 sec.
    03:48:40 Pointing error (arcmin): RA -0.1; Dec 0.1
    03:48:40 Try 2 slew error: 5.8 arc-sec
    It took 3 attempts and 2 minutes to get the error down to 5.8 arc-secs. But at least it worked.
  • Focusing with every new filter didn't work at all. The focus degraded from sequence to sequence. When I analyzed the @Focus2 log files, these are the first focusing graphs that I got:



    The first two are completely useless. The third one makes sense and leads to a correct focus. So, I'll have to work on my @focus2 routine to make it more robust.
    I should try to use the recommended focus range of 4500 to catch the outer, lower areas of the graph. Will do that tonight.
    I worked on the @Focus2 parameters and could create a rock-solid process. It converged and worked all the time. I think the problem is that when @Focus2 is invoked from CCDAP, it does not slew to an appropriate star, but tries to focus where the scope is pointed to. Will need to investigate further.
  • A weird bug(?) I found was that I can't enable tracking through TheSkyX (in the Telescope->Tools menu). Which is annoying, because CCDAP likes to put the scope into parking and then disable tracking...
  • And of course, I have to figure out guiding with CCDAP.
  • The good thing was the automatic meridian flip that CCDAP does.
But if I figure all this out, this will make taking images way easier. So, tonight, I'll work on the @focus2 routine and then try this out again.