×

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: 1185
  • Thank you received: 370
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
The following user(s) said Thank You: Alfred, Micheal Fields, Craig
4 years 4 months ago #45183

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

  • Posts: 73
  • Thank you received: 8
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 -8)

So check los angeles time to make sure it is dark here.
Last edit: 4 years 4 months ago by Micheal Fields.
4 years 4 months ago #45211

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

  • Posts: 1185
  • Thank you received: 370
I‘m afraid I was too optimistic. I will build a specific version with increased logging to drill it down.
4 years 4 months ago #45224

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

  • Posts: 554
  • Thank you received: 138
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
4 years 4 months ago #45230

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

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

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

  • Posts: 73
  • Thank you received: 8
Curious of one or both of you have discovered the issue as of yet. I know you released a version with more logging. How do I obtain that so I can help?

Thanks
4 years 4 months ago #45263

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

  • Posts: 1185
  • Thank you received: 370
Here is the explanation how to build KStars from the sources.

The only difference is that you have to pick the sources from my clone and checkout the right branch:
git clone https://github.com/sterne-jaeger/kstars.git
cd kstars
git checkout align_startrails

HTH
Wolfgang
4 years 4 months ago #45271

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

  • Posts: 73
  • Thank you received: 8
Ok, just have to be sure that it doesn't overwrite the changes Jasem made to my QHY driver. Finally have a driver that works and don't want to go back to previous. I'll run those commands and see about getting that going so I can get you logs.

git clone url

Error: inflate: date stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

cd kstars
no such file or directory

This is on Stellarmate for RP4.
Last edit: 4 years 4 months ago by Micheal Fields.
4 years 4 months ago #45272

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

  • Posts: 73
  • Thank you received: 8
Would still like to help by supplying logs. If someone could help me get the above figured out that would be great.

Or perhaps you have some possible fixes to try instead? Again, anyone is welcome to log into my stellarmate over teamviewer from 6PM - 5am PST (los Angeles) and try to patch it up. That was how Jasem solved my QHY driver issue.
4 years 4 months ago #45404

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

  • Posts: 1185
  • Thank you received: 370
Michael, could give it a try. I just sent you a message in the forum.
The following user(s) said Thank You: Micheal Fields
4 years 4 months ago #45407

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

  • Posts: 1119
  • Thank you received: 182
Could this be the same problem I'd been having?

indilib.org/forum/ekos/5950-meridian-fli....html?start=12#45383

I think you solved it, Wolfgang!

I'll supply the logs shortly. Flip worked today without a hitch. Shortening the polling to 100ms was key, I think.

Thanks!

Jo
4 years 4 months ago #45432

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

  • Posts: 1185
  • Thank you received: 370
Good to hear that at least on iOptron the problem is solved. On 10micron not yet, and the situation is even weirder. Here an extract from the log:
[2019-11-06T07:15:12.573 UTC DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "03h 16m 32s" ( 3.27563 ) DE: " 30° 37' 42\"" ( 30.6285 )
[2019-11-06T07:15:12.574 UTC INFO ][     org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (03h 16m 32s) DEC ( 30° 37' 42\")."
...
[2019-11-06T07:15:12.574 UTC DEBG ][           org.kde.kstars.indi] - Process number vector  Eq. Coordinates ( EQUATORIAL_EOD_COORD )@ LX200 10micron  status= 2
[2019-11-06T07:15:12.575 UTC DEBG ][     org.kde.kstars.ekos.align] - Mount slew running.
[2019-11-06T07:15:12.640 UTC DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Tracking"  to  "Slewing"
...
[2019-11-06T07:15:12.738 UTC DEBG ][           org.kde.kstars.indi] - Process number vector  Eq. Coordinates ( EQUATORIAL_EOD_COORD )@ LX200 10micron  status= 1
[2019-11-06T07:15:12.757 UTC DEBG ][     org.kde.kstars.ekos.align] - ## RA "01:03:53" DE "31:54:15" state: Ok slewStarted? true
[2019-11-06T07:15:12.757 UTC DEBG ][     org.kde.kstars.ekos.align] - ## IPS_OK --> Auto Update Position...
[2019-11-06T07:15:12.759 UTC DEBG ][     org.kde.kstars.ekos.align] - Mount slew completed.
[2019-11-06T07:15:12.759 UTC INFO ][     org.kde.kstars.ekos.align] - "Slew complete. Solving Alignment Point. . ."
[2019-11-06T07:15:13.037 UTC INFO ][           org.kde.kstars.indi] - LX200 10micron :  "[INFO] Slewing to RA:  3:16:32.27 - DEC: 30:37:42.60 "
[2019-11-06T07:15:13.039 UTC DEBG ][           org.kde.kstars.indi] - Process number vector  Eq. Coordinates ( EQUATORIAL_EOD_COORD )@ LX200 10micron  status= 2
[2019-11-06T07:15:13.039 UTC DEBG ][     org.kde.kstars.ekos.align] - Mount slew running.
We can observe here the following:
  1. 07:15:12.573: Slew command issued
  2. 07:15:12.574: Status 2=IPS_BUSY detected, mount slewing
  3. 07:15:12.738: Status 1=IPS_OK detected, slew completed, mount tracking
  4. 07:15:13.039: Status 2=IPS_BUSY detected, mount slewing again!!
So (at least with 10micron), there comes an intermediate "tracking" event that is misleading. No clue, why this is happening and what we can do about.
4 years 4 months ago #45489

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

Time to create page: 0.509 seconds