Others have reported this but I have yet to see any solution. For what it’s worth here is some interesting data which might help the more knowledgeable amongst you to come up with an explanation/solution.
I was imaging with C9.25 SCT and SX695 mono ccd. Using Slew Now followed by Centre Now in Target Settings the centre routine always took me to 0+/-5 pixels in DEC and 100+/-5 pixels in RA. No matter whether I started bang on centre or nudged the target to several hundred pixels off in any direction, Centre Now always took me to the same spot, even if I set 10 attempts and a limit of 10 pixels (so that it would fail and cycle through all 10 attempts - always the same finish point and usually from the second attempt. I learned to live with it, since 100 pixels error in RA with a scale of 0.4 arc sec per pixel is only 40 arc sec off target.
I changed my imaging train to include f6.3 reducer, and I noticed the same problem though now DEC was still going to 0+/-5 but RA was going (always) to 64+/-5. That’s when I noticed the RA error was consistently 40 arc sec. Again I lived with it.
More recently I changed to 115mm, f7 OTA and found the same problem, though now the RA error is consistently 35 pixels, which again corresponds to 40 arc sec in error. Just to check further, I switched to a 80mm, f5 refractor and now I’m getting consistent 18 pixel RA error, again 40 arc sec error (DEC is still spot on).
It seems to me that something, presumably PS2, is resolving the error of 40 arc sec in RA into a mathematical result of zero - or could it be the mount driver (CGX(L)) which seems unlikely, or possible something in the RA drive chain which has a permanent bias (even more unlikely). Even something in SGP itself - I’ll now wash my mouth out!
As I said - for what it’s worth.
i had the same problem, images was always out of center of some hundred pixels even after successful autocenter, with my 10micron issue was JNOW or J2000 coordinates… once set correctly on mount (and given correct coordinates from planetarium) it worked perfectly…
That’s interesting. Before you made the correction were you off in both axis or just one. I’m not qualified to say whether epoch is the problem in my case. I know that the CGXL uses JNOW while SGP uses J2000 but the log shows a conversion taking place every time a mount movement instruction is given. Of course it could be the conversion itself which is introducing a consistent error in the RA axis. However, since my error is always the same irrespective of target, and given that it is only on the RA axis, I don’t think it is down to a mis-setting somewhere. Having said that, I wouldn’t know where, if at all, the setting could be changed.
Just a thought, to eliminate a variable, do you get the same platesolve result from the other platesolvers. If you do not have PinPoint, I can solve one for you.
Good thought. Short answer - no idea. I’m away from the Obs till tomorrow but I’ll check a few images with local ANSVR as soon as I can. I don’t have PinPoint so if ANSVR doesn’t answer the question I will gladly drop a couple of images into dropbox and await your verdict. One question (it’s the novice in me), do I simply load the image and then right-click and solve, or do I have to do anything to tell it what the actual target coordinates are?
Are you using a pointing model?
If you are delete the model and do two Solve & Sync.
Nigel
I think the answer is yes, in that I have performed a 2-star + 2 calibration star alignment, and then subsequently used “use last alignment” when powering up the mount for a new session. However, over the past months I have done at least three alignments, plus a couple of polar alignments, and I have also used the “quick alignment” which just builds a pointing model from the input date and time. In all cases the Centre Now error has been the same and that has led me to eliminate a pointing model conflict. Also, I’m not sure if you can actually clear the ‘current’ pointing model because the only way I know to enable the usb link between the mount (handset) and the obs pc is to go through the standard CGXL startup routine, the last step of which is to either perform a new alignment, use the last alignment or use quick alignment. I have not used ‘Solve & Sync’ so will certainly give it a try and see if it alters things. However, from reading the logs it seems that SGP issues a sync command every time it does a plate solve so I would have thought that achieves the same thing as ‘solve & sync’
A few quick checks show that PS2 and ANSVR are solving to within 1 arc sec of each other in both axis on all images so I guess that eliminates one variable.
For what ever its worth. I sometimes experience the same thing in RA after a meridian flip and recenter. Last night it made the flip and nailed DEC but was way off RA. Subsequent iterations did nothing but move the RA by just a few pixels. Every time that has happened to me the only way I was able to solve it was to park the scope, delete all sync points from EQMOD and then recenter. It nailed it perfect after that.
I have not idea why it does that but it seems to be an Eqmod/Sgpro issue.
This is the way the slew works with Celestron mounts, It always ends up something like 40 arc seconds in RA from the target. Set the margin in pixels to something like an arc minute and relax. An arc minute is pretty good.
If it were up to me I’d specify the limits in arc minutes, not pixels. People have no idea how small a pixel is.
Chris, I agree your point that a 40 arc sec error is no big issue, and particularly so in this specific case since the error is consistent and repeatable so in reality ‘Centre Now’ always takes you to the same point, night after night - it’s just slightly the wrong point, and it would be nice if it didn’t happen. Repeatable problems are almost always fixable.
I struggle though with your comment “This is the way the slew works with Celestron mounts, It always ends up something like 40 arc seconds in RA from the target”. If you are suggesting this is a random error (eg up to 40 arc secs, in either direction) then ok, it would be mechanical intolerance and would be difficult to fix in this ‘price bracket’. But a random error is not what I am getting - it’s systematic - always the same. So if you are suggesting it is a systematic error that Celestron is aware of then they could easily fix it because if it is in the mount itself, and it’s systematic, then it is an electrical bias problem somewhere in the drive train and most likely in the backlash control circuit (these mounts do have quite a lot of backlash).
sg_logfile_20171116141401.zip (73.4 KB)
In the thread ‘solving fails when it knows where you are’, I explained about the repeated failure of f&f to correctly ‘centre here’. Nigel suggested that I did it a different way - using the scope centre facility. Last night I had the first chance to try that. It completely failed - see uploaded log. Despite doing this carefully it moved the scope to a wrong position. I used M45 to identify a suitable ‘centre here’ target but the target ended up almost off screen. This facility on both f&f and ‘scope’ does not work and is a major bug in my humble opinion. The failure time was 2002 GMT in the log attached.
Lawrence Harris:disappointed:
Lawrence, Looking at your log I can see a successful centre timed at 20:01:22.219 and the next one, also successful is at 20:08:04.634 which appears to be the first one on M45. I can’t see any entries timed at 20:02. What am I missing?
This is the real problem! I point at a target (in this case a triplet
of stars in the Pleiades where I tell it to centre), but when it moves
the scope it does not move to the selected centre but to somewhere
else. It then solves again and tells me that it is there - when in fact
it is loads of minutes of arc away. For some reason it does not
recognise that this place is not where I selected. I always select an
unambiguous target - in this case, the triplet.
Its just the same if, say M2 or similar is selected. It does not go
there. FWIW I would be /delighted /if I have made a mistake but so far
logic tells me that I have done things correctly.
regards
Lawrence
Ah Ha. Now I (think I) understand your issue, which is similar, but different, to mine. So, I’ve had another look at the log. Indeed, the target location of the Centering routine (at 20;07;39.547) is very close to the centre of M45, and the plate solve (20;08;04.101) after the slew is within a nat’s of spot on the target coordinates. So the log shows the mount has gone where it was told to go, and that it was told to go to the right place. I’ve probably just arrived at the same point of confusion as you’ve been at for a while. It doesn’t make sense! So my next question is how are you measuring “it is loads of minutes of arc away”. At your image scale several arc minutes equates to hundreds of pixels of error, yet plate solve, which is looking at the same image as you, says it’s only a handful? Also, have you tried a quick solve after the centre routine is complete just to see if PS2 still reports the same small error, or does it now report the much bigger error that you are seeing. That would indicate (maybe) that there is further mount movement after the centre routine has finished (or thinks it has). Another possible check would be to solve with a different plate solver, such as ANSVR to see if it gives the same results.
Lawrence, just a thought from way way out in left field. Are you using a guide scope? If so, is there any chance SGP is picking up the guide image instead of the main image for plate solving when centring? This would certainly centre you in the wrong place (unless your alignment of the guide scope is ultra perfect).
On occasions I use the guide-scope for PHD2 guiding but not every time and actually, on this occasion, the cable was not connected … ! However, thanks for your ponders 
BTW the guidescope is not yet aligned with the main scope, following a mount height adjustment.
I increasingly feel that SGP is simply to blame! Two facilities with one bug.
Lawrence
Lawrence, I think you are overstating things here. From what you say it would be easy to think that the mount ended up nowhere near where you ask it to go, for example instead of pointing to a star in the Pleiades it goes to the Hyades.
This doesn’t seem to be the case, the error you are talking about is small, something like an arc minute. About the size of M57.
Buggs, You will be better going to Celestron to discuss their pointing accuracy with them. I don’t think it’s my part to say any more here.
Your expectations about what a medium priced mass produced mount can achieve may be a bit high… An arc minute is pretty good. There could be all sorts of reasons for this.
Hello again
My judgement is based on the fov. I am currently using the scope at f2,
giving a fov of 2.5 deg x 1.7 or so. The pointing leaves the scope at
about 0.25 to 0.5 the fov. That’s a lot of arc-minutes isn’t it?
regards
Lawrence
Just an extra note here about this evening:
I just completed a test with a mosaic of M31 (2 frames of two images).
I wanted to go there before starting SGP. CdC placed M31 near the edge
of thee two degree field. I did a solve-and-sync. I then clicked on
M31 (near the edge remember) and did ‘centre here’. It did its stuff
and placed the final image supposedly a few pixels off. I did a f&f and
M31 was not in the frame at all.
regards
Lawrence