Fascinating!? From this video, I am also hard pressed to see how this is not an issue in the Gemini firmware itself since the discontinuity clearly occurs in the HC. When I get back home to my scope, I will try to reproduce as well.
(1)? I lost track of your configurations ... did you see this on both the released and beta version of Gemini firmware??
(2)? To echo an earlier question, can you confirm this only occurs during a slew operation, not during normal sidereal tracking?
(3)? Are you only seeing this around the Meridian, which John relayed is likely to have trickier math?
(4)? If so, do you have any sense of how close you have to be to the meridian during a slew to see the anomaly?
(5)? I gather from your last comment that this does not happen everywhere along the meridian?
As you continue to document this, it might be good to note your lat/lon, time-of-day, rough RA/DEC, etc before the slews to see if there is any pattern that might be useful to someone who knows the code. Also allow others to reproduce the issue by resetting their clock and location in the HC to match your documented occurances.
In the meantime, as a work-around in your automation it might be good to set BOTH "Pause Before Meridian" and "Minutes after Meridian" in NINA to a minute or two, based on what you report for question #4 above. Leave "Max Minutes after Meridian" to the larger value based on WSL. Use the spreadsheet to get consistent values for the other parameters. This should ensure that NINA is not pushing the slew buttons or grabbing bogus coordinates during the window around the meridian.?
I would like to hear whether those settings sufficiently "hide" the occurrence of the anomaly.
By the way, I uploaded a newer version of the spreadsheet with some added round-off error checks.
--
Edward
Edward Plumer