Meridian flips SGP vs Mount RA limit settings?

This is related to my “At my wits end post” but started a new thread so it might get noticed :slight_smile:

I am using a Celestron CGX-L mount controlled via ASCOM interface (through the hand controller).

The CGX-L is capable of guiding / tracking up to 20 degrees past meridian. It is configurable on either side of the meridian from +20 before up to -20 after.

My question is if I set SGP’s meridian flip setting to track lets say up to 2 minutes past meridian but the mount is set to track up to say 10 degrees past meridian, which will take precedent?

There are several different scenarios here, but in this case, because the mount allows tracking past the meridian up to 10 minutes, SGPro will track 2 minutes past and perform the flip. This configuration is “ideal” because it ensures that the mount won’t stop tracking prior to SGPro’s flip point. The opposite of this is where a lot of folks find themselves though.

Okay I think I understand. A slight misunderstanding about units. Actually the mount can track up to 20 degrees past meridian or 80 minutes past.

Its 1 degree over 4 minutes right?

So yea since the hardware was configured to stop 5 degrees BEFORE meridian that would equate to roughly 20 minutes before meridian which is about precisely where it failed.

Do I have tha right?

Yes, that seem right to me and this would explain the second problem in your other post, but not the first. That may have to do with sync settings.

Well I think I have this issue whipped.

I had set the mount’s RA limits to 5 degrees past meridian (20 minutes or so), and SGP to 2 minutes past meridian.

Watched as the meridian point was reached and sure enough it performed the flip. However once on the other side it failed to center the target missing by over 1,300 pixels. I waited and it failed by some 1,300 pixels a couple of times.

Frustrated I went out to the hand controller and selected “Disable limits” POOF it centered the target on the second try and continued along all night with some 4 additional targets, including flips and centering without issues.

Even though the RA limits had been set for the mount well beyond those specified in SGP it had issues centering. Evidently ANY RA limit set even if well within bounds causes issues. Not sure why or how but simply just selecting Disable limits seems to have fixed things.

1 Like

Well it is not ‘all fixed’ after all.

Last night the sequence went to start and center a new target. I was watching at the time. It kept failing by the same amount on the RA axis each time, by some 6,000 pixels. It finally went into recovery.

This time I went out to the mount to watch and sure enough the camera was crashing into the pier. SGP would attempt to slew and center the next target ‘bonk’ pier crash.

So I tried an experiment and set both SGP and the mounts RA limits to zero. Now the mount was telling me I was getting into the switch limits and would not move. So I ended up resetting everything and this time it seemed to go fine.

Why the mount chose to start a target with the weight bar way the heck past horizontal on the west side is beyond me. SGP is set to flip at 2 minutes past meridian but I guess that does not affect where to start a new target.

I ‘think’ the problem may lay in my meridian settings. Right now I have Meridian disabled and RA limits disabled. I have attached a screen shot of the CGX manual to help describe.

Any input or suggestions? Maybe set Meridian to ‘favor current’?

Just a brief update on this baffling confusing issue!

It was discovered, for whatever reason, the hand controller kept changing its Meridian preferences to favor west. Even when it was verified and changed to ‘Disabled’ before the start of the sequence. It failed again on the second target with the repetitive RA axis off by some 2,000 pixels over and over. A quick check of the HC and sure enough it was set back to 'Prefer West"! Changed that to disabled and the sequence ran the rest of the night with no issues.

A reset to factory defaults of the hand controller appears to have fixed this as it defaults to disabled.

Of course it will be many days / weeks until I can field test things due to the weather but it seems to have been ‘fixed’.

1 Like