Centering Conundrum

Looking at the log they you posted:
The target position is this:

[10/27/17 20:40:35.049][DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 4.89689444444444 (04h53m48.82s) Dec: 64.6466222222222 (64°38’47.84")

After a couple of iterations the solved position is this:

[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] *********** SUCCESSFUL SOLVE *************
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] SOLVER: False
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] SUCCESS: True
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] CONF: 383
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] BLIND: False
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] RA: 4.89645885262137
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] DEC: 64.6449527337473
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] SCALE: 5.73586
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] FLIPPED: True
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] ANGLE (EON): 359.23
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] MSG: Valid solve.
[10/27/17 20:41:00.858][DEBUG] [Telescope Thread] ******************************************

The difference in Ra is 23.52 arc seconds and the difference in declination is 6.01 arc seconds.

Are you really saying that’s not good enough?

The pixel scale that your data gives is 2.86 arc seconds per pixel and a field width of 1.2 degrees.

I don’t see any case to answer.

edit…

The plate scale reported by the plate solver is 5.73 arc secs per pixel, twice the plate scale that I got by comparing the error and the offset in pixels. That doubles the difference to 48 by 12 arc seconds and the image size to 2.4 degrees. Maybe there’s a 2x2 binning that I’ve missed.

Even that isn’t bad still less that an arc minute.

I confess to being completely baffled. This evening, typically, I took a
solve+sync image of the goto field of M31. The galaxy was near the edge
of the 2 degree frame. I then pointed at the galaxy core, did a ‘centre
here’ and it slewed. I then got a new f+f and the galaxy had gone from
the fov.

All I am saying is that these two functions that provide 'slew here’
after a solve are surely not working properly when they do not ‘slew
here’? /This fov is 2.5 degrees x~1.7 degrees/ and all such slew here
commands are taking the slew way over a few minutes of arc. Somewhere
along the line the ‘slew here’ command is delivering wrong coords.

I’m going to leave it at that …

Lawrence

Lawrence, I think there is a way to get to the bottom of this. You say " I then pointed at the galaxy core, did a ‘centre
here’ and it slewed. I then got a new f+f and the galaxy had gone from the fov". Now if you can remember the approximate time that you “pointed at the galaxy core …”, and post the log, we can look at the coordinates that were generated by your action and see where you ‘actually’ told the mount to go. We can also see from the subsequent plate solve how close to this ‘target’ the scope actually got. By a process of elimination we will should then be able to figure out whether “pointing at the galaxy” is the error, or the actual slew is the error. All we need is logs that show where you told the mount to go, and where the subsequent plate solve said it actually went.

The problem originally reported by Buggs is a known thing with Celestron mounts and additional modes of centering were added to SGP that should also help with other mounts - but none of the new modes appears to have fixed the problem. At the same time, I don’t know what they are doing under the covers - so I don’t know how they might affect other mounts.

The whole idea of the centering routine - which is fairly elaborate - is to iteratively converge to as close to center as possible. You know something is wrong if it keeps ending up at exactly the same distance off center in exactly the same way - because you can look at what it is doing and say - well - it should have aimed a little down and to the left and it would have nailed it.

Since it is already doing multiple solves and adjusting the manner in which it slews to the target - I don’t know why it wouldn’t also accommodate this need for celestron and other mounts.

I previously have explained and implemented a simple routine that controls SGP and makes this change - so I know it is possible and it would work - converging to within arc-seconds in a few steps with cge-pro.

Frank

Frank, this sounds interesting. These additional modes you refer to - are they automatically included within the centring routine or do I need to select one of them to see if it solves the problem? I’m presently imaging with a 115mm F7. With target coordinates set in Target Settings and using Slew Now I usually end up a few hundred pixels off target. With centring set at 5 attempts and an error of 20 pixels the first attempt takes me to DEC 0 +/- 5 and RA 30 +/-5, and then attempts 2 through 5 take me to exactly the same spot. My present solution is to set the error to 35 pixels (which is 40 arc secs) and I get a successful centre every time. It is remarkably consistent and accurate, and a 40 arc sec error is no big deal. But it is annoying because such a systematic error should be solvable. Any suggestions would be welcome.

Chris, Thanks for your comments. I’m almost totally satisfied with my mount. It guides all night at better than 0.7 arc seconds RMS and I can point to the same place in the sky, within 10 arc seconds, night after night using Centre Now. I think that’s pretty good for a “medium priced mass produced mount”. I do however find it challenging that it should always point 40 arc seconds off the actual target centre on one axis, while hitting the other bang on every time. This is a systematic error, not a random one, and it therefore should have a specific and logical explanation, dare I say a bit more precise than “There could be all sorts of reasons for this”. I just don’t have the knowledge or experience to figure it out. Since others were reporting pointing problems on various threads I thought I would start this one with some analytical information in the hope that somebody with more experience than me might come up with some suggestions. A 40 arc sec error is obviously no big deal. But it’s a bit like a stone in the shoe – mildly annoying and easily solvable!

Regards,

Martin

sg_logfile_20171117181117.zip (74.2 KB)

Re the solves: yesterday I did a run in bitterly cold weather so it wasn’t as long as I would have liked. The sequence includes a long run on NGC1499 with dithers 1 in 3 frames. All this ran fine and I moved the dome around as required. At the end I tried my first test mosaic on M31. I use CdC for goto. M31 was in the f+f frame (bin 4) - around 1940gmt. At this point I tried ‘solve and sync’. I then pointed at the core of M31 I wish that I had kept the f+f image!! I did a ‘centre here with solve’ (sorry I can’t remember the menu option label). At this point it slewed, took its image, solved and waited. I looked at the new image but there was no sign of any trace of M31.

I started the sequence for the mosaic (which was now pre-loaded and ready) and off it went. It did the mosaic fine.

I’ve taken up a lot of peoples’ time for which I am grateful - and sorry.

Lawrence Harris

[quote=“Buggs, post:26, topic:6565”]
This is a systematic error, not a random one, and it therefore should have a specific and logical explanation, dare I say a bit more precise than “There could be all sorts of reasons for this”.[/quote]

Yes, some of the error is systematic. I’ve looked at it and think I know what is happening but don’t see that I’m required to outline my speculations here. I don’t speak for Celestron.

Agree you you there, but the you say…

How can you claim that a problem which you admit that you don’t have the knowledge or experience to figure out is easy to solve?

I don’t think Celestron publish a slew accuracy figure, but have a vague recollection of something some years ago of about 1.1 arc minutes. For normal use as Celestron designed it - doing an alignment using the HC and using that to slew to an object - the errors in the alignment model will be several arc minutes - I doubt they will claim better than 5’ to 10’.

Incidentally it’s thanks to Celestron that you have the ability even to command a position to this sort of accuracy. Their original slew and position commands provided the position as a 16 bit fraction of a circle that gives a resolution of about 3 arc minutes. If they hadn’t provided additional commands that use a 24 bit number and I hadn’t implemented them in the ASCOM driver that’s the best resolution you would be getting.

BTW Celestron are aware of this and say they will fix it some time. If you were to contact them that will be far more effective than posting here. Fixes to existing systems have to compete with new developments and other bugs. Another user contacting them will help to raise the profile of this.

Lawrence, At 19:39:39.560 you give an auto centre command to coordinates RA 00h43m59.44s, DEC 41°56’55.86" and at 19:40:04.942 the scope has arrived and the image is successfully solved with an error of a few pixels. So the scope went almost exactly to where you sent it. However, the (J2000) coordinates of M31 are RA 00h42m44.33s and DEC 41deg16min7.5sec. So the target you are giving is around -430 pixels off target in RA and 14,047 pixels off in DEC which equates to 1 min 15 seconds in RA and 40 min 48 seconds in DEC. It seems your centring routine works fine. If you are ‘right-clicking’ a f+f image and selecting ‘centre here’ then maybe your mouse is not reflecting the correct coordinates of the point you are clicking on. It might be worth pasting the coordinates of your chosen target into Target Settings and using the slew and centre facilities there.

Not particularly constructive

Over 50 years experience in designing and developing (electrical and mechanical) guidance systems for rockets, aircraft, satellites, ships, tunnel borers, remote surgery equipment. You kind of get a feel for these things.

I’ll happily do this, and will be happy to tell them that I think they have done a pretty good job with this mount.

If you look at the Telescope page in the control panel there is an option called Sync behavior - and the choices are Sync, Target Offset, Scope Offset, and None.

These were added to address the problem that some mounts don’t like to be sync’d at all because it alters the sky model. Another problem was this celestron issue with a landing error - where a slew to a particular coordinate does not hit that target exactly even according to the mount’s own encoders. This is obviously not ideal - but for the mount itself it has little impact in its own ability to point around the sky to within perhaps 5 arc-minutes. So using the mount by itself, without a plate solve, you would never be impacted by this landing error.

But when you combine the mount with a plate solve accurate to arc-seconds - then the problem appears. But SGP is orchestrating the plate solve and camera and mount - so it is in a new supervising position to compensate for the landing error - by adjusting the target position.

I thought that one of the options such as Target Offset was meant to do this very thing - but if so it isn’t working as well as it should - because I have implemented a routine that does work well - and it uses SGP for all operations.

So I think that all that’s needed to fix this problem is a tweak to how one of those Sync Behavior options is implemented.

Frank

Thanks Frank. I’ll certainly give them a try.

Here is a thread where I describe it in some detail - and the developers talk about implementing it. That was from last year:

When new versions came out I immediately tested them with cge-pro - but they didn’t seem to work. Since then I have seen numerous people with Celestron mounts ask about Center not converging - and instead getting stuck - so if you try the various options and they don’t seem to work - and if you do feel you need more accurate centering - then that would be good info.

It may seem like 1’ accuracy is adequate for most needs - but a) for long focal length work the lack of accuracy makes the mosaic tool less useful and you need to plan larger overlap and b) a big part of what sgp does is get high performance from a system of medium performance tools - and accurate centering with a plate solve is a good example of it.

Frank

Frank, Thanks for this. I’ve just re-read you earlier thread (I recall scanning it at the time but it didn’t mean a lot back then due to my newness to AP), but now it all makes sense. It seems the problem is with the origins of how centring with platesolve was implemented in SGP verses the variability of mount requirements. I didn’t realise they used the mount encoders rather than the PS error to drive the centring process and it explains why there is no further improvement after the first cycle. I can understand the Developers’ reluctance to prioritise an issue which appears to trouble a relatively small numbers of users. For me it is more a niggle than a problem other than when using very long FL, and I do like the fact that I always centre on the same point, within a few arc secs every time, even though it is 40" off where it should be. As you rightly say, SGP makes all the differece. This particular problem, and a few other ‘quality control’ issues (overhanging drive belts for example) should really be fixed by Celestron if they were of a mind. But that’s another matter.
I will run some tests as you suggest (if ever the skys clear) and see what, if any, effect the other sync settings have.

Frank, as promised I did some test runs on all the available sync settings in the telescope tab. I can report that (as you probably expected) none of the sync settings, including None, has any effect whatsoever on the centering routine. Neither, for that matter, does Solve & Sync in the Platesolve tab. Using Slew Now in Target Settings I slewed to a target and solved (right click on image) which confirmed I was a few hundred pixels off target (scale is 1.16 arc sec /pixel). Then with Sync Behaviour set to Sync I did Centre Now. The first iteration confirmed several hundred pixels off target. The second brought me to 32 px RA and 0 px DEC. With number of attempts at 4 and error at 20 px it cycled through producing exact same result (within 5 px in each axis). Repeating the foregoing with Target Offset, Scope Offset and None all produced exactly the same results. I even tried Solve & Sync after the initial slew but it made no difference. Clearly the mount does not take sync instructions from SGP. However, the mount does centre very well with SGP, in that it gets to the exact same place, within a couple of arc secs, every time. It’s just getting to a place which (in my case) is bang on in DEC and 40 arc off in RA.

Update.
As originally reported, following ‘Quick Align’ on my CGX-L a ‘Slew to Target’ would usually land within 40 arc-min of the target and then the second iteration of ‘Centre Now’ would always get me to within 40 arc-sec in RA and spot-on (+/-3 arc-sec) in DEC. Further iterations of ‘Centre Now’ would get no closer. This issue of getting ‘stuck’ somewhere close, but consistently slightly off target, is a known problem with Celestron mounts and the solution has been suggested as either a change to the way SGPro calculates the pointing error during the ‘Centre Now’ routine by comparing plate solve co-ordinates with Target co-ordinates (rather than Mount coordinates), or by Celestron fixing the error in reported mount co-ordinates.
I recently updated the mount and handset firmware using CFM. While ‘Slew to Target’ still lands within 40 arc-min, the second iteration of ‘Centre Now’ now gets me to almost spot-on (3 or 4 arc-sec) in both RA and DEC. This performance is repeatable and in all areas of the sky. The new firmware module is: CGXL_APP_7.15.8160.cfm

Excellent news, but I wonder when they will update the firmware for the CGEM mount. I land about 30 arc seconds in Dec and 100 arc seconds in RA and nothing I do will get it closer to the target. I spent a few hours on the weekend trying out different manual adjustments to the cone error and other calibration settings in the mount. This allowed me to walk the error in until it turned a corner and started to increase again. I came to the conclusion that I could possibly reduce the errors to an acceptable level if I had enough time, but having sufficient time finding the minima on a three dimensional surface was unlikely. I finally resolved that the only way is to trick SGP by setting the target using the Framing and Mosaic Wizard and then manually changing the target to subtract the known errors. This way, the scope will center on the wrong part of the sky, but the image will be spot on.
I don’t know what the reluctance is to provide a true closed loop control. The auto focus routine looks at the resulting image quality given to us by the focuser and makes adjustments until the answer is correct. This is independent of the capability or quality of the focuser hardware (within reason), doesn’t care if the stepper motor software is full of bugs and works perfectly because it is a true closed loop system. Developers, surely this is a simple thing to achieve with the Centre routine so that it doesn’t care if the mount has serious software bugs as long as it moves precisely. If SGP isn’t changing the target coordinate like a closed loop controller would do, then why does it work it’s way from a large Slew error to a reasonably small error that, in my case, is repeatable to within 3 arc seconds. This tells me that the hardware is excellent, but the closed loop control that should take care of all other issues isn’t really a closed loop. I understand your reluctance to fix Celestron errors in SGP, but just true closed loop control would have fixed the error without anyone realizing that Celestron have a problem