I am still evaluating CCDAP and have finally got the flats working but there is another problem. For example, last night did a series of images of NGC925. It ran the L frames, seemed to guide reasonably well, did a meridian flip and picked things up on the other side. So it ran, flipped when it was supposed to and shot a few more L frames on the opposite side of the meridian. OK, problem is that every image through the RGB filters is trailed, not slightly elongated but trailed, the images are unusable. In looking at the log file, it seemed to have great trouble guiding or even finding the guide star. This is curious as it shot the L frames fine. The system is a Paramount ME, OGS 12.5" RC, ST10XE/CFW8A, and first series Astrodon filters, also Pyxis 3" rotator. Anyone have any clues as to what may be happening? BTW, it has always seemingly had issues through the color filters continually. I have a lot of nice L frames...

Mike

ccdap20091013_215743.log (97 KB, 14 downloads)

Reviewing your log, I note the luminance filtered guide star location is 202,142. The R filtered guide star is 125,163. It appears you are trying to guide on a hot pixel. Since you are guiding through a filter, the guide star at approx. 202,142 is weaker than the hot pixel. Maxim doesn't allow simple autodark via their automation interface, which would remove this hot pixel but your min. guide star exposure time is probably too short anyhow. Since you are guiding through the filters, some things to try:

1. Increase your minimum guide star exposure to 3 - 5 seconds.
2. Try CCDSoft, which does support simple autodark for the guide star.

John:
I'm seeing something similar after upgrading to the latest release. The guiding is perfect until it suddenly breaks and then gets either consistent "no guide error reported" messages or appears locked onto a fixed value. Of course it's possible the camera suddenly developed a hot pixel but this problem hasn't happened before and the first half of the session (including after meridian flip) worked fine. In the attached log the problem begins just after 2am (sub #605 was the last w/ proper guiding). One thing I noticed was the log entries for the new bad pixel mapping. I do NOT have this enabled so is it normal to see these messages anyway ?

ccdap20091014_171830.log (67 KB, 10 downloads)

This is the same problem I seem to have been having, seems to work well enough and then hacks on guiding, does OK with a meridian flip. At first thought that it was clouds or whatnot but is to consistent. I also seem to get a weird pixel mapping error and as you, do not have that turned on. Frustrating as wasting clear night here in southern Arizona...

When Maxim doesn't report a guide error, it is usually due to a guide star being below the detection threshold. I have run numerous sessions with Maxim and 4.15.9 and have not seen the issue you both are seeing. However, I use an off-axis guider, which of course gives a constant brightness guide star. Since you both are guiding through filters, the guide star does change its peak level. Also, you are slewing to a focus star and returning to the target coordinates. If the return slew is not precise for whatever reason, you may not get the same guide star.

Try checking the option "Use Maxim Guide Star Detection" on the Tracking and Guiding page. Also, I again suggest you try CCDSoft to see if the problem still occurs.

A couple of comments...
1. AFAIK, there is no change to the guiding code between 4.15.7 and 4.15.9.
2. I suggest a short test run that includes filter changes and a meridian flip so you can actually watch the guider window to see if indeed a guide star (and the same guide star) is being properly detected. This should take less than an hour (use short exposures) and will help diagnose what is going on in your setup. This is always a good idea when things don't go as expected and is better than committing a long unattended session before things are fully shaken down.
3. Keep an eye on the guide star coordinates in the log. If you are getting good precision slew plate solves, the guide star coordinates should always be within a few pixels after every return to target. In both your cases, I see a wide variation from when guiding is "good" to when it is "bad".
4. The pixel mapping message is a logging error. The bad pixel map process is not being applied if it is not checked - only the message is being sent to the log. This will be corrected in the next maintenance release.
5. Jim, try Precision Slew with Tolerance of say 30 arc-sec. so that we can see how close the final slew is to the desired target coordinates. If the mount isn't slewing to the desired coordinate after your focus run, you may be picking up a weaker guide star.

I changed the Precision Slew as recommended and repeated essentially the prior run. It failed in almost the exact same way - guiding was fine, it did the meridian flip and worked fine on the completion of that series and then failed on starting the next filter series (same target). I watched it and the failure did appear locked onto a hot pixel. I cancelled the run and reran it. This time it locked on a good guide star but walked it off the chip like it was confused as to which side the mount was on. I assumed the prior cancel after meridian flip left something set wrong so I parked the mount, recycled all the control sw (MaxIm, Fmax, Autopilot, sky6) and reran it. It did the same thing and walked the guide star off the chip. I then regressed to autopilot 4.15.7 and then it all ran and guided fine. I have attached the log of the original failure.

ccdap20091016_180913.log (25 KB, 12 downloads)

Hi Jim,

In looking at your log, I don't see anything really wrong. If you are referring to the entry starting 22:05:50, that is normal. The dither between the second and third frame has the biggest move, 6 pixels in your case, and depending on the max. move specified, it may take a number of cycles to get there.

Or is there another point in the log I should look at?

PS I believe there is a way to set calibration for the guider in Maxim. I think you have to have a bias and dark long enough so that Maxim can scale the dark for proper calibration. This has been discussed recently on the Maxim forum. You may want to look into that.

John:

Sorry, I guess I wasn't very specific in my description. The guiding went into the "fixed offset" mode of x/y 1.0/1.0 at 22:33 so I killed the run and restarted (too few clear moonless nights to let it keep failing just to test). I didn't realize the log didn't catch enough to show the pattern more clearly. The live graph in MaxIm was just a flatline on both axis. I think I'm going to try CCDSoft and see if I have better luck with it. I still get the impression that something is confused after the meridian flip and once it finishes the series that straddles the flip it can't properly find the guidestar.

Hi Jim,

I have a hunch on what might be going on. I noticed the target PA is different from the plate solved PA by 180, which is probably the cause of the apparent ReverseX error. I noticed something similar in another user's (Michael) log who is reporting the same problem.

Can you post a log from one of your run's with 4.15.7?

Thanks.

Jim,

Please see the comments and patch file posted at the end of the thread here

John:

Here is the log from the same night on 4.15.7. This worked ok (except for an unrelated hang between Maxim & FocusMax at the end of the session). It does show:

23:15:11 Target RA: 22 15 11.4, Dec: +70 21 32 , PA: 82.8
23:15:11 Target is already passed the meridian

I noticed in one of the earlier runs (still on 4.15.9) where it failed that it recognizes the meridian crossing but doesn't seem to adjust the PA:

22:50:56 Target RA: 22 15 08.4, Dec: +70 21 27 , PA: 262.9
22:50:56 Target is already passed the meridian

I'll download the patch and will try it tonight if the weather stays clear.

thanks,
Jim

This message has been edited. Last edited by: Jim,

ccdap20091016_230927.log (28 KB, 5 downloads)

John:

I tested last night but still had issues. As before, everything worked fine until after the meridian flip. The active series of 3 subs was interrupted by the flip and both subs after transit guided properly. As before, the next filter series on the target then failed to guide. In this case it was back to selecting a hot pixel so I couldn't tell if the axis reverse changed or not.

Here is a subset of MaxIm's log:

Track Log Started at UT 2009-10-19 04:26:09
UT Time, Star X, Star Y, OffsetX, OffsetY, Corr X, Corr Y, Bright
04:26:14, 404.00, 277.00, 1.00, 1.00, -0.52, 0.16, 3833
04:26:21, 404.00, 277.00, 1.00, 1.00, -0.52, 0.16, 3961
04:26:28, Guide Star Fade
04:26:35, Guide Star Fade
04:26:41, Guide Star Fade
04:26:47, Guide Star Fade
04:26:53, Guide Star Fade
04:26:58, Guide Star Fade
04:27:04, 404.00, 277.00, 1.00, 1.00, -0.52, 0.16, 3717
04:27:11, Guide Star Fade
04:27:16, Guide Star Fade
04:27:22, Guide Star Fade
(etc)

I then cancelled the run, parked the mount & reset the key software. I reran on the patched 4.15.9 and had exactly the same result as it locked onto the hot pixel. I then regressed to 4.15.7 and it ran successfully the rest of the night. In looking at the various logs I did notice one strange thing - I couldn't find any log entry in the initial run showing the target's expected PA after the flip. In the failing retry on 4.15.9 it does show up with the bad PA value and then in the good 4.15.7 run it shows the properly adjusted PA:

1st retry on 4.15.9 (patched):
22:36:12 Target RA: 22 15 08.4, Dec: +70 21 27 , PA: 262.9
22:36:12 Target is already passed the meridian

Good retry on 4.15.7:
22:51:35 Target RA: 22 15 11.6, Dec: +70 21 32 , PA: 82.8
22:51:36 Target is already passed the meridian

So it looks like it's still getting confused after the target transits. It's also strange that the message showing the target's PA doesn't seem to be in the first run at all but does show up in the failing retry. I've attached the first run's log and can also send you the other 2 logs & Maxim tracking logs if you need them.

thanks,
Jim

ccdap20091018_180054.log (23 KB, 5 downloads)

Hi Jim,

I am pretty sure the guiding problem is that hot pixel. The meridian flip is a red herring. Note the guiding through the green filter was fine after the meridian flip. It was only when you guided through the blue filter that the problem occurred. Apparently Maxim can treat a hot pixel as a non-star.

Starting with 4.15.8, CCDAP starts the auto guide exposure at the minimum exposure time, increasing as necessary to achieve the target ADU level. This was done to avoid saturated guide stars as requested by users. This of course exposes you to a potential hot pixel issue. 4.15.7 used a mid-range initial setting. With your ranges, 4.15.7 would start with an exposure of 12.2 sec.; with 4.15.9, it starts at 5 sec.

However, the bigger issue is the hot pixel. That must be removed because as long as it exceeds your target ADU (3000) at the minimum exposure (5 sec.), it will be selected as the "guide star". The hot pixel is 3650 ADU at 5 sec. exposure. It will be 3650 ADU at 12.2 sec. as well but the star will be considerably brighter and will be selected.

CCDSoft allow setting an autodark for the guider. With Maxim, you need to work at it a little harder. There has been some discussion on the Maxim Yahoo list about how to do this to remove hot pixels. You may want to check it out to see if you can set up a full calibration for the guider. I think it may be possible.

Another alternative is of course to use CCDSoft, which will eliminate the hot pixel issue altogether.

A third alternative is to set your target ADU to something well beyond the hot pixel - say 5000 ADU.

Yet another alternative is to check "Use Maxim Guide Star Detection" on the CCDAP tracking and guiding page. See if Maxim can internally ignore the hot pixel.

But the best solution is to fix the root cause - calibration to remove the hot pixel - using either CCDSoft's autodark facility or Maxim's full calibration one.