Thanks, Logs attached.
Log_19-18-42 is the one which contains the log fragment that I posted earlier, there are several bad image collections starting at 22:44:04 with a good one at 22:43:30. This has Ekos running on my Windows 10 laptop and indiserver remotely on my rasPi.

Log_21-26-35 has errors at about 23:35, 23:36:57 and 23:37. That's the times I noticed bad images. This is running Ekos on the RasPi. This log seems remarkably uninformative, apart from a vast number of phonon reports, no idea why.

The windows log gives chapter and verse about versions, the RasPi log doesn't, I'm running 3.2.2 at present but not sure if that was the case when the log was collected.

Hope this helps, Chris

OK, at least we could see now what happens:

1. The Align module thinks the slew is completed
2. 122ms later the mount starts to slew
3. The Align module starts capturing
4. ~5sec later the mount finishes the slew.

It's obvious, that this leads to star trails.

OK, let's see whether I can find the problem. At least, we are closer now...

- Wolfgang

I have this issue as well. 10Micron 1000HPS. Using the mount model section, create a list. Sometimes the mount stops and takes a nice solvable photo other times I get star trails and the solver keeps spinning forever. I found that if I press the "pause" button and then the "play" button, it tries again and this time of course the mount is tracking and it solves fine.

Looking at the last post before mine... 5 months ago?

Any luck tracking this down Wolfgang?

I experienced the problem recently as well. Not sure whether there was a fix that is broken again. I will check...

Thank you! It's driving me crazy.

If you see this happening simply press "Stop" in the Align tab. This automatically forces a new capture and a restart of the plate solver.

Stop doesn't work. It quits the whole process. When doing modeling I need it to be automated. What I have had to do is press "pause" instead. This stops the current plate solve and then I press "play" and it does it over again. It's a way around the problem but not worth my effort. I don't mind testing to help developers squash bugs but I don't want to switch over to Raspberry / ekos /indi until things like this are resolved. I honestly need to learn to code. I have so much free time but it seems overwhelming to pick it up at my age.

I think I found the problem: in some situations, slewing is started before a sync succeeded.

When this happens, the Align module takes the IPS_BUSY as an indication that the mount has already started to slew. But this is wrong, since the IPS_BUSY stems from the syncing action that has not completed. After the sync command succeeds, it answers with an IPS_OK and the Align module thinks that the slew is completed - which is wrong. As a result, capturing is started while the mount slews.

I will try a fix...

- Wolfgang

Let me know if you would like to remote to my system and apply the fix and try it. I can give you the teamviewer access. Keep in mind I am in Southern California so -7 (soon to be -

So check los angeles time to make sure it is dark here.

I‘m afraid I was too optimistic. I will build a specific version with increased logging to drill it down.

A difference I've seen between the telescope simulator and the CelestronGPS driver is that in the simulator Sync EqNP.s is set to IPS_OK while in the CelestronGPS driver it isn't touched. Presumably this is done elsewhere, not sure where. Possibly when an updated position is read from the mount.

Ekos seems to assume that Sync will always complete so doesn't check EqNP.s before sending the slew command.

One possible fix is to change the driver so it does as the simulator does and sets EqNP.s to IPS_OK in Sync, however that means that the position hasn't been updated and there may be things that rely on the position being updated. A sync may not always be followed by a slew.

Chris

As far as I understood, the underlying inditelescope.cpp class sends an IPS_OK. The question is whether something creates an IPS_BUSY when the sync is initiated. If yes, then we have a good chance that this creates the problem. But I haven't found out the place were it happens.

I came up with the idea when I saw, that in the Kstars INDI window the status light switches to yellow when the "Set" button has been pushed. It's only a short flicker, but it is visible. But when I run it in the debugger, I haven't seen it happen. This might be the case that it is simply to fast, but maybe the yellow light is only an artefact from the INDI window.

In order to get a better understanding, I created a version with enhanced debug logging. So for all interested, please check out the branch "align_startrails" from my kstars fork: github.com/sterne-jaeger/kstars.git

Cheers
Wolfgang