I have been using PlateSolve2 for a while without major issues but last night I ran into something I have never experienced before. After solving the frame, PlateSolve2 was not able to move the mount to the precise DSO location. PS2 would solve and then SGP would tell me the mount had slewed, take another test shot (which was identical to the previous) and solve again and again tell me the mount slew, take another test shot without moving the mount by a single pixel.
The mount slew no problem to the area but would not center with SGP/PlateSove2 combo. I could move the mount “manually” through SGP.
I am a bit at a lost as to where the problem could be from.
Thanks for the reply. The sync method was not changed. It happens anywhere the scope is pointing to in the sky.
Centering on the target after PLatesolve 2.29 has done its solving AND “center here” when right clicking on a sub are the only functions that are affected by this odd problem. Everything else works just fine.
sorry, no. I had issues with my PMX, but that was due to earlier versions of SGP flipping back to sync from target offset each time I tried out a beta.
Are you using EQMOD or Chris Rowland’s ASCOM driver? I had an Avalon Linear with the SynScan controller and I never needed EQMOD.
On the basis that I’m assuming this is not a widespread issue and that it is occurred without provocation, I think you are going to have share the log files from SGP.
Here is a log file.
The issue happened early in the night: 18:30ish as I was trying to frame the DSO. I eventually found the DSO by using the “telescope nudge”…
Yes I did verify and everything matches your guidelines. I have used the mounts for months without this issue.
Could something have changed in the SGP parameters ? Is the star catalog specified somewhere in SGP? Could it be something related to that? I have J2000 in EQMOD.
Were my logs useful at all? Jared, did you have a look at them? Anyone else?
Here are screen shots of my settings (shared link below). Is there something wrong with my settings? As I said above, that issue of Platesolve not moving the mount after solving the frame started all of a sudden.
Could any settings have been changed on me ? I checked everything but maybe I missed something…
Don’t know If this will help, but similar issue happened to me.
PS2 worked great always (12 months), except around Polaris.
Then one night, when my scope was slewing to object I accidentally flipped the wrong switch toggling the power to mount/computer instead of the observatory lights.
Anyway, after I rebooted computers,etc. I couldn’t get EQMOD / SGP / PS2 to sync with each other. Solve successfully, but no syncing, no slewing.
There was some disconnect between EQMOD and PS2/SGP. This went on for a week.
I solved it by installing a local Astrometry backup blind solver as described in SGP manual.
I then manually grabbed the OTA/Mount and hand slewed it to a known point in sky. In SGP, Took frame and focus shot. Right/Click BLIND SOLVE HERE. Entered in RA/DEC hints and scale. Presto. It synced. No problems for the last few months now.
No good explanation except a corrupt file somewhere that PS2/SGP couldn’t resolve with EQMOD.
Take an image manually. Right-click the image. Select Plate-Solve. Select Blind Solve.
Make sure your RA/DEC hint is near object.
Would be good to open up the Astrometry Console App to see what results are. Make sure the RA/DEC match. Then try to solve with PS2, using same RA/DEC hints. At that point EQMOD should have synced.
BTW. I had everything connected in SGP when I did this (EQMOD, FilterWheel, Camera, etc).
Just into Blind and/or PS2 hint section. Once it ‘solved’, it finally autosynced with EQMOD, and I was able to do my normal SGP platesolving when running a sequence.
Didn’t have to enter anything directly into EQMOD - but double check those RA/DEC platesolving coordinates with EQMOD, you may have to force it.
And I use StellariumScope to interface with Stellarium/EQMOD. I run this at the same time as SGP. So in my case, there may have been an issue with StellariumScope corrupting somehow since they use the same ASCOM driver.
