I just started my evaluation of the application last weekend and I am very impressed with it thus far. I have been having problems with the Precision Slew to Target feature, which is a deal killer for me. I suspect that my G11 with Gemini Level 4 Version 1.04 may be too sloppy a mount to support this capability. I have the Ovision precision worm assembly installed and get great PE (< 5 arcsec p-p), but the manufacturer recommends a significant amount of RA backlash for optimal performance. With PEMPro's help, I have virtually eliminated all backlash on my Dec axis.

My issue is detailed in the attached log file. The error for my first slew to target is almost always ~ -6 arc-min in RA and ~ -2 arc-min in Dec for targets in the vicinity of Cygnus based on plate solves. I've been doing a lot of imaging in this area and my Gemini pointing model is not too bad. Three attempts by CCDAP to reduce this error will inevitably lead to an even higher error, with some attempts resulting in no change in plate solve solutions.

I took out most of the RA backlash last night, but there was no change in the application's behavior. I guess this should not have surprised me. Dec errors are not handled well either and I have very little backlash on that axis.

I did notice today that I have not been using the ASCOM driver for Gemini via TeleAPI in The Sky 6 Professional as recommended. I am now and will test the application again tonight if weather permits. I am running ASCOM Platform 5.0a, Gemini driver v4.2.27 and TeleAPI v4.0.1.0.

Any assistance would be appreciated. If anybody is having success running CCDAP with their G11, then please let me know.

Thanks,
Ken

ccdap20090918_224628.log (11 KB, 9 downloads) Sample Log File

Hi Ken,

How many points are in your Gemini Pointing model? Does it include points from both sides of the meridian? Having a well tuned mount is, of course, a plus when it comes to pointing. I noticed that you are using a C-11. Have you incorporated any type of mirror lock, as a SCT mirror flop can certainly cause errors in pointing as well. I know there are folks out there that use CCDAP4 and G-11 mounts, so hopefully some will offer some specific sugesstions based on their experience. Do you have any backlash compensation set in your controller that might help take up the gear mesh ?

Frank,

Thanks for the feedback. I have 3 or 4 stars on each side and can put the object on my 21 x 30 arc-min CCD every time. I have a C9.25 with no mirror locks, but the shift is relatively small. I do not have any backlash compensation programmed into Gemini. As I mention above, I zeroed my Dec backlash with help from PEMPro.

I ran my test tonight and the problem is still there. The corrections made by CCDAP during Precision Slew to Target (no target value or synch) were always in the wrong direction in RA and the wrong way 6 out of 7 times in Dec. The errors were very repeatable.

When I started running my session, the two Precision Slew to Target runs (once to the target and once coming back to the target from the focus star) resulted in the object being completely off the CCD chip. 7 arc-sec error o start. Correction moves it ~ 5 arc-sec more off target and sets a new target for the program. The very same thing happens again after focusing, pushing the object further away and off the chip.

I don't think this is backlash. Corrections are being made in the wrong direction.

Ken

Hi Ken,

One thing I would suggest is that you rotate your camera about 10 degrees and then perform a new initialization. This moves the calibration off the cardinal points. After the initialization, you are free to orient the camera at any PA. Try this and see if it resolves your issue. Also, after you are on target, execute a manual plate solve and verify that you are getting at least 6 stars are identified in the solution. If not, then the plate solves are probably suspect and this can feed incorrect information to CCDAP4. HTH ...

Hi Ken,

I have a 6" f/12 refractor on a G11 mount, also with the Ovision worm modification. I'm a relatively new user to CCD Autopilot, but I've had very good success with my pointing. I have not done any backlash correction. I use Pinpoint for plate solving. My FOV is 20'x 17'. I'm attaching a log from my last run on M15. I caught a cable on the meridian flip so the run was aborted at that point, but I've had a number of successful meridian flips as well. I specify a fairly loose tolerance of 35 arcseconds for pointing, but the program usually gets me a good bit tighter than that. I wonder if there's something amiss with your plate solving settings or your calibration. Hope this helps,
Bob English

ccdap20090824_203625.log (53 KB, 7 downloads)

Frank,

Thanks for the rotation suggestion. I didn't realize calibrating on the cardinal points could cause a problem. Unfortunately, rotating the camera and re-initializing did not solve the issue. Precision slews still behave in exactly the same manner as before. Very, very repeatable ever increasing errors with each correction.

I did a manual plate solve on one of the synch images and got a good solution. 22 stars used and an RMS error of 0.41 arc-sec. The RA, Dec and PA all look right.

I am now very suspicious that some kind of communication issue exists between my computer and the Gemini. Based on what I see in The Sky and on my CCD, my pointing model must be pretty good. When I manually center precisely on an object, the telescope cross-hairs in The Sky are within an arc-min of center on that same target. The reverse is also true. If I can do it using the cross-hairs as a guide, then CCDAP4 should be able to do it, too.

I'm going to order a Gemini L4 v1.05 PROM to make sure nothing is amiss in the mount's software. In the meantime, I will do a "CMOS Reset" of my Gemini L4 v1.04 computer (remove the battery, let it sit for a while and then replace the battery). If these things don't fix it, then I'm out of ideas.

Thanks again for the help.

Ken

Bob,

Thanks for letting me know about your success using CCDAP4 to control your G11 with Gemini. This gives me some hope that automation is possible with my system. I'll keep trying.

I don't think bad plate solves are my problem. The progression of errors, start to finish, was almost identical on three different objects in different parts of the sky (all on East side of Meridian). Whatever the problem is, it's common to every session and repeatable with computer-like precision.

Ken

Here's and update...

CMOS reset did not change anything.

New EPROM with Gemini L4 v1.05 is on the way.

I'm also going to try a new RS-232 adapter that's on the way to make sure my current adapter isn't causing a communication problem.

Finally, I'm looking at potential problems with how The Sky is set up to control Gemini. There are some set-up steps identified in the Help file that I did not know about.

Ken

Ken,

Sorry I can't think of more to help you out. The fact that your initial slew is reasonably close to the target would seem to indicate that the sky and the mount are communicating okay. Are you absolutely sure that all backlash compensation has been removed? My only other suggestion, which would be easy to try, is to relax the precision slew tolerance to something really large, like 60 arcseconds, and see if it makes a difference. If it does, you could iteratively keep reducing the tolerance and see if there's some value at which you start seeing the problem.

Bob

Bob and Frank,

Many thanks and good news! Based on a few trial runs last night, my problem seems to have been resolved. Precision Slew and Precision Slew with a 25 arc-sec tolerance both performed well on several targets.

These are the changes I made to my setup / method since the last time I was out testing CCDAP4:

1) New USB to RS-232 adapter
2) Changed Gemini communication to Epoch of Date
3) Went back to using The Sky's driver for Losmandy Gemini instead of TeleAPI + ASCOM driver
4) Changed my procedure for synchronizing the mount

Regards number (4), I have been using the standard Gemini method (Go to Bright Star - Manually center star on CCD - Synchronize on star), all via the hand controller before linking to The Sky. Last night I linked The Sky to the telescope immediately after a warm start, I picked one of Gemini's alignment stars in The Sky, slewed the telescope to that star using The Sky, manually centered the star using the hand controller, synchronized The Sky to the telecope via the Object Info window's Telescope tab and then synchronized Gemini to the PC Object (coordinates?) via hand controller.

I don't think (1) or (3) really contributed to the fix. I'm curious enough that I may go back and see if I can determine just what did the trick.

Bob,

Do you initialize The Sky and Gemini as I describe above in my new (The Sky Help file recommended) approach?

How is your Gemini communication protocol set up, Epoch of Date?

Thanks again to Bob and Frank.

Ken

Hi Ken,

Glad to hear you're up and running. I do use the Epoch of Date in the Gemini communication protocol.

As for synchronizing the mount, I use standard Gemini method (Go To Bright Star) to slew to a bright star, center it with the hand controller, and synch on it with the hand controller. I then link to the Sky, then synchronize to the Sky via the Object Info window's telescope tab, then synchronize Gemini to the PC Object with the Gemini hand controller. But I think whatever method works the best for you is the way to go. I do seem to remember early on in my own tests that if the sync did not appear accurate in the Sky I could expect problems on CCDAP's centering of the object. I'll try your new method with the Sky when I get a chance to see how it does with my scope.

Bob

One last add on this topic. My issue was the communication protocol setting in Gemini. It must be set to Equinox of Date when connected to The Sky for proper function. Based on trial runs tonight, I find that Gemini defaults to J2000.0 any time a new connection is made by The Sky. I wish I could change that behavior. It's bound to ruin a session from time to time. At least now I know how to fix the problem when it comes up.

Thanks again for all the help.
Ken

This makes sense, Ken. TheSky6 and CCDAP sends all slew commands in current equinox. All other coordinate data used internally in CCDAP is in J2000. Appropriate coordinate transformations are made when sending slew commands to the mount. So having the Gemini set for current equinox is correct.