The Elephant's Trunk (VDB 142)

I used the opportunity of being under really clear and dark skies to take LRGB images. Here is the Elephant's Trunk (VDV 142):

The Elephant's Trunk is about 2400 light years away from earth - it is part of a much larger nebular region (IC 1396):

(click on the image for full resolution)

The entire IC 1396 region is ionized by the bright, massive star (HD 206267) which is slightly left of the center of the image. The Elephant's Trunk itself is the birth place of stars. There are several relatively young (100,000 years) stars in it. The ionizing effect of HD 206267 and the wind from the young stars lead to high pressure which forms new protostars.

This image was the first light of my new FLI ML 16070 camera. It's an overall integration time of 6.8 hours.

Milky Way - from Cassiopeia to Ophiuchus

I took this wide-angle shot of the milky way with my Nikon D7000 and the Vixen Polarie tracker. It spans almost 90 degrees - from Cassiopeia (left) to Ophiuchus (right). You can see the Summer Triangle with Vega (middle of the image above the Milky Way), Altair (in the right of the image below the Milky Way) and Deneb (in the left of the image inside the Milky Way).

I had to crop this image as the lens (Tokina f11-16) shows severe coma in the corners. The image consists of 11 x 5 min exposures.

Imaging Trip to Orange Spring Ranch

Originally, I wanted to attend the Oregon State Star Party. But then, my friend Richard invited me to spend a couple of nights at his ranch and image from there. To make it short: we had amazing skies! Great imaging! Unfortunately I was once again fighting with my guiding. Still, took some great images.

Sharpless objects in TheSkyX

I'm writing this mostly for me to remember:

TheSkyX has a catalog of all sharpless objects - and many other catalogs. But for some reasons, you can't find them just by typing 'sh2-101' into the search box. You have to type 'SAC sh2-101'. You can also show them in the map - go to Input -> Database Manager -> Optional Databases and select the catalog that you want to show.

Atlas focuser woes

Seems like my software stack isn't working too well with the Atlas focuser:

1. Connecting
When I try to connect the Focuser (from SGPro, TheSkyX and even the POTH hub from the ASCOM driver) I get a "Can't connect to Focuser" error message. I tried to analyze this with POTH (to see which commands are sent). Upon a successful connection, I see:

Focuser Link: False -> True (connected)

Focuser Link: False

Focuser Absolute: True

Focuser Halt  (done)

Focuser TempCompAvailable: False

Focuser Temperature: 29.5625

Focuser Temperature: 29.5625

Focuser Absolute: True

Focuser MaxMaxStep: 0

Focuser Temperature: 29.5625

Focuser Position: 22774

When the connection is unsuccessful, I see:

Focuser Link: False -> True

Focuser Link: False -> False no change

Not much useful information. But after trying various combinations, I noticed that when I just press "Connect" (in either SGPro, TheSkyX or POTH) I get an error message. When I press "Setup" first and then "Connect" all programs connect very reliably. I guess calling the setup program loads the driver or some dll's that are required for the driver to connect and that aren't loaded just by connecting. Or it might be a timeout issue. Contacted FLI support for this.
But at least I have a reliable way to connect.

2. Hanging or ignoring focus move commands
Quite often, the autofocus routine in SGPro would just hang at the initial focuser move. No timeout, no focuser move, nothing. Upon inspection of the log files I could see this exception:

[8/11/2014 10:41:49 PM] [DEBUG] [Camera Thread] ASCOM Focuser: Error in Move(abs) : Exception has been thrown by the target of an invocation. (System.Runtime.InteropServices.COMException (0x80020009): Focuser is currently moving)

   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)

   at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)

   at SequenceGenerator.SafeFocuser.Move(Int32 val)

   at au.Move(Int32 absolutePosition)

Seems as if SGPro thinks that the focuser is still moving from a previous command. Upon further analysis, I found out that this only happens when I use temperature compensation. In this case, SGPro moves the focuser to compensate for a temperature change and then immediately stars the autofocus routine. And the first move of it gets this exception and then hangs.
I also saw the same issue when I try to cancel an autofocus routine. SGPro just moved the focuser to the next position and then tries to move it back to its original position. And the second move gets this exception ... and leaves the focuser WAY out of focus. I sent an email to the SequenceGenerator forum asking for help or if Jared and Ken could fix this.

For temperature compensation I noticed that I can workaround this by setting a short delay between each image. SGPro applies the temperature compensation BEFORE the delay and starts the autofocus routine AFTER the delay.

So, I can at least work around both issues...

Guiding glitches - again

I suddenly saw the same guiding glitches again that I had earlier this year. It results in images like this one:

What happens is that suddenly the scope moves into one direction by several arcseconds and then PHD2 slowly brings back the guide star.

I checked the usual suspects:

1. Cabling
   Checked if cables can get stuck somewhere. I even moved the cables out of the mount to check if they get stuck somewhere on the inside. No change.
2. RAPAS
   I always leave the RAPAS in (pure convenience). It could be that it pulls on the cable inside the mount. Removed it. No change.
3. Gear Meshing
   I wondered if I have too much backlash in my gears. I remeshed the gears. I remeshed them too tight (using a mallet and carefully bumping the gear box while tightening the screws). Guiding was pretty bad after that (it took PHD2 several pulses to get the guide star back - and then it immediately overshot. I also remeshed them too lose (resulting in more backlash) - which of course made guiding also bad. But: no change.
4. Periodic Error
   I normally don't use PEC as PHD2 can guide out the periodic error. But just to be on the safe side, I took another measure. Enabled PEC. No change.
5. Accessories
   I am normally hanging the keypad from the mount - when it's windy, it could bump into the mount. I also wondered if the Alnitak flip-flat box could be responsible for this. Removed both of them. I checked the counterweight bar and the counterweights. I checked the retractable dew shield of the TOA-130 and tightened its screws. No change.
6. Screws
   Checked all the screws an tightened them (scope rings, dovetail, saddle plate, mount...) No change.
7. PHD2 error
   I also checked if maybe PHD2 has an error and drives the guide star out. But as it is clear from this image, PHD2 doesn't make corrections until after the glitch occurs:

Next, I wanted to check if there is something in common between these glitches (happen at the same time, in the same location...) I went through my PHD2 log files and searched where I had these in the past. They are pretty easy to spot. A normal guiding graph looks like this:

You can see the regular dithering events where the guide star wanders out by up to 4.5 arcseconds. And also times when guiding stops and then resumes - either focusing or a meridian flip.

When these glitches happen, it looks like this:

This event is much larger then the 4.5 arcsec dithering event. And it occurs in the middle of imaging.

I created a table with all these glitches from the past months:

	RA	DEC	Date	Time	Altitude	Azimuth	Direction
M101	14:03	54:16	4/22/2014	23:35	66:58:00	35:20:00	RA
M101	14:03	54:16	4/23/2014	23:25	66:15:00	36:40:00	DEC
M101	14:03	54:16	4/27/2014	23:21	67:36:00	33:58:00	DEC
M101	14:03	54:16	4/28/2014	23:39	69:51:00	27:39:00	DEC
M101	14:03	54:16	4/29/2014	23:48	70:57:00	23:04	DEC
Crescent Nebula	20:12	38:23:00	5/1/2014	2:24	40:08:00	67:45:00	RA
Crescent Nebula	20:12	38:23:00	5/2/2014	3:26	73:07:00	52:20:00	RA
Crescent Nebula	20:12	38:23:00	5/5/2014	1:44	50:07:00	72:13:00	RA
Crescent Nebula	20:12	38:23:00	5/8/2014	1:39	36:02:00	65:43:00	RA
Crescent Nebula	20:12	38:23:00	5/10/2014	1:12	33:17:00	64:17:00	RA
Tulip Nebula	299:51:00	35:28:00	8/8/2014	22:40:32	42:14:00	35:13:00	DEC
Tulip Nebula	299:51:00	35:28:00	8/11/2014	2:59:51	64:32:00	356:13:00
Tulip Nebula	299:51:00	35:28:00	8/12/2014	2:29:00	63:50:00	10:57	DEC
Tulip Nebula	299:51:00	35:28:00	8/12/2014	3:07:00	64:37:00	358:43:00	RA
Tulip Nebula	299:51:00	35:28:00	8/13/2014	21:30:00	37:49:00	34:38:00	RA
Tulip Nebula	299:51:00	35:28:00	8/14/2014	2:14:00	64:13:00	7:50	RA

There are a lot of failures at altitude 65-70 degrees. Both in RA and DEC direction.

Also, the above images were taken with various configurations:

• the OAG and the new guidescope
• both cameras: the H694 camera (and SX filter wheel) and the new ML 16070 camera (with the FLI filter wheel)
• with the clamshell holder and the new scope rings
• the Robofocus focuser and the FLI Atlas focuser
• the Flattener and the Reducer

So, it can't really be anything of those.

What's left:

• The Rotator (connection to the imaging train and connection to the stock focuser)
• The Takahashi focuser (though with the FLI focuser I clamped it down)
• The connection of the Takahashi focuser to the optical tube
• Something inside the OTA (lenses or such)
• The mount itself
  The position in which the glitch mostly occurs, is between these two positions:
     =>   

It looks as if the center of gravity shifts here from the left to the right side. I.e. if there is anything loose on the mount it would sift slightly from left to right. That could also explain why I see DEC or RA errors - if it would be the RA (or DEC) axis itself, then the error would be primarily in that axis.

I checked and rechecked all screws and connections (legs, mount plate, mount screws...) but couldn't find anything yet.

Calibrating the Atlas Focuser

I have to recalibrate the new focuser:

1. Autofocus parameters in SGPro
2. Temperature compensation
3. Filter defaults
4. Filter offset

Before I could start, I noticed that it sometimes took several attempts to connect to the focuser. And later, SGPro would sometimes hang when it needed to move the focuser out for the first measurement. I asked on the SGPro mailing list - need to find a way to generate debugging information for the Atlas Focuser. Asked FLI about it.

Next, I wanted to calibrate autofocus in SGPro. But the very small resolution of the Atlas focuser means that even with a step size of 1,000, I have to take more then 20 (better 30) data points to create a good V-curve. Unfortunately, SGPro doesn't allow step sizes greater then 1,000. I asked on the mailing list and the maximum will be raised to 10,000 in the next SGPro release. Yei!

So, for now, I have to use a step size of 1,000 and 31(!) data points to get a good V-curve. Which of course takes quite a while :-(

While I was playing with the step sizes, I also played with binning. And I noticed that there isn't much of an accuracy improvement from binning 1x1 to 2x2. But of course, the exposure times are going down significantly. But when I set binning to 3x3 or even 4x4, the accuracy in the focus region gets very bad. So, binning 2x2 is what I will now be using.

With regards to temperature measurement, the Atlas focuser has 2 measurements: internal and external. The internal one looks much more reasonable (the external one reads very high). So, I'm using that one for now, but also asked FLI what these two temperatures are about.

For the next night, I created an SGPro sequence to do the focus measurements. In the autofocus settings I set "Refocus after each frame", so that SGPro would run the autofocus routine every time. As SGPro writes the temperature and the focuser position into the FIT file, I could run this sequence all night and evaluate it the next morning.

1. Sequence

8 Luminance images

3 Red images

3 Green images

3 Blue images

3 Ha images

3 SII images

3 OIII images
(I set this sequence to end at 3:30, so that I would take another series of Luminance images)

2. Sequence (to be started at 3:30)

8 Luminance images.

All images are 0 second exposure time.

With the Luminance images at the beginning and the end of the night, I can determine the temperature coefficient of my focuser. With the other images, I can determine the focus position differences. With the temperature coefficient I can then calibrate them all to the same temperature.

The next morning I noticed a) it wasn't enough time to capture all filters. The narrowband filters take 30 second exposures. With 31 exposures that's 16 minutes per images!

And b) it also got cloudy at the end of the night and I only had 5 luminance images at the end of the night.

Nevertheless, I think I had enough measurements for the temperature coefficient:

	Evening Measurement			Morning Measurement
	23.5625	25251		19.5	23104
	23.6875	25202		19.75	23159
	23.4375	25010		19.625	22963
	23.375	24886		19.6875	23118
	23.4375	24380		19.63	23265
	23.25	24688
	23.0625	24606
	23	24337
Average	23.35	24795		19.64	23122
	Temperature Difference		3.71
	Focus Position Difference		1673
	Focuser Steps per 1 degree		451

So, 451 steps per 1 degree (which shows the small resolution of the Atlas Focuser - the Robofocus focuser had 15 steps per 1 degree!!!)

Next, the individual filter measurements.

From the Averages (you can see all measurements in this spreadsheet):

	Lum		Red		Green		Blue
	Temperature	Focuser Pos.	Temperature	Focuser Pos.	Temperature	Focuser Pos.	Temperature	Focuser Pos.
Averages	23.3516	24795	22.813	24139	22.6250	23942	22.1875	23349
Diff to Lum Temp			0.5391		0.7266		1.1641
Adjustment				243		327		525
Adjusted Pos				24382		24269		23874
Diff to Lum Pos				413		526		921

So, these are my filter offsets and filter defaults for the RGB filters. Next, I need to take the defaults and offsets for the narrowband filters. But I'll do that after the Oregon Star Party (where I will use the LRGB filters only).

In the next nights, I will still focus before each frame to compare how well the temperature compensation works.

Powering my scope in the field

I recently registered for the Oregon Star Party. One of the restrictions is that we can't use generators - especially at night. So, I have to figure out how to power my scope entirely from batteries. I need two batteries - as the Mach1 mount doesn't like to share power but needs its own battery. Plus the FLI camera requires very stable supply and shouldn't be powered by the 12V batteries who don't deliver straight 12V. I checked on the FLI mailing list and received the advice to use a DC-DC converter. I ordered one of these (plus an enclosure).

I also ordered a second solar panel to make sure that I can recharge both batteries easily (plus I like to have a backup for all of my equipment). Finally, I ordered an MPPT charge controller plus a digital readout.

The plan is to power the mount with my slightly weaker 100Ah battery and with the 120Ah battery the rest. I ordered a pigtail cable from FLI to figure out how to connect the camera to a 12V outlet.

I spent some time to put Anderson Power connectors on all elements.

Wired everything up and powered the entire setup (inclusive laptop) for an entire night. Worked flawlessly! In the morning the batteries were at 50% and 40% charge. I then connected everything to the solar panels:

By 2pm both batteries were at 100% charge!