Why sync mount for meridian flip?


#1

Continuing the discussion from New TheSkyX ASCOM driver:

I’m moving this to a new topic so we can stay on track in the other thread.

Essentially we don’t trust your mount. So we take an image and plate solve it to get the REAL location that you’re pointed. This could agree with the mount…it could be off by a couple of degrees. Then we use those values to get you back on target. If you feel that your mount has an accurate enough pointing model that it can get get you back where you want then you can disable the “Center” option with regards to the meridian flip and target change.

Hope that helps,
Jared


New TheSkyX ASCOM driver
#2

I think you are being rather over the top here Jared.
You have done a solve and sync before you started imaging, so you know where the scope is pointed.
You are guiding so you can be confident that the scope is still pointing at the same object.
You have trusted the mount to report that it’s moved past the flip position.

Then you do a solve and sync and immediately do a slew to the other side of the meridian, thus ensuring that the sync you did just before the flip is invalidated so you do ANOTHER solve and sync.

I can’t think of anything that is achieved by doing a solve and sync just before doing the pier flip, other than making the entire process more time consuming and unreliable.

Chris


#3

I understand the need to plate solve the target after the flip to confirm the location. it’s the need to plate solve before the flip that I don’t understand.


#4

[quote=“Martyk22, post:3, topic:855, full:true”]
I understand the need to plate solve the target after the flip to confirm the location. it’s the need to plate solve before the flip that I don’t understand.
[/quote] I don’t think there is one. All it does is make the pier flip process more time consuming, more complex and less reliable.

All a pier flip does is a slew to the current position when the mount is in the state where it will prefer to move to the other side of the pier. The trick is determining when the mount is in that state.

For unsophisticated mounts, such as the SB mounts, you can’t tell when this is so you have to guess - and that is usually when it’s well past the meridian. There may be more control available for SB provided imaging applications but it isn’t available through their scripting so for our purposes it isn’t available.

More sophisticated mounts, such as the Celestron GEMs, have a property that can be read to say which side of the pier a slew will end up on - Destination Side Of Pier. The Celestron mounts using the NS and NS+ HCs also have the ability to chose which side of pier to use. This can be used to move the mount to the side of the pier you want independently of the position of the target relative to the meridian - within limits of course. It may be possible to slew to a target position early and avoid having to do a meridian flip at all.

By the way, the problem with sync on Celestron mounts is ONLY for the StarSense and even then only when the sync is done after the meridian has been passed.


#5

Thanks Chris.

Funny, that’s the first time I’ve heard the Celestron mounts referred to as more sophisticated than Paramounts. :smile:


#6

If the sync makes your mount unreliable then you have bigger problems than a meridian flip.

Exactly…but what is that position? Lots of stuff happens between images. There are dithers, you could slew to different targets. You could manually move the mount. This is why we sync before slews when Auto Center is used. It’s not just to get the mount on target…this is also done so that SGP knows where to center to after the flip has happened.

If you don’t want this behavior then the solution is to not use auto center which will cause SGP to only issue a slew. Which is likely what you’re after as you’re essentially saying that the position the mount is reporting is where you want to slew to.

Seems like this should be fixed in the Celestron mount/driver rather than SGP incurring support for improper driver behavior. The goal of ASCOM is that we can treat all of the same devices the same. If we have to start branching code based on what driver we’re connected to then the benefit of ASCOM and interfaces is completely lost. There is no reason that SGP shouldn’t be able to perform a sync at any position and have the hardware behave correctly.

Thanks,
Jared


#7

Jared,

I think that Celestron has acknoleged that it is their issue. They just haven’t fixed it yet.

Is the centering an all or none process. In other words can you just issue a slew command before the flip but have it autocenter after?


#8

Not at the moment. The sync prior to the slew is part of the auto center process. So if auto center is enabled it will perform the initial sync.

So it is all or nothing at the moment.

Yes, I believe you’re correct. I was just illustrating that we don’t have the desire to fix bad driver behavior in SGP. Not just for Celestron, but in general.

Thanks,
Jared


#9

It takes me 50 seconds to know that I am carrying on from exactly the same point (and angle). It works.

There is more than the mount in the equation: It is comforting for those with big floppy mirrors, flexible focusers and for those trying to make the most of their FOV.
It also removes telescope collimation issues (cone angle), even on refractors where the tube rings are offset slightly on the dovetail plate.


#10

I think in most cases it is overkill to solve and sync before flip, however if the mount’s position slightly drift during capturing without solve and sync before flip you might perform a double flip. Something like this:

– Ask the mount for position: Mount reports is time to flip
– Issue and Slew, mount performs a flip.
– Solve and sync, now the mount knows the true position and you target happens to be on the other side of the meridian.
– The SGP center routine will issue an slew and the mount flip again
– You take an image
– Perform the flip again

I know this is a corner case but It might happen. On top of that if your are using a slow mount like the my EM200 you might enter a triple flip condition.

Cheers,

Jose


#11

Wow, I highlighted this statement, hit reply, and it auto-quotes. Very nice. :smile:

When doing the flip, is SGP auto-centering on where the mount is at the moment the flip is initiated (hence the first plate solve) or the target’s defined RA/DEC?


#12

I don’t believe this is actually possible unless there is an issue with your mount’s driver.

It will center on the solved location prior to the flip.

Thanks,
Jared


www.mainsequencesoftware.com