×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Alignment starts before mount is finished slewing

  • Posts: 86
  • Thank you received: 9
You're correct but when ekos "thinks" the mount has stopped and is tracking, it actually has not stopped and is still flipping or slewing and the settle time of 3000 isn't enough time for the slew or flip, perhaps I can work around it by adding even more settle time (the time is takes to flip). It'll just make the flip longer but at least it may actually work.
4 years 10 months ago #39101

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I think I've seen this as well with a Celestron mount running the CelestronGPS driver. What I see is an image with streaked stars. I'll keep an eye open for it and see if I can get logs.
The way that it seems to be happening with several different mount drivers seems to indicate that it's happening at a different level than the driver, at least the device specific part of the driver.

Hiding the problem with a delay is really only putting a sticking plaster on the problem, it doesn't solve it.

First thing is to find out if this is happening at the start or end of the slew.

Chris
The following user(s) said Thank You: Craig
4 years 10 months ago #39106

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I had two or three occurences of this last night but there's nothing in the logs that give any indication of what happened. All I see are 'mount status changed from 3 to 2' which I think is when a slew starts and 'mount status changed from 2 to 3' when it finishes. No other messages apart from vast numbers of phonon errors. There seems to be more in the display but it looks as if info messages aren't logged to a file, just to the screen.
If I turn logging on in the telescope and CCD I get messages from them but still nothing from the alignment.

Or is there a way to get more of the messages to the log that I've missed? I'm enabling logging to file in the EKOS log setup for EKOS and drivers. I can see mount movement messages and CCD messages but nothing to report the alignment progress even though this is checked in the Ekos setup.
4 years 10 months ago #39152

Please Log in or Create an account to join the conversation.

  • Posts: 86
  • Thank you received: 9
I'm not sure. I tried to re-create this issue yesterday to log it but of course, it didn't do it!! I always thought Verbose with the part you wanted logged check should always write every bit of activity to a file.
The following user(s) said Thank You: Craig
4 years 10 months ago #39157

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I've found a log that shows the problem. This was running KStars on a Windows machine and INDI running remotely.
Here's a log fragment:The sequence starting 22:43:30 shows the expected behaviour, sync, sync complete, slew, slew complete, capture image,capture complete, solve, solve complete.
The sequence starting at 22:44:04 shows the sync and the start of the slew but then the image capture starts and the slew complete message only shows up after that.
The solve seems OK but that's probably because there is sufficient image data after the slew has ben completed.

This looks as if ekos is being a bit impatient, it should at least wait until after it has sent a successful slew command to indi.

Chris
4 years 10 months ago #39159

Please Log in or Create an account to join the conversation.

  • Posts: 86
  • Thank you received: 9
Interesting. I know it doesn't show in the log but do you know if your mount switches the tracking from "ON" to "OFF" and then "ON" to "OFF" a second time when you slew? I see this happen in my case in the mount control tab.
4 years 10 months ago #39162

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I didn't look. The tracking indicator in the mount control tab seems a bit fragile, quite often I've seen it indicate off when tracking is on.
wonder if there's a way to trigger this process using simulators, maybe by applying an offset to the slew target position so the mount will always report a different position.
4 years 10 months ago #39165

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I've done some more digging and I don't see a way that this can be happening in the driver, at least not in the device specific part and I don't see anything obvious in the base inditelescope part either.

The slew and tracking state change in the driver uses an enumeration - TrackState - that is defined in inditelescope.h. Goto() sets this to SCOPE_SLEWING, then ReadScopeStatus uses this to poll the mount to see if the slew has finished and if it has sets TrackState to SCOPE_TRACKING. That's it and the log messages show that this is working. There are no transient changes.

inditelescope has a switch property CoordS(P) which seems to be analogous to TrackState and I guess is what is used for communicating the state between the client and indi. However I can't see anywhere where changes in TrackState get passed into CoordS(P). The only mention is in inditelescope ISNewSwitch where IUUpdateSwitch and IDSetSwitch are called.

I may have found the problem; in inditelescope in ISNewNumber the number called "EQUATORIAL_EOD_COORD" is found, this is EqNP. The Ra and Dec are extracted and CoordSP is checked, if it is "SYNC" then the driver Sync function is called, otherwise the driver Goto function is called.

No change is made to the CoordSP state in inditelescope but somehow after each of these CoordNP is set to the default "TRACKING" state, this seems to be done after a short delay for sync and after the slew has completed for slew. I guess that CoordNP is used by ekos to determine if a slew has completed.

When things are working well ekos sets CoordSP to "SYNC" then sets the coordinates in EqNP . This causes the sync to be done and CoordSP is set back to "TRACKING". Then ekos sets CoordSP to "SLEW" then the slew destination in EqNP. This cause the slew to be done and CoordSP is set to "TRACKING" when it completes.

When it goes wrong ekos sends the sync command but before the response to the sync command has been returned it sends the slew command. When the sync response is received it sets CoordSP to "TRACKING". ekos sees this and thinks it means that the slew has finished but what it means is that the sync has finished. The slew is still in progress. This accounts for seeing the state in the telescope tab change momentarily.

It looks as if ekos should wait until it gets the signal that the sync has completed before sending the slew command.

Hope this helps.

Chris
4 years 10 months ago #39175

Please Log in or Create an account to join the conversation.

  • Posts: 86
  • Thank you received: 9
Very interesting Chris. A lot of this is above my head though. What exactly is inditelescope? Is it the way Ekos reads the mount?
4 years 10 months ago #39180

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
Developer speak. inditelescope.cpp and inditelescope.h are the source code files that provides much of the basic functionality of the telescope driver. Ekos will use these to control the telescope.
4 years 10 months ago #39181

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Hi Chris,
I experience the same problem form time to time, but not too often. Please be so kind and post the entire log file. Maybe I can drill the problem down.

-Wolfgang
4 years 10 months ago #39228

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138

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

File Attachment:

File Name: log_19-18-42.txt
File Size:307 KB

File Attachment:

File Name: log_21-26-35.txt
File Size:1,280 KB
4 years 10 months ago #39234
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 1.361 seconds