Center On - Too small improvements

Sequence Generator Plate Solving
1

Hello together,

I have a question regarding the “Center on” functionality on start of a sequence.

First I slew to the target with CdC. I did no star alignment, as I thought SGPro can do the job. But the “Center here” worked not as I have expected. The improvements gets smaller and smaller, but still far away from the target (in my opinion).

I had a sessions with a FSQ85 with 450 mm focal length on a GM2000 mount. I wanted to have the target centered with a max. total error of 50.

The “total error” developed as following:

689, 649, 621, 592, 566, 545, 522, 504, 486, 473, 455, 443, 431, (gave up)

(around 10:09 in log file: https://www.dropbox.com/s/str2bb3ft7dwuf9/sg_logfile_20151219191440.txt?dl=1 )

I do not understand why the total error improves only arround 12 to 20, if the center is still > 400 away.

Do I overestimate the “center on” capabilities, or does anybody know what I am doing wrong?

Thanks a lot for input and best regards

Reinhard

2

Hi Reinhard,

The „center on“ process works like this:

a. Tell the mount to slew to the target coordinates
b. Wait for the slew to end; take a Photo and do a plate solve
c. Compare the Center of the plate solve with the target coordinates
d. If they differ by more than 50pix send a “sync” command to the mount and repeat from a.
Else continue

Basically, this process is extremely accurate.

Now, there are at least two ways for the system to get it wrong:

  1. The mount (i.e. the ASCOM driver) reports “end of slew” too early. For the combination Synscan + EQMOD this happens while the mount is finishing the slew at very low speed. Then, the new plate solve is done on the wrong mount position (you might even get slightly trailed stars).

Fortunately, there is an easy cure for this: just increase the “Mount settling time” – under “Telescope” For my EQMOD setup I have this at 20sec.

  1. The “sync” command has actually two meanings and accordingly two use cases. One is to add the new measured coordinates to the pointing model and the second and completely different one is to synchronize an existing pointing model to the actual sky coordinates the mount is pointing to. This is – IMHO – a mistake in the ASCOM definition, as it should contain two different command names for the two different use cases.

Anyway, most ASCOM-Telescope drivers have a setting about how to interpret the “sync” command. In normal use, it should be set to an option saying something like “do not add syncs to the pointing model”. I do not know how it is implemented for your mount, but I am sure this setting exists.

There is a third possibility of huge flexing in the system (something like a mirror flip during slews) but I would exclude that. From your description, the sync handling is the most probable cause for the poor centering.

Regards,
Horia

1 Like
3

Hi Horia,

thank you very much for advice!

I will check the “Mount Settling Time” and the bevaviour of the sync command. I can remember there are two options available (adding to pointing model/ do not add).

Hopefully I can test it tonight. Currently the clear sky is around 250 km away, moving towards my place :smile:

Best regards

Reinhard

4

This sounds like the problem I have with cge-pro. You can tell if mount settling time is an issue by seeing if the image moves much after the centering procedure. If you take a new image some time after centering completes and the image is still in the same place - it is probably not a settling time issue.

In my case the problem is that the mount doesn’t go and land exactly where it was told to. So no amount of syncing and slewing will help - and after the first one or two images - there is no improvement in the centering.

This would all be solved if the final motion involved small nudges of the mount in the right direction - and I have entered a feature request for this. In my case, I have to set a fairly high minimum requirement for the centering tolerance in order for it to complete - but the resulting error is more than I would like.

You may have a different problem here - but it sounds the same.

Frank

5

Hi Frank,

first: the link to the log file in my initial post was wrong, It is from the same evening, but does not contain the “total error” numbers mentioned in that post. These numbers (689, 649, 621, 592, 566, 545, …) are from a second attempt after a restart of SGPro to center in “Frame and Focus” with “Center Here”.

The log file of my first post contains a"Center On" attempt where the total error developed as following:

443, 384, 343, 309, 284, 264, 247, 235, 225, 214, 206, 201, 195, 196, 191,

As the improvements gets smaller and smaller I gave up after 15 cycles.

I investigated the log file. It seems that SGPro is sending the correct commands. In every step 3 of “Center On”, there are allways the same target coordinates shown.

The settling time in SGPro is set to 0 seconds. I will try my next session with a bigger number here.

Yesterday the weather was too bad to go out for my imaging site, so I couldn’t check the “Sync” settings for the GM2000.

I calculated the absolute and relative development of the total error for two sessions (one with a “Center On” on sequence start and one with “Center Here” from Frame and Focus:

Do you think this is a mechanical issue, or a problem with the driver of the mount? I have not much experience with the GM2000 (it is a mount of our astronomy club), but I thought it is very good one.

Thanks a lot for support!

Reinhard

6

Hi-

In your case, it looks like you are seeing consistent but slow approach to the target. That’s different from what I get because for me it doesn’t get any closer after a few tries. So I can believe your issue may be solved by giving it a settling time - and you should know soon.

For me the problem isn’t really “mechanical.” It’s just that the mount is designed to make the move to the target quickly, but it isn’t designed to go there exactly because it would require a slower and more careful approach. The assumption of the “plate solve/slew” approach is that the mount may have a local error in the coordinates - but it always goes to what it thinks is the correct location. But that isn’t easy to do because it requires accurate timing and so forth. I think the error in my mount is around 1 arc-minute but I’m not sure. It’s not huge, but it is enough to affect framing and oag use.

Frank

7

One thing to try that can be done indoors is to check that a sync causes the mount to report a position that’s the same as the sync position.

Start the mount and do some sort of default alignment so you can connect using the ASCOM driver.
Connect using a planetarium program, I use Cartes du Ceil, and slew to an object. CdC should show that the mount is reporting a position close to the selected object.
Offset the mount position a bit if you need to.
Select the object and do a sync.
You should see that the position reported is the same as the sync position and that a slew to that position also stops at the object. Both within an arc minute or two.
If there’s some sort of systematic error then you need to find out what it is. SGP won’t work properly if a sync to a position followed by a slew doesn’t reach that position.

Chris

8

Hello Frank, hello Chris,

@Chris: unfortunately I couldn’t test it indoors as the mount is placed at the observatory of our astronomy club. But in case a similar error occurs, now I now another thing to test/ to check. Thanks for input!

@Frank: Your advice helped! You saved me a lot of valueable imaging time!
There is a setting in the ASCOM configuration for the GM2000:

My setting was on “Syncs append to refine model”. After switching to “Syncs align model” it worked: the centering was done within 2 steps!

But another precondition must also be met: there must be an alignment model available. First I thought the GM2000 has a sort of a “default model” (so I did not do a start alignment, resp. did not load an existing model). As the “center on” did not work again, I loaded an existing 2 point model and I had success!

Best regards

Reinhard

9

Hi-
Glad you figured it out. That’s actually more like what Chris was asking and isn’t what I was proposing - but it makes perfect sense - and you definitely would not want it to operate the way it was before if you are centering with sgp.

So in the mode you had it before - a sync would not cause it to set the position exactly to the sync position - and instead it would just add a new point to the model - and the model would slightly improve in your area - and that would slightly improve the centering - which is exactly what you saw - and is not what happens for my mount.

If you are bouncing all over the sky and doing syncs then that mode would be good because it would improve the all sky model. But if you are in one part of the sky and you keep adding sync points - I expect that would be bad for the all sky model.

So yes - I think anyone using sgp with your mount would want to know about this setting and make the change you made.

Frank

10

Hi guys,

I too have had the problem in the past of the scope after a "center here’ command getting within a hundred pixels or so, and then getting no closer. My mount is an Skywatcher AZ-EQ6. I have found an ASCOM setting with the choices “append on sync” and “dialogue based”, but I see no “syncs align model” option available. I would like to try this solution. Does anyone know what setting I need and where exactly to find it? Thanks!

Dean

11

Although this problem isn’t the same as mine - it is another case of having to do very mount specific things in order for the slew to land in the right place. I think there would be big benefits in having that sync correction occur in SGP itself - without needing to sync the mount at all. It would fix the problem with my mount - and probably others - that don’t exactly land where they are told to in the first place. And it would avoid altering the mount model of mounts that don’t like that - and it would avoid the issue here of a mount that has different ways to synch and you need to set it properly.

Just let SGP do a slew and a plate solve - to calculate the error in position. Then apply that error to the slew target position and slew again - and repeat. As long as the mount behavior is repeatable (and if it isn’t nothing will work) it should converge for my mount and all mounts - without syncing. Of course - if a user wants to sync that could be an option also.

Frank

12

Hi Dean,

This sounds like EQMOD. The setting “dialog based” is the equivalent of “sync aligns model” and should be used in this case. Check also the mount settling time setting, as your mount might need it.

Regards,
Horia

13

Hi Frank,

If the mount has pointing errors, it feels natural to me to try to align the “local” pointing model (even an empty model is a pointing model: the model of a supposedly perfect mount). Telling the mount to point somewhere else to get it to the target is bad. You do not want to fool the mount.

A small model - like 6 point on each side of the meridian - would produce a real improvement of the pointing accuracy in most of the cases.

Regards,
Horia

14

A normal sync is just applying an offset in the mount - so syncing this way with sgp is no different - except it is sgp that holds the small error. And I think some mounts are not intended to use sync the way it is used here - so it is actually “bad” for them to be sync’d like this. But regardless - for my mount and I think others - the sync approach just won’t converge to an accurate solution - whereas I think the approach I describe would work - and would avoid centering by nudging - which should also work, but was removed as a feature request.

And if you do have a multi-point model and you keep applying syncs in one part of the sky and adding them to the model - it would converge slowly and it wouldn’t be a good model.

Frank

15

Excellent…thanks Horia! And yes that was EQMOD. :slight_smile: I look forward to seeing if this solves the problem, which fortunately has been happening less frequently lately. And I did increase my settling time too.

Dean