During the last few nights I have been having problems with the pointing of my EQ8 mount. The telescope slews to an object and as soon as the telescope arrives to its position, it slews again away to about 20 degrees off in declination. This triggers a blind solve and the procedure starts again with the same result.
The eqmod slew through the keypad work fine at all speeds. Is this a software or cable issue? I have reinstalled SGP over the old one with the same result. Tried a new sequence in case that the sequence file is corrupt but the problem persisted.
What could have gone wrong?
Regards,
Stephen
Link to Logs
Approx time of issue: 06/01/2023 20:55
Useful Info
OS: Microsoft Windows 11 Pro Ver: 4.1.0.869 (32-bit) .NET: 4.8 ASCOM: 6.6.1.3673
I had a similar issue with my AZEQ6 mount. The reason was that the encoder ring was getting dirty, after cleaning it worked fine again. You could test this by disabling the encoders in EQMOD: when the GOTO works well with encoders disabled, it is the encoder ring,
You don’t even need a clear night to test this. If you initiate a Goto with the handcontroller (no telescope and PC attached), you will see different end position with the encoders than without - in case the dirty DEC encoder ring is the root cause.
I had a similar problem. It was because of the pointing data that I had set up in EQMOD. Check you have cleared out any point data and its set to Dialog based. Directions here: Using EQMOD with SGPro
Many thanks to both for your help. Since then, I turned off the AUX encoders on the EQ8 through the keypad. I downloaded the EQMOD version 1.28m and the mount pointed to the right direction. Having solved this problem, another became apparent. Once the telescope goes to the target of the area, it performs a plate solve and platesolve2 issues the amount of pixels to fix on to the target. The voice command is issued that the mount is slewing to target but in actual fact, it fails to do so and remains at near the same original location (the offset number of pixels remains nearly the same). This promts Platesolve2 to a continuous loop that forces plate solve to fail.
The interesting thing is that all slew commands (from 1x to 4x) work well in all directions as well as PHD2. This demonstrates that EQMOD and the mount is working well (gee Thanks Ken). Hence the fault is likely to reside within the SGP framework. I uninstalled SGP and re installed it with the hope that a broken file will be substituted. However my uninstall did not remove all of the files as the reinstalled version contained all of my pervious settings. I has a log file of SGP failing the plate solve but it seems that I cannot upload it from here. Any thoughts on how to fix this issue?
Some drivers will not accept slew commands when it thinks it is already on target. If I recall correctly I believe EQMOD may be one of those. Best way to get us the log is to create an issue from within the help menu of SGP.
It looks like you have SYNC disabled in SGP. Any reason why? We generally only recommend disabling it if your mount doesn’t support it or if you want to use the modeling in your mount for pointing (in which case you’d then only use Slew and not Centering)
For an EQMOD mount we recommend setting it to SYNC and that should alleviate the issue you’re seeing. With SYNC off SGP is basically telling the mount to go to where the mount already things it’s going so it’s basically a no-op.
Many thanks Jared. Although I have looked everywhere, I did not notice that the synch setting (under the telescope settings) was off on the control panel (this was enabled on the Equipment Manager).
Once enabled, the telescope worked just fine last night. Many thanks for your guidance and support.
