An old centering Bug

Sequence Generator Plate Solving
1

This is a very long one. Please bear with me.

Given that the new 3.1 SGP should be as bug clean as possible, I would like to address an old centering problem related to the “Target Offest” method. It only applies for settings where the telescope uses a pointing model and, for this reason, can not use the “Sync” centering.

A short description:
When using Target offset as a centering model, the first one or two corrections will improve the pointing. After that, no significant change in the centering accuracy can be achieved. Sometimes the correction is sufficient, sometimes not.

A recent example can be found in this thread:

The example in this thread is based on the SGP-Log uploaded there by Eric. Unfortunately, it contains a lot of error messages from TheSkyX, so it is not easy to read. In order to document just the bug I had to extract the relevant lines:

SGP-Centering-Extract.txt (36.7 KB)

The target is the Helix Nebula. The centering will attempt to center 10 times and the accepted error is 150 pix. The evolution for the first 6 steps is:

CenteringSteps
CenteringSteps859×218 8.21 KB

It can be easily seen that after the first two steps the centering error stays almost constant as that SGP does not apply the necessary correction to the Slew Coordinates (GoTo Coord. in the table). The correction algorithm is basically flawed.

For a correct and very easy implementation let’s first define some variables. All coordinates are J2000, and all variables are RA/DEC structures.

TargetCoord – Contains the Target coordinates (RA and DEC); this is a constant. We want to center the image on this point.

GoToCoord – contains the coordinates for the slew command sent to the telescope. It is maintained as J2000 and should be converted to JNow before being sent if the mount so requires.

SolveCoord – The result of the Plate Solve

Error – Contains the pointing error and is computed as:
Error = SolveCoord – TargetCoord

AllowedError – The allowed centering error, in degrees

The correction formula is then:

GoToCoord = GoToCoord - Error

And the correction procedure would look like this:

  1. GoToCoord = TargetCoord
  2. Slew to TargetCoord
  3. Plate solve to get SolveCoord
  4. Compute Error = SolveCoord – TargetCoord
  5. Compute GoToCoord = GoToCoord - Error
  6. If Error-Magnitude > AllowedError go to 2 (but limit the number of loops!); else Done

That’s it. Very simple and it always works.

This would take care of the bug, but there are some more points to be improved:

  • The target setting has one option to <“Slew to” when target starts> and a second option to <“Center on” when target starts>. I can not imagine a use case where somebody would want to start a target without first slewing to it, independent of the option to center on it or not. The option “Slew to when target starts” is unnecessary and should be dropped.
  • The solve hint coordinates should always be the target coordinates and never some corrected coordinates, like this example:
  • It looks like SGP changes the user setting for the pixel scale, without telling. I do not know if this happens after every solve or only for manual solves. Anyway, this is a bad idea: I had one case where – due to some passing haziness – the solve was somehow wrong but not as bad as to be considered unsuccessful. The solved pixel scale was false, and it have been applied to my settings. That killed the night and I needed some detective work to understand why suddenly my solves where not working anymore.
  • Once the “Target Offest” algorithm has been corrected, we only need two target centering options: “Sync” and “Target Offset”. The third one, called “Scope Offset” does nothing useful. The fourth one called “None” is redundant: if no centering is wanted, unchecking the <“Center on” when target starts> option on the target settings does the same.
  • The wording “Sync Behavior” on the Telescope tab is a misnomer. It should read: “Centering Method” or something equivalent, as “Target Offset” does not use Sync

Kind regards,
Horia

2

I think for “2” that should be the GoToCoord. Unless I’m mistaken, what you’re suggesting is actually exactly what we’re currently doing:

  • We slew to the target.
  • The location is solved
  • The current location and reference location are used to compute the error
  • A subsequent slew comes in and the error from above is applied to that slew.

If your telescope only has setting circles it cannot be slewed or if you are not using a motorized mount. I agree for most use cases you would certainly want it to slew. But not all. Granted if a telescope was connected we could make the assumption that you wanted to slew if your target contained coordinates…but what if you forgot to connect it? If this option were removed then we would just assume that you weren’t using a telescope and wouldn’t prompt you.

I’m not sure why this would be the case. You’d want the solve hints to be the actual coordinates coming out of your telescope (adjusted for J2000). The target has little to do with solving an image that you just took.

I’ll do some testing around the Offset behavior this evening. I know what is there could certainly be improved.

Thanks,
Jared

3

I’ve seen the same thing and have given up on centering. My mount has an internal model that results in pointing within 5a/s rms so I have it just “slew to” without plate solving or correction. I think I have all possible sync options turned off in SGP but I still see that after a few days my model gets pretty far off and I have to re-do it. It is as if somewhere there is still a sync going on.

Anyways, the point of this reply is to say that I have seen the same thing Horia pointed out. Regardless of target offset or scope offset I can very rarely ever get it to continue to correct regardless of how many attempts I tell it to try. Whatever CCDAP+TSX do, it will always correct accurately on the first attempt. They must do something different than SGP. But like I said, I use SGP with all forms of sync and plate solve centering turned off (I hope) and I am able to get buy.

4

I did some testing around “Target Offset” and everything seems fine there. I induced a very large error and it was able to get back to the target with very little error.

image

Scope Offset is likely another story That will need some additional looking into.

Jared

5

I wonder if it is a j2000 to jnow issue. going in circles trying to center where one is saying X marks the spot and the other saying Y marks the spot.

Target offset does work except that it needs to sync to the mount and my mount already has 100/100 model points sync positions filled. I can tell the driver to allow a sync that updates the current model by replacing one of the points each time it sync’s but I’ve found that my model does not last very long before it deteriorates if I do that. So I wish there as a way to use plate solve centering BUT not send a sync to the mount. Not sure how TSX does it with closed loop slews but I’ve never had a problem where it tries to change my mounts model to correct centering errors.
For now, zero sync and I just tell it to slew-to and trust that I am well within 50 pixels. 10Micron.

6

Hi Jared,

You are right, sorry for the mistake That line should read:

  1. Slew to GoToCoord

I think the error lies either in in the way you are computing the error or in the way you apply it to the next slew. Looking at the fourth pass through the loop (Slew 4 in the table):

The mount is told to slew to: 22,54335998134 ; -21,4979033370853

After the slew, the solve returns: 22,4997695941333 ; -20,8859152686

The error (Solved – Target) is: 0,00516682 ; -0,05782082

The next Slew should be to (Previous GoTo – Error): 22,53819316 ; -21,44008251

But SGP computes the next slew coordinates as: 22,5432668146796 ; -21,4963316700088

The difference between the “should be” coordinates and the SGP coordinates is: -0,00507365 ; 0,05624916 and this is what is missing to almost completely kill the error.

For the case of the Target Offset method, SGP tells the mount to go to (Target + SomeOffset) hoping it will point to (Target). The actual coordinates as read from the mount are not the pointing coordinates but they contain the offset and are not the coordinates of the image center. Especially when close to being centered on the target, the from-the-mount coordinates are a worse hint than the target coordinates.

If the mount cannot slew, then it cannot center. The user must do it manually. This is just another case where the <“Slew to” when target starts> option is not necessary.

Rethinking the whole centering options, once the “Target Offset” function is corrected, this would be the only centering function ever necessary as it would work for mounts with or without a pointing model.

Kind regards,

Horia

7

Hi Horia,
Thank you for your detailed reply. It does seem to explain the behaviour I have been experiencing.

Since my last post, the spring plungers which set the pressure to engage the gears on the Paramount ME have been adjusted because I was suspecting some play in the gears. I have not been able to check fully because of weather conditions but I have been able to solve and centre successfully on 3 or 4 occasions with an allowed error of 100px. However, this has worked after 2 attempts each time.

My theory is that it never needed more than 2 attempts previously but ageing/wear in the mount had introduced some play in the clutch. So that it started to need more than 2 iterations to solve and centre. The comments you have posted would explain what happened thereafter.
The complication with communications to the SkyX appears to have been resolved by changing the settings in Ascom and updating to the Sky X latest daily build.
Hopefully I can confirm all is working well on the next clear night but it looks good so far.

Best wishes

Eric

8

I agree with @Horia that there is likely a bug in the way SGP is calculating the offsets to accomplish the centering. As I have outlined in other posts, my MEII mount has always had the following behavior (Sync Behavior is set to Target Offset):

  1. the first slew gets to within the range of 60 to 150 pixels
  2. the 1st correction slew gets to either less than my 30 pixel requirement where it is done, or something in the range 31 to 70 where it must try again
  3. if it must to try again, it does not ever get any closer, no matter how many retries I set. So a common sequence is: 130, 65, 62, 66, and so on
  4. since I have recovery mode set, one minute later it tries again. This try is always perfect, usually to within 1 or 2 pixels.

Because of this behavior I have set Attempt to Center/Rotate =2. This results in a minimum of wasted time.

9

Thanks for your information.
I will try your method to overcome this bug, as soon as I get the opportunity…
I’m interested to know how many points you have in your T-Point model?

10

The most recent model has about 650 points. I had requested a build with 750, but in one area of the sky it had a lot of solve failures. It took the entire night. And I am really disappointed in the results. Initially it would slew to less than 100 pixels (0.70 arcset/pixel). This was an improvement but I was expecting and hoping for < 30 pixels. I don’t know if this is an expected result with 650 points or not. @Buzz says he gets < 10. I have tried using ProTrack but it gives me much worse results than I get not using it. What do you get?

11

I seem to be fortunate. The best RMS pointing error I have had was 4". With a rubbish focuser, I was about 12", after a supermodel. My polar alignment is within about 1’ and the mount is attached to a tall pier. The only mount adjustment I have ever made was to check the cam stops, belt tension and renew the lubrication. I typically bin 2x2 on the solve exposures,for about 5 seconds. Some on the forum use 4x4 binning and a smallish subframe. They whistle through a TPoint solve every few seconds. The longest FL I use is 2m. I don’t have moving mirrors, which I know are very hard to keep under control.
I do update the astmospheric parameters with humidity, temp and pressure. The internal temp sensor in my MX gets heated by the work. (update) I also only solve from 40 degrees upwards, as lower than this is generally obscured by my neighbours.

12

I spent a lot of time with my PA and it is < 1’. I always image unguided, doing up to 5 minute exposures with pinpoint stars. But the slew accuracy is really poor. The centering process gets me to 1 or 2 pixels, but I would love to have the initial slew at < 30 pixels, then I would not even need to do centering. What could be wrong? Do I really need to do some maintenance on my MEII? I have had it for 2 years and never done any maintenance.

Where does this come into play?

13

In the model - atmospheric refraction.

The problem here is that it is a complex mechanical system. The telescope, couplings, camera, focuser all can have play and modelling that is quite tricky. The mount is likely to be only a part of the problem. You could quickly check the cam stops and balance, which affect the worm engagement. Trailing cables? You can also make sure your PC clock is bang on using a NTP server. You can also do PEC too for good measure. I typically do 200-350 points at which point a simple model is about 50 RMS and then press the supermodel button, which adds more terms to the model and gets me to single figures. I’m not obsessive about it as the solve and center in SGP works admirably well within a cycle. My MX is probably about 4 years old now and since I don’t live in a dusty environment, have only cleaned and lubed it once. The good thing about these mounts is that SB have plenty of documentation on setting up the worm etc.

14

I do most of these things: through the mount cabling, NTP server for clock, PEC irrelevant with my absolute encoders. Focuser not an issue because it is already in excellent focus. My Super Model is 22" which is not as good as yours, but does not seem bad.

Do the parameters that affect atmospheric refraction need to be adjusted nightly? I thought they only mattered for creating the model. And maybe I need some maintenance.

15

These parameters affect pointing, more than tracking, as they change slowly. I set them up at the beginning of a session as good practice. It is also less important at high object altitude of course. In a discussion on SB, I recall pressure was quite important.

16

Thanks, I will do some adjusting of those and see if it makes a difference in my pointing.

17

My T point model is only 15 points! Maybe I need to do a much larger run and see how that goes.
I assumed SGP solve and centre would get me to under 50px which would be good enough for me and for several months it was doing so. It is only in the last couple of months that the problem has arisen.