I am constantly observing that 9 out of 10 times, the lowest precision I can set the Align module to is 35", or it'll get stuck in an endless platesolving loop with the mount never getting more precise than about 29~35" when using Capture&slew.
I was wondering what strategies do you use to get a more accurate goto. I need to image a very large target for my fov, where I barely have wiggle room for +-10" coming from dithering, so I'd need my initial centering to be repeatable within 10" over several nights. I can obviously center manually but I was wondering if there are known automated workarounds. For example, I believe I can set a slower slew rate via Celestron's "custom 9 rate", but would that increase the chance of getting a better goto? It sounds like it'd be very nice to have the possibility of having the Align module use pulse guide to achieve final centering, but I know that's beyond the scope of the module. Any suggestions are welcome!
Sorry for the delay. The issue appears intermittent, as previous sessions had the profile explicitly selected and did not crash. Here are the scheduler and sequence files. I did not have file logging enabled unfortunately.
Great to hear that. To answer your question, I thought they would fight because apparently the way the driver level BL comp works is by moving the equivalent of x-steps, where X is the BL level, without returning that as a value in the resulting step position, so that creates a discrepancy between step value and shaft position. E.g. say you are at step 20 and your last move was in. Your BL comp setting is 10. You move in 20, motor moves 20 and final value is 40. Now say you move 20 out. Motor moves 30 out, but your final value is reported at 20. So if the BL is not in the EAF, now You're at a shaft position of 10, with the driver reporting 20. I thought this would throw off BL calculation at the Linear algo level, that's all. Glad to hear that I am wrong!
I'm about to update and I was wondering if there is any experience about this. Logic would seem to suggest that setting backlash compensation at a driver level would fight the internal backlash compensation of the algorithm? Any first hand account?
A quick question now that this is merged into 3.6.0.
Later versions of the EAF INDI driver include a backlash compensation setting at the indi driver level. Should this be disable for this algorithm to work optimally?
According to the user guide:
Profile: Select which equipment profile to utilize when starting Ekos. If Ekos & INDI are already started and online, this selection is ignored.
Tonight I had 2 crashes in a row starting a Scheduler job that had the profile set to my usual profile by name instead of Default. Ekos was already connected and I saw the log window reporting an attempt to connect devices for the profile nevertheless. After that, KStars crashed. This happened twice.
Only setting the profile in the job to Default I could start. Looks like the selection might not be ignored when ekos is already connected?
Do you have a recorded run generated by OpenPecTool that you can share? I wanted to see if I can get the original PecTool to average it, as it seems the main missing thing in the Open port.
Thank you, yes I thought after the fact that using the Fits feature would have effectively prevented an extra align before (because I was there already) but ensured one after the flip. Too late! Oh well, I'll reshoot the second half of the data.
i had my first semi-unattended session driven by the scheduler. The session included a MF, which performed successfully, however there is a pretty large offset in pointing between the subs before and after the flip (about 15 arcmin).
Now, since I had performed the Alignment manually before starting the scheduler, I deselected the Align step in the scheduler. Does that also disable the solver-based realign after a flip?
ooking at the log in Analyze, no Align was performed after the flip.
Thanks for clarifying!
I will try it again soon. I have found a suitable configuration without using that limit for now. As soon as I can test, will post logs!
I am new to the forum and want to thank you all for the great hard work!
I have been configuring my Celestron CGEM with Ekos in KStars 3.5.9 and latest Indilib. Running on Kubuntu 20.04LTS.
Everything perfect except one thing, and I suspect I might be missing something:
I have set my HA limit at 0.67 hours, matching the 10 degrees limit set in RA on the CGEM Hand Controller.
Meridian flip is set at +5 degrees HA, so half that (20 minutes of margin). The Flip triggers correctly and happens succesfully, but after the flip, tracking is not restarted, because of error telescope hour angle is more than the maximum hour angle of 0.67, even though the mount is reporting the correct side of the pier, so this error should not trigger.
Am I missing something?
As a side note, I was curious to ask if there is an option to set the flip behavior to aborting current exposure instead of waiting for it to finish. That would allow me to set a lower gap between limits and Flip.
Thanks for your time!