×

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: 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.

  • Posts: 1185
  • Thank you received: 370
OK, at least we could see now what happens:
[2019-04-21T22:44:04.710  ][     org.kde.kstars.ekos.align] - "Slew complete. Target accuracy is not met, running solver again..."
[2019-04-21T22:44:04.822  ][           org.kde.kstars.indi] - Celestron GPS :  "[INFO] Slewing to JNOW RA 11:21:13 - DEC 12:53:15 "
[2019-04-21T22:44:06.233  ][     org.kde.kstars.ekos.align] - "Capturing image..."
[2019-04-21T22:44:06.354  ][           org.kde.kstars.indi] - Astrometry :  "[INFO] Astrometry solver is enabled. "
[2019-04-21T22:44:06.406  ][           org.kde.kstars.indi] - Atik 383L :  "[INFO] Taking a 5 seconds frame... "
[2019-04-21T22:44:12.242  ][           org.kde.kstars.indi] - Celestron GPS :  "[INFO] Slew complete, tracking..
  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
4 years 10 months ago #39237

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

  • Posts: 73
  • Thank you received: 8
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?
Last edit: 4 years 4 months ago by Micheal Fields.
4 years 4 months ago #45154

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

  • Posts: 1185
  • Thank you received: 370
I experienced the problem recently as well. Not sure whether there was a fix that is broken again. I will check...
4 years 4 months ago #45156

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

  • Posts: 73
  • Thank you received: 8
Thank you! It's driving me crazy.
4 years 4 months ago #45171

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

  • Posts: 1185
  • Thank you received: 370
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.
4 years 4 months ago #45173

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

  • Posts: 73
  • Thank you received: 8
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.
4 years 4 months ago #45178

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

Time to create page: 0.739 seconds