Hi John & Frank,

I upgraded to CCDAP 4.15.9 and re-intialized my system, which is a Paramount ME, RC 400mm reflector and ST10 XME. The system will not plate solve during initialization with any of the following software combinations:

CCDSoft V5 with The Sky6/CCDSoft V5 plate solve
CCDSoft V5 with Pinpoint 5.0.13
Maxim 5.07 with Pinpoint 5.0.13
Maxim 4.61 with Pinpoint 5.0.13

When I plate solve by "Taking an Image" in either Maxim v5, Maxim v4 or CCDSoft/Sky 6 with the same exposures times, the plate always solves within 10 seconds or less. (My FOV is small. ST10 XME with FL of 3200 mm. Plates always have 15 to 30 stars, Guide Star catalog used in CCDAP and GSC 1.1 in Pinpoint).

Here is the message I get from the trace in CCDAP4: PinPoint.Plate: No matching stars found. Check your estimated center-point RA/Dec, and your image scaling and quality.

Of course, I have checked the image FITS and they have the correct RA/Dec, focal length, pixel size and image scaling.

I deleted CCDAP4 4.15.9 via the Windows remove utility. I reinstalled 4.15.7, Unfortunately, with the same result above (initialization fails). I "reset" 4.15.7, restarted 4.15.7 but the same initialization failure. I then "reset" 4.15.7, restarted 4.15.7 and upgraded to 4.15.9 but the same initialization failure.

I am out of ideas after two night of testing. I even disabled my internet virus software with no difference. BTW, this is a US version of the XP operating system located the PST time zone.

I have benn using registery mechanic for 1 year without problems with CCDAP4.

No log files, since I cannot get past initializaiton.

This is a weird one.
Thanks,
Dale

Hi Dale,

Does your FL, Pixel Size, and unbinned image scale on the Settings tab in CCDAP4 match what you are seeing in the Fits header? When the plate solve works in CCDSoft/TheSky6 stand alone, How many stars are identified in the solution. One thing you might try is to turn on the Hipparcos/Tycho catalog and the UCAC2 catalog to see if that helps. My experience with my 16RC and ST-10 was that the GSC catalog worked many times but not all depending on the time of year and place in the sky I was initializing. HTH .....

Hi John and Frank,

I believe that I have a possible explaination. There are small but significant differences in the OBJCTRA and OBJCTDEC keywords when the images are stored as a SyncImage from CCDAP or stored as a regular image from CCDSoft.

I took a series of three 2x2 binned images using CCDAP, CCDSoft, Sky6 using CCDSoft/Sky6 image link for the plate solving and UCAC2 catalog. Images 1 and 3 were SyncImages generated by CCDAP using the Initialize Button. Image 2 was take with CCDSoft using the "Take Image" Button. All images were taken within a few minutes of each other, with the same exposure and binning, while pointed at same place in the sky (same RA/DEC, no slews between images. Image 1 was taken before Image 2 and Image 3 was taken after Image 2.

Image 2 will plate solve (UCAC2 using 257 stars). SyncImages 1 and 3 will not solve using either CCDAP "From FITS" or via CCDSoft directly. Here are the FITS keywords from the 3 images:

Image 1, SyncImage_NA_205907
OBJCTRA = '18 41 56.5 '
OBJCTDEC = '-04 18 21 '

Image 2, Image 20
OBJCTRA = '18 41 24.452 '
OBJCTDEC = '-04 18 56.94 '

Image 3, SyncImage_NA_210714
OBJCTRA = '18 41 54.9 '
OBJCTDEC = '-04 18 22 '

Using the FITS Editor, I replaced the OBJCTRA and OBJCTDEC data in image 1 with the data from image 2. Image 1 will now sucessfully plate solve.

Note the RA/DEC differences are about 30 arcseconds in each corrdinate. My FOV for the telescope/camera is about 15 arcminutes x 10 arcminutes. So the RA/DEC differences are about 5% of the FOV.

So, why are there differences in the OBJCTRA and OBJCTDEC keywords and why would relatively small differences cause failure or success in plate solving.

I use a 12 term T-Point model with the Sky. Are the differences in keyword values due to corrected vs uncorrected RA/DEC coordinates? Might the problem be different Epochs?

I can send the images, but they are too large to attach to this post.

Thanks,
Dale

Hi John and Frank,

The differences in the RA/DEC coordinates between Image 1 and Image 2 FITS headers match up with the differences between Epoch 2000 and Epoch Current for the Target.

I am guessing that CCDSoft solves the plate in Epoch 2000 coordinates, and CCDAP sets the OBJCTRA and OBJCTDEC keywords using Epoch Current coordinates.

Thanks,
Dale

Dale,

You are correct - OBJCTRA and OBJCTDEC use the current equinox coordinates as reported by the telescope. Have you tried increasing the expansion for PinPoint?

Hi John,

I am using the CCDSoft/Sky Image Link for plate solving since it automatically uses UCAC2(my FOV is small). I have tried Pinpoint using the guide start catalog and Nomad (net) with expansion factors of .3, .5 and .8 without reliable successes.

I repeated the initialization experiment last night, this time near the star rich Double Cluster. The SyncImage will not solve with Image Link, yet an image (same target) collected with CCDSoft (Take Image button) solves within a few seconds.

Replacing OBJCTRA and OBJCTDEC data in the SyncImage header with the coordinates from the CCDSoft image header solves the problem. It solves within a few seconds.

SyncImage
OBJCTRA = 02 19 47.5
OBJCTDEC = 57 11 05.00

CCDSoft Image
OBJCTRA = 02 16 55.44
OBJCTDEC = 57 13 00.86

I checked the plate solving help files of both Pinpoint and CCDSoft/Image Link. Both use and report in equinox 2000 coordinates.

So why would CCDAP SyncImages use the current epoch coordinates rather that equninox 2000 coordinates as the starting coordinates for plate solving?

BTW, I could not solve the Double Cluster SyncImage with Pinpoint (From FITS button) with expansion factors of .3 and .8 (guider star and Nomad). However, I could solve the CCDSoft image with Pinpoint, expansion factor of .8 in about 60 to 70 seconds.

Thanks,
Dale

quote:

So why would CCDAP SyncImages use the current epoch coordinates rather that equninox 2000 coordinates as the starting coordinates for plate solving?

Why? I dunno - because I started that way almost 4 years ago and no one complained

I believe this is a red herring in your case. Differences between current and J2000 equinox coordinates should not be that significant. The precession difference in RA should be around 45 sec and it is 172 sec. in your case. It sounds like a location/time setting issue to me. Your PC clock may be a couple of minutes off.

Try putting in a current equinox RA/Dec that correspond to the J2000 image and see how it solves with your FOV. See the attached screen cap from TheSky6

PrecessDiff.gif (16 KB, 11 downloads) precession differences

Hi John,

I ckecked the time and it is correct. In fact, the PC time is set by the Dimension 4 application which polls network time servers over the internet to set PC time.

The location data in the Sky6 is GPS accurate. Time and location is transferred to the Paramount ME when it is linked to the Sky6.

<<<<<Try putting in a current equinox RA/Dec that correspond to the J2000 image and see how it solves with your FOV. See the attached screen cap from TheSky6.

Did it. The image will no longer plate solve with current equinox RA/DEC. I put the J2000 coordinates back in, and it solves in a few seconds.

The CCDSoft Image J2000 coordinates are:
OBJCTRA = 02 19 06.144
OBJCTDEC = 57 08 21.92

Indeed, the difference in RA is about 45 arcsecs and ~170 arcsecond in DEC.

Just for fun, I plate solved a SyncImage taken with 155mm f/7, FL=1100 mm refractor and the ST10. The FOV is 3 time larger in each dimension. The SyncImage solves just fine using the Current Equinox or J2000 version. In fact, I never have plate solving issues with this setup.

Perhaps, the narrow FOV of 400mm RC/ST10 combo has uncovered a sensitivty related to small FOVs and the need to use the coordinate system of the catalogs

Hope you some ideas because the alternative is a big camera

Hi Dale,

All CCDAP can do is to convert the telescope coordinates in the current equinox to J2000. If the telescope pointing is off, this may not help.

Nevertheless, attached is an .exe that converts the telescope coordinates to J2000 prior to inserting into the FITS header.

Copy ccdautopilot.exe in the attached zip to C:\Program Files\CCDWare\CCDAutoPilot4. You may want to save the existing ccdautopilot.exe

Let me know if this works better with your small FOV system.

ccdap4160p1.zip (395 KB, 5 downloads) patch file

Thanks John,

I cannot imagine better technical support that you and others big users (Frank Barnes) have provided over the last 4 years since the introduction of CCDAP 2.0 that I got started with. The test software image is great.

I will load it up and report results back to the group. It looks like I might not get to it tonight. ClearSky Clock predicts a fair night tomorrow however.

Thank you,
Dale

Hi John,

I copied 4.16.p1 into the CCDAutoPilot4 folder saving 4.15.9 for backup.

I launched 4.16.0.p1. I shows up as 4.16.0 in the Help/About pulldown.

I took an image with CCDSoft which plate solves using J2000 coordinate
OBJCTRA 02 19 6.3
OBJCTRA 57 08 22.25

I took an SyncImage with CCDAP via the Initialization Button which successfully plate solves using your Jcurrent to J2000 coordinate routine

OBJCTRA 02 19 2.8
OBJCTRA 57 08 11

I took an SyncImage with CCDAP via the Slew to Target Button which did not plate solve

OBJCTRA 02 19 48.7
OBJCTRA 57 10 59

And finally, I took an SyncImage with CCDAP Run Session Button which did not plate solve

OBJCTRA 02 19 48.7
OBJCTRA 57 10 59

Looks like we are almost there. The Jcurrent to J2000 routine seems to work in Initialization (I did it about 10 times, all worked). Looks like subroutine calls in the other parts of the code are in order (just guessing of course).

Thanks,
Dale

Hi John,

One more point of clarification. I removed the T-Point model from the Sky6 for testing 4.16.0. Just minimizing the variables.

Do you read the telescope coordinates as modified by T-Point, or use the current equinox coordinates as provided by the Sky6 prior to T-Point?

Thanks,
Dale

Dale,

First, post your session log.

As to Tpoint, here is how things work. After building a Tpoint model, when you tell the telescope to go to a specific coordinate, the coordinate is adjusted internally to correct the pointing according to the Tpoint model. If you disable the Tpoint model, your pointing could be considerably off, depending on the strength of the Tpoint correction.

Now if you slew to an uncorrected location with your small FOV, even an equinox correction may not be able to get you within a solution range.

PS the same sub is used for inserting J2000 coordinates during initialization, slew to target and run session.

Hi John,

Please find the attached log flie that I generated tonight. The Target is the Double Cluster consistent previous posts.

I had success initailizing using CCDSOFT/Image Link with the new 4.16.0p1. The plate solve was successful and the guider was calibrated successfully.

Next was a "Run Session". The same target failed on the plate solve. See log.

So, I examined the FITS headers of the two SyncImages generated during Initialization and "Run Session" (scope does not slew at all of course).

Here are the OBJCTRA and OBJCTDEC coordinates of the two images:

Initialization Image -> this one plate solves
OJBCTRA = 02 19 02.3
OBJCTDEC = 57 08 13

Run Session SyncImage -> this one fails
OJBCTRA = 02 19 48
OBJCTDEC = 57 11 01

So why are they different, since they should be the same?

Sorry to get you off topic with my question on TPoint. My mount is well sighted to the pole, with less that 1 arcminute of error in both az and elevation. With TPOINT, the RMS point accuracy is 30 arcseconds. For tonight's test, I ran with T-Point pointing since you had some concerns.

If you are getting ready for AIC, this can wait as I can talk to you in San Jose.

Thanks,
Dale

ccdap20091028_001929.log (8 KB, 5 downloads)

Hi Dale,

No problem with the Tpoint thing - fair question.

If you get this before you leave for AIC, please bring this file: C:\Documents and Settings\Dale\My Documents\Astronomy\AstroImagery\09-Oct 27-30 pv\CCDAutoPilot_SyncImages\SyncImage_Double Cluster_002004.fit

See you at AIC!