Hm, that's strange. My first idea was that there is a timing misfit between mount and controlling computer. But when you see an HA of -01:24, it occurs 01:24 + 0:18 too early.
@others: please be so kind and post your logs and capture files as well. Maybe I can find a common pattern.
Hi Magnus,
there is one thing that I do not understand: does the mount really change the pier side although the meridian flip has been triggered more than 1,5h too early?
So there are two things that need to be explained:
Why does the EKOS trigger a meridian flip although it is obviously too early?
Why does the mount change the pier side although it is too early?
The only explanation for 2. that I currently have is, that the mount reports another RA position than EKOS. The decision, when EKOS triggers a meridian flip is based upon the RA position the mount reports.
Do you remember what RA position was shown on the RA tab? Did this value correspond to the RA position of M51?
And what was shown in the message for the meridian flip when the meridian flip happened? Did it really show -1:24? Or was it the value in the HA field of the mount tab?
Hi!
No, the mount did not flip. No movement at the mount at all. If I got it right, Ekos issues a goto to present coordinates. THe mount is already there, so no movement, none at all, as I recall. If the mount were past the meridian and past the "Goto limit" on the mount, it would have flipped (or tried). So the mount must have thought it was too early for flip, so to speak.
No I don't remember the RA position on the RA tab. But Ekos had slewed to and aligned on M51, and it is really M51 on the subs, so in some sense coordinates were right. And the "icon" on the map, showing the position og the telescope, was right on M51.
And sorry, I don't remember the message during the "flip" more than it started post-flip align. But aren't those messages in the log file?
I'm afraid, I cannot explain it. If date/time is correct and target RA is correct, it should simply not happen. The only explanation that I have is that the capture module emits a "FLIP_ACCEPTED" although there has never been one requested. But to get more clarity, I need a log file generated with the improved logging.
For those being able to build from the sources: my changes to improve the logging is already merged into master.
@Jasem: when will be the new KStars version holding D20975 will be available?