Plate solve and GoTo

[DirtyRod]

Hello,

I’ve been trying to add a platesolve and GoTo to my script so I can do a meridian flip. I’m using CPWI and All Sky Plate Solver with several Celestron mounts and cameras and I’ve configured Sharpcap to get the location from CPWI.

I can successfully solve for the image both in Sharpcap and using ASPA and, when I click the Plate Solve button in Sharpcap, the image syncs and re-centers. If I press the button or issue the Platesolve and GoTo command in the sequencer when the target is past the meridian I assumed it would perform a meridian flip and recenter the target but it does not. Even if the target is way past the meridian it does not flip whereas if I had done a GoTo in CPWI it does flip. No matter how far past the meridian the target is it just recenters.

What is interesting is that after I use the button or issue the platesolve command in the sequencer, CWPI will no longer do a meridian flip either. It acts like the mount and/or CPWI no longer knows where it is. When I tell the mount to go home or any coordinates it goes off in some random direction where everything was working fine before issuing the command.

Looking for suggestions on what I misconfigured.

[admin]

Hi,

I wonder if it is the 'sync' past the meridian that is messing things up? I would have assumed, like you, that sending a Slew command to the mount for co-ordinates on the other side of the meridian would cause it to do a flip. I have a horrible feeling that this is going to be one of those things where the behaviour of the system is going to depend on the choices made by the developers of the ASCOM driver, so that different hardware may have different behaviour...

One thing to try would be to perform a straight Slew to the target co-ordinates after crossing the meridian. If that doesn't work, try a slew to back across the meridian to the east side and then back to the target. If you can get it to go to the target on the west side then you can do a plate solve/sync there, which will be much more effective than performing the solve on the 'wrong' side of the meridian followed by a long goto movement anyway.

cheers,

Robin

[DirtyRod]

Robin,

I can try that tonight or tomorrow and see how that works. Unfortunately, that kind of defeats the purpose of what I was trying to do.

When I first slew to a target, I generally have to move the scope to get the correct framing. That means if I perform a GoTo for the meridian flip the target will most likely not be centered the way it was before the flip. Doing a platesolve prior to the flip was my way of ensuring the target was properly framed after the flip.

Any ideas on the confused mount situation after the platesolve? After I issue any platesolve command no GoTo's are accurate. Last night I was testing and told the mount to go Home and had to run for the power button before the camera and scope hit the legs. To get the mount to slew correctly after a platesolve I always have to power cycle the mount and do a new alignment.

[admin]

Hi,

the problem with plate solving before the flip is that there is a very large slew that should happen to move the mount round to the other side of the pier. Any inaccuracies in the mount, polar alignment or any cone error will mean that the place that you end up will not be where you expect. Ideally you would plate solve before, store the co-ordinates, flip, plate solve again and then return to the stored co-ordinates, but I don't think that is possible with the sequencer just yet.

It does sound like your ASCOM driver is reacting badly to being sent the 'Sync' command after plate solving. You can look in the ASCOM driver settings for anything related to sync or pointing models and see if changing that helps. You could also try changing the action that SharpCap takes from 'sync and recenter' to 'offset goto' in the plate solving settings.

cheers,

Robin

[DirtyRod]

Thanks. I will look and see what I can find in ASCOM. I'm using CPWI so I don't know that there are many settings related to this that I can change.

I did do some Go-To commands from Sharpcap before the plate solve and they worked just fine. I then issued a platesolve commend and tried the same GoTo and the mount went haywire so I assume it's like you said and the Sync blows something up.

I guess I will keep staying up and manually flipping until I figure something out.

Thanks.

[admin]

Hi,

hope that you find a solution for the sync problem as it is otherwise tricky to get useful results from plate solving.

I made some additions to the sequencer yesterday based on your experiences - two new steps that can save the current co-ordinates during a sequence (one saves from the mount directly, the other from plate solving) and a new step to GOTO the saved co-ordinates. I think those should help with the meridian flip sequencing. I will also try to add a step that forces a flip if I can work out how.

cheers,

Robin

[DirtyRod]

That is fantastic. The flip is the last thing I need to automate so definitely looking forward to trying this out.

[admin]

Hi,

just to give an update - with this week's update (due tomorrow) there will be a new step that will perform the physical meridian flip of the mount, along with the steps mentioned above to save/restore position. I will then be thinking about a more complex sequencer step that will do all the necessary processing for the whole flip procedure (stop/restart guiding, plate solve after flip, etc).

cheers,

Robin

[lowenthalm]

Solutions to described problems below...

I just came across this post, very late to the party. I thought it was worth posting to in case others came across this same post having the same problem. I had very similar problems with my CGX mount and CPWI. Sorry about the excruciating detail, but I experienced several months of blood sweat and tears solving this collection of problems and want to share the knowledge so others might avoid some pain.

CPWI has mount settings that allow you to specify how far past the meridian the mount will track before halting tracking. The mount has a hard limit (the manual says it's 20 degrees) that it won't go beyond, but you can specify any amount less than this, or 0 in the CPWI software. This settings is called "RA Slew Limit" found in CPWI->Telescope->Configure Mount as in degrees mount degrees, presumably.

Originally, I set "RA Slew Limit" to a negative value to allow my camera to finish its current exposure as the mount tracked past the meridian. A positive value would make it stop before the meridian is reached. It really should be called "tracking limit", no? Every time I looked at it, the value seemed to have change from what I had originally set it to. No explanation in the manual, of course. Probably related to the current declination when the settings is changed, but I never tried to figure it out as there were bigger issues. The gigantic problem was that if I allowed the mount to track past the meridian any significant amount, there was a non-zero chance it would "get turned upside down" and not reliably slew to coordinates. The odds were even higher if I hit the RA limit. I found it couldn't even go to home properly - the mount would start pointing the telescope at the ground, and I had to smash the stop mount button! I changed my go home code to go near the home position using azimuth and altitude to avoid any possibility of this occurring during automated operations. I also stopped allowing the mount to track past the meridian more than a minute or two in HA. This eliminated all of the problems described above.

A related setting, again found in CPWI->Telescope->Configure Mount is called "Meridian Sweep". This setting affects slewing rather than tracking (but of course is called sweep, since the phrase slew limit was already taken). When set to non-zero, slew commands will NOT cause the mount to flip to the opposite pier side if the target coordinates are closer than the Meridian Sweep value to the meridian. One might imagine this might be useful if you want to start imaging a target that is within a few degrees of passing the meridian: you go to somewhere on the west side of the pier, you issue the slew to target command, the mount slews to the target, but stays on the west side of the pier, and you start imaging! No waiting for it to pass meridian before starting. What a time saver! Sound possibly useful, but in practice, you get the behavior you describe - it doesn't do a meridian flip with a slew when you want to do one!

Due to this, I eventually set "Meridian Sweep" to 0 to avoid all the headaches it caused me. Before Robin implemented "MOUNT FLIP" in the sequencer (which is still marked Experimental - is it still experimental?), I implemented sequencer code to perform a meridian flip pretty accurately. I implemented it in this odd way so I didn't run afoul of meridian sweep, no matter what it was set to:

Code: Select all

   DEF SUB Meridian_PerformFlip
            UNLOCK CONTROLS
                MOUNT OFFSET 1 0
                MOUNT OFFSET -2 0
                MOUNT OFFSET 1 0
                MOUNT SOLVEANDSYNC
            END UNLOCK
    END SUB

So first, it backs the mount off to the east by one hour in RA. Then it slews the mount west two hours in RA, which causes the meridian flip to occur, no matter what "Meridian Sweep" is set to. Then it slews the mount back to the east by one houre in RA to return to the original target coordinates. Finally, a plate solve and sync will get you exactly on target.

By the way, make sure you are using a version of CPWI later than mid-2024. Using versions before that, solving and syncing the mount will disable PEC playback, care of a bug in the CPWI ASCOM driver.

[admin]

Hi,

thanks for sharing - useful to have that sort of information as the behaviour of mounts around the meridian flip/meridian tracking seems to be highly variable (for instance EQMOD sulks if it tracks to the limit and needs you to use the MoveAxis commands to bring it back before it will accept slew instructions).

cheers,

Robin