Centering tests with cge-pro

Sequence Generator Plate Solving
1

I did some centering tests with cge-pro to see if the various offset methods work - and the results were somewhat odd and I’m not sure what is happening under the covers. Here are my observations:

First - the original python code I wrote some time ago to use sgp to center on objects works fine. It is very simple code and doesn’t rely on sync - and it centers to within a few arc-seconds in about 3 iterations. So the mount is capable of centering very accurately when using sgp’s infrastructure.

Sync None: This caused a somewhat up and down result that was under 100 pixels in dec., but ra would vary from about 22 to 3600 pixels - up and down.

Target Offset: This went to about 80 in RA and 12 in dec. and stayed there

Scope offset: This was under 20 in dec but ra rapidly increased: 117 104 859 858 7626 7679 7702

There were two additional observations:

If you don’t use one of the “Sync Behaviors” that does a sync, then even when you do a manual “Solve and Sync” - it appears not to tell the mount to sync. Did you intend that? I pictured centering to be able to use sync or not - but when you actually do a manual solve and sync - it should always sync the mount. It looks like the only way to sync the mount is to change the sync behavior to sync - and then do solve and sync.

The second observation is that the hint given to the plate solve is not what it should be. Whether the mount is syncing or not, sgp should always have a good idea of where it is actually pointing. But during the centering process it kept using a hint that was the same value many arc minutes away from the target - even though it was centering on the target. This caused the solves to take a long time.

I know some people have said the solves take a long time - and if they aren’t using sync then this may be the cause.

The math for what I use to center the cge-pro is extremely extremely simple. It just looks at the last error between where it was sent to and where it solved and adjusts the next move based on that. I think there is a chance “scope offset” is almost doing the right thing but there is a sign error making it move away.

So it looks like the new centering methods still aren’t working - but maybe there is a sign error. And I think that solve and sync should always do a sync - and it’s up to the user to know if the mount can handle that or not.

Frank

2

Here is a log from how I am using sgp to center - and it works well. The key things to note are the two different errors: the “encoder miss” and the “solved error”. The encoder miss is how far off the final encoder value is from the encoder destination that was requested. Note that it is very consistent and around 24 arc-seconds.

The other error is the solved error - which is the distance of the latest plate solve from the true target coordinates. It starts at 89" in the first move but immediately drops to 5" in the first iteration - and then down to below 2".

I chose a target destination of RA=10, Dec=-50 so it is easy to see what’s happening. The first move is directly to encoder position 10 -50, but after that the encoder values to move to include both the effective “sync offset” and the “encoder miss” - which are separate things.

Frank

slewing from encoder position 10.000918 -49.998582
To encoder position 10.000000 -50.000000
Slew complete. Landed at encoder position 9.999564 -49.999006 with encoder miss of -23.539515 3.577224 - distance 23.809773 arc-seconds
take exposure
do solve

Try 1 has solved error: ra, dec, dist = -72.926571 51.311670 89.169346 arc-sec
slewing from encoder position 9.999574 -49.999006
To encoder position 10.001350 -50.014253
Slew complete. Landed at encoder position 10.000844 -50.013152 with encoder miss of -27.359863 3.964578 - distance 27.645614 arc-seconds
take exposure
do solve

Try 2 has solved error: ra, dec, dist = -5.244900 -0.504112 5.269070 arc-sec
slewing from encoder position 10.000882 -50.013151
To encoder position 10.001448 -50.014113
Slew complete. Landed at encoder position 10.001014 -50.013965 with encoder miss of -23.423881 0.532694 - distance 23.429937 arc-seconds
take exposure
do solve

Try 3 has solved error: ra, dec, dist = 2.675669 -4.107558 4.902166 arc-sec
slewing from encoder position 10.001008 -50.013965
To encoder position 10.001398 -50.012972
Slew complete. Landed at encoder position 10.000951 -50.012872 with encoder miss of -24.148344 0.361759 - distance 24.151054 arc-seconds
take exposure
do solve

Try 4 has solved error: ra, dec, dist = -3.256507 -0.054454 3.256962 arc-sec
slewing from encoder position 10.000935 -50.012850
To encoder position 10.001458 -50.012957
Slew complete. Landed at encoder position 10.001017 -50.012592 with encoder miss of -23.860108 1.314347 - distance 23.896281 arc-seconds
take exposure
do solve

Try 5 has solved error: ra, dec, dist = -2.200431 0.766479 2.330105 arc-sec
slewing from encoder position 10.000989 -50.012592
To encoder position 10.001499 -50.013170
Slew complete. Landed at encoder position 10.001036 -50.012270 with encoder miss of -24.983327 3.240339 - distance 25.192587 arc-seconds
take exposure
do solve

Try 6 has solved error: ra, dec, dist = -2.185993 1.492532 2.646925 arc-sec
slewing from encoder position 10.001018 -50.012270
To encoder position 10.001540 -50.013585
Slew complete. Landed at encoder position 10.001032 -50.012570 with encoder miss of -27.398401 3.651252 - distance 27.640623 arc-seconds
take exposure
do solve

Try 7 has solved error: ra, dec, dist = -1.789964 0.403453 1.834870 arc-sec
Success with final solved error of 1.834870 arc-seconds
{‘Ra’: 10.0010564986271, ‘Dec’: -50.0125486106164}

3

Here is a link to a log file:

It is a very long file, and the centering tests start around 18:29.

I test a number of different methods - and in between I use my python routine to get it accurately centered at the start.

Frank