<div dir="auto">Wolfgang, </div><div dir="auto"><br></div><div dir="auto">Sorry I worded that poorly. I agree with you that there is no “wrong direction”. His complaint seems to be that during the RA-out phase, the tracked star goes in some direction, and then when it should turn around for RA-in, instead of reversing, the star continues to move in the same direction as it was moving when going out. You can see that on the plots.</div><div dir="auto"><br></div><div dir="auto">Hy</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 19, 2021 at 12:38 AM Wolfgang Reissenberger <<a href="mailto:sterne-jaeger@openfuture.de">sterne-jaeger@openfuture.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto">I still do not understand what is meant by „RA is going in the wrong direction“. For the guide calibration I thought it doesn’t matter in what direction it is going, since the direction will be inverted anyway and the task of calibration is learning the direction effect a guiding pulse will have.<br><br><div dir="ltr"><div>Do you understand what the problem is?</div><div><br></div><div>Wolfgang</div>--<div><div><span style="background-color:rgba(255,255,255,0)">Wolfgang Reissenberger</span></div><div><span style="background-color:rgba(255,255,255,0)"><a href="http://www.sterne-jaeger.de" target="_blank">www.sterne-jaeger.de</a></span></div></div></div><div dir="ltr"><br><blockquote type="cite">Am 18.09.2021 um 17:46 schrieb Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Jasem: the log spam is my fault, but it's already gone:</div><div><a href="https://invent.kde.org/education/kstars/-/commit/31eaa16abac3cd2d3e0c9986b14f7a6efae15947" target="_blank">https://invent.kde.org/education/kstars/-/commit/31eaa16abac3cd2d3e0c9986b14f7a6efae15947</a><br></div><div><br></div>Wolfgang: do you think this is related? Another post-flip issue. Earlier on the thread he complained about the mount going in the wrong direction post flip<div><a href="https://indilib.org/forum/ekos/9640-guider-calibration-is-wrong-after-meridian-flip.html?start=24#75644" target="_blank">https://indilib.org/forum/ekos/9640-guider-calibration-is-wrong-after-meridian-flip.html?start=24#75644</a><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 18, 2021 at 3:11 AM Wolfgang Reissenberger <<a href="mailto:sterne-jaeger@openfuture.de" target="_blank">sterne-jaeger@openfuture.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div>Folks, I think I have an idea where the problem lies. </div><div><br></div><div>The original target has RA 22:48:14 and the mount obtains a slew command to this position. When the slew completes, it should report exactly the same position.</div><div><br></div><div>The problem is, that it doesn’t! Instead, the slew finished at RA= "02h 48m 14s“. And here the mess starts, a new meridian flip is planned and started although the post-flip activities aren’t completed yet:</div><div><br></div><div><div>[2021-09-17T00:33:51.921 EDT DEBG ][ org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "22h 59m 56s" scope RA= "02h 48m 14s" ha= 8.19508 , meridian diff= 0.13 , hrstoFlip= -8.06508 , flipDelayHrs= 0 , "Pier Side: East (pointing West)“</div><div><br></div><div><b>Conclusion</b>:</div><div>1. We need to check after a meridian flip slew whether the target has been reached. If we are too far off, I think aborting the capture is the right reaction. With a running scheduler, it will recover.</div><div>2. Align needs to listen to the mount about MF announcements and should abort upon MF_STARTED or similar.</div><div><br></div><div>Cheers</div><div>Wolfgang</div><div><br></div><div><br><blockquote type="cite"><div>Am 18.09.2021 um 09:36 schrieb Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank">mutlaqja@ikarustech.com</a>>:</div><br><div><div>I found several interesting things:<br><br>1. Why "Scheduler iteration never set up." is spammed all over the<br>log? what does it mean?<br>2. Meridian flip is odd<br><br>It starts here:<br><br>[2021-09-17T00:31:46.079 EDT INFO ][ org.kde.kstars.ekos.mount] -<br>"Meridian flip slew started..."<br><br>Finishes here:<br><br>[2021-09-17T00:33:45.927 EDT INFO ][ org.kde.kstars.ekos.mount] -<br>"Meridian flip completed OK."<br>[2021-09-17T00:33:45.929 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>Setting meridian flip status to "FLIP_COMPLETED"<br><br>Post-flip alignment starts:<br><br>[2021-09-17T00:33:46.349 EDT INFO ][ org.kde.kstars.ekos.capture] -<br>"Performing post flip re-alignment..."<br><br>Then mount modules re-schedules another meridian flip?<br><br>[2021-09-17T00:33:51.921 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>Meridian flip planned with LST= "22h 59m 56s" scope RA= "02h 48m 14s"<br> ha= 8.19508 , meridian diff= 0.13 , hrstoFlip= -8.06508 ,<br>flipDelayHrs= 0 , "Pier Side: East (pointing West)"<br>[2021-09-17T00:33:51.921 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>Setting meridian flip status to "FLIP_PLANNED"<br><br>Then while alignment is running, another meridian flip is executed!<br><br>[2021-09-17T00:33:52.156 EDT DEBG ][ org.kde.kstars.ekos.capture] -<br>Align State changed from "Complete" to "In Progress"<br>[2021-09-17T00:33:52.203 EDT INFO ][ org.kde.kstars.ekos.align] -<br>"Capturing image..."<br>[2021-09-17T00:33:52.220 EDT DEBG ][ org.kde.kstars.ekos.scheduler] -<br>Align State "In Progress"<br>[2021-09-17T00:33:52.433 EDT DEBG ][ org.kde.kstars.ekos.capture] -<br>setMeridianFlipStage: "MF_READY"<br>[2021-09-17T00:33:52.433 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>Received capture meridianFlipStatusChange "FLIP_ACCEPTED"<br>[2021-09-17T00:33:52.433 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>meridianFlipStatusChanged "FLIP_ACCEPTED"<br>[2021-09-17T00:33:52.435 EDT DEBG ][ org.kde.kstars.ekos.scheduler] -<br>Scheduler iteration never set up.<br>[2021-09-17T00:33:52.923 EDT INFO ][ org.kde.kstars.ekos.mount] -<br>Meridian flip: slewing to RA= "22h 48m 14s" DEC= " 58° 14' 51\"" Hour<br>Angle "00h 00m 47s"<br>[2021-09-17T00:33:52.923 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>Setting meridian flip status to "FLIP_RUNNING"<br>[2021-09-17T00:33:52.924 EDT DEBG ][ org.kde.kstars.ekos.mount] -<br>meridianFlipStatusChanged "FLIP_RUNNING"<br>[2021-09-17T00:33:52.924 EDT INFO ][ org.kde.kstars.ekos.mount] -<br>"Meridian flip started."<br>[2021-09-17T00:33:52.975 EDT DEBG ][ org.kde.kstars.ekos.capture] -<br>meridianFlipStatusChanged: "FLIP_RUNNING"<br><br>So this issue is about executing meridian flip twice in a row.<br><br>--<br>Best Regards,<br>Jasem Mutlaq<br><br>On Sat, Sep 18, 2021 at 2:57 AM Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br><blockquote type="cite"><br>In this forum post<br><a href="https://indilib.org/forum/ekos/10389-ekos-orchestration-a-very-weird-mystery.html" target="_blank">https://indilib.org/forum/ekos/10389-ekos-orchestration-a-very-weird-mystery.html</a><br>The user's log seems to show that guiding was not restarted after the meridian flip, even though the other procedures (slew, align, capture) were restarted after the flip.<br><br>I'd guess that's his main issue.<br><br>Is there some known bug that might cause guiding to not get restarted after a meridian flip?<br><br>There is also some strangeness where 4 hours later the system decides to re-align and does re-start guiding, but I'd guess what's happening is the scheduler job completed at ~5am (it kept capturing even though guiding was never started up again) and perhaps the user had the scheduler job set to repeat multiple times or forever, so the scheduler restarted the job, and then re-aligned properly and re-started guiding.<br><br>Hy<br></blockquote></div></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div></div></blockquote></div></div>