Hi folks,
there is a fix in the latest KStars builds that should hopefully fix this behavior. If you can compile from sources, please checkout the latest version and build it. I think it will make it into V 3.3.9 for all of you who do not compile on your own.
Meanwhile I am quite sure that it is a concurrency issue on mount level. My Avalon shows this behavior and I would not be surprised if there are many mounts out there that behave similar. There are two things that happen in parallel:
- KStars sends a SLEW command to the mount.
- The INDI driver checks the mount status (frequency defined by the polling interval in the driver's options)
If the driver status check happens very fast after the SLEW command has been sent, the mount still reports to be tracking although the slew command is already on it's way inside the mount's firmware.
KStars obtains a BUSY response directly from issuing the SLEW command (meaning that the mount is slewing) and directly afterwards it obtains a "OK" status (meaning that the mount is tracking). The latter one is created by the periodical status check. KStars itself thinks that the slew has finished although it has not started yet. And with the next check it detects that the mount is slewing again, but this was not captured in the old KStars version. That's what causes the star trails.
With the current fix, the alignment recognizes when the mount is slewing during capturing and restarts capturing as soon as the slew has terminated. So you will see the messages about a slew detected, but in all my tests it looks like the restart is working fine.
It would be great if you could test this fix and give some feedback here.
Since I can reproduce the problem with my own mount, I can continue working on it, since the solution is OK, but far from elegant...
Cheers
Wolfgang