I like the explanation Mike! I had wondered about that ‘sync’ command. Given that the scope will be working on its own model of the sky, a sync is fine as long as the new position is added, as you suggest.
Lawrence
Hi Lawrence,
I am glad you like the explanation. The fact that you can predict the outcome of the next move with good accuracy is to me very convincing.
To me the issue seems to be the speed with which new positional information is propagated from SGP to the mount controller. Unfortunately it seems not to be fast enough to affect the next centre but is there for the one after.
I am not clear whether the SYNC info has to be transferred solely between processes running on my lap-top i.e. SGP and the mount’s ASCOM driver, or whether it must go via USB link to the StarGo control box on the mount. And I guess different mount’s may have different requirements.
Mike
Lawrence,
you gave the mount just one chance to center:
I would suggest to allow at least 4 attempts.
Regards,
Horia
Hello Horia
This is very interesting. The reason that I had reduced the number to1
was because the previous slewing seemed to get nowhere relevant because
I was actually slewing on target. So the errors listed (that I could
not find in the log) are bewildering to me. I have increased the number
to 4 for future attempts but meanwhile I seek the exact reason for the
program to feel a need to slew. 279 - I shall try to find the position
in the log to interpret more closely.
Thank you.
Lawrence
Further to my previous:
Looking at the downloaded image I notice that it is 1590 - 1364 pixels
(= 226 pixels (?) off-centre, so my visual judgement was not correct
and I should have used more slews plus the reticule. Should be easy to
check and fix, assuming that other factors are not involved as well.
again thanks
Lawrence Harris
I have the Linear mount (Synscan version). I notice that the mount does backlash compensation after every slew - though there is nothing enabled in the HC. Does Stargo do the same - and what is more I’m guessing that SGP would check for the mount to stop slewing before starting the next exposure. It would be worth checking whether a stop slewing status is being sent prematurely…also in the telescope tab in SGP, I recall there is a delay feature after slewing…never tried it but it might help.
Hi Buzz,
I don’t think backlash is my issue but in answer to your first question I can say that there is no occurrence of the word ‘backlash’ in the StarGo User Guide and nothing in the application UI for configuring any such compensation. There is only one mention of backlash in the M-Zero User Guide but this is solely to promote Avalon’s view that their Fast Reverse drives are backlash free.
On the Avalon Support web-page where PHD2 configuration is discussed they recommend not to configure backlash. I am compliant with this advice and have to say I am very content with my mount’s guiding performance.
As you correctly say there is a ‘Mount Settling Time’ parameter in SGP Telescope TAB which I currently have set to a low value (20 sec) which is what Avalon recommended. I haven’t noticed badly misshappened stars so think this isn’t an issue. I understand the purpose of this parameter is to allow for vibrations that may be caused by elasticity in the mount drive coupled with the inertia of a heavy rig to dampen down. My OTA and camera are comparatively light so maybe even 20 seconds is overkill.
My current view is that my centering issue is caused by the displacement for the next corrective slew being determined without recognition of the latest mount positionning as communicated by the most recent SYNC. Any idea how long a SYNC action should take to become effective? Anyway I’ve been thinking I should perhaps try setting the SYNC behaviour parameter to ‘None’ or one of the other two available options, but am unclear what results to expect from such a change - haven’t seen any mention in the SGP guides.
Unless there is something in the ASCOM interface standard regarding SYNCing then to my mind corrective action for this issue probably lies with Avalon, perhaps a state flag to indicate that a SYNC update is in progress, but I’ve yet to get a response from them on this issue.
Regards
Mike
I had this - plate solve, and the mount would go off into never never land. I seemed to fix it by clearing the pointing model in ascom.