I changed the telescope behavior to sync.Still does the same. Centers quite well in dec., but keeps slewing too much in RA and never gets closer than 175 pixels. Here’s the log. Thanks.
Link to Logs
Useful Info
OS: Microsoft Windows 10 Pro Ver: 3.1.0.415 .NET: 4.8
Your mount is still failing to converge and there is no error when syncing. This means that the mount is applying its own model to sync requests. You will need to look into how your mount interprets requests to sync or if it is indeed trying to build its own model for every sync (this is a bad idea for a portable setup).
It’s permanently mounted in an observatory. The Celestron Planewave software runs the mount and uses a pointing model. I guess what you are saying is “ask Celestron.” The same setup did platesolve and center fine, before installing the updated SGP, and going from Windows 7 to Windows 10. Have there been similar problems with the CPWI software and SGP?
No, but, in general, there are always problems when the mount keeps its own model. It tends to fight with the level of control that SGPro wants to have.
I’ve started to get the same problem since upgrading to the latest version of sgpro. Everything has been working perfectly then I upgraded to the latest version and platesolve fails but mine is in Dec. I’m using Paramount MYT and SkyX as the driver. In case it was a corrupted ascom driver , I’ve reinstalled it. But I’m unable to test if the problem is solved as I’ve not had a clear night. I’m very frustrated
Looks like there might be a problem with the latest version of sgpro
What do you mean by “latest version”? 3.1, in general, or a specific version of 3.1.
Also… @MarkW@dsol fwiw… please install and try the version released last night (3.1.0.422). There is a bug fix for auto center in there and I’m not sure if it’s related to what you are seeing or not.
Hi Ken, it was about a fortnight ago now . Sgpro said a new version is available. So I installed it but that night it would not centre on platesolve. I had been away after that so today was my first time to do anything. So all I’ve done is reinstalled the ascom driver for my paramount Myt. I don’t know if it’s worked because I’ve not had a clear night to test. I’m not at my observatory so can’t check the software version. I’m assuming this post is recent hence why I answered on it pal
I have a MyT w/ SkyX as the driver. I haven’t had the problem you mention. Just imaged last night w/ 3.1.0.422 w/ Sync Behavior set to Target Offset and Inhibit Sync to protect TPoint model checked in the Sky driver setup. Did a handful of Slew then Center w/ plate solves and all worked.
I have had this problem with SGP and the latest version of CPWI (2.2.3). The Synch mode for plate solving failed to converge. When I reinstalled the previous version of CPWI, plate solving worked. Derik, Celestron firmware engineer, told me that the older version of CPWI did not correctly perform the slewing steps when issued a GoTo command via ASCOM. I noticed it made a short move when SGP’s plate solver commanded it to move to a new RA/DEC. However, plate solving always converged in 3 to 5 iterations. With the latest version of CPWI, every SGP command to move resulted in CPWI moving away from the position, then doing a slow, final approach to the new coordinates. When in Synch mode, SGP plate solving did not converge. Derik told me that there is an inherent error in slewing to a position, so every plate solve move results in the same error range at the new position. That is, it is not Celestron’s problem. Ken told me to try using one of the offset modes for plate solving. I have not had good weather to try it with the latest versions of SGP and CPWI.
I had suggested to Ken to perhaps implement a mount nudge (N,S,E or W) when the plate solve error is relatively small, say 500 pixels. Note I have set the convergence error to < 15 pixels with 5 iterations.
I’m thinking with the CGEM II and a convergence error of <15 pixels is much to tight for your mount, depending of your image scale. I currently use both the CGE-Pro, Image scale of .50" as well as the CGEM-DX , image scale of .75". I set the Scope Centering error to 75 pixels. Typically after 2 to 5 iterations it centers and usually is around 60 pixels. I found anything below 35 pixels and the plate solve will never converge. These mid range mounts just can’t perform to the accuracy you’re expecting. I think if you increase your Scope Centering Error you should find it will center. Also centering errors are different depending on the part of the sky you’re pointing. You might want to experiment by trying high Scope Centering Error to start with, say 100 pixels, and do several Plate Solves at that same location and record the centering error. Move to another part of the sky and repeat. By doing so, you might find what your mount/image scale is capable of. Just my suggestion.
Thanks for your help info. Yes, the CGEM is quite lacking in many respects. I am now completing a Hypertune and the RA is much better and I am finishing adjustment.
I do have the convergence value too low, but it was working with the first release of CPWI. I’ll test larger values when the sky clears.
I used CGE-Pro with the normal ascom driver and now CGX-L with the latest CPWI beta - and both setups allow centering to under 5" without relying on sync at all - using my own code. As Derik described there is landing error in a GoTo slew, which means the SGP process of slew/solve/sync - slew/solve/sync will never converge. This happens with other mounts also. The mount is quite capable of accurate centering because the landing error is repeatable.
There is no need to rely on sync when centering on a target. Just slew, plate solve, calculate the offset, slew again - and repeat. Doing it that way includes the contribution of the landing error and allows rapid convergence on the target without bothering the mount model at all. If you like, you can go ahead and sync when you are finally centered.
I thought that one of the centering modes for SGP was syncless and allowed this method for centering - but it never worked for me when I tested it. The procedure does work quite well when implemented properly - as evidenced by my results with CGE-Pro and CGX-L.